>Number: 179113 >Category: misc >Synopsis: ATA DMA does not fall back on systems that misreport capability >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu May 30 16:20:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Majdi S. Abbas >Release: 9.1-RELEASE/i386 >Organization: Lattice, L.L.C. >Environment: FreeBSD procyon.latt.net 9.1-RELEASE FreeBSD 9.1-RELEASE #2: Wed May 29 16:01:42 UTC 2013 [email protected]:/usr/src/sys/i386/compile/NET4801 i386 >Description: The system in question is a Soekris NET4801, running from a Kingston CF card. This CF card reports DMA capability, which the internal PATA/CF adapter does not support.
As a result, when the kernel is booting, it will sit there and retry UDMA_66 access to the drive indefinitely. It claims to timeout after the 5th retry, but will, in fact, retry continuously. >How-To-Repeat: Attempt to boot (or access media) on any system that has an PATA-CF adapter that does not have the two additional pins required to support DMA. >Fix: While disabling DMA by handing hw.ata.ata_dma=0 to the loader works, NetBSD has an interesting approach here that requires no user intervention. I installed NetBSD 6.1/i386 on the same machine as a test, and the NetBSD kernel will attempt UDMA_66 3 times, and then fall back to UDMA_33, attempt 3 times, and then fall back to PIO mode. Something like this may make sense for FreeBSD, as it will reduce failures to boot or access media. >Release-Note: >Audit-Trail: >Unformatted: _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
