Bug 234448 - vesafb breaks consoles on ThinkPad X60
vesafb breaks consoles on ThinkPad X60
Status: CLOSED DUPLICATE of bug 236195
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xorg-x11-drivers (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-29 08:11 EDT by Patrick C. F. Ernzer
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-13 18:59:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmidecode output (12.98 KB, text/plain)
2007-03-29 08:12 EDT, Patrick C. F. Ernzer
no flags Details
lspci -vvv output (20.47 KB, text/plain)
2007-03-29 08:13 EDT, Patrick C. F. Ernzer
no flags Details

  None (edit)
Description Patrick C. F. Ernzer 2007-03-29 08:11:35 EDT
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 08:12:23 EDT
Created attachment 151187 [details]
dmidecode output
Comment 2 Patrick C. F. Ernzer 2007-03-29 08:13:51 EDT
Created attachment 151188 [details]
lspci -vvv output
Comment 3 Patrick C. F. Ernzer 2007-03-29 09:20:08 EDT
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 12:13:22 EDT
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 12:24:11 EDT
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 14:28:18 EDT
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 09:27:57 EDT
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 04:28:05 EDT
(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 07:52:00 EDT
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 18:59:09 EDT
OK, closing duplicate.

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

Note You need to log in before you can comment on or make changes to this bug.