Re: matroxfb console oops in 2.4.2x

["Petr Vandrovec" <VANDROVE@vc.cvut.cz>]

On 24 Jun 03 at 10:09, David Woodhouse wrote:
> On Thu, 2003-06-19 at 20:45, Petr Vandrovec wrote:
> > This one is culprit. If you'll comment this message out, it will not
> > crash.
> 
> As discussed, this is true but if anyone _else_ happens to call printk
> during the same period, it'll still crash. 
> 
> Matroxfb is registering a screen for which it's not yet willing to
> attempt output -- and taking out this printk only serves to fix the
> coincidence which makes it 100% reproducible -- the thing is still
> broken without that printk.

There is no way around - at least I do not know such. matroxfb cannot 
initialize hardware before call to the set_var, as otherwise you'll 
get white 80x25 square instead of vgacon text copied to the matroxfb.

If you'll replace matroxfb_set_var(..., -2, &ACCESS_FBINFO(fbcon))
with matroxfb_set_var(..., -1, &ACCESS_FBINFO(fbcon)) in matroxfb_base.c,
you'll get behavior you are asking for: hardware gets initialized before
call to register_framebuffer(). Unfortunately it breaks 
take_over_console for all vgacon users - and as there is more vgacon
users than sh users, I prefer just creating dummy putc/putcs functions
which will do nothing, over changing initialization order.

I'm still trying to find why PLL does not lock on your hardware,
but I still do not understand why it works on ia32 for secondary adapters,
but not on sh.
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz