Subject: Re: problems in scsipi detach code.
To: Michael van Elst <firstname.lastname@example.org>
From: Manuel Bouyer <email@example.com>
Date: 08/05/2004 14:07:03
On Thu, Aug 05, 2004 at 06:13:10AM +0000, Michael van Elst wrote:
> firstname.lastname@example.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
> 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
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 <email@example.com>
NetBSD: 26 ans d'experience feront toujours la difference