From owner-freebsd-ppc@FreeBSD.ORG Thu Mar 5 00:51:09 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 0C0B3106566C; Thu, 5 Mar 2009 00:51:09 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id D2DF68FC18; Thu, 5 Mar 2009 00:51:08 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) id <0KG000G00D18N500@smtpauth1.wiscmail.wisc.edu>; Wed, 04 Mar 2009 18:51:08 -0600 (CST) Received: from trantor.tachypleus.net (adsl-99-154-1-172.dsl.mdsnwi.sbcglobal.net [99.154.1.172]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KG000G4BD16EU00@smtpauth1.wiscmail.wisc.edu>; Wed, 04 Mar 2009 18:51:07 -0600 (CST) Date: Wed, 04 Mar 2009 18:52:12 -0600 From: Nathan Whitehorn In-reply-to: <20090304215257.GA8306@narn.knownspace> To: Justin Hibbits Message-id: <49AF223C.5010907@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=99.154.1.172 X-Spam-PmxInfo: Server=avs-13, Version=5.5.1.360522, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2009.3.5.3421, SenderIP=99.154.1.172 References: <20090304091310.EQW86822@dommail.onthenet.com.au> <20090304215257.GA8306@narn.knownspace> User-Agent: Thunderbird 2.0.0.19 (X11/20090126) 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: Thu, 05 Mar 2009 00:51:09 -0000 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