On Fri, 7 Sep 2001, Darren Reed wrote:

> In some email I received from Matthew Jacob, sie wrote:
> [...]
> > The normal path was (roughly) expected to be:
> > 
> > isp_pci_intr
> >   isp->isp_onintstack = 1;
> >     isp_intr
> >     ...
> >     (SCSI midlayer)
> >       ...
> >       isprequest
> > 	isp_start
> > 	(exception condition causes)
> > 	  isp_mboxcmd
> > 	    if (isp->isp_onintstack)
> > 	      POLL
> > 	    else
> > 	      tsleep
> > 	  ...
> > 
> > 
> > The problem that broke me was:
> > 
> > isp_pci_intr
> >   isp->isp_onintstack = 1;
> >     isp_intr
> >     ...
> >     (SCSI midlayer- called with BUSY status on SCSI command)
> >       (kthread schedule of scsi_completion, which then does
> >       callout_reset so that in 1 second, essentially)
> >       ...
> >       isprequest
> > 	isp_start
> > 	(exception condition causes)
> > 	  isp_mboxcmd
> > 	    if (isp->isp_onintstack)
> > 	      POLL
> > 	    else
> > 	      tsleep
> > 	  ...
> > 
> > But because isp->isp_onintstack isn't set, I called tsleep. Boom.
> 
> Oh, that's just plain _yuck_.
> 
> NetBSD needs, at the very least, an interrupt kthread for kernel callouts.
> Preferably one for each callout which gets activated.
> 
> Meanwhile, you can't push whatever it is you're doing back and force a new
> interrupt for the ISP controller, can you?  Or even fake one happening...

The fix for now probably would be to have scsipi_complete get reactivated
to run the callouts in process context.