Messages in this thread |  | | Date | Tue, 10 Oct 2000 11:33:28 -0700 | From | Matthew Dharm <> | Subject | OOPS REPORT: Will someone _please_ look at this? (was Re: BUG & OOPS REPORT: /proc/scsi/ entries not properly cleaned up) |
| |
Yet more followup with myself.... I can reproduce this problem on 2.4.0-test10-pre1 every time. I'm using the ide-scsi and usb-storage modules to trigger the bug -- loading and then unloading either one causes /proc/scsi to not be cleaned up properly.
As yet, nobody has indicated to me that they are looking into this problem. I've taken a few experimental pokes at it, and it seems that the SCSI layer is, in fact, calling the procfs function to remove the entries. At least, I think it is -- I'm not sure if it's the right entry.
Will someone _please_ look at this? I consider this a critical item for 2.4.0, and I hope others do too.
Matt
On Mon, Oct 02, 2000 at 06:00:53PM -0700, Matthew Dharm wrote: > 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) > > >
-- Matthew Dharm Home: mdharm-usb@one-eyed-alien.net Maintainer, Linux USB Mass Storage Driver
P: How about "Web Designer"? DP: I'd like a name that people won't laugh at. -- Pitr and Dust Puppy User Friendly, 12/6/1997 [unhandled content-type:application/pgp-signature] |  |