On Wed, 20 Oct 2004, Peter Seebach wrote:
> Followup:  It turns out that the problem is that some modern CF cards report
> themselves capable of DMA, because they are, and the IDE controller may
> also be capable of DMA - but the actual wires to make it work aren't
> installed, because everyone knows CF cards don't have DMA.  So you need
> the flags set on wd0 to tell it not to use DMA, and all is well.  Yay for
> the Soekris-tech list.

My problem must be different then. according to an rcsdiff of the
versions of my dmesg.boot from before and after the hardware change (see
PR 27274 for the code), nothing relating to the drives' DMA capabilities
changed:

-wd0 at atabus0 drive 0: <HITACHI_DK23EB-40>
+wd0 at atabus0 drive 0: <FUJITSU MHT2060AT>
 wd0: drive supports 16-sector PIO transfers, LBA addressing
-wd0: 38154 MB, 77520 cyl, 16 head, 63 sec, 512 bytes/sect x 78140160 sectors
+wd0: 57231 MB, 116280 cyl, 16 head, 63 sec, 512 bytes/sect x 117210240 sectors
 rnd: wd0 attached as an entropy source (collecting and estimating)
 wd0: 32-bit data port
 wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
 wd0(piixide0:0:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using DMA data transfers)
 
--apb (Alan Barrett)