[lkml]   [2003]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: matroxfb console oops in 2.4.2x
    On 19 Jun 03 at 14:47, David Woodhouse wrote:
    > On Thu, 2003-06-19 at 13:21, Petr Vandrovec wrote:

    > take_over_console() attempts to redraw the screen.

    It is not take_over_console... It does init first.
    > > It is not allowed to call fbdev's putc
    > > before mode set was issued (at least I always believed to it; before
    > > first mode set hardware is in VGA state)
    > If I omit the fixes, I just get...
    > matroxfb: Matrox Mystique (PCI) detected
    > matroxfb: 1280x1024x8bpp (virtual: 1280x1635)
    > matroxfb: framebuffer at 0x1000000, mapped to 0xc017d000, size 2097152
    > matroxfb: Pixel PLL not locked after 5 secs

    This one is culprit. If you'll comment this message out, it will not

    > Console: switching to colour frame buffer device 160x64
    > fb0: MATROX VGA frame buffer device
    > If I call matrox_init_putc() earlier as you suggest, then it seems to
    > end up busy-waiting in mga_fifo()...

    Ok. It means that hardware is completely uninitialized when this happens.
    Probably accelerator clocks are stopped (== message about pixclocks was
    right...) Bad.

    Does driver work with your change without problems? It looks strange
    to me that PLL did not stabilized in 5 seconds. Do you get same message
    when you change videomode with fbset, or happens this only once during
    boot, and never again?
    Petr Vandrovec

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:36    [W:0.019 / U:23.072 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site