Archaic wrote:
That's a bit hasty. vga=792 only affects console. In every system I've
tested the livecd on, the proper (e.g. ati or nv) driver was selected
even though I chose a framebuffer console. Are you saying that the X
video driver isn't properly resetting the video card or that the
framebuffer is still in control of the MTRR even when X has taken over?
Any video card has some video memory. The CPU wants to write to this
memory, and uses special MTRR registers for defining the caching policy,
i.e. if it is allowed to reorder or delay the writes. For video memory,
the proper setting is write-combining for the whole video RAM. vesafb
makes an uneducated guess about the amount of video RAM and (in linux <
2.6.15) sets the write-combining MTRR for its guessed amount of memory.
Then the X server wants to set the (correct) MTRR for the whole range of
video memory, and fails because its MTRR overlaps with the bad one set
by vesafb. This results in slow video memory access.
In linux-2.6.15-rc?, framebuffer drivers no longer set MTRRs unless
explicitly told to do so, and the "uneducated guess" problem no longer
exists.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/livecd
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
