Re: ATA anomaly Question

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Matthew Dillon wrote:

> :
> :Testing various PATA & SATA controllers under DragonFlyBSD 1.1 STABLE of 
> :15 March:
> :
> :- Anomalies:
> :
> :Add-on controllers, SATA:
> :
> :- booting may report in dmesg: 'DMA limited to UDMA 33, non-ATA66 cable 
> :or device'
> :
> :None of the SATA controllers under test have PATA ports.
>
>    Just ignore it.  It's because our ATA driver isn't really all that
>    SATA-aware, so it is doing certain ATA checks that don't apply to
>    SATA.  The SATA controller ignores it.

Fine with me - so long as it doesn't actually downshift I/O rate-wise.
(which IIRC, the FreeBSD ones actually *did* do, at least early-on.
Ancient history now...)

> :Same message can also occur with actual PATA controllers when the cable 
> :is a proper UDMA-100,'
> :and can do so erratically when different 'race' of UDMA-100 drives are 
> :on same cables as Master/Slave.
> :..
> :Bill
>
>     Typically the cable is reversed (motherboard side is connected to the
>     drive and the drive side is connected to the motherboard) when the
>     message occurs for a standard PATA drive and the cable is 
>     UDMA-capable.
>     
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>

Most sockets & headets are keyed (blocked pin position) to prevent
that (at least on the better cables I try to use). Ground leads 'float'
at one end, are collected at the other end, IIRC.

Message doesn't (usually) occur in MB POST, BTW - only OS boot,
which is why I mentioned it.  Mixing older IBM/Hitachi masters
with newer Western Digital slaves can also cause it, even with
good cables, and on FreeBSD 4.10/11.

Was wondering if ACPI would get the same info from
a MB BIOS with HDD type set to 'AUTO' as from one
where the IDE discovery was done manually, then results
locked-in to the MB BIOS.

Not sure ACPI is even involved here, so the answer is
probably 'depends on the BIOS & ACPI compliance'.

Still testing....

Thanks,

Bill