From owner-freebsd-ppc@FreeBSD.ORG Fri Mar 6 12:06:02 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 E8FCF10658C0; Fri, 6 Mar 2009 12:06:01 +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 803228FC1A; Fri, 6 Mar 2009 12:06:01 +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; Fri, 06 Mar 2009 07:05:59 -0500 id 00007D0C.49B111A8.0000672A Date: Fri, 6 Mar 2009 07:06:26 -0500 From: Justin Hibbits To: Nathan Whitehorn Message-ID: <20090306120626.GA12461@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <49B0712B.1090109@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: Fri, 06 Mar 2009 12:06:20 -0000 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