ATA anomaly Question
Bill Hacker
wbh at conducive.org
Sat Mar 19 11:31:28 PST 2005
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
More information about the Users
mailing list