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>