Subject: Re: how do I tell if I'm on the interrupt stack?
To: Darren Reed <darrenr@reed.wattle.id.au>
From: Matthew Jacob <mjacob@feral.com>
List: tech-kern
Date: 09/07/2001 08:41:18
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.