Re: VIA IDE driver, v1.5 (final)

From: Rask Ingemann Lambertsen (rask@kampsax.k-net.dk)
Date: Thu Jul 20 2000 - 09:25:28 EST


Den 18-Jul-00 00:12:39 skrev Vojtech Pavlik fĝlgende om "Re: VIA IDE driver, v1.5 (final)":

>I'll try to find the bit if it is there. I still don't have enough info
>(except for some T13 drafts) on how the 80-wire cable detection works in
>hardware. I don't like having to manually configure this either.

   Check the ATA/ATAPI 5 (draft?) specification, it is all in there. See
<URL:http://www.t13.org/>. The host adapter needs to support the cable
detection. There was some discussion about a method of letting the device
do the cable detection (something about adding a capacitor to the adapter),
but I think that idea was dropped pretty quickly.

>It could be the BIOSes just try UDMA66 and if they get CRC errors they
>fall back to a lower speed.

   Certainly yes, in an ideal (or at least better) world. But in practice,
you have this horrible construct commonly referred to as an IBM compatible
PC, which the T13 people would really like to be able to use ATA devices,
so lots of workarounds and pseudo-bogus solutions have been added over the
years to those that were already there from day one.

   A while ago, I asked on the T13 mailing list why you needed cable
detection in the first place when you have CRC checks, and thus know
exactly (at least after a few transfers) how good or bad the cable is. I
asked specifically if the CRC check used was too weak to allow you to
simply start out with the highest supported UDMA mode and then drop the
transfer rate if too many transfers failed the CRC check. The answer was
that the CRC check was fine for detecting transfer errors, but that this
method alone wouldn't work on a PC because the BIOS might not do enough
transfers to see any CRC errors before it would load (and transfer control
to) an OS which had no chipset specific support and would therefore be
unable to lower the transfer rate should CRC errors occur at a later point.
Also, there would be the possibility that the OS would not know that CRC
errors should be retried (since there was not such thing before UDMA), but
instead confuse them with media errors, so CRC errors had to be given a
"non-error" status bit. Of course, if the OS wouldn't be able to detect CRC
errors and retry, the BIOS needed to be able to configure an "error free"
transfer rate before loading the OS, and thus with very little opportunity
to gather sufficient CRC error statistics to do it properly. Thus the cable
detection hack. Besides, many (most?) BIOSes use just the PIO modes for
transfers for fear that the address translation service needed by DMA
transfers might not be working properly. Further, it was pointed out that
some adapter chipsets can only be programmed once per reboot or power cycle
and may even smoke if you try anyway.

   In short, only PC BIOSes need to worry about cable detection for
backward compatibility, Linux (or any other OS) doesn't have to as long as
it uses a driver capable of reducing the transfer rate if is sees to many
CRC errors (for some definition of "too many"). At least until WDC decided
to throw a nutwrench into the machinery with their not-quite-UDMA devices,
but I suppose they should be run at no more than UDMA mode 0.

> It could be the BIOS can ask the drive if it sees an 80-wire cable.

   The cables are not made in such a way that the device can tell the
difference between a 40-wire cable and a 80-wire cable.

Regards,

/ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\
| Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk |
| Please do NOT Cc: to me or the | WWW: http://www.gbar.dtu.dk/~c948374/ |
| mailing list. I am on the list.| "ThrustMe" on XPilot, ARCnet and IRC |
| You have not converted a man because you have silenced him. |

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:13 EST