Re: matroxfb console oops in 2.4.2x

[David Woodhouse <dwmw2@infradead.org>]

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