On Wed, Aug 04, 2004 at 08:18:29PM -0400, Matthew Orgass wrote:
> On 2004-08-05 bouyer@antioche.eu.org wrote:
> 
> > I've found various problems in the scsipi detach code, for scsi devices,
> > when there is active commands for this device.
> 
>   While testing my updated slhci driver (a CF USB Host Controller) I have
> seen two problems with scsipi detach (which might be due to my driver or
> the pcmcia problems I am having).  I have not looked into this much.
> Perhaps you can see an obvious way this could be happening and if so make
> sure any modifications take this into account.
> 
>   I once got a TAILQ_INSERT_TAIL panic on line 1440 of scsipi_base.c
> during cddetach.  I usually did not run with QUEUEDEBUG, so it may be that
> this would have happened more frequently had it been possible.

It could be the result of a double scsipi_done(), I guess there is a race
condition that could allow this.

> 
>   Frequently the usb thread would get stuck in scsipi_channel_shutdown
> waiting for the thread to shutdown.  Meanwhile, the thread is stuck in
> scsipi_execute_xs waiting to be woken up.  (Yanking the card causes the
> pcic thread to get stuck in scsipi_channel_shutdown too:
> usb_disconnect_port gets entered twice for the same port.)

Because it tries to shutdown the channel before aborting the commands.
With my patch this should not happen any more; all commands are 
scsipi_done()'d before we try to shut down the thread, so a wakeup()
on the scsipi_xfer will happen in this case.

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