Re: no DRQ after issuing WRITE was Re: 2.4.23-uv3 patch set released

[Eric D. Mudama]

On Tue, Dec 30 at 20:21, Marcelo Tosatti wrote:
> "hda: no DRQ after issuing WRITE
> ide0: reset: success
> hda: status timeout: status=0xd0 { Busy }
>
> hda: no DRQ after issuing WRITE
> ide0: reset: success"
>
> (Daniel wrote the patch which got applied to 2.4, it fixed the problems
> for him).
>
> There are several other reports of "no DRQ after issuing {MULTI}WRITE",
> some of them probably involved with this bug, some of them potentially
> not. You can find more reports (both from 2.6 and 2.4) at:

Old ATA specifications had the concept of an auto-write segment,
in that the drive had to begin accepting data an extremly short time
after the command had been issued.

> From what I understand, there was a time when people attempted to
remove this from the spec, however, it was discovered that some old
BIOSs didn't bother to check the DRDY bit at all after issuing a PIO
write, and they immediately just went straight to data
transfer... without the drive ready to receive the data, it would
corrupt the block since the first N words of data wouldn't be seen.

In more modern versions of the ATA specification, the only time
constraint built into PIO protocol transfers is that the hardware has
at most 400ns to assert BSY following the write of the command
register.  Since every drive today has hardware to automate this
process, that time constraint is never violated.

Other than that, the drive is free to leave BSY asserted as long as it
needs to prior to setting DRQ and being ready for data-transfer in.

I could just be talking totally tangential to the issue being
discussed, but is the 20/30 or 29/30ms wait being discussed at this
point in the protocol, or is it elsewhere?

Unless it has been something like 5-8 *seconds* without DRQ=1 and
BSY=0, I don't think the driver should reset the device.

--eric


--
Eric D. Mudama
edmudama@xxxxxxxxxxxxxxxxxxxxx

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/