> From: Jason Thorpe <thorpej@nas.nasa.gov>
> Date: Mon, 08 Jan 1996 10:48:42 -0800

> Actually, the work-around I checked into the MI SCSI code (which I 
> believe Gordon was referring to) ensures that the SCSI disk driver (and 
> CD-ROM driver) will use a 6-byte cdb when the transfer can fit.  On 
> ancient devices, like Emulex ESDI bridges, the transfer is always limited 
> to one that will fit inside a 6-byte cdb.

Yes, I was referring to the change to use 6-byte commands.

> Anyhow, this problem eliminated 90% of the "wanted 10 got 6" messages on 
> my 3/60.  I still get them occasionally, but haven't had the chance to 
> track them down (I get them using the new 5380 driver under NetBSD/sparc, 
> too.  They are _extremely_ rare there, and the disk is a modern SCSI-II 
> disk.)

These short command transfers can also happen if the SCSI device
is sluggish about sucking in the SCSI command.  The ncr5880 driver
uses a shorter timeout for transferring bytes within a command, so
a device that reads the first 6 bytes and then sits around a while
will cause the ncr driver to give up and go look for a phase change.
There are tunable variables to control that wait.  Try adjusting:

	int ncr5380_wait_req_timo = 1000 * 50;	/* X2 = 100 mS. */
	int ncr5380_wait_nrq_timo = 1000 * 25;	/* X2 =  50 mS. */

which are used by ncr5380_pio_out() in ncr5380sbc.c
(you can patch these using "gdb -k --write /netbsd")

> Perhaps that message should include the opcode from the cdb .. 
> does it already?

Yes, that is what gets printed just after the complaint, i.e.

> > ncr5380_command: short transfer: wanted 10 got 6.
> > si(0,0,0)-28,0,0,2b,9c,9d,0,0,1,0-
              ** This is the SCSI command (ten-byte read)

> Anyhow, it's possible there's another problem with your disk, or another 
> case where we need to use a different cdb format.

Possibilities: bad SCSI termination, SCSI parity errors?

Gordon