re: CVS commit: src/sys/dev/pci

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

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