This message is from the T13 list server.
So the way I read the spec is the host has the
option to retry the command using any of the host/drive
supported transfer options.
That could be:
1) Retry using the same UDMA transfer Mode
2) Reconfigure for a slower UDMA and retry the transfer
3) Reconfigure for a MWDMA transfer and retry the transfer
4) Retry using a PIO cycle (do not need to reconfigure)
Retry problem areas:
Given the signal integrity on the ATA bus is VERY pattern dependent,
1) retrying the cycle using the same transfer mode is NOT very useful
2) retrying the cycle using a lower speed UDMA cycle helps if it
was a setup violation, but if the host/device does not allocate
some of the additional time afforded by a slower transfer
mode to hold time, this option will not get you past
a hold time violation (timing, or noise)
I have seen a number of device controllers recently that use
5 ns of hold time for ALL UDMA Modes. This is fine
for Mode [5], but a complete VIOLATION for Mode [2 or 0]
3) Reconfiguring for MWDMA is a pain, as you have to do it
before you retry the cycle and after you complete the
cycle (given you don't want to permanently downshift)
Downside: No CRC checking
4) Retrying in PIO can be done just by using a different command
and you don't have to reconfigure the system or the drive.
Downside: No CRC checking
Upside: If using PIO Mode [0] you have the most amount of
setup time.
Jeff's recommendation:
1) Retry the cycle in PIO Mode [0], but leave normal
transfers at ATA UDMA Mode [N]
2) If you get more than 6 CRCs, then shift to UDMA Mode [N-1]
retry the cycle in PIO Mode [0], but normal
data transfers will now use mode [N-1]
3) If you get more than 6 CRCs, and you are already down
to UDMA Mode [0], then downshift to PIO Mode [0]
Why not switch to MWDMA ?
Several reasons:
MWDMA does not have CRC checking
UDMA Mode [0], generally has more than TWICE
the Valid window (setup + hold) over
MWDMA Mode [2] even though both have a sustained
transfer rate of 16 MB/s.
I would NOT suggest a REQUIRED retry sequence as OSs and hosts
have different requirements
Just my humble opinion.
Jeff
Jeff Wolford Email: [EMAIL PROTECTED]
Senior Storage Architect
Storage Interface and Tools - PC Storage Group
Voice: (281) 514-9465, Pager: (800) 973-5739
Compaq Computer Corporation
> -----Original Message-----
> From: Paul Walker [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 11, 2001 9:58 AM
> To: [EMAIL PROTECTED]
> Subject: [t13] UDMA 'recovery procedure'
>
>
> This message is from the T13 list server.
>
>
> Hi all,
>
> Jeff mentioned recovery procedures (albeit in a different
> context), which
> reminded me.
>
> I've been having a look through the ATA-5 specification for
> DMA recovery
> procedures. Admittedly I haven't gone over the entire thing,
> but in the
> details of the DMA protocol, DMA WRITE commands, and the UDMA
> CRC stuff, the
> only references to errors I can find are:
>
> 1) "For READ DMA, WRITE DMA, READ DMA QUEUED, or WRITE DMA
> QUEUED commands:
> When a CRC error is detected, the error shall be reported by
> setting both
> ICRC and ABRT (bit 7 and bit 2 in the Error register) to one. ICRC is
> defined as the "Interface CRC Error" bit. The host shall
> respond to this
> error by re-issuing the command."
>
> Is this a requirement, that the host shall keep re-issuing
> this command? If
> so, how many times must it fail before the host can
> reasonably be expected
> to give up?
>
> Presumably (following the note given at the end of the CRC section,
> reproduced below) it should have fallen back to mode 0 before
> giving up? Any
> rules of thumb as to what 'excessive' should mean? :-)
>
> "NOTE - If excessive CRC errors are encountered while operating in an
> Ultra mode, the host should select a slower Ultra mode."
>
>
> Also, in the details of the DMA protocol:
>
> 3) "Transition HDMA0:HI0: When the BSY is cleared to zero and
> DRQ is cleared
> to zero, then the device has completed the command and shall make a
> transition to the HI0: Host_Idle state (see Figure 19). If an error is
> reported, the host shall perform appropriate error recovery."
>
> No details on "appropriate error recovery" are given, either
> in the protocol
> details or in the command details. Is this purely restricted
> to the UDMA CRC
> checking at present, or did I miss something?
>
> Thanks,
>
> --
> Paul
>
> STMicroelectronics, Tel: (01454) 462454
> 1000 Aztec West, Almondsbury, Fax: (01454) 617910
> Bristol BS32 4SQ
> Subscribe/Unsubscribe instructions can be found at www.t13.org.
>
Subscribe/Unsubscribe instructions can be found at www.t13.org.
