Red Hat Bugzilla – Bug 591718
Screen corruption (and lockup) booting on EFI system,
Last modified: 2014-09-07 18:53:40 EDT
Tested with RHEL6 Beta#1
IBM x3550 M2 (Full hardware details attached in lspci and dmidecode)
Booting from install DVD (or boot.iso) brings up initial grub screen, hitting enter starts a boot but it locks up with screen corruption (green blocks)
Using nodemodeset or xdriver=vesa makes no difference.
Machine can boot and install correctly in legacy bios mode.
Peter Jones had a look at this to see where the problem was
I'm not at all sure what's going wrong here, but to me it looks
like a kernel issue - the screen corruption starts between initrd
unpacking and the audit subsystem starting up. The normal log looks
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 29540k freed <-- this is the last thing we see.
audit: initializing netlink socket (disabled)
On this machine, we never see past Freeing initrd memory, but the code
that's actually *in* the initrd (i.e. the installer) doesn't actually
start execution until much later, so it's unlikely the problem is
So this is most likely a kernel bug, I think.
This machine is in Westford, I can provide physical access.
Created attachment 413577 [details]
Output of dmidecode
Created attachment 413578 [details]
Output of lspci
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
------- Comment From firstname.lastname@example.org 2010-05-24 17:07 EDT-------
reverse mirror of RHBZ 591718 - Screen corruption (and lockup) booting on EFI system
This issue also reproduces on the x3650 M2 that has the same
Matrox VGA controller. On that system with the serial console
enabled in the BIOS and "console=tty0 console=ttyS0,115200"
added to the kernel command line, the kernel successfully boots
after which the initial installation screens are displayed in
text form on the serial console. After responding to each of
the initial screens, Anaconda appears to successfully start.
Nothing is displayed on the VGA console while this is happening.
I will attach the serial console output.
I also tried with only "text" (no console= options) appended
to the kernel command line and saw nothing displayed on VGA
console and only the following displayed on the serial console.
Created attachment 416967 [details]
serial console output showing successful boot and Anaconda startup
(In reply to comment #7)
> I also tried with only "text" (no console= options) appended
> to the kernel command line and saw nothing displayed on VGA
> console and only the following displayed on the serial console.
Oops, I didn't include the output. The following was displayed.
Trying to allocate 923 pages for VMLINUZ
[Linux-EFI, setup=0x1026, size=0x39b000]
[Initrd, addr=0x77a03000, size=0x1c96b26]
Andrew, Could you please go into the F1 setup and check the
state of the 'Force Legacy Video on Boot' option under
System Settings->Legacy Support? If it is set to "Enable"
please change it to "Disable" and then initiate an install
and check to see if the screen corruption issue still exists.
(In reply to comment #10)
> Andrew, Could you please go into the F1 setup and check the
> state of the 'Force Legacy Video on Boot' option under
> System Settings->Legacy Support? If it is set to "Enable"
> please change it to "Disable" and then initiate an install
> and check to see if the screen corruption issue still exists.
Back in the office now. I just checked the box and it was set to the default of Enable. Changing this to disable I was able to boot normally and access anaconda.
Thanks, Andrew. I saw the same result on the x3650 M2.
We know of an earlier video corruption issue originally
discovered on x3650 M2 that had symptoms that appear to
be very similar to this issue, including the improvement
when 'Force Legacy Video on Boot' is changed from "Enable"
to "Disable". Unfortunately, the history for that
previous issue indicates that it was resolved with the
below two changes that are already included in the
I hope the Red Hat Xorg experts have some ideas on what
later change may have caused this to regress.
Author: Yannick Heneault <email@example.com>
Date: Tue Apr 21 10:00:24 2009 -0400
Fixed bad vga access in memory count routine.
Author: Yannick Heneault <firstname.lastname@example.org>
Date: Tue Apr 21 09:51:34 2009 -0400
Force pitch of 1024 for G200SE Pilot1 when edid is used as modeline.
------- Comment From email@example.com 2010-06-01 20:23 EDT-------
I was just reminded that the changes I mentioned in the last comment are
probably related to a different issue that appeared later in the install, after
X actually started. We are seeing the video corruption at the very beginning
of the install so X isn't even in the picture yet.
Stand by while we do some more research.
------- Comment From firstname.lastname@example.org 2010-07-06 17:28 EDT-------
We are pursuing this as a possible firmware issue. We have not
definitely confirmed that it really is a firmware issue which is the
reason we are keeping this bug open.
------- Comment From email@example.com 2010-08-02 11:05 EDT-------
Just to let you know, we are still in discussions with the BIOS
team concerning this issue.
------- Comment From firstname.lastname@example.org 2010-08-10 14:37 EDT-------
Upgrading Priority - Looks like an issue in OS code and not firmware. Affects nearly every system being shipped today. All customers will see this if installing from CD/DVD. summary comment to follow.
IBM, please be advised that this issue risks not getting resolved for RHEL 6.0. We need immediate action on this.
Could we get some details on what the firmware team investigated and discovered?
------- Comment From email@example.com 2010-08-12 18:43 EDT-------
(In reply to comment #31)
> Could we get some details on what the firmware team investigated and
I've asked and am awaiting a response. I'll include the information here as soon as I get it.
Please realize that this problem is about to get booted out of RHEL6 for lack of information.
------- Comment From firstname.lastname@example.org 2010-08-19 01:40 EDT-------
This is a firmware issue. With 'Force legacy video' mode during a native UEFI boot the firmware must disconnect the native UEFI (GOP) driver and attach a thunk driver that translates GOP protocol to an int10 interface .A bug in this code caused stale frame buffer data (bogus address/size) to be passed to the loader / kernel resulting in the blank screen during boot.
This only occurs if the video mode is switched midstream. If legacy int10 is used during the entire boot process or native UEFI video is used during the entire boot process (i.e., 'Force legacy video' is disabled, then no corruption occurs.
closing not a bug, firmware issue
Steve, do you want to propose a release note for 6.0? And maybe point people to where to find firmware updates?
At the very least, we want to tell our customers not to enable "force legacy video mode" in the firmware; we want the GOP driver at all times if the user is booting via UEFI.
OK, how is this for a relnote?
Systems such as the IBM x3650 M2 and similar, using the Matrox VGA controller, may encounter installation problems in which the screen is unreadable when booted using UEFI.
This is a firmware issue. Do not enable "force legacy
video mode" in the firmware; use the GOP driver at all times if the user is
booting via UEFI.
Alternatively, enable the serial console in the BIOS and add "console=tty0 console=ttyS0,115200" to the kernel command line.
Updated firmware can be found at (sbeal???)
------- Comment From email@example.com 2010-08-31 14:46 EDT-------
Couple changes below:
Systems using an Integrated Management Module (IMM), using the Matrox VGA controller, may encounter installation problems in which the screen is unreadable when booted using UEFI.
This is a firmware issue. Do not enable "force legacy video mode" in the firmware; use the GOP driver at all times if the user is booting via UEFI.
A future firmware release will correct this issue and will be available at ibm.com.