Re: 2.5.67-mm1 cause framebuffer crash at bootup

Andrew Morton
2003-04-09T10:18:45Z

Helge Hafting <helgehaf@aitel.hist.no> wrote:
>
> 2.5.67 works with framebuffer console, 2.5.67-mm1 dies before activating
> graphichs mode on two different machines:
>
> smp with matroxfb, also using a patch that makes matroxfb work in 2.5
> up with radeonfb, also using patches that fixes the broken devfs in mm1.
>
> I use devfs and preempt in both cases, and monolithic kernels without module
> support.
>
> 2.5.67-mm1 works if I drop framebuffer support completely.
>
> Here is the printed backtrace for the radeon case, the matrox case was
> similiar:

Well I tried to reproduce this with an

nVidia Corporation NV17 [GeForce4 MX440] (rev a3)

and the screen came up in a strange mixture of penguins and obviously uninitialised
video RAM overlayed on top of text. I can't read a thing.

But there is no oops.

The Cirrus drivers still do not compile, so scrub that test box.

We have some compilation scruffies:
drivers/video/aty/mach64_gx.c:194: warning: initialization from incompatible pointer type
drivers/video/aty/mach64_gx.c:486: warning: initialization from incompatible pointer type
drivers/video/aty/mach64_gx.c:602: warning: initialization from incompatible pointer type
drivers/video/aty/mach64_gx.c:726: warning: initialization from incompatible pointer type
drivers/video/aty/mach64_gx.c:873: warning: initialization from incompatible pointer type

Another machine here uses

ATI Technologies Inc Rage Mobility M3 AGP 2x (rev 02)

and..... it oopses! Backing out

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.67/2.5.67-mm1/broken-out/earlier-keyboard-init.patch

prevents it oopsing. Can you please try that?

Despite the lack of oopses, framebuffer support is sick on this machine also.
The LCD alternates between blackness and a strange smeary set of flickering
lines.