Date: Thu, 05 Mar 2009 18:41:15 -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: <49B0712B.1090109@freebsd.org> In-Reply-To: <20090305125438.GB8306@narn.knownspace> References: <20090304091310.EQW86822@dommail.onthenet.com.au> <20090304215257.GA8306@narn.knownspace> <49AF223C.5010907@freebsd.org> <20090305125438.GB8306@narn.knownspace>
next in thread | previous in thread | raw e-mail | index | archive | help
Justin Hibbits wrote: > 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. My card, at least, has a framebuffer BAR that is 128 MB long, but only actually has 32 MB of graphics RAM. Writing anything to that 32 MB does not cause problems, but of course writing beyond that kills the machine, since that memory region does not actually exist. Is this true for yours as well? -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49B0712B.1090109>