An old controller in the aac driver family had a variation of this problem back when the FreeBSD contigmalloc algorithm started from the bottom of memory instead of the top. I worked around it at driver init time by basically assuring that page 0 (and page 1) were allocated and thrown away; it seemed easier to leak 8k of memory than to jump through expensive hoops in busdma.
The busdma filter is expensive, and is used so rarely that I'm not even sure it works. It was created for an old SCSI controller that had a buggy DMA controller which aliased a repeating pattern of address ranges; in other words it was a hack. It's expensive to use, since it forces every bus_dmamap_load() request through the slow path and possibly bouncing. With that said, your idea of a flag is probably a reasonable change for now. Alternatively, the ability to specify multiple DMA exclusion ranges has come up in the past, and would be a more complete answer to your problem; just treating page0 as special might not be enough (and I know for a fact that this is true with old i960RX pci processors). That'll involve an API change, so is something that I'd rather not happen on a whim. Scott On Jan 10, 2012, at 1:18 PM, Andriy Gapon wrote: > > > Some hardware interfaces may reserve a special meaning for a (physical) memory > address value of zero. One example is the OHCI specification where a zero > value > in CurrentBufferPointer doesn't mean a physical address, but has a reserved > meaning. To be honest I don't have another example :) but don't preclude its > existence. > > To deal with this peculiarity we could use a special flag/quirk that would > instruct the bus dma code to never use the page zero for communication with > the > hardware. > Here's a proof of concept patch that implements the idea: > http://people.freebsd.org/~avg/usb-dma-pagezero.diff > > Some concerns: > - not sure if BUS_DMA_NO_PAGEZERO is the best name for the flag > - the patch implements the flag only for x86 at the moment > - usb code uses the flag regardless of the actual controller type > > What do you think? > > -- > Andriy Gapon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
