Date: Fri, 6 Mar 2009 07:06:26 -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: <20090306120626.GA12461@narn.knownspace> In-Reply-To: <49B0712B.1090109@freebsd.org> References: <20090304091310.EQW86822@dommail.onthenet.com.au> <20090304215257.GA8306@narn.knownspace> <49AF223C.5010907@freebsd.org> <20090305125438.GB8306@narn.knownspace> <49B0712B.1090109@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 05, 2009 at 06:41:15PM -0600, Nathan Whitehorn wrote: > 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 My card has 256MB of graphics RAM, and according to dmesg allocates that size block, plus 64k in the 256MB region before it. I haven't yet tested what address byte actually causes the crash, but that can be determined relatively easily. What I'm guessing, though, is writing to anything past (end - 32k) will cause the crash. I'll see if I can test this weekend. So, short answer to your question: it's not quite true for me, because it happens when I write to what should be inside graphics RAM. - Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090306120626.GA12461>