DragonFly users List (threaded) for 2005-03
Re: ATA anomaly Question
Matthew Dillon wrote:
:Testing various PATA & SATA controllers under DragonFlyBSD 1.1 STABLE of
:Add-on controllers, SATA:
:- booting may report in dmesg: 'DMA limited to UDMA 33, non-ATA66 cable
: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.
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
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'.