> >As far as I understand the problem, it sufficient to just ignore
> >the extraneous data.
> 
> I think this is not the case, particularly when using synch scsi.

Well, whenever this particular bug bites, we're nowhere near a data
transfer phase. So, common sense (does that apply to scsi controllers?)
would dictate that the on-chip state machine is not affected by synch
transactions in the past when arbitration takes place.

> In some circumstances (I forget what), the chip fails to flush
> command bytes from the FIFO, but in others, it has incoming data
> bytes in the FIFO.  You must inspect the phase (and/or step?)
> and decide whether the FIFO data is `good stuff' or `bad stuff'...

At the point in the NetBSD ncr53c9 driver where --upon RESELECT -- it
expects the ID & Identify message in the FIFO, it has already verified
that the phase is MESSAGE IN.

Here's the comment for the workaround I put yesterday:

	/*
	 * The C90 only inhibits FIFO writes until
	 * reselection is complete, instead of
	 * waiting until the interrupt status register
	 * has been read. So, if the reselect happens
	 * while we were entering a command bytes (for
	 * another target) some of those bytes can
	 * appear in the FIFO here, after the
	 * interrupt is taken.
	 */

followed by something like:

	nfifo = <bytes currently in FIFO>;
	if (nfifo == 2)
		Ok;
	else (if <chip is ESP100> && nfifo > 2)
		pretend first two bytes in FIFO are what we want
		flush rest of FIFO
	else
		NOT Ok;