From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 8 19:34:43 2009 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8FC5106564A; Sun, 8 Mar 2009 19:34:43 +0000 (UTC) (envelope-from jrh29@alumni.cwru.edu) Received: from beta.eecs.cwru.edu (beta.eecs.CWRU.Edu [129.22.150.110]) by mx1.freebsd.org (Postfix) with ESMTP id 979498FC08; Sun, 8 Mar 2009 19:34:43 +0000 (UTC) (envelope-from jrh29@alumni.cwru.edu) Received: from narn.knownspace ([::ffff:69.250.50.210]) (AUTH: PLAIN jrh29, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by beta.eecs.cwru.edu with esmtp; Sun, 08 Mar 2009 12:06:43 -0400 id 00004717.49B3ED14.00000199 Date: Sun, 8 Mar 2009 12:07:16 -0400 From: Justin Hibbits To: Nathan Whitehorn Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <49B2E5EA.1030004@freebsd.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Peter Grehan , freebsd-ppc@freebsd.org Subject: Re: graphics on G4 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 19:34:44 -0000 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. - Justin