On Mon, 12 Dec 2011, matthew green wrote: > > On Mon, Dec 12, 2011 at 03:54:57PM +1100, matthew green wrote: > > > > > > > On Mon, Dec 12, 2011 at 02:44:15AM +0000, Jonathan A. Kollasch wrote: > > > > > Module Name: src > > > > > Committed By: jakllsch > > > > > Date: Mon Dec 12 02:44:15 UTC 2011 > > > > > > > > > > Modified Files: > > > > > src/sys/dev/pci: if_sip.c > > > > > > > > > > Log Message: > > > > > Using BUS_DMA_NOCACHE for bus_dmamem_map() causes issues on (at > > > > > least) sparc64. > > > > > > > > What kind of issues? > > > > > > this is maping normal memory uncached. attempting to access this > > > mapping causes data faults. > > > > Jonathan, please add some explanation to the commit message. > > > > Isn't this just covering a bug in the sparc64 bus_dma(9) implementation? > > that's what i have been wondering since writing the above. > > eeh, should we turn off CP/CV and E bits for ram BUS_DMA_NOCACHE > addresses, instead of device memory?
Hm. Let me look at that commit.... (cvsweb is slooooo today...) Let's see... BUS_DMA_NOCACHE went into the man page in 2003 based on an x86 machine specific bit... It was added to the sparc64 bus_dma.h at the same time... Replacing an existing MD BUS_DMA_NOCACHE that was added to in 2000... I can't figure out what the happened in x86 land... it seems to have moved across half a dozen files. So... The original BUS_DMA_NOCACHE for sparc64 had different semantics. It was supposed to be used for memory that is attached to the system through an I/O bus, such as the framebuffer on a PCI I/O card. The options are: 1) Remove the inherently MD BUS_DMA_NOCACHE flag from the man page so it's not used by people who don't understand why it's needed. 2) Properly define the semantics of BUS_DMA_NOCACHE so people know when it needs to be used. 3) Redefine that bit for sparc64. Eduardo