From owner-freebsd-ppc@FreeBSD.ORG Wed Oct 22 19:31:46 2008 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 81A761065679 for ; Wed, 22 Oct 2008 19:31:46 +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 31F2F8FC2B for ; Wed, 22 Oct 2008 19:31:46 +0000 (UTC) (envelope-from jrh29@alumni.cwru.edu) Received: from narn.knownspace ([::ffff:69.140.221.138]) (AUTH: PLAIN jrh29, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by beta.eecs.cwru.edu with esmtp; Wed, 22 Oct 2008 15:31:44 -0400 id 00005D30.48FF7FA1.00005114 Date: Wed, 22 Oct 2008 15:31:18 -0400 From: Justin Hibbits To: freebsd-ppc@freebsd.org Message-ID: <20081022193118.GD2578@narn.knownspace> References: <20081022050101.EKN14563@dommail.onthenet.com.au> <48FE557C.5020207@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <48FE557C.5020207@freebsd.org> User-Agent: Mutt/1.5.18 (2008-05-17) 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: Wed, 22 Oct 2008 19:31:46 -0000 On Tue, Oct 21, 2008 at 05:19:40PM -0500, Nathan Whitehorn wrote: > Peter Grehan wrote: > > Hi Justin, > > > > > >>> The framebuffer uses a large chunk of kernel VM when mmap'd. > >>> Are you able to dump some vm stats while doing this e.g. > >>> sysctl vm.kvm_free ? > >>> > > > > I shouldn't hit send before the morning coffee :( mmap'ing > > uses process VM, not kernel, except for the extra alloc's > > needed for this but these should all come from the non-KVA UMA > > small malloc area. > > > One thing that worries me about our PMAP layer could cause this. This > machine has a lot of RAM. What happens if we have physical or device > memory in the same range as kmem VAs? It seems like trying to modify it > through the BAT map (as zero/copy page, /dev/mem and friends do) will > overwrite random bits of KVA instead... > -Nathan I'm not sure where all the RAM lies, but according to ofwdump, the base address of the video memory is 0xa0008000 -- a rather strange address, being 32k offset from base. I'm not sure what the whole memory map is, though. Is there an easy way to get this? I'll run the 0xdeadc0de test in a couple weeks when I get back from vacation, since I don't know if it'll have crashed before I leave, because it's not an instantaneous crash, it just happens -- minutes, hours, or days, either while running or after exiting the "offending" program. - Justin