Following up yet some more with myself... is anyone actually looking at
this stuff? I can provide even more information if desired, but I'd really
like to know that at least one person who understands this code is looking
at it....
Anyway, I managed to get a better OOPS trace. Here it is:
ksymoops 0.7c on i586 2.4.0-test9. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test9/ (default)
-m /boot/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Reading Oops report from the terminal
Unable to handle kernel paging request at virtual address d38c2010
c0145032
*pde = 01594063
Oops: 0002
CPU: 0
EIP: 0010:[<c0145032>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: d38c2000 ebx: cf93f0a0 ecx: c1466fc0 edx: 00000023
esi: c6c1a360 edi: cf93f0f4 ebp: ffffffea esp: c8be7ef0
ds: 0018 es: 0018 ss: 0018
Process ls (pid: 11563, stackpage=c8be7000)
Stack: c7f81360 c49c17e0 c0146a9c c144b800 00001190 cf93f0a0 fffffff4 c7f81360
c49c17e0 c49c1834 c0137083 c49c17e0 c7f81360 00000000 00000000 c8be7f68
c9f0f013 c01377c4 c7f812e0 c8be7f68 00000000 c9f0f000 00000000 c8be7fa4
Call Trace: [<c0146a9c>] [<c0137083>] [<c01377c4>] [<f27a545f>] [<c0137daa>]
[<c0134a71>] [<c010a413>]
Code: ff 40 10 8b 43 24 80 48 14 18 66 8b 43 08 25 00 f0 ff ff 66
>>EIP; c0145032 <proc_get_inode+96/108> <=====
Trace; c0146a9c <proc_lookup+68/8c>
Trace; c0137083 <real_lookup+4f/b8>
Trace; c01377c4 <path_walk+5a0/7ec>
Trace; f27a545f <END_OF_CODE+1eebbdb8/????>
Trace; c0137daa <__user_walk+3a/54>
Trace; c0134a71 <sys_newlstat+15/70>
Trace; c010a413 <system_call+33/40>
Code; c0145032 <proc_get_inode+96/108>
00000000 <_EIP>:
Code; c0145032 <proc_get_inode+96/108> <=====
0: ff 40 10 incl 0x10(%eax) <=====
Code; c0145035 <proc_get_inode+99/108>
3: 8b 43 24 movl 0x24(%ebx),%eax
Code; c0145038 <proc_get_inode+9c/108>
6: 80 48 14 18 orb $0x18,0x14(%eax)
Code; c014503c <proc_get_inode+a0/108>
a: 66 8b 43 08 movw 0x8(%ebx),%ax
Code; c0145040 <proc_get_inode+a4/108>
e: 25 00 f0 ff ff andl $0xfffff000,%eax
Code; c0145045 <proc_get_inode+a9/108>
13: 66 00 00 addb %al,(%eax)
1 warning issued. Results may not be reliable.
This is under the same test scenario as before -- load ide-scsi, unload
ide-scsi, ls /proc/scsi
It's interesting to note that 'cat /proc/scsi/scsi' works just fine -- only
getting the directory listing seems to be broken, not the actual reading of
files.
Again, this was collected on 2.4.0-test9-pre7 -- but the behavior is the
same for 2.4.0-test9-pre9.
Matt
On Sun, Oct 01, 2000 at 06:32:38PM -0700, Matthew Dharm wrote:
> Just to follow-up to my own post, I have some more datapoints...
>
> The bug definatley seems to be in either the SCSI layer or the procfs
> layer. The behavior is the same if I use either ide-scsi or usb-storage,
> which are the only two SCSI modules I can test.
>
> Matt
>
> On Fri, Sep 29, 2000 at 03:19:23PM -0700, Matthew Dharm wrote:
> > I'm using 2.4.0-test9-pre7 and have a _very_ reproducable OOPS with the
> > SCSI layer. Everything relevant is compiled as a module (except for the
> > /proc support).
> >
> > The test scenario is this:
> > (1) Boot the machine
> > (2) modprobe ide-scsi (note this autoloads scsi_mod but nothing else)
> > (3) rmmod ide-scsi
> > (4) ls /proc/scsi
> > Then the OOPS happens.
> >
> > If, instead of step (4), I instead re-modprobe ide-scsi again, then an 'ls
> > /proc/scsi/' will show (without an immediate OOPS):
> >
> > [root@zen mdharm]# ls /proc/scsi/
> > ide-scsi/ ide-scsi/ scsi
> >
> > No, the double ide-scsi entry isn't a typo -- this is what ls reports as
> > being there.
> >
> > The OOPS case is decoded via ksymoops below. My intuition suggests that
> > this is related to the fact that /proc seems to always be busy (and
> > therefore not umountable) at shutdown.
> >
> > I'm more than willing to test patches that might fix the problem.
> >
> > Sep 29 15:05:01 zen kernel: Unable to handle kernel paging request at
> > virtual address d38c2010
> > Sep 29 15:05:01 zen kernel: c0145032
> > Sep 29 15:05:01 zen kernel: *pde = 01594063
> > Sep 29 15:05:01 zen kernel: Oops: 0002
> > Sep 29 15:05:01 zen kernel: CPU: 0
> > Sep 29 15:05:01 zen kernel: EIP: 0010:[proc_get_inode+150/264]
> > Sep 29 15:05:01 zen kernel: EFLAGS: 00010286
> > Sep 29 15:05:01 zen kernel: eax: d38c2000 ebx: cf687520 ecx: c1466fc0 edx:
>00000023
> > Sep 29 15:05:01 zen kernel: esi: cd990340 edi: cf687574 ebp: ffffffea esp:
>cd99def0
> > Sep 29 15:05:01 zen kernel: ds: 0018 es: 0018 ss: 0018
> > Sep 29 15:05:01 zen kernel: Process ls (pid: 705, stackpage=cd99d000)
> > Sep 29 15:05:01 zen kernel: Stack: cda17ec0 cd9901c0 c0146a9c c144b800 00001190
>cf687520 fffffff4 cda17ec0
> > Sep 29 15:05:01 zen kernel: cd9901c0 cd990214 c0137083 cd9901c0 cda17ec0
>00000000 00000000 cd99df68
> > Sep 29 15:05:01 zen kernel: cf115013 c01377c4 cda17e40 cd99df68 00000000
>cf115000 00000000 cd99dfa4
> > Sep 29 15:05:01 zen kernel: Call Trace: [proc_lookup+104/140] [real_lookup+79/184]
>[path_walk+1440/2028] [<f27a545f>] [__user_walk+58/84] [sys_newlstat+21/112]
>[system_call+51/64]
> > Sep 29 15:05:01 zen kernel: Code: ff 40 10 8b 43 24 80 48 14 18 66 8b 43 08 25 00
>f0 ff ff 66
> > Using defaults from ksymoops -t elf32-i386 -a i386
> >
> > Code; 00000000 Before first symbol
> > 00000000 <_EIP>:
> > Code; 00000000 Before first symbol
> > 0: ff 40 10 incl 0x10(%eax)
> > Code; 00000003 Before first symbol
> > 3: 8b 43 24 movl 0x24(%ebx),%eax
> > Code; 00000006 Before first symbol
> > 6: 80 48 14 18 orb $0x18,0x14(%eax)
> > Code; 0000000a Before first symbol
> > a: 66 8b 43 08 movw 0x8(%ebx),%ax
> > Code; 0000000e Before first symbol
> > e: 25 00 f0 ff ff andl $0xfffff000,%eax
> > Code; 00000013 Before first symbol
> > 13: 66 00 00 addb %al,(%eax)
> >
> > Matt Dharm
> >
> > --
> > Matthew Dharm Home: [EMAIL PROTECTED]
> > Maintainer, Linux USB Mass Storage Driver
> >
> > NYET! The evil stops here!
> > -- Pitr
> > User Friendly, 6/22/1998
>
>
>
> --
> Matthew Dharm Home: [EMAIL PROTECTED]
> Maintainer, Linux USB Mass Storage Driver
>
> Your lips are twitching. You're playing Quake aren't you.
> -- Stef to Greg
> User Friendly, 8/11/1998
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
It was a new hope.
-- Dust Puppy
User Friendly, 12/25/1998
PGP signature
