Odd problem: Guaranteed Oops on my "pathological file system" (a monster ext2)
System: Athlon tbird 1100 MHz
GA 79X motherboard (with the notorious VIA kt133 chipset)
this problem with a very minimal 2.4.2 install except with
Pavlich's v4.3 via82cxxx.c driver (same problem with 2.4.2
stock driver), also same problems problems also seen with
RedHat's rawhide 2.4.2-0.1.25 (and 0.1.19)
I had corruption problems before, slowly knocked away by upgrading
mb bios to current and using less aggressive disk parameters. Now
running:
/dev/hda: (and hdb and hde, my 3 drives)
multcount = 0 (off)
I/O support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 7473/255/63, sectors = 120064896, start = 0
(and I just reproduced the oops even with DMA entirely off on these three
drives).
My "pathological file system" is a three physical partition lvm volume,
nonstriped, just a simple concretion, containing an e2fs 180G volume.
But some of the directories have many thousands of files (ugh) of
considerable length (40-60 characters, in many cases).
Just doing a "du -s *" in the top level will create the oops, quite
reliably. Sometimes fscking the system after a reboot will oops it also.
It's a new system and has been a royal pain in the three days I've had it.
More problems with the vaunted VIA chips? (the AmiBios isn't terribly
configurable but I've got all the parameters set at their conservative
end -- this is for a spacecraft data server in our lab here, and I'd
sort of like the thing to be stable -- not an auspicious beginning so far.
Cheers, Don Barry,
SIRTF/IRS Science Team,
Cornell Astronomy
(please cc to don@astro.cornell.edu any messages to the list)
----ksymoops follows
ksymoops 2.3.4 on i686 2.4.2. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.2/ (default)
-m /usr/src/linux/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Warning (compare_maps): ksyms_base symbol __blk_get_queue_R__ver___blk_get_queue not found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol blk_cleanup_queue_R__ver_blk_cleanup_queue not found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol blk_get_queue_R__ver_blk_get_queue not found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol blk_init_queue_R__ver_blk_init_queue not found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol blk_queue_headactive_R__ver_blk_queue_headactive not found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol blk_queue_make_request_R__ver_blk_queue_make_request not found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol blk_queue_pluggable_R__ver_blk_queue_pluggable not found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol blkdev_release_request_R__ver_blkdev_release_request not found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol end_that_request_first_R__ver_end_that_request_first not found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol end_that_request_last_R__ver_end_that_request_last not found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol generic_make_request_R__ver_generic_make_request not found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol generic_unplug_device_R__ver_generic_unplug_device not found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol io_request_lock_R__ver_io_request_lock not found in System.map. Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol queued_sectors_R__ver_queued_sectors not found in System.map. Ignoring ksyms_base entry
Unable to handle kernel paging request at virtual address 003dde2f
c014196b
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c014196b>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010207
eax: cffd9188 ebx: 003dde0f ecx: 0000000e edx: 006d0225
esi: 003dde0f edi: 00000000 ebp: cffd9188 esp: ce419eb8
ds: 0018 es: 0018 ss: 0018
Process du (pid: 902, stackpage=ce419000)
Stack: 006d0225 00000000 006d0225 ce885c00 c0141d87 ce885c00 006d0225 cffd9188
00000000 00000000 006d0225 c7024340 c70b6300 c70b635c cffd9188 c01506cb
ce885c00 006d0225 00000000 00000000 fffffff4 c7024340 c70b6300 c70af5c8
Call Trace: [<c0141d87>] [<c01506cb>] [<c01385d3>] [<c0138d57>] [<c013833b>] [<c013938c>] [<c0136236>]
[<c012dfd3>] [<c0108f47>]
Code: 39 53 20 75 24 8b 54 24 14 39 93 8c 00 00 00 75 18 85 ff 74
>>EIP; c014196b <find_inode+1b/60> <=====
Trace; c0141d87 <iget4+47/e0>
Trace; c01506cb <ext2_lookup+5b/90>
Trace; c01385d3 <real_lookup+53/c0>
Trace; c0138d57 <path_walk+5b7/820>
Trace; c013833b <getname+5b/a0>
Trace; c013938c <__user_walk+3c/60>
Trace; c0136236 <sys_lstat64+16/70>
Trace; c012dfd3 <sys_close+43/60>
Trace; c0108f47 <system_call+33/38>
Code; c014196b <find_inode+1b/60>
00000000 <_EIP>:
Code; c014196b <find_inode+1b/60> <=====
0: 39 53 20 cmp %edx,0x20(%ebx) <=====
Code; c014196e <find_inode+1e/60>
3: 75 24 jne 29 <_EIP+0x29> c0141994 <find_inode+44/60>
Code; c0141970 <find_inode+20/60>
5: 8b 54 24 14 mov 0x14(%esp,1),%edx
Code; c0141974 <find_inode+24/60>
9: 39 93 8c 00 00 00 cmp %edx,0x8c(%ebx)
Code; c014197a <find_inode+2a/60>
f: 75 18 jne 29 <_EIP+0x29> c0141994 <find_inode+44/60>
Code; c014197c <find_inode+2c/60>
11: 85 ff test %edi,%edi
Code; c014197e <find_inode+2e/60>
13: 74 00 je 15 <_EIP+0x15> c0141980 <find_inode+30/60>
15 warnings issued. Results may not be reliable.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 15 2001 - 21:00:13 EST