There is a bug in the current Sun3/Sparc VME si driver.  Although I am
rewriting the driver, here is a quick fix for now:

In both sci_data_in() and sci_data_out(), you have the following:

	if (SCI_CUR_PHASE(regs->sci_bus_csr) != phase)
		return cnt;

	WAIT_FOR_REQ(regs);

Interchange the order of the two statements:

	WAIT_FOR_REQ(regs);
	if (SCI_CUR_PHASE(regs->sci_bus_csr) != phase)
		return cnt;

The current SCSI bus phase is only valid after REQ rises.  The code as it
was sampled the phase a little too early.  Most of the time, the SCSI device
was so fast that this didn't make a difference.

One place where it does seem to make a difference is in LUN probing.  It
appears that some devices take longer to respond to a non-existent LUN
probe, and during these probes, the old si driver will miss status phases, etc.
As a result, devices show up at all LUNs even if the device groks LUNs.

Since I'm redoing the driver, this will be fixed.  The real question is:
How many devices got added to the SCSI quirks table through no fault of
their own?  Can anybody who uses the si driver go back and re-check their
devices with this fix in place?

-- 
David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto
           email: dej@eecg.toronto.edu, finger for PGP public key
         For a good time, telnet torfree.net and log in as `guest'.
          Click me!