Michael L. Hitch wrote:

>   This patch attempts to duplicate when the newer Mach driver does, i.e.
> send null padding on the command.  It may not make the drive work if the
> drive is actually missing a byte of command data, but it should at least
> let the SCSI bus sequence through the phases to completion and not end up
> rebooting.

I've done some more "heavy" testing (rebooting several times, turning
the machine off and on, and building most of the world) with this
patch and it works well for me, at least.  I almost always get these
messages during boot:

rz0 at asc0 drive 0 slave 0 QUANTUM LIGHTNING 540S rev 241E, 1075649 512 byte blocks
asc_intr: target 1 wants more command data
asc_get_status: cmdreg 11, fifo cnt 4
rz1 at asc0 drive 1 slave 0 SGI IBM  0662 S12 rev 1S, 2055035 512 byte blocks

(sometimes it won't be any problems or messages at all - about one
time in 10, with no pattern I have found).  Apart from this the drive
works well, I only get lots of these (debug?) messages:

asc_intr: IN: dmalen 10 len 0 fifo 1

I think this patch can be commmited, it can't hurt :-)

I've cc'ed port-pmax in case somebody else want to test it, hope
that's OK.

  -arnej

diff -cr /c/src/sys/dev/tc/asc.c sys/dev/tc/asc.c
*** /c/src/sys/dev/tc/asc.c	Mon Apr  7 05:21:20 1997
--- sys/dev/tc/asc.c	Sun May 25 08:57:57 1997
***************
*** 973,978 ****
--- 973,992 ----
  			readback(regs->asc_cmd);
  			goto done;
  
+ 		case SCSI_PHASE_COMMAND:
+ 			/*
+ 			 * This seems to occur after the command is sent
+ 			 * following sync negotiation.  The device still
+ 			 * wants more command data.  Rather than giving up,
+ 			 * pad the command phase and let the target sequence
+ 			 * normally.
+ 			 */
+ 			printf("asc_intr: target %d wants more command data\n",
+ 			    asc->target);
+ 			ASC_TC_PUT(regs, 0xff);
+ 			regs->asc_cmd = ASC_CMD_XFER_PAD | ASC_CMD_DMA;
+ 			goto done;
+ 
  		default:
  			printf("asc_intr: target %d, unknown phase 0x%x\n", 
  			  	asc->target, status);