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/
This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:32 EST