CompactFlash cards have been a popular choice for boot drives in embedded PC's for several years. Depending on the state/wiring of some configuration pins in its socket, a CompactFlash card can assume three essential modes of operation: "memory mapped", "IO mapped" and "True IDE". In True IDE mode, you can attach it to the IDE channel of any stock PC IDE controller (via an appropriate passive socket adaptor) and it behaves exactly like an IDE device, at least at the interface protocol level. (U)DMA is only relevant in the TrueIDE mode. Note that most photo cameras and USB readers access the cards in "memory mapped" mode, where the (U)DMA capability is irrelevant and is certainly not required for reaching the card's full speed.
Originally, CompactFlash cards in TrueIDE mode only supported PIO modes (up to PIO4) and did not support DMA (MWDMA, UDMA). The original/traditional "IDE" wiring of the CompactFlash socket reflected that status quo. Later on though, UDMA-capable CF cards have become available. If you buy an UDMA-capable CF card based on the past impression that there's nothing to go wrong with the True IDE mode, and based on the total lack of any warning in any relevant marketing and technical documentation, you have a good chance of suffering a nasty shock: you plug the card into your trusty CF-to-IDE socket, and the card appears dead!
The trouble is that, compared to PIO, the DMA modes (not just UDMA, but also MWDMA) need two more signals in the CF socket: DMA REQ and ACK. These two signals are nowadays commonly present in all "enhanced IDE" channels (usually integrated on-chip in the system south bridge), but many CF sockets on the market today lack those signals! In traditional IDE-enabled CF sockets, pin 43 is floating free and pin 44 is wired to +5V (power supply line). In a UDMA-capable socket, these should be wired to the UDMA signals, i.e. CF(43)->IDE(21) = DMA REQ and CF(44)->IDE(29) = DMA ACK.
(Click for a full-size image with pin labels)
Many of you have previously met the classic UDMA game of hide'n'seek consisting in 40wire vs. 80wire IDE cable, the automatic detection of a 40pin cable, some of you may have worked with a setup where the 40pin cable is not detected and the machine tries the higher UDMA modes (anything above UDMA2 = 33 MBps) and fails to operate reliably, some of you may have experimented with forcing higher UDMA modes on setups where a 40pin attach is normally detected, but the conductors are actually quite short and the higher transfer rates actually work... (ide_core.ignore_cable=[channel_number])
So, for those of you who are aware of that classic UDMA 40wire vs. 80wire stuff, note that this CF DMA/UDMA affair is quite a different story. If you try to run a DMA-capable CF card in an old PIO-only CF socket, the card doesn't work at all, UDMA2 doesn't help, not even MWDMA, and there's no salvation in automatic fallback to PIO. The CF card is identified by the BIOS and OS, but as soon as the BIOS or the OS attempts some UDMA transfer, that IO transaction immediately grinds to a screeching halt, maybe followed by a series of pathetic messages about timeouts and bus resets. Your only chance out of this mess is by forcing "PIO4 only" in some way, ahead of talking (U)DMA to the card at all (since the last power-up/reset).
Consequently, using a 40pin cable (CF socket wiring) doesn't help, as even that way, BIOS/Windows/Linux attempt the 40pin-compliant UDMA2 (33 MBps) and fail. There are also some higher-end CF cards of the past, featuring high transfer rates, yet uncapable of UDMA, but supporting MWDMA - those are guaranteed to fail as well, with identical symptoms.
Note that none of this can be blamed on the card. Blame it on the wiring of the CF socket. Try getting a 40wire "coarse" IDE cable and cut lines 21 and 29. Use that modified cable to attach a decent recent disk drive to a decent IDE controller (onboard Intel, discrete Promise or some such). Note that any disk drive attached using that cable fails in exactly the same way as your unfortunate CF Card.
There are cards on the market, that don't boast DMA capability in IDE mode on their label, yet they do support e.g. MWDMA. Those do not work in old sockets. OTOH, we've also seen cards labeled "Ultra4", which technically don't advertise any DMA capability at all :-) and obviosly these work just fine in PIO-only sockets. The next batch of cards with the same label do support UDMA.
If you want to know for sure, whether or not your card is (U)(MW)DMA-capable, boot Linux and ask the card via "hdparm -I /dev/hdc" (or wherever your CF card happens to sit). Obviously this only works in True IDE mode, i.e. on an IDE channel (not in a USB reader). And, you may need to tell Linux to avoid using DMA in the first place, for the respective IDE device, to be able to boot at all (see the Linux workaround below).
ide=nodma(MWDMA/UDMA disable on all IDE channels). Linux 2.6 in some earlier versions accepted e.g.
ide0=nodmafor the primary IDE channel. Latter Linux 2.6 versions accept an even more refined argument, in the format of
ide_core.nodma=x.y, where x = channel number and y = drive number, both of them zero-based. E.g.,
ide_core.nodma=0.1means "disable DMA for the primary slave". For permanent configuration, obviously you can put this on the "append" line in lilo.conf or just after the kernel image name in Grub's menu.lst. Note that historically the introduction of the latter ide_core.nodma syntax highly correlates with the moment when Libata became the default driver package even for parallel IDE in many Linux distributions. The ide_core.nodma only works for the legacy IDE driver stack, not for libata - so if your IDE drives and TrueIDE CF cards are all detected as sda/sdb/sdc/sdd etc (SCSI naming convention in Linux), rather than hda/hdb/hdc/hdd etc (IDE naming convention in Linux), try libata.dma=0 (or up to 2, which should allow DMA for all ATA devices except CFA). Alternatively, you can check your kernel's compile-time configuration, disable any Libata drivers for parallel IDE and enable the "legacy" IDE subsystem... then recompile and reinstall the kernel, which is a different story.