lkml.org 
[lkml]   [2008]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.27 mtrr fixes do not work
    Yinghai Lu wrote:
    > On Mon, Aug 25, 2008 at 4:29 PM, Alexander Huemer
    > <alexander.huemer@sbg.ac.at> wrote:
    >> Yinghai Lu wrote:
    >>> On Mon, Aug 25, 2008 at 1:44 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
    >>>
    >>>> On Mon, Aug 25, 2008 at 1:24 PM, Alexander Huemer
    >>>> <alexander.huemer@sbg.ac.at> wrote:
    >>>>
    >>>>
    >>>>> what do you mean with tip/master?
    >>>>>
    >>>> http://people.redhat.com/mingo/tip.git/readme.txt
    >>>>
    >>>>
    >>>>> here is my .config: http://xx.vu/~ahuemer/config.txt
    >>>>>
    >>> using your config, i do get mtrr cleanup
    >>>
    >> very interesting, thx.
    >> so, what can i do to make it working here?
    >> are there some more debug options i could turn on?
    >>
    >
    > can you post whole boot log with command line
    >
    > console=uart8250,io,0x3f8,115200n8 debug show_msr=1
    >
    > assume you have serial console...
    >
    > YH
    yinghai,

    there are quite good news! 2.6.27-rc5 brought some significant changes.
    now i get this:

    # dmesg|grep -E "(mtrr|uvesafb)"
    Command line: root=/dev/sda1 video=uvesafb:1280x1024p-97,mtrr:2
    debug show_msr=1
    mtrr: your BIOS has set up an incorrect mask, fixing it up.
    Kernel command line: root=/dev/sda1
    video=uvesafb:1280x1024p-97,mtrr:2 debug show_msr=1
    uvesafb: XGI Technology, Inc., Volari Z9s, 1.09.10, OEM: XGI, VBE v3.0
    uvesafb: VBIOS/hardware supports DDC2 transfers
    uvesafb: monitor limits: vf = 97 Hz, hf = 129 kHz, clk = 364 MHz
    uvesafb: scrolling: redraw
    uvesafb: framebuffer at 0xd8000000, mapped to 0xffffc20002100000,
    using 10240k, total 32768k
    mtrr: 0xd8000000,0x2000000 overlaps existing 0xd8000000,0x800000
    # grep -E "(^\(WW\)|^\(EE\)|^\(NI\)|^\(??\))" /var/log/Xorg.0.log
    (WW) VESA(0): Failed to set up write-combining range
    (0xd8000000,0x2000000)
    # cat /proc/mtrr
    reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
    reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
    reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
    reg03: base=0xd8000000 (3456MB), size= 8MB: write-back, count=1
    # grep MemTotal /proc/meminfo
    MemTotal: 4041064 kB
    #

    which is much better than before, the total size of system memory is
    correct.
    the size of the graphics adapter memory is not correct.
    and AFAIK the memory ranges should be:

    ranges of system memory until the beginning of the graphics adapter
    memory is reached (in my case 0x00000000 - 0xd8000000).
    one range of the graphics adapter memory (0xd8000000, size 0x2000000).
    with write combining.
    remaining range of system memory (if applicable).

    is this correct, yinghai?
    so, something seems to be still wrong, X is still not satisfied, but i
    think the kernel hackers are on the right way.

    --
    regards
    alex


    \
     
     \ /
      Last update: 2008-08-29 17:13    [W:0.027 / U:30.848 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site