Re: BUG & OOPS REPORT: /proc/scsi/ entries not properly cleaned up

From: Matthew Dharm (mdharm-kernel@one-eyed-alien.net)
Date: Sun Oct 01 2000 - 20:32:38 EST


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: mdharm-usb@one-eyed-alien.net
> Maintainer, Linux USB Mass Storage Driver
>
> NYET! The evil stops here!
> -- Pitr
> User Friendly, 6/22/1998

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
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


- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:08 EST