Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 234448

Summary: vesafb breaks consoles on ThinkPad X60
Product: Red Hat Enterprise Linux 5 Reporter: Patrick C. F. Ernzer <pcfe>
Component: xorg-x11-driversAssignee: Adam Jackson <ajax>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5.0CC: ian.laurie, ilaurie, rda, stanislav.polasek
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-05-13 22:59:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
dmidecode output
none
lspci -vvv output none

Description Patrick C. F. Ernzer 2007-03-29 12:11:35 UTC
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)

Comment 1 Patrick C. F. Ernzer 2007-03-29 12:12:23 UTC
Created attachment 151187 [details]
dmidecode output

Comment 2 Patrick C. F. Ernzer 2007-03-29 12:13:51 UTC
Created attachment 151188 [details]
lspci -vvv output

Comment 3 Patrick C. F. Ernzer 2007-03-29 13:20:08 UTC
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.)

Comment 4 Bob Arendt 2007-03-29 16:13:22 UTC
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.

Comment 5 Bob Arendt 2007-03-29 16:24:11 UTC
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


Comment 6 Stanislav Polasek 2007-05-04 18:28:18 UTC
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.

Comment 7 Ian Laurie 2007-05-05 13:27:57 UTC
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.


Comment 8 Stanislav Polasek 2007-05-06 08:28:05 UTC
(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.

Comment 9 Ian Laurie 2007-05-13 11:52:00 UTC
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


Comment 10 Patrick C. F. Ernzer 2007-05-13 22:59:09 UTC
OK, closing duplicate.

*** This bug has been marked as a duplicate of 236195 ***