matroxfb console oops in 2.4.2x
Quoted 11 lines · David Woodhouse
Quoted 2 lines · Petr Vandrovec
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 [email protected]