lkml.org 
[lkml]   [2003]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: matroxfb console oops in 2.4.2x
    From
    Date
    On Thu, 2003-06-19 at 20:45, Petr Vandrovec wrote:
    > 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.

    Hmmm yes. The 'Pixel PLL not locked' message happens in the middle of
    take_over_console(), so if I do something stupid like trying to debug
    using printk instead of GDB, I get...

    <7>take_over_console starts
    <7>take_over_console calls save_screen()
    <crash>

    ... but if I make the Pixel PLL message KERN_DEBUG too, it continues...

    <7>matroxfb: Pixel PLL not locked after 5 secs
    <7>take_over_console calls update_screen()...
    <4>Console: switching to colour frame buffer device 160x64
    <7>take_over_console ends

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

    Indeed -- it won't crash _today_ if I do that.

    But the problem is not recursion -- the problem is that there is a time
    window during which _any_ printk (which could be from a timer or
    interrupt) would kill the box, because it seems the console is getting
    registered and allowing output before the hardware is fully initialised
    and ready to accept it.

    I don't know whether you consider this a bug in the generic console
    code, or a bug in matroxfb -- but removing the 'Pixel PLL not locked'
    message is only a workaround which serves to mask the real problem, so
    I'd advocate leaving it in for now until the problem is fixed correctly.

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

    The hardware _was_ completely uninitialised before matroxfb started,
    certainly.

    I'd sort of expect it to have been initialised before we attempt to
    register it as a console device though -- and even if it's OK to
    register a partially-initialised device because the console registration
    is supposed to perform the final initialisation by setting modes, etc.,
    then I'd _still_ expect it to be initialised before the console code
    actually lets any printk() through...

    > 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?

    Once during boot and never again.

    --
    dwmw2

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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