On 19 Jun 03 at 11:06, David Woodhouse wrote:
> Below is a workaround which lets the machine boot. It's obviously not a
> fix.
>
> --- drivers/video/matrox/matroxfb_accel.c~ Wed Jun 18 17:16:40 2003
> +++ drivers/video/matrox/matroxfb_accel.c Thu Jun 19 10:57:54 2003
> @@ -487,6 +487,9 @@
>
> DBG_HEAVY("matroxfb_cfb8_putc");
>
> + if (!ACCESS_FBINFO(curr.putc))
> + return;
> +
It looks like that someone tried to print something on the console
during fbcon initialization. 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). Do not you see some error
message in dmesg with these fixes?
> @@ -504,6 +507,9 @@
>
> DBG_HEAVY("matroxfb_cfb16_putc");
>
> + if (!ACCESS_FBINFO(curr.putc))
> + return;
> +
Instead of plugging these tests into fast path please call
"matrox_init_putc(PMINFO NULL, NULL)" somewhere in the initMatrox2(),
before call to the register_framebuffer. At worst some part of video
memory gets smashed by painted characters, but no damage should
occur.
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/
This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:29 EST