Date: Wed, 04 Mar 2009 18:52:12 -0600 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Justin Hibbits <jrh29@alumni.cwru.edu> Cc: Peter Grehan <grehan@freebsd.org>, freebsd-ppc@freebsd.org Subject: Re: graphics on G4 Message-ID: <49AF223C.5010907@freebsd.org> In-Reply-To: <20090304215257.GA8306@narn.knownspace> References: <20090304091310.EQW86822@dommail.onthenet.com.au> <20090304215257.GA8306@narn.knownspace>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49AF223C.5010907>