graphics on G4

[Justin Hibbits]

On Wed, Mar 04, 2009 at 09:13:10AM +1000, Peter Grehan wrote:
> Hi Justin,
> 
> >>What happens if we have physical or device memory in the
> >>same range as kmem VAs?
> 
>  This shouldn't happen: kmem VAs use seg regs 13 and 14 i.e.
> the virtually-mapped space is 0xD000.0000 -> 0xEFFF.FFFF.
> 
>  Kernel physical memory is 1:1 mapped, using BAT registers, as
> is i/o space. Since there are only 4 BAT registers used, a DSI
> trap will evict a BAT and re-use it, if the faulting address
> falls in the battable[] array. See
> powerpc/aim/trap_subr.s:dsitrap().
> 
>  Now, mapping the frame buffer from user-space *doesn't* use
> the BATs, but instead uses PTEs from user VA. Each process has
> unique segment register values which prevent it from
> corrupting memory in other address spaces (including the
> kernel's).

Seems something is overwriting kernel's memory.  Should I try simply removing
one of the RAM sticks and see if that fixes things?

> 
> >> > > >It seems like trying to modify it through the BAT map (as
> >> > > >zero/copy page, /dev/mem and friends do) will overwrite
> >> > > >random bits of KVA instead...
>  
>  Shouldn't do, since KVA doesn't occupy that space.
> 
> >I wrote a simple kernel module to print out BAT and segment
> registers, and the
> >output immediately following boot is:
> 
> >Later, and I don't know precisely what is meant by "later",
> registers 540 and 541 get changed to 0x4......., which
> >means the video memory gets un-BAT-mapped.
> 
>  That is probably a BAT spill, which should be harmless.
> 
>  None of the above helps, I know :( But it's outlining what
> should be happening.
> 
> later,
> 
> Peter.

- Justin