I wouldn't worry about it. On the face of it, it's a disconnect without a
Save Data Pointer message. This is legal and  a lot of disk drives do it
on the last segment of a transfer. When you reconnect, you're supposed to
restore the data pointer to where it was from the last save. If a save
didn't happen, you obviously restore it from the point previous. All of
this is only germane if the target re-enters a ata phase. 99.999% of the
time this won't happen. Some devices can use this mechanism to retry
failed data transfer (e.g, SCSI bus parity errors detected by the
initiator, e.g. with this sequence

	DATA IN Phase (with Parity Error)
	*ATN asserted by initiator
	Message Out Phase (IDE - Initiator Detected Error)
	Message In Phase (DISCONNNECT)
	****disconnect***
	****Reselect***
	MSG IN Phase (Identify)
	DATA IN Phase (retransmit data that had failed previously- the
		disconnect w/o a Save Data Pointer should mean that
		the xfer will restart at the beginning of this portion
		of the xfer)

But most devices don't bother- they just complete the xfer with a check
condition and flag it with aborted command, etc...

As for performance, well, 1.2MB/sec is miserable. Maybe it's rife with
slipped && spared sectors so nominal reads/writes are actually going all
over the map...

On Fri, 12 Feb 1999, Jukka Marin wrote:

> NetBSD 1.3.3, GENERIC kernel:
> 
> sd0(ncr0:4:0): M_DISCONNECT received, but datapointer not saved:
>    data=43f9b4 save=43c6b0 goal=43c6d4.
>    
> Is this serious enough to forget about using this disk and controller
> for real work?
> 
> Also, what could make the disk to perform very badly (dd can read only
> 1.2 MB/sec)?  The disk is a 4.3 GB Micropolis (sorry) and I _think_
> it should be faster.
> 
> Thanks, for the zillionth time..
> 
>   -jm
>