lkml.org 
[lkml]   [1996]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subjectsbpcd bug ?
Date

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


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.045 / U:6.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site