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?
NEVER turn on the CP or E bits for DRAM. (I think it's the CP bit. Need to review the manual.) DRAM always goes through the E$ which does all the ECC checking. I/O addresses do not go through the E$. You have the choice of turning off the CV bit for DRAM, which means the data goes into the E$, but not the L1 D$ or I$. If you turn off the CP bit or turn on the E bit for DRAM you get data exceptions. If you turn on the CP bit for I/O addresses you get data faults. So don't do that. (BTW, the synchonization domain for UltraSPARC class machines is the E$. All DMA to DRAM goes through the E$.) Eduardo
