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