Messages in this thread | | | From | "Petr Vandrovec" <> | Date | Thu, 19 Jun 2003 21:45:44 +0200 | Subject | Re: matroxfb console oops in 2.4.2x |
| |
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. > > 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 at 0x1000000, mapped to 0xc017d000, 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. > 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? 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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |