This message is from the T13 list server.
On Wed, 08 Jan 2003 02:07:29 +0000, Steve Ambrose wrote: >This message is from the T13 list server. >1. What is the behavior of IDE drives when they encounter a CRC error? >In particular , on dma writes is the write data discarded. The >specification does not make any mention of this. In ATA/ATAPI-x find the section named "Ultra DMA CRC Rules" - In a copy of ATA/ATAPI-5 I have here it is section 9.15 (may be the same section number in ATA/ATAPI-6). Don't forget that a single R/W DMA command may result in one or many DMA bursts. In Ultra DMA there is a CRC for each DMA burst. The standard says a device may terminate the command as soon as a CRC error is detected or the device may complete the command's data transfer (the latter could result in additional CRC errors but it doesn't matter). Either way the device must end the command with error status (ERR=1 ICRC=1). Like all ATA commands, none of the data transferred is "valid" and the entire command must be retried. That is for a Read command that ends in a ICRC error *none* of the data received by the host is "valid". For a Write command the host must assume that *none* of the data received by the device is "valid" (the device did not write any of the data to the media). >2. Are there any conditions apart from wrong crc value when the ICRC error >bit of the error register can get set ? The problem I am seeing is that even though >interface timing is ok and crc value is correct, crc error is being reported. Sounds a little strange to me. You checked every single word of data that was transferred, you computed what the expected CRC value(s) should be for each DMA burst and that matched the CRC word(s) that were sent from the host to the device at the end of each DMA data burst? There could be some devices that also use ICRC to signal other types of data transmission errors (but I don't know of any). >3. Can a CRC error be generated if the task file registers are >read/modified while dma is in progress ? NO. If such a thing did happen then you would have a broken host or broken device. See the IOR/IOW response tables in section 7 of ATA/ATAPI-x. There you will see that while DMACK is asserted there can be no access to the registers (because the CSx and DAx signals are "disabled"). And even during the execution of a DMA command when DMACK is not asserted the host may read the registers and the device shall ignore a write to the registers (except that DEVICE RESET thing) - this is all because at this time the device will have BSY=1 or BSY=0 DRQ= (because there is a command in progress). However... Who knows if all the PCI ATA controllers shipping today have been completely tested. I know of older controllers that had the habit of corrupting data in their internal FIFOs if the host side did an unexpected R/W of a register (like the Status register) during PIO and/or DMA data transfers. Hale *** Hale Landis *** www.ata-atapi.com ***
