Messages in this thread | | | Date | Tue, 30 Dec 2003 16:18:45 -0700 | From | "Eric D. Mudama" <> | Subject | Re: no DRQ after issuing WRITE was Re: 2.4.23-uv3 patch set released |
| |
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@mail.bounceswoosh.org
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |