Hello everyone,
 
pk wrote:

> 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.

Yes, that explanation kind of makes sense, given the way SunOS and NetBSD
decide to name the register-bit. And of course this is only neccesary on
ESP-versions <100A, too. So it is indeed kind of a "carry" or "overflow"
situation.

> 
> > 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).

[ chainsaw ]
 
> 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...

Ok, I hope I understand this: The interrupt comes in, and resid = 0, 
while TC is unset. We therefore assume that this must have been a 64k
request, of which no bytes were transferred yet, and let it go for another
round, resetting resid to 65536 which will loose it's first (high) bit
again somewhere on it's way to the esp-chip.

But I think it's fairly safe to assume that 64k transfers won't be happening
at this stage, we are after all autoconfigging the devices. And anyway, I
only requested 4 bytes. So how come I still end up with an unset TC while
resid = 0? Are we replying too quickly to the interrupt, perhaps, it needing
some more time to flip TC?

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

Well, as we apparently know how big the transfer was we requested, maybe one
ought to add a check on sc->sc_dmasize to the code that sets resid to 65536?

> >  > 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.

Well, on my ELC, even that doesn't happen, the drive is not recognised at 
all. It could be that Kirsten gets 44 bytes transfered, and I only 4, there
is likely a bit more information in what he gets :)

The rest of the error-messages we see are all !TC, I think (not 100% sure)
and it therefore seems that the problems we have are really with the TC-
bit of the ESP-status-register. Or is this just symptomatic, and is there
another reason why this doesn't work on so many ELCs?

I recompiled the kernel, with the original dma.c again, and after setting
the debugging on esp on. Would anyone be interested in a dump of this, to
help further the search? In that case, I'll hook up another computer and set
the console to ttya etc.
-- 
----------------------------------------------------------------------
Paul Boven, <e.p.boven@student.utwente.nl>  PE1NUT  QRV 145.575 JO32KF
 "And  she  looked  like  she  had  sex,  with  a  tyranosaurus  rex"
Cannibal surf babe     --     Afraid of sunlight     --     Marillion
----------------------------------------------------------------------