2.6.0-test7 vs. vga= boot parameter

On a machine with unknown graphics chip and a 1024x768 screen, 2.4.18 and 2.6.0-test1 through test7 can all be booted with vga=791 and have no problem.

On a machine with a Neomagic 128XD chip and an 800x600 screen, 2.4.19 and 2.4.20 can be booted with vga=788 and have no problem. But booting 2.6.0-test1 through test7 with vga=788 yields a black screen during boot and disables all text mode displays in VT consoles. After X11 starts up, switching to a VT just displays whatever was last put in graphics memory by X11 and does not change until I switch back to X11.

Booting 2.6.0-test1 through test7 without any vga option has no problem displaying boot messages, and after X11 starts up, it has no problem switching between X11 and VT consoles.

This part of dmesg might be relevant to the vga problem in test7. vesafb seems to say it aborted and then succeeded, but maybe it aborted and went crazy instead?

neofb: mapped io at c6800000
Autodetected internal display
Panel is a 800x600 color TFT display
neofb: mapped framebuffer at c6a01000
neofb v0.4.1: 2048kB VRAM, using 800x600, 37.878kHz, 60Hz
fb0: MagicGraph 128XD frame buffer device
vesafb: abort, cannot reserve video memory at 0x43000000
vesafb: framebuffer at 0x43000000, mapped to 0xc6c02000, size 1984k
vesafb: mode is 800x600x16, linelength=1600, pages=1
vesafb: protected mode interface info at c000:8cb0
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
fb1: VESA VGA frame buffer device

I had the same problems with all the 2.6 test versions and the vga= bootoption.

I didn't find out what the cause was of this problem, but using the following line video=matroxfb:vesa:0x118,depth=32 did work on my matrox card.

This way I don't have to use the vga= line.

Hope this helps you.

Maurice Lucas