Re: Next round of console patches

Richard Gooch (rgooch@atnf.csiro.au)
Sun, 30 Aug 1998 11:22:59 +1000

Tom Eastep writes:
>
>
> >Gerd Knorr writes:
> >> [ lockup with vesafb + mtrr + Millennium 2MB ]
> >>
> >> > vesafb: framebuffer at 0xa0800000, mapped to 0xc8800000, size 2048k
> >>
> >> Ok, size is correct.=A0 Base address probably too, otherwise you
> >> would'nt see anything...
> >>
> >> Richard, any idea what is wrong there?=A0 vesafb will try to create a
> >> mtrr entry for the framebuffer: base=3D0xa0800000, 2 MB size.=A0 This
> >> locks the machine (which can be "fixed" by disabling mtrr in .config).
> >
> >Sorry, I haven't been following this thread. At what point does the
> >machine lock up? Is it as soon as the MTRR region is setup, or later
> >(such as when you do graphics operations or change video modes)?
>
> It appears that the lockup occurs when the video mode is changed during
> bootup).

OK, that would make sense if the write-combining is fouling up MMIO
register access. Can you please patch your kernel where it calls
mtrr_add() and add another call to mtrr_add() so that you set up a
small uncacheable region either at the beginning or the end of the
framebuffer?
With luck that will fix it. If it does, start trimming the uncacheable
region down in size until it fails again. That will tell you the
minimum size of the register region. If you're unsure of how big a
region to start with (say 4 kBytes still fails), make the entire
framebuffer uncacheable and step down in factors of two.

I'm afraid that this can be a rather tedious process. You can make it
easier by disabling the call to mtrr_add() and using the /proc/mtrr
interface manually. It will save editing and recompiling :-)

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html