Bothersome X in First Use of LiveCD

Alexander E. Patrakov patrakov at ums.usu.ru
Thu Dec 22 07:11:01 PST 2005


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



More information about the livecd mailing list