Date: Tue, 10 Mar 2009 22:23:43 -0500 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Justin Hibbits <jrh29@alumni.cwru.edu> Cc: Peter Grehan <grehan@freebsd.org>, freebsd-ppc@freebsd.org Subject: Re: graphics on G4 Message-ID: <49B72EBF.9010001@freebsd.org> In-Reply-To: <20090308160716.GA1065@narn.knownspace> References: <20090304091310.EQW86822@dommail.onthenet.com.au> <20090304215257.GA8306@narn.knownspace> <49AF223C.5010907@freebsd.org> <20090305125438.GB8306@narn.knownspace> <49B0712B.1090109@freebsd.org> <20090306120626.GA12461@narn.knownspace> <20090307145708.GA1128@narn.knownspace> <49B2E5EA.1030004@freebsd.org> <20090308160716.GA1065@narn.knownspace>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49B72EBF.9010001>