Hello,
I have the same problem as reported a month ago on this list:
I repeatedly have kernel oops caused by msec_find (a trace follows)
I use a Mandrake 8.2 (2.4.18-6mdk kernel) on a Celeron+VIA Apollo 133 PC.
I have a NCR 53c810 PCI SCSI adapter, to which
2 hard drives and an Iomega ZIP 100 are connected.
When the kernel oops has occured, only the devices
attached to the SCSI chain are frozen:
- the processes trying to access IDE/ATA devices still work fine.
(1 hard drive, 1 CDROM, plus 1 CD writer using IDE-SCSI emulation)
- the processes trying to access the ZIP or one of the
SCSI drives are blocked during a system call (impossible
to kill them)
I have tried to disable supermount, but it did not seem to
solve the problem. However, removing the ZIP drive from the SCSI chain
seems to solve it... it's not a pleasant solution though !
I did not have this kind of problem with the Mandrake 8.1 kernel or
the standard 2.4.8 kernel.
From what I can read on the 2.4.18 changelog there has been some work
concerning removable devices:
pre9:
[...]
- Really add devfs fix for removable devices:
its on pre8 changelog but not on pre8 patch(me)
Does anyone know more about this problem ?
Does the 2.4.18-6mdk kernel include this fix ?
Thanks for your help,
Dominique
Unable to handle kernel paging request at virtual address 204f2f8d
c0160783
*pde =
Oops:
CPU:0
EIP:0010:[c0160783]Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: ccdad920 ebx: 204f2f49 ecx: edx: ccdad920
esi: c6126040 edi: cfe828e0 ebp: c4bb1940 esp: cd58df28
ds: 0018 es: 0018 ss: 0018
Process msec_find (pid: 4955, stackpage=cd58d000)
Stack: c6126040 c0160c16 cfe828e0 c0265a40 c6126040 c61260c0
c61260ac
c4bb1940 c0141690 c4bb1940 cd58dfa0 c0141b90 c4bb1940 fff7
000d
bfffece8 c0141d3f c4bb1940 c0141b90 cd58dfa0 cc0c0360 c01338f7
cc0c0360
Call Trace: [c0160c16] [c0141690] [c0141b90] [c0141d3f]
[c0141b90]
[c01338f7] [c0106f23]
Code: 66 8b 43 44 25 00 f0 00 00 66 3d 00 60 75 0d f6 43 10 04 74
EIP; c0160783 devfs_unregister_blkdev+193/18c0 =
eax; ccdad920 ___strtok+cab1510/12519c50
ebx; 204f2f49 Before first symbol
edx; ccdad920 ___strtok+cab1510/12519c50
esi; c6126040 ___strtok+5e29c30/12519c50
edi; cfe828e0 ___strtok+fb864d0/12519c50
ebp; c4bb1940 ___strtok+48b5530/12519c50
esp; cd58df28 ___strtok+d291b18/12519c50
Trace; c0160c16 devfs_unregister_blkdev+626/18c0
Trace; c0141690 vfs_readdir+60/90
Trace; c0141b90 dcache_readdir+4d0/720
Trace; c0141d3f dcache_readdir+67f/720
Trace; c0141b90 dcache_readdir+4d0/720
Trace; c01338f7 vfs_statfs+c57/1090
Trace; c0106f23 __up_wakeup+1137/25b4
Code; c0160783 devfs_unregister_blkdev+193/18c0
_EIP:
Code; c0160783 devfs_unregister_blkdev+193/18c0 =
0: 66 8b 43 44 mov0x44(%ebx),%ax =
Code; c0160787 devfs_unregister_blkdev+197/18c0
4: 25 00 f0 00 00and$0xf000,%eax
Code; c016078c devfs_unregister_blkdev+19c/18c0
9: 66 3d 00 60 cmp$0x6000,%ax
Code; c0160790 devfs_unregister_blkdev+1a0/18c0
d: 75 0d jne1c _EIP+0x1c c016079f
devfs_unregister_blkdev+1af/18c0
Code; c0160792 devfs_unregister_blkdev+1a2/18c0
f: f6 43 10 04 testb $0x4,0x10(%ebx)
Code; c0160796 devfs_unregister_blkdev+1a6/18c0
13: 74 00 je 15 _EIP+0x15 c0160798
devfs_unregister_blkdev+1a8/18c0