graphics on G4

[Justin Hibbits]

On Thu, Mar 05, 2009 at 06:41:15PM -0600, Nathan Whitehorn wrote:
> Justin Hibbits wrote:
> > On Wed, Mar 04, 2009 at 06:52:12PM -0600, Nathan Whitehorn wrote:
> >> 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
> > 
> > Yes, I did perform that test, and it does cause the problem as well.  For me it
> > hangs when starting a new process some time later, so can be tested somewhat
> > easily by performing a buildworld after doing the graphics test.
> 
> My card, at least, has a framebuffer BAR that is 128 MB long, but only 
> actually has 32 MB of graphics RAM. Writing anything to that 32 MB does 
> not cause problems, but of course writing beyond that kills the machine, 
> since that memory region does not actually exist. Is this true for yours 
>   as well?
> -Nathan

My card has 256MB of graphics RAM, and according to dmesg allocates that size
block, plus 64k in the 256MB region before it.  I haven't yet tested what
address byte actually causes the crash, but that can be determined relatively
easily.  What I'm guessing, though, is writing to anything past (end - 32k) will
cause the crash.  I'll see if I can test this weekend.

So, short answer to your question: it's not quite true for me, because it
happens when I write to what should be inside graphics RAM.

- Justin