Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 May 1999 13:36:46 +1000
From:      Stephen McKay <syssgm@detir.qld.gov.au>
To:        freebsd-scsi@freebsd.org
Cc:        syssgm@detir.qld.gov.au
Subject:   Re: aha1542 brokenness, and CAM technique query 
Message-ID:  <199905260336.NAA19611@nymph.detir.qld.gov.au>
In-Reply-To: <199905241351.HAA21077@narnia.plutotech.com> from "Justin T. Gibbs" at "Mon, 24 May 1999 07:51:21 -0600"
References:  <199905241351.HAA21077@narnia.plutotech.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 24th May 1999, "Justin T. Gibbs" wrote:

>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).

Well, everyone should be happy to know that the interleaved commands
scenario that I described above is not happening.  A much simpler case
of colliding commands (without any chance of FS corruption) was causing
the problem.  Justin made a patch, it works fine on my box with dual
1542s and lots of disks, and it's already in the tree.  Another happy
ending!

Stephen.


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?199905260336.NAA19611>