Re: netbsd-5 crash in scsipi

[Chris Ross <cross+netbsd%distal.com@localhost>]

On Feb 20, 2011, at 14:07 , Michael L. Hitch wrote:
>  It's much more likely due to a DIAGNOSTIC kernel that panics when the scsipi 
> layer is trying to allocate a tag for a transfer.  The ciss(4) ignores the 
> tag set by the scsipi layer and does its own tagging (if I
> understand the use of tags and how the ciss(4) driver works).  Ciss(4) can 
> typically accept > 256 commands, which exceeds the number of tags available 
> to the scsipi layer.  When I was testing the changes to ciss(4) to use tagged 
> queueing, I was not running a DIAGNOSTIC kernel, and never saw any problems, 
> even when the number of commands queued to ciss(4) vastly exceeded 256.  The 
> following change to ciss.c should fix this by limiting the number of commands 
> the scsipi layer can send to a single peripheral device.  Perhaps the maximum 
> of 256 could be controlled by DIAGNOSTIC to take full advantage of the number 
> of commands ciss(4) can handle.
> 
> -        sc->sc_adapter.adapt_max_periph = sc->sc_adapter.adapt_openings;
> +       sc->sc_adapter.adapt_max_periph = min(sc->sc_adapter.adapt_openings, 
> 256);

  Excellent catch.  I later saw that a GENERIC kernel didn't display the same 
panic, and wasn't sure why.  My kernel is mostly the same as GENERIC with many 
many drivers removed.  But, as you figured out, it *does* have DIAGNOSTIC.  
This is surely what caused me the problem.

  I applied that patch into my netbsd-5 tree, and the resulting kernel does not 
cause the panic given the same approximate set of circumstances.

  So, I guess the question is, should some other solution be proposed?  You 
describe some other solution that might allow ciss to use more than 256 tags, 
which seems worth some additional effort, but it may not be if it's too 
difficult.

  Thanks.

             - Chris