ATA anomaly Question

[Bill Hacker]

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 at 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