I wrote > Okay, I've tried some experiments. [...]
Found it. Nothing at all to do with bus_dma. The actual fix is bus_space_write_4(sc->lcr_t,sc->lcr_h,PLX9080_DMATHR, ( 7 << PLX9080_DMATHR_C0PLAF_S) | ( 7 << PLX9080_DMATHR_C0PLAE_S) | ( 4 << PLX9080_DMATHR_C0LPAE_S) | - (10 << PLX9080_DMATHR_C0LPAF_S) | + ( 1 << PLX9080_DMATHR_C0LPAF_S) | ( 4 << PLX9080_DMATHR_C1PLAF_S) | ( 4 << PLX9080_DMATHR_C1PLAE_S) | ( 4 << PLX9080_DMATHR_C1LPAE_S) | - ( 4 << PLX9080_DMATHR_C1LPAF_S) ); + ( 1 << PLX9080_DMATHR_C1LPAF_S) ); That register is DMA thresholds: the 9080 doesn't even request the PCI bus for DMA until it has at least that many samples pending. (There are two numbers changed because there are two channels; this application doesn't use one of them, but rather than fiddle around with that I just set it the same for both channels.) Apparently it's willing to sit on data indefinitely if the thresholds aren't reached. My apologies to everyone for the noise and for (spuriously, albeit implicitly) casting doubt on the bus_dma infrastructure - and my thanks, again, to everyone who took time and brain cycles to help me with this. I just feel really really stupid that it's taken me multiple months to remember that the hardware even _has_ that register and realize that it could be relevant. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B