matroxfb console oops in 2.4.2x
Quoted 3 lines · David Woodhouse
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.
Quoted 10 lines
Quoted 3 lines
It is not allowed to call fbdev's putc
before mode set was issued (at least I always believed to it; before first mode set hardware is in VGA state)If I omit the fixes, I just get...
matroxfb: Matrox Mystique (PCI) detected
matroxfb: 1280x1024x8bpp (virtual: 1280x1635)
matroxfb: framebuffer at0x1000000, mapped to0xc017d000, size 2097152
matroxfb: Pixel PLL not locked after 5 secs
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This one is culprit. If you'll comment this message out, it will not crash.
Quoted 5 lines
Console: switching to colour frame buffer device 160x64
fb0: MATROX VGA frame buffer deviceIf I call
matrox_init_putc()earlier as you suggest, then it seems to end up busy-waiting inmga_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? 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?
Thanks,
Petr Vandrovec
Quoted 6 lines · Petr Vandrovec
Quoted 3 lines · David Woodhouse
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.
Quoted 6 lines
Quoted 2 lines
Quoted 1 line
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.
Quoted 11 lines
Quoted 5 lines
Console: switching to colour frame buffer device 160x64
fb0: MATROX VGA frame buffer deviceIf I call
matrox_init_putc()earlier as you suggest, then it seems to end up busy-waiting inmga_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.
Quoted 3 lines
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.
Signature · 1 line
dwmw2
Quoted 6 lines · Petr Vandrovec
Quoted 3 lines · David Woodhouse
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
Quoted 2 lines
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.
Quoted 3 lines
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...
Quoted 4 lines
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.
Signature · 1 line
dwmw2
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.
Signature · 1 line
dwmw2