graphics on G4

[Justin Hibbits]

On Tue, Mar 10, 2009 at 10:23:43PM -0500, Nathan Whitehorn wrote:
> Justin Hibbits wrote:
> > On Sat, Mar 07, 2009 at 03:23:54PM -0600, Nathan Whitehorn wrote:
> >> Justin Hibbits wrote:
> >>> On Fri, Mar 06, 2009 at 07:06:26AM -0500, Justin Hibbits wrote:
> >>>>>>> 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
> >>> Nathan-
> >>>
> >>> Attached is a simple program I wrote that just writes a straight line down the
> >>> first column of the framebuffer.  It reliably kills my system while running a
> >>> 'make buildworld' within a few minutes of running this program.
> >>>
> >>> (Possibly) Relevant Details:
> >>>
> >>> ATI Radeon 9600PRO, 256MB edition.
> >>> 1280x1024x8 framebuffer
> >>> 1.25GiB RAM
> >>>
> >>> - Justin
> >>>
> >> Thanks for the test. It looks like you've exposed a bug in how we mmap() 
> >> physical memory. It seems that if you try to write to the last page of 
> >> any mmap()ed physmem region, you get a panic in UMA. Using write(), on 
> >> the other hand, works just fine.
> >> -Nathan
> > 
> > Thanks for finding the actual problem.  I'll be a welcome guinea pig for testing
> > any patch for this.
> 
> Let me know if SVN revision 189675 (changes to powerpc/aim/mmu_oea.c) 
> solves your problem. It fixes the test program on my G4 iBook. 
> Apparently trying to unmap mmaped physical memory regions caused the 
> fictitious pages created by the VM to be deallocated from the wrong UMA
> zone, which was panicing the kernel.
> -Nathan

It seems to have fixed it.  The machine's been up for about an hour now, running
a make buildworld, and I've run in parallel a couple port builds, and started X
a few times, and it hasn't crashed yet.

Thanks for the fix, now all I need is DRI and I'll have everything I need for a
good workstation.

- Justin