Matthew Dharm wrote:
>
> 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,
Well I looked at it on the weekend and didn't see anything.
Unfortunately I don't have any USB devices or IDE cdroms
in the right place to replicate your configuration.
I guess the problem revolves around calling
remove_proc_entry() with the appropriate
arguments bottom up for the subtree you wish to
delete from procfs.
One way that I have noticed that you can see
that remove_proc_entry() is working is to
place the cwd in a procfs directory belonging
to driver you are about to rmmod. [For example:
'cd /proc/scsi/sg ; rmmod sg']. When the rmmod
is done the kernel spits out a message like:
remove_proc_entry: scsi/sg busy, count=1
When I back out of that directory the kernel outputs:
de_put: deferred delete of sg
Hope this helps.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
