graphics on G4

[Nathan Whitehorn]

Justin Hibbits wrote:
> 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?

I've just set up X on my laptop, and am seeing what I think is the same 
problem. The system is completely stable until I start X, at which point 
it will hang some random time later (ranging from seconds to hours), or 
have weird panics in the UMA allocator.

This is a G4 iBook with 1.5 GB of RAM. I instrumented ofw_syscons mmap() 
routine to check what memory X is using, and, besides the framebuffer, 
it appears to be mapping PCI configuration space for PCI bus 1 (the one 
that the MacIO ASIC is on, and not the one the graphics card is on). I 
can't figure out why. There are also no memory overlaps of the 
framebuffer -- neither with physical memory nor with KVA space.

Did you ever discover whether writing to random bits of the framebuffer 
without ever having run X also causes this problem?
-Nathan