sbp2: modprobe -r fails, module allegedly in use

sbp2: modprobe -r fails, module allegedly in use

[Stefan Richter]

Hi all,

it seems the sbp2 driver module can never be unloaded because the
module "is in use" even though all SBP-2 devices were physically removed
(after umount etc.). I believe it is an old problem of the last few 2.6
kernels but am not sure when it was really introduced.

One thing can easily be spotted by "ps x": The scsi_error_handler of an
SBP-2 device does not exit. The /sys/bus/scsi/devices/$a:$b:$c:$d 
vanished, the /sys/bus/ieee1394/devices/$guid-$unit too, but the 
scsi_eh_# daemon is still there. It seems shost->shost_gendev.release 
was never called.

So I just added a few more scsi_host_put() to sbp2_remove_device(). 
scsi_eh_# now goes away when I disconnect the device. Still, modprobe -r 
sbp2 fails with "FATAL: Module sbp2 is in use.".
-- 
Stefan Richter
-=====-=-=-= -=== -=-=-
http://arcgraph.de/sr/

Re: sbp2: modprobe -r fails, module allegedly in use

[Stefan Richter]

I wrote:
> So I just added a few more scsi_host_put() to sbp2_remove_device(). 
> scsi_eh_# now goes away when I disconnect the device. Still, modprobe -r 
> sbp2 fails with "FATAL: Module sbp2 is in use.".

I also added printks and according to them, shost_gendev.release is 
called after scsi_host_put is entered for the fourth time in 
sbp2_remove_device.
-- 
Stefan Richter
-=====-=-=-= -=== -=-=-
http://arcgraph.de/sr/

Re: sbp2: modprobe -r fails, module allegedly in use

[Ben Collins]

Yeah, seems like every two months we have to change sbp2 to accomodate
changes to the scsi layers whole reference scheme which never seems
simple, and never stays the same.

Any of the scsi guys care to comment on any changes in the reference
counting to scsi over the last couple of months? Seriously, I've been
having to go through tracking these sorts of changes every month or so
ever since scsi switched to using the driver model. Usually I just take a
peek at the usb storage module, since it somehow seems to stay up with
whatever changes are needed to keep working with the scsi callbacks.

On Sun, Jul 10, 2005 at 04:42:54PM +0200, Stefan Richter wrote:
> Hi all,
> 
> it seems the sbp2 driver module can never be unloaded because the
> module "is in use" even though all SBP-2 devices were physically removed
> (after umount etc.). I believe it is an old problem of the last few 2.6
> kernels but am not sure when it was really introduced.
> 
> One thing can easily be spotted by "ps x": The scsi_error_handler of an
> SBP-2 device does not exit. The /sys/bus/scsi/devices/$a:$b:$c:$d 
> vanished, the /sys/bus/ieee1394/devices/$guid-$unit too, but the 
> scsi_eh_# daemon is still there. It seems shost->shost_gendev.release 
> was never called.
> 
> So I just added a few more scsi_host_put() to sbp2_remove_device(). 
> scsi_eh_# now goes away when I disconnect the device. Still, modprobe -r 
> sbp2 fails with "FATAL: Module sbp2 is in use.".
> -- 
> Stefan Richter
> -=====-=-=-= -=== -=-=-
> http://arcgraph.de/sr/
> 

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: sbp2: modprobe -r fails, module allegedly in use

[Christoph Hellwig]

On Sun, Jul 10, 2005 at 11:31:26AM -0400, Ben Collins wrote:
> Yeah, seems like every two months we have to change sbp2 to accomodate
> changes to the scsi layers whole reference scheme which never seems
> simple, and never stays the same.

While the implementation has changed a little the exposed interface
never changed at all since before 2.6.0.

Re: sbp2: modprobe -r fails, module allegedly in use

[Ben Collins]

On Sun, Jul 10, 2005 at 06:40:54PM +0100, Christoph Hellwig wrote:
> On Sun, Jul 10, 2005 at 11:31:26AM -0400, Ben Collins wrote:
> > Yeah, seems like every two months we have to change sbp2 to accomodate
> > changes to the scsi layers whole reference scheme which never seems
> > simple, and never stays the same.
> 
> While the implementation has changed a little the exposed interface
> never changed at all since before 2.6.0.

The exposed implementation might not have, but atleast 3 times now, since
the driver model started being used, I've had to change the way I use the
exposed implementation in order to get bean counting right with the device
and host devices.

Prior, we were using one scsi host per ieee1394 host, with each sbp2
device being one device and even supporting real LUN's to make things as
close to looking like a real scsi host as possible.

Had to ditch all that and do one-host-per-device like USB does in order
save myself all the headache involved. This kind of sucks because the
plug/unplug can quickly increment the scsi-host counter to a point where
things like cdrecord don't work with firewire cd/dvd/rw devices anymore
(until a reboot or the scsi module is removed/inserted). But that's a
whole different issue :)

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: sbp2: modprobe -r fails, module allegedly in use

[Christoph Hellwig]

On Sun, Jul 10, 2005 at 01:46:43PM -0400, Ben Collins wrote:
> The exposed implementation might not have, but atleast 3 times now, since
> the driver model started being used, I've had to change the way I use the
> exposed implementation in order to get bean counting right with the device
> and host devices.

What about reporting your problems to linux-scsi instead of all this
silly bitching?

Re: sbp2: modprobe -r fails, module allegedly in use

[Ben Collins]

On Sun, Jul 10, 2005 at 06:49:13PM +0100, Christoph Hellwig wrote:
> On Sun, Jul 10, 2005 at 01:46:43PM -0400, Ben Collins wrote:
> > The exposed implementation might not have, but atleast 3 times now, since
> > the driver model started being used, I've had to change the way I use the
> > exposed implementation in order to get bean counting right with the device
> > and host devices.
> 
> What about reporting your problems to linux-scsi instead of all this
> silly bitching?

I just did, and I have. Never got a reply before. Plus the fact that
generally the fix I needed was in the USB storage driver led me to believe
"yes, we know it changed", so why bother?

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: sbp2: modprobe -r fails, module allegedly in use

[James Bottomley]

On Sun, 2005-07-10 at 16:42 +0200, Stefan Richter wrote:
> it seems the sbp2 driver module can never be unloaded because the
> module "is in use" even though all SBP-2 devices were physically removed
> (after umount etc.). I believe it is an old problem of the last few 2.6
> kernels but am not sure when it was really introduced.
> 
> One thing can easily be spotted by "ps x": The scsi_error_handler of an
> SBP-2 device does not exit. The /sys/bus/scsi/devices/$a:$b:$c:$d 
> vanished, the /sys/bus/ieee1394/devices/$guid-$unit too, but the 
> scsi_eh_# daemon is still there. It seems shost->shost_gendev.release 
> was never called.
> 
> So I just added a few more scsi_host_put() to sbp2_remove_device(). 
> scsi_eh_# now goes away when I disconnect the device. Still, modprobe -r 
> sbp2 fails with "FATAL: Module sbp2 is in use.".

Actually, I think your error is the opposite of this: you should never
have to do a scsi_host_put() unless you did a corresponding
scsi_host_get(), which, as far as I can see, sbp2 never does, so the
extra put should be meaningless.

Except, I notice that you don't do a scsi_device_put() after
scsi_add_device().  I think this is probably the source of the
refcounting errors: scsi_add_device returns an sdev with the refcount
incremented by one, so you need to decrement the count after you've
finished with it (in your case, you do nothing with it, so just
decrement after you've checked it's not an error pointer).

James

Re: sbp2: modprobe -r fails, module allegedly in use

[Ben Collins]

> Actually, I think your error is the opposite of this: you should never
> have to do a scsi_host_put() unless you did a corresponding
> scsi_host_get(), which, as far as I can see, sbp2 never does, so the
> extra put should be meaningless.
> 
> Except, I notice that you don't do a scsi_device_put() after
> scsi_add_device().  I think this is probably the source of the
> refcounting errors: scsi_add_device returns an sdev with the refcount
> incremented by one, so you need to decrement the count after you've
> finished with it (in your case, you do nothing with it, so just
> decrement after you've checked it's not an error pointer).

Thanks. Stefan, can you test with that change? I've already put it in the
repo.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: sbp2: modprobe -r fails, module allegedly in use

[Stefan Richter]

Ben Collins wrote:
[James Bottomley wrote]
>>I notice that you don't do a scsi_device_put() after
>>scsi_add_device().  I think this is probably the source of the
>>refcounting errors: scsi_add_device returns an sdev with the refcount
>>incremented by one, so you need to decrement the count after you've
>>finished with it (in your case, you do nothing with it, so just
>>decrement after you've checked it's not an error pointer).
> 
> Thanks. Stefan, can you test with that change? I've already put it in the
> repo.

That fixes it. The error handler commits suicide when he should, and the
sbp2 module can be unloaded.

Thanks James.
-- 
Stefan Richter
-=====-=-=-= -=== -=-=-
http://arcgraph.de/sr/