Date: Mon, 24 May 1999 07:51:21 -0600 (MDT) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: Warner Losh <imp@harmony.village.org> Cc: scsi@FreeBSD.org Subject: Re: aha1542 brokenness, and CAM technique query Message-ID: <199905241351.HAA21077@narnia.plutotech.com> In-Reply-To: <199905240453.OAA11833@nymph.detir.qld.gov.au> <199905231225.WAA05009@nymph.detir.qld.gov.au> <199905240343.VAA16346@harmony.village.org> <199905240727.BAA17292@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199905240727.BAA17292@harmony.village.org> you wrote: > In message <199905240453.OAA11833@nymph.detir.qld.gov.au> Stephen McKay writes: > : A mailbox command (ie real SCSI command) is in flight when aha_cmd() > : is called. After the command byte, but before all of the parameter > : bytes are written, it completes, calling aha_intr(), which calls > : ahadone(), which calls xpt_done() which (as far as I can tell) allows > : something else to run which queues another command which issues another > : mailbox command. Crunch! At least, that's what I think is happening. > > Ouch! I think that Justin's bt_cmd will also have this same problem, > since it doesn't block CAM interrupts while the bt_cmd is processing. > It does check to see if there is an interrupt pending, however. You should be at splsoftcam() when this code is executed which will prevent the queuing of any additional commands to the card. If we aren't at splsoftcam() here, then there is a bug in the cam xpt. You do not need to block hardware interrupts in order to prevent additional commands from comming down the pipe due to the deferred processing technique used by CAM (similar to the networkig stack). -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905241351.HAA21077>