lkml.org 
[lkml]   [2003]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.056 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site