Widespread deviations from ATA standard and related bugs
Here you can find list of deviations from ATA standard (non-standard behavior, compatibility issues) and simply bugs,
those I have meat during UniATA development.
Some of them are widespread among various models of controllers on ATA/ATAPI devices from different vendors.
Some devices require word counter to be set to 0 when IDENTIFY command is issued. Other ones require
Some devices report error when IDENTIFY command is issued for the first time, but successfully
execute it if the commend imemdiately re-sent.
some HDDs with capacity greater then 32Gb (in particular my
Seagate Barracuda ATA 4, ST340016A, 40Gb) report their capacity as 32Gb by default
regardless of jumper position.
Thus, we should use special command to determine its true capacity
(see ATA specifications,
keyword="READ/SET NATIVE MAX LBA")
with LBA48 we have same problem on 128Gb. To get real HDD capacity we should use
"READ/SET NATIVE MAX LBA 48")
some HDDs with capacity less then 128Gb (in particular my
WDC WD800JB-00ETA0, 80Gb) report LBA48 support.
When READ NATIVE MAX LBA 48 is issued no error status is reported. But higher 24 bits are
returned equal to lower 24 bits.
if SataCapabilities (76th WORD in config block) is equal to 0xffff, than
SATA is either not supported, or this device is connected via IDE-SATA bridge.
In such case it worth to limit transfer rate to UDMA5 (UDMA-100).
some HDDs with LBA48 support. Have different operation behavior of different registers.
For example, on some HDDs if I write 0x55 to Feature register and immediately attempt to read it back, I'll
get previous value of this register. But if I do the same with BlockNumber register, I'll alway read back my 0x55
regardless of HDD. Such test write/read sequences are used for fast device detection. Described fact discovers
why all HDD tools use BlockNumber register, nut do not use other ones.
On some ATAPI devices we must wait for DRQ bit assertion if an error occured. On other ones
we shall experience timeout when waiting for DRQ in such case.
Some ATAPI devices generate operation completion interrupt significantly earlier than clear BUSY bit
in status register.
Some ATAPI devices generate operation completion interrupt earlier than clear BUSY bit
in status register when using PIO mode. The same time, same commands clear BUSY immediately after generating interrupt
if device is programmed to use DMA.
On some ATAPI devices when processing null-transfer commands in DMA mode generate operation completion interrupt significantly
earlier than clear BUSY bit in status register. The same time if switch device and controller to PIO, wait time becomes acceptable.
However, I don't understand why they keep BUSY set after interrupt. Set of pathalogical commands depends on device model.
ATAPI device + ATA controller
Some newer ATAPI devices start generating endless interrupts after controller reset
(write IDE_DC_RESET_CONTROLLER to AlternateStatus, make delay, write IDE_DC_REENABLE_CONTROLLER to AlternateStatus).
This problem appears at least on CMD-649, Intel ICHxxx and still one controller, which name I could not find in my notes.
That is why MS Windows XP drivers for CMD controllers hang if such CD/DVD drive is connected.
Further investigations shown that such interrupt must be reset with both reading base IDE status register and
writing BM_STATUS_INTR to DMA status register.
nForce controllers may hang if there is only one device connected to the channel and this device is
not selected before enabling interrupts after reset.
Some controllers return 0xff in status register instead of 0 when nonexistent device is selected.
Mail me here:
Mail to alterX@alter.org.ua (remove X)