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 = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c0160783>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: ccdad920 ebx: 204f2f49 ecx: 00000000 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 00000000 c6126040 c61260c0
c61260ac
c4bb1940 c0141690 c4bb1940 cd58dfa0 c0141b90 c4bb1940 fffffff7
0000000d
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>
00000000 <_EIP>:
Code; c0160783 <devfs_unregister_blkdev+193/18c0> <=====
0: 66 8b 43 44 mov 0x44(%ebx),%ax <=====
Code; c0160787 <devfs_unregister_blkdev+197/18c0>
4: 25 00 f0 00 00 and $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 jne 1c <_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>
