Messages in this thread |  | | From | Callum McKenzie <> | Subject | sbpcd bug ? | Date | Wed, 17 Apr 1996 01:30:39 +1200 (NZST) |
| |
Gudday,
The following error occurs with a Creative/Panasonic 2x CD-ROM drive connected to a 486DX2/66. To get it you have to mount and unmount the cdrom drive several times in quick succession (Don't ask how I discovered this :). Important notes : - Both sbpcd and isofs need to be modules (if isofs is in the kernel this doesn't occur, if both are in the kernel it most certainly doesn't occur). - It always occurs with the mount command. - It takes 2 - 5 mount/unmount pairs for it to occur. - If the autoeject feature of sbpcd is enabled, it happens sooner rather than later. - It occurs on a number of kernels (I modularised about 70), I've tried 70, 75, 80 and 89. - It occurs with modules 1.3.69 1.3.69f and (I think) 1.3.57 . - It occurs with any CD. - I use kerneld to load the modules (with the default 60 second time till the module is dumped, the remount occurs well within this time.) The number of kernels it occurs with makes me suspicious of my hardware, but then again its a relatively obscure way to create an error and the sbpcd code hasn't been changed much in that time (I *think*). Even if it is hardware, the error isn't handled very gracefully.
Below is the error and the ksymoops report. This is a typical example, they all occur shortly after the read_super call.
Unable to handle kernel paging request at virtual address c100d64a current->tss.cr3 = 0006c000, *pde = 00001067 *pte = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<0012881d>] EFLAGS: 00010202 eax: 00182365 ebx: 0018d364 ecx: 00000004 edx: 0100d64a esi: 0018238c edi: 0100d64a ebp: 0100d64a esp: 00051ee0 ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Process mount (pid: 780, process nr: 17, stackpage=00051000) Stack: 00000000 00001900 0000000f 08001900 00128c36 0100d64a 01011900 00001900 0000000f 0800afe8 00129163 00001900 0100d64a 0000000f 007f8000 00000000 010195f4 00001900 08010000 c0ed000f 002a9a50 0012971a 00001900 08010000 Call Trace: [<00128c36>] [<0100d64a>] [<01011900>] [<00129163>] [<0100d64a>] [<010195f4>] [<0012971a>] [<0100d64a>] [<0100d64a>] [<0010a4e9>] Code: ae 75 08 84 c0 75 f8 31 c0 eb 05 19 c0 83 c8 01 85 c0 74 07
Using `/usr/src/linux/System.map' to map addresses to symbols.
>>EIP: 12881d <get_fs_type+2d/b0> Trace: 128c36 <read_super+46/100> Trace: 100d64a Trace: 1011900 Trace: 129163 <do_mount+e3/150> Trace: 100d64a Trace: 10195f4 Trace: 12971a <sys_mount+31a/360> Trace: 100d64a Trace: 100d64a Trace: 10a4e9 <system_call+59/a0>
Code: 12881d <get_fs_type+2d/b0> scasb %es:(%edi),%al Code: 12881e <get_fs_type+2e/b0> jne 128828 <get_fs_type+38/b0> Code: 128820 <get_fs_type+30/b0> testb %al,%al Code: 128822 <get_fs_type+32/b0> jne ffffffff <_EIP+ffffffff> Code: 128824 <get_fs_type+34/b0> xorl %eax,%eax Code: 128826 <get_fs_type+36/b0> jmp 12882d <get_fs_type+3d/b0> Code: 128828 <get_fs_type+38/b0> sbbl %eax,%eax Code: 12882a <get_fs_type+3a/b0> orl $0x1,%eax Code: 12882d <get_fs_type+3d/b0> testl %eax,%eax Code: 12882f <get_fs_type+3f/b0> je 128838 <get_fs_type+48/b0>
------------------------------------------------------------------------
- Callum
|  |