Upon further investigation...

> esp_quick_dma_setup called with 101000, 0, 0, 0

OK.  This means that the bus is still in a DATA transfer phase.  The
second "0" there means that it's initializing DMA for a write operation
(datain == 0).  So, this is a DATA_OUT_PHASE.  Now, since the size
passed is 0, the driver will issue a NCRCMD_TRPAD command to flush
0s out to the drive until the drive has had enough.

> dmaintr: DMA xfer of zero xferred 65504

This is actually a buggy message.  The chip really transferred
65536-65504 = 32 bytes before the device had enough.

Now.  How can we get here?  I can think of two different scenarios.  One
much more likely than the other.  ;-)

	1) The drive is buggy and asks for more data than it needs, or

	2) We are sending too little data on the prior transaction,
	   and not noticing.

I think it's likely that that's the real problem.  The question is...
How?

> esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 0, resid 1f0

This says that we received an interrupt during data transfer and the
transfer complete flag was not set even though all of the bytes had
been transferred.  This appears to be a bug in the m.i. driver with
handling the pad operation.  We shouldn't be hitting the pad operation
to begin with, so this is a probably fallout from the above.

> panic: esp0: invalid state: 6

State 6 is NCR_DISCONNECT which means that a disconnect message has been
received, but we still ended up in the interrupt routine in a place
where we expected to be connected.  This is also fallout from the above,
most likely.

So, I think if we can figure out if we're hitting case #2 above (which
is what I suspect) and why, we can fix things so that they work for you.
What kind of drive is this happening on for you?

-allen

-- 
 Allen Briggs                     briggs@wasabisystems.com
 http://www.wasabisystems.com/    Quality NetBSD CDs, Sales, Support, Service