graphics on G4
Justin Hibbits
jrh29 at alumni.cwru.edu
Fri Mar 6 04:06:20 PST 2009
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
More information about the freebsd-ppc
mailing list