On Thu, Aug 05, 2004 at 06:13:10AM +0000, Michael van Elst wrote:
> bouyer@antioche.eu.org (Manuel Bouyer) writes:
> 
> >Note that I didn't test this yet, as I don't have a USB device in hands,
> >and my SCSI test box is hung, probably in the scsi_kill_pending() loop,
> >and I can't get into debugger remotely.
> 
> It fails as described. You could easily observe this with ehci-devices
> some weeks ago before Charles fixed the ehci code. When the USB transfer
> fails there are some slow retries, unplugging the device in that state
> will freeze the system.
> 
> scsipi_done() tries to abort a pending command by running the completion
> thread.
> 
> One thing is that this may take some time and effectively busy-waiting
> for it in scsi_kill_pending() isn't a good idea.

Well, if we're there because the controller is gone (unplugged), the
controller will never complete the command anyway, and we can abort it in
the scsipi code.

> 
> The other is that, at least when I tested this with USB and Firewire,
> the underlying xfer code didn't handle a XS_DRIVER_STUFFUP. In fact,
> with the device gone, it didn't do anything. This part might have
> changed.

What do you mean ? XS_DRIVER_STUFFUP cause the request to be terminated with
EIO, this is what it's supposed to do.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--