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. 

Hmm. OK. For some reason my two-year-old GDB and KGDB between them
aren't giving me a sensible backtrace today so I can't see precisely
what's happening. I accused take_over_console because my vague memory of
a debugging printk session the other day led me to believe that was the
case.

take_over_console (actually update_region()) is definitely doing
_something_ bizarre... there have been 34 lines of printk output since
boot, and it's rendering the 34th line 34 times, one on each of the top
34 lines of the new console.

> > >  
> > matroxfb: Pixel PLL not locked after 5 secs
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   
> This one is culprit. If you'll comment this message out, it will not
> crash.

OK; I'll try that in the morning.

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

Yes, it's fine. The hardware just seems to take a few seconds to
initialise after printing the console/matroxfb-related messages.

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

Answering that question will require compiling/obtaining fbset for SH3.
Tomorrow.

-- 
dwmw2