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. How reproducible: always Steps to Reproduce: 1. power-up machine 2. in grub append vga=773 (or 791 or 792) 3. boot Actual results: screen black during boot gdm comes up fine switching to a VT gives black screen (switching back to X works fine) Expected results: 1024x768 framebuffer console Additional info: 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] dmidecode output
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 xen-eabled kernels.
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: people.redhat.com/dzickus/el5/18.el5
OK, closing duplicate. *** This bug has been marked as a duplicate of 236195 ***