Date: Wed, 22 Oct 2008 15:31:18 -0400 From: Justin Hibbits <jrh29@alumni.cwru.edu> To: freebsd-ppc@freebsd.org Subject: Re: graphics on G4 Message-ID: <20081022193118.GD2578@narn.knownspace> In-Reply-To: <48FE557C.5020207@freebsd.org> References: <20081022050101.EKN14563@dommail.onthenet.com.au> <48FE557C.5020207@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081022193118.GD2578>