This message is from the T13 list server.
Well how in gods green earth (sorry to any pagans out there) can your original proposal (in this thread) do what you are now suggesting (indicate how many words transferred)? When you first started this thread you said you wanted a simple state machine that says something started moving, versus DMA PRD count hit, and DMA PRD count exceeded? Adding a "something moved" indicator really doesn't do what you are now saying, which is how much. You're bait-and-switching this discussion, so pick your side and stick to it! MKE. -----Original Message----- From: Hale Landis [mailto:[EMAIL PROTECTED]] Sent: Monday, February 11, 2002 10:24 PM To: T13 List Server Subject: RE: [t13] a proposal - lets fix the DMA host problem This message is from the T13 list server. On Mon, 11 Feb 2002 11:09:57 -0800, Eschmann, Michael K wrote: >This message is from the T13 list server. >1. Case 00 and 01 are represented by the "Interrupt/Active" bits set as 0/1 >(respectively). No, sorry, the Interrupt/Active bits only say if the DMA engine is "active" (aka "running") they DO NOT tell the host if any data has been tranferred. It is the problem of determining if data was transferred and how much data was transferred that we are trying to solve here. >I don't see what is better about knowing "controller has >transferred some data" from "controller is active". The current DMA engine design allows a command to "start" and "end" with no data or only part of the data actually transferred and the host side has no way to know that. This is a serious data integrity problem and until it is fixed I don't see how anyone can implement high reliability high availability system using ATA/ATAPI DMA. The x86 world needs to wake up and address these issues or face the possibility that x86 systems might become known as unreliable and prone to undetected data corruption. >2. Case 10 are represented by the "Interrupt/Active" bits set as 1/0 >(respectively). OK, I will buy that. >3. Case 11 should not happen since this should be reported by the HBA as an >error condition. And, I don't see how hardware can possibly transfer more >than is represented in the PRD. In the case of U-DMA where the device sends a few extra words in the last DMA burst before stopping are you saying this will be reported as an error? I have never seen that documented????? Please explain!!!!! >If the PRD list is empty, we take away >DACK#, stopping all transfers. I also thought that we went through the >rathole where the extra data can occur at intermediate stopping points, but >not at the end of the transfer. Yes, there can be extra data sent to the host by a device at the end of any U-DMA data burst and that includes at the end of the last DMA data burst. This would normally be considered an error because clearly the host was not expecting the data the device is trying to send. >Additionally, if the Error bit in the status register is set then the >controller has some problem transferring data to/from memory. Specifics of >the error have to be determined using bus-specific information. If the >Error bit is not set and the "Interrupt/Active" bits are set as 1/1 then the >PRD's specified a smaller size than the IDE transfer size. Maybe. But with U-DMA the device may have send a few extra words before asserting INTRQ and the PRD list may not have been long enough to store those bytes. The U-DMA protocol says the receiver ignores these bytes (except for the CRC check). But again this is a data integrity problem. Please think about all the possible "race" conditions that can exist with U-DMA and you will see there are a few cases of possible "lost" or "extra" data. >So I don't see directly how your proposal is any better than what we have >now. I'm sure your gonna tell me, so "Sock it to me, baby"! I was only trying to get ATA host adapter designers to provide more information to the host software concerning the amount of data actually transferred without asking again for a byte/word counter. No one seems to want to implement a byte/word counter for this purpose. As I said, my proposal is not a complete solution but for most ATAPI DMA transfers it would provide the missing information needed by the host to insure reliable data transfers. As a side note... I continue to be amazed by the lack of concern for designing high reliability and high availability PC systems. Today's PC systems are toys and should be treated as such. No one should be using them for mission critical applications... You will never know if or when your critical data is lost or corrupted. Sigh... Why do we have to rediscover all the things that computer system designers knew about 50 years ago? Think about it... Why does IBM still sell huge numbers of their mainframe computers? Answer: Because these systems are designed to protect customer data. The most minor hardware or software failure is reported and logged. Yes... The mainframe OS reports, logs and even recovers from software errors (and they have been doing that for 20 years). I would bet that if you wanted to re-boot your bank's mainframe you would have to schedule that a few weeks in advance and it would happen only in the middle of the night. No kidding folks! A mainframe that is down for more than a few minutes a year is considered an unreliable system. *** Hale Landis *** www.ata-atapi.com *** Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
