This document is intended for facts so disappointing and ugly that they could never appear in any standards document. The question marks ask for confirmation. Suggested updates should be mailed to me.
Updated 04/17/2001
Not all devices setup the ATAPI signature correctly after reset and software reset. For some devices, the Sector Count register is not always set to 1. The safest thing to do is to just check the Cylinder Low (=0x14) and Cylinder High registers (=0xeb).
Discussions on the t13 mailing list suggest that the IO and CD bits are not correctly set by many ATAPI devices. Instead, the host needs to know a priori the direction of the transfer. With this information, it can use the BSY and DRQ bits to determine which phase of the command protocol it is in.
This warning should be taken with a grain of salt. The Windows NT, Linux, NetBSD, and OpenBSD drivers all use the IO and CD bits to the phase of the device. All these drivers make sure to sanity check the IO and CD bit in case the drive does something unusual (like signals that data is to travel from the host on a read command). I do not personally know of any device which fails when relying on IO and CD bits.
Some drivers poll ATAPI devices instead of waiting for interrupts. Unfortunately, on PACKET commands, some devices drop BSY long before transitioning to being ready for the next phase.
Some devices, despite dropping BSY, actually maintain the DRQ, IO, and CD bits correctly. A driver can determine what phase the PACKET command is in by examining those bits.
However, if a device does not correctly maintain the DRQ, IO, and CD bits, then OpenBSD may not reliably work with it.
The OpenBSD driver keeps polling a device in case the device indicates a state that the driver did not expect. Unexpected states include invalid or unexpected phases, data transfers in the wrong direction, and zero-length data transfers. I have not confirmed that doing this actually improves reliability.
The driver does not carefully check the phase for the command phase of the PACKET command. It assumes that the first assertion of DRQ is a request for the command packet.
DEVICE RESET is not implemented completely by all ATAPI devices. For example, in many cases, if BSY=1 or DRQ=1, the drive will not react to writes to the command register. I speculate that this is due to ATA chips that ignore writes to the command register when BSY or DRQ=1.
The only way to get past this block is to issue an ATA Software Reset (SRST). This will clear BSY and DRQ and allow you to issue a DEVICE RESET to the ATAPI drive.
Some ATAPI devices clear BSY after reset before they are ready to accept commands. They will abort any command sent, or worse, hang. As such, after a DEVICE RESET, drivers will wait between 50 milliseconds and 1 second for a drive to get its bearings. Some devices take longer if there is media in them.
To prevent BIOSes from detecting ATAPI devices as ATA devices, ATA/ATAPI-4 define modes where DRDY is disabled. Unfortunately, some devices have never implemented DRDY handling correctly so all ATAPI drivers ignore DRDY.
Some devices do not support the SCSI REQUEST SENSE command for returning extended sense information. The host must use the upper four bits of the error registers as the sense key in that situation.
Some older CD-ROMs return a device type of 0 (disk drive) rather than 5 in response to ATAPI Inquiry and Identify Packet Device.
Normally, the vendor, serial #, etc., from IDENTIFY PACKET DEVICE needs to be be byte-swapped in 16-bit chunks to yield the correct ASCII string. The strings are returned from the drive on the 16-bit data register. The first byte of the string appears on bits 15:8 and the second byte in bits 7:0. On the next read of the data register, bits 15:8 represent the third byte, bits 7:0 the fourth byte, and so on. For example:
1 1 1
5 8 7 0 5 8 7 0 5 8 7 0
+---+---+---+---+---+---+
| A | T | A | P | I | |
+---+---+---+---+---+---+
But, remember that sixteen-bit words get written on little-endian
architectures as follows:
Memory Location: 1000 1001 1002 1003
+------+------+-----+-----+
| T | A | P | A |
+------+------+-----+-----+
Bits: 7 0 15 8 7 0 15 8
So, the string in memory needs to be byte-swapped to yield the original
string (at least on little-endian architectures).
However, certain CD-ROM drives from NEC, Mitsumi, and Pioneer, return the strings in the opposite byte order. This can be detected by looking for "NE" or "FX" or "Pi" in the first 2 bytes of the unswapped model field. The strings in the IDENTIFY PACKET DEVICE data on these drives should not be swapped.
Some CD drives return and accept MSF information as a binary-coded decimal instead of a straight binary value. This can be detected on some drives when the table of contents indexes skip from entry 0x09 to 0x10 (instead of 0x0a).
In a device 0-only configuration, ATA/ATAPI-4 requires that device 0 respond to any reads of the non-existant device 1's status or alternate status registers with 00h. In contrast, SFF 8020i r2.6 suggests that the device 0 return either its own status or some faked status.
An SFF 8020i r2.6 compliant device will abort any command sent to a non-existant device 1. An ATA/ATAPI-4 compliant device will silently ignore such commands and keep status at 00h.
Some ATAPI device 0s float the bus when a non-existant device 1 is selected.
Note that ATAPI device 0s that don't keep a separate copy of the error and status registers for drive 1 may continue to show those error conditions when switching back to drive 0.
In this scenario, there is one ATAPI device on the chain and it is device 0.
An ATAPI device exhibiting this flaw will respond to commands sent to the device 1. This leads the host software to believe that there are two ATAPI devices on the chain, when in fact, there is only one.
There are no software work-arounds for this problem.
The drive light is directly connected to the DASP-/PDIAG- signal on the IDE bus. The PDIAG- signal is used by device 1 to indicate its presence on the bus to device 0 upon Hardware RESET, SRST, and Execute Device Diagnostic.
Most ATAPI devices will de-assert PDIAG- upon receiving an ATA command after reset. However, some devices seem to require a PACKET COMMAND before they deassert PDIAG-. Others seem to require a DEVICE RESET.
Some SCSI commands return less data than the host allocated for the response. With DMA transfers, the drive indicates that it has no more data to send the host by asserting an interrupt. It seems that some host adapters either ignore or lose this interrupt (or perhaps some devices fail to signal the interrupt). The adapters hang waiting for the device to accept or request more data.
Probably the best work-around here is to limit DMA transfers to reads and writes where the number of bytes transferred is well known.
The chiplist here has info about various host bugs.
Access to device registers (such as the ATA status register) is best avoided when the bus-master is active. This can lead some chips to lock up if the device is slow to respond.