Red Hat Bugzilla – Bug 234448
vesafb breaks consoles on ThinkPad X60
Last modified: 2007-11-30 17:07:43 EST
Description of problem: using any onf the 1024x768 vesafb modes (773, 791, 792)
breaks consoles in the way that console is black during and after boot.
790 is reported as invalid mode (1024x768 @ 32K)
Version-Release number of selected component (if applicable):
2.6.18-8.1.1.el5 (x86_64) I did not try this with an earlier kernel.
Steps to Reproduce:
1. power-up machine
2. in grub append vga=773 (or 791 or 792)
screen black during boot
gdm comes up fine
switching to a VT gives black screen (switching back to X works fine)
1024x768 framebuffer console
My machine is an X60, specifically 1706-GMG. BIOS 2.07
Phil Knirsh was also able to reproduce this on an X60s ia32 (specific type
unknown to me)
Created attachment 151187 [details]
Created attachment 151188 [details]
lspci -vvv output
FWIW: just updatyed BIOS to 2.09
screen still black with vga=792, vga=791, vga=773
790 still considered illegal mode
(did not boot all the way through, I use dm_crypt and it's easier to do 3x ENTER
and then ctrl-D when testing this.)
Same issue with Dell Dimension-370 desktop, card nVidia Corporation NV37GL
[Quadro FX 330/Quadro NVS280] (rev a2). vga=791 produces black screen.
This used to work with RHEL3, RHEL4, and FC6 (latest updates). Only seen this
with RHEL5 (no updates).
The Xserver on console 7 starts correctly, but vtys 0-6 are still black.
BTW(In reply to comment #4)
> Same issue with Dell Dimension-370 desktop, card nVidia Corporation NV37GL
> [Quadro FX 330/Quadro NVS280] (rev a2). vga=791 produces black screen.
This running the 2.6.18-8.el5 i686 32-bit kernel
Vesa framebuffer console is disabled by default in the rhel5 kernel. Look for
the CONFIG_FB_VESA parameter in the /boot/config-`uname -r`. I have no idea why
is that so.
Same problem on a Dell PowerEdge 750 with a Matrox G450 fitted.....
So pardon the stupid question, but how do we fix this? That is, how do we
enable the CONFIG_FB_VESA parameter? Do we need to make a custom kernel... pls
don't say that we do.
(In reply to comment #7)
> Same problem on a Dell PowerEdge 750 with a Matrox G450 fitted.....
> So pardon the stupid question, but how do we fix this? That is, how do we
> enable the CONFIG_FB_VESA parameter? Do we need to make a custom kernel... pls
> don't say that we do.
Yes, you have to, unfortunatelly. But it would be better to find out why exactly
Red Hat did that. There could be a real problem using it, for instance, with
I believe this bug is against the wrong component, should be the kernel.
Also, this bug is a duplicate of bug #236195.
Looks like it will be fixed in 2.6.18-18.el5 and a test version is already
available for download and testing at:
OK, closing duplicate.
*** This bug has been marked as a duplicate of 236195 ***