Re: SCSI changes - PR58452 for review

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Wed, 7 Aug 2024 09:18:17 +1000
> From: Nat Sloss <nathanialsloss%yahoo.com.au@localhost>
> 
> Would this patch suffice, it kicks the queue after calling scsipi_done_once.
> 
> I've been running this without issue for a day with heavy (heavy for dse(4)) 
> network traffic - so far so good.
> 
>  	/* Tell common SCSI code it is done. */
> -	scsipi_done(xs);
> +	scsipi_done_once(xs);
>  
>  	sc->sc_state = NCR_IDLE;
>  	/* Now ncr5380_sched() may be called again. */
> +
> +	/* Check the queue. */
> +	scsipi_channel_thaw(&sc->sc_channel, 0);

Instead of introducing scsipi_done_once, why not just freeze and thaw
the channel around scsipi_done?

+	scsipi_channel_freeze(&sc->sc_channel, 1);
 
 	/* Tell common SCSI code it is done. */
 	scsipi_done(xs);
 
 	sc->sc_state = NCR_IDLE;
 	/* Now ncr5380_sched() may be called again. */
 
+	scsipi_channel_freeze(&sc->sc_channel, 1);

Alternatively, is it critical for scsipi_done to happen before
sc->sc_state = NCR_IDLE?  Could we just swap the order of scsipi_done
and sc->sc_state = NCR_IDLE?

(I wonder why only this scsi driver seems to have the issue.  Is it
doing something wonky with maintaining its own copy of some kind of
driver state that is inconsistent with the normal control flow of the
scsi framework?)