> ...it looks like we treat the "TC" bit differently ... SunOS calls it:
> 
> #define ESP_STAT_XZERO  0x10    /* transfer counter zero */
> 
> ...where we call it:
> 
> #define  ESPSTAT_TC     0x10            /*      Terminal Count          */
> 
> I would guess from the SunOS name for the bit that they treat the 
> presence of that bit as "zero bytes transfered".

I don't think so. The `terminal count' bit is (reportedly) set at the moment
the transfer count goes from 1 to 0. If, by the time the device interrupts,
`TC' is not set this means that the actual transfer was less then requested.
(this is not an error, it happens all the time because of intervening
SAVEPOINTER messages or when `requesting sense'). If that's the case, the
residual io count can be found in the esp's transfer count registers.

> From looking at our 
> handling of this in dma.c (line 450), I'm not entirely certain that 
> setting resid to 64k is a wise idea ... it _seems_ like it should be set 
> to sc->sc_dmasize (the size of the request).
> 
> Note that the chunk of code in espdmaintr() looks like this:
> 
>         if (resid == 0 && (sc->sc_esp->sc_rev <= ESP100A) &&
>             (sc->sc_esp->sc_espstat & ESPSTAT_TC) == 0)
>                 resid = 65536;
> 
>         trans = sc->sc_dmasize - resid;
>         if (trans < 0) {                        /* transferred < 0 ? */
>                 printf("%s: xfer (%d) > req (%d)\n",
>                     sc->sc_dev.dv_xname, trans, sc->sc_dmasize);
>                 trans = sc->sc_dmasize;
>         }

The idea behind this is that loading an all-zero bit pattern in the esp's
transfer counters actually means "a 64K transfer count". Now, this never
happens in any of the cases reported here...

Note that the transfer size _is_ actually set to the initial request size
(after printing the message), whenever this "impossible" situation is
detected.


> Now, if it is indeed an indication that nothing was actually transfered, 
> then that chunk of code "feels wrong"...
> 
>  > sd0 at scsibus0 targ 3 lun 0: <QUANTUM, TRB850S, 0404> SCSI2 0/direct fixed
>  > sd0: dma0: xfer (-65528) > req (8)
>  > esp0: !TC [intr 10, stat 83, step 4] prevphase 1, resid 8
>  > 810MB 3653 cyl, 4 head 113, sec, 512 bytes/sec

Obviously, something has made it to the host, as the inquiry and mode sense
commands have at least produced some reasonable output.

-pk