RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1196714 - Can't acquire EDID with UEFI system
Summary: Can't acquire EDID with UEFI system
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: xorg-x11-drv-mga
Version: 6.6
Hardware: ia64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Adam Jackson
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-02-26 15:12 UTC by Matrox
Modified: 2017-12-06 10:17 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-06 10:17:17 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Proposed patch for DDC support (2.65 KB, patch)
2015-02-26 15:12 UTC, Matrox 		no flags Details | Diff
Proposed patch for DDC support - Take 2 (2.85 KB, patch)
2015-03-13 17:29 UTC, Matrox 		no flags Details | Diff
xrabndr output and Xorg.0.log when I'm patching RHEL6.7 mga driver (119.31 KB, text/plain)
2015-08-28 00:00 UTC, Haruo Tomita 		no flags Details
The mga driver's rpm/srpm for RHEL6.7 using use-ddc_randr12_2.patch (867.02 KB, application/x-bzip)
2015-08-28 00:39 UTC, Haruo Tomita 		no flags Details
Show Obsolete (1) View All

Description Matrox 2015-02-26 15:12:04 UTC 
Created attachment 995669 [details]
Proposed patch for DDC support

Description of problem:

The mga driver cannot get the EDID on UEFI system

Version-Release number of selected component (if applicable):

1.6.3-5.el6

How reproducible:

Always

Steps to Reproduce:
1. Boot on a UEFI only system without legacy Video BIOS.
2. Check the Xorg.0.log
3. Mga was unable to acquire EDID

Actual results:

Mga is unable to acquire EDID

Expected results:

Mga should be able to acquire EDID

Additional info:

When randr 1.2 support was added to the Mga driver. The DDC was supported through VBE and the Video BIOS. However, on UEFI system this mechanism is not available. So DDC support needed to be brought back to the MGA driver.I'm attaching a patch with a proposal.
Comment 2 Adam Jackson 2015-03-11 17:54:43 UTC 
Isn't that going to break G400/450/550?
Comment 3 Adam Jackson 2015-03-11 17:56:08 UTC 
I really can't follow the logic of that patch.  Can you explain why this patch would fix the issue?
Comment 4 Matrox 2015-03-13 17:29:52 UTC 
Created attachment 1001451 [details]
Proposed patch for DDC support - Take 2

Thank you Adam for your comment. You are right, I developed the patch without considering the non randr12 situation and without considering the old product line G400/G450/G550

Here, my new proposed patch. The goal is to add support for DDC read in the driver when running in randr12 mode. In the current implementation, the MGA driver solely rely on VBE to get the EDID of the monitor. This fails in UEFI system. My proposed solution if to port DDC read routine, from the old code, into the randr12 part.
Comment 6 Haruo Tomita 2015-08-28 00:00:51 UTC 
Created attachment 1067884 [details]
xrabndr output and Xorg.0.log when I'm patching RHEL6.7 mga driver

> Created attachment 1001451 [details]
> Proposed patch for DDC support - Take 2
> 
>　Thank you Adam for your comment. You are right, I developed the patch 
> without considering the non randr12 situation and without considering 
> the old product line G400/G450/G550

I used patch in RHEL6.7. A graphic chip is ServerEngine g200e pilot.
The patch seems to work fine for ServerEngine g200e pilot.
xrandr/Xorg.0.log is attached.
Comment 7 Haruo Tomita 2015-08-28 00:39:26 UTC 
Created attachment 1067885 [details]
The mga driver's rpm/srpm for RHEL6.7 using use-ddc_randr12_2.patch
Comment 8 Haruo Tomita 2015-08-28 00:48:18 UTC 
(In reply to Matrox from comment #4)
> In the current implementation, the MGA driver solely rely on 
> VBE to get the EDID of
> the monitor. This fails in UEFI system. My proposed solution if to port DDC
> read routine, from the old code, into the randr12 part.

I think that I will use KMS in case of UEFI BOOT.

https://bugzilla.redhat.com/show_bug.cgi?id=1192865
Comment 9 Matrox 2015-08-31 15:10:19 UTC 
(In reply to Haruo Tomita from comment #8)
> (In reply to Matrox from comment #4)
> > In the current implementation, the MGA driver solely rely on 
> > VBE to get the EDID of
> > the monitor. This fails in UEFI system. My proposed solution if to port DDC
> > read routine, from the old code, into the randr12 part.
> 
> I think that I will use KMS in case of UEFI BOOT.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1192865

I thought that bringing the mgag200 kernel driver to RHEL 6 was too much work. If you end up going that route, I would like to have a build for testing. We have a lot of products to support so we need to make sure it works for every one.
Comment 10 Matrox 2015-08-31 15:11:29 UTC 
(In reply to Haruo Tomita from comment #7)
> Created attachment 1067885 [details]
> The mga driver's rpm/srpm for RHEL6.7 using use-ddc_randr12_2.patch

I'll test that rpm over here and see if it works well with G200e and all the other g200 products too.
Comment 11 Haruo Tomita 2015-09-02 01:12:46 UTC 
(In reply to Matrox from comment #9)
> I thought that
> bringing the mgag200 kernel driver to RHEL 6 was too much work. If you end
> up going that route, I would like to have a build for testing. We have a lot
> of products to support so we need to make sure it works for every one.

Thank you replay.

mgag200 kernel drm driver is already backpoted as kmod driver.
Please download rpm/srpm the following site. It's for RHEL6.7.

https://bugzilla.redhat.com/show_bug.cgi? id=1192865

When a build does srpm, attention is necessary for the following bug.

https://bugzilla.redhat.com/show_bug.cgi? id=1133703

For a build to do srpm,
Please add /usr/src/kernel2/2.6.32-573.el6.x86_64/include/uapi files.
This bug is fixed in kernel-devel-2.6.32-573.1.1.el6.

Moreover there is race issue in RHEL6.7.
I inspected by the following patch.

--- linux-2.6.32-558.el6/drivers/video/efifb.c.orig     2015-05-29 06:51:38.615956154 +0900
+++ linux-2.6.32-558.el6/drivers/video/efifb.c  2015-05-29 07:11:12.954953627 +0900
@@ -165,6 +165,8 @@ static int efifb_setcolreg(unsigned regn

 static void efifb_destroy(struct fb_info *info)
 {
+       printk(KERN_INFO "efifb_destroy()\n");
+       dump_stack();
        if (info->screen_base)
                iounmap(info->screen_base);
        release_mem_region(info->aperture_base, info->aperture_size);

<log of NG>

SELinux: initialized (dev drm, type drm), not configured for labeling
mgag200 0000:7d:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
mc.vram_base=4177526784 mc.vram_window=16777216
[drm:mga_vram_init] *ERROR* can't reserve VRAM
mgag200 0000:7d:00.0: Fatal error during GPU init: -6
mgag200 0000:7d:00.0: PCI INT A disabled

…

SELinux: initialized (dev proc, type proc), uses genfs_contexts
efifb_destroy()
Pid: 197, comm: plymouthd Not tainted 2.6.32-558.1.el6.x86_64 #2
Call Trace:
 [<ffffffff812f0774>] ? efifb_destroy+0x24/0x60
 [<ffffffff812d49cd>] ? put_fb_info+0x5d/0x60
 [<ffffffff812d4e48>] ? fb_release+0x58/0x60
 [<ffffffff81193115>] ? __fput+0xf5/0x210
 [<ffffffff81193255>] ? fput+0x25/0x30
 [<ffffffff8118e37d>] ? filp_close+0x5d/0x90
 [<ffffffff8118e455>] ? sys_close+0xa5/0x100
 [<ffffffff8100b308>] ? tracesys+0xd9/0xde
pci 0000:7d:00.0: Invalid ROM contents
fuse init (API version 7.14)
SELinux: initialized (dev fuse, type fuse), uses genfs_contexts

<log of OK>

udev: starting version 147
[drm] Initialized drm 1.1.0 20060810
checking generic (f9000000 800000) vs hw (f9000000 1000000)
fb: conflicting fb hw usage mgag200drmfb vs EFI VGA - removing generic driver
Console: switching to colour dummy device 80x25
efifb_destroy()
Pid: 198, comm: work_for_cpu Not tainted 2.6.32-558.1.el6.x86_64 #2
Call Trace:
 [<ffffffff812f0774>] ? efifb_destroy+0x24/0x60
 [<ffffffff812d49cd>] ? put_fb_info+0x5d/0x60
 [<ffffffff812d5a48>] ? do_unregister_framebuffer+0x118/0x130
 [<ffffffff812d77a7>] ? do_remove_conflicting_framebuffers+0x187/0x1b0
 [<ffffffff812d780d>] ? remove_conflicting_framebuffers+0x3d/0x60
 [<ffffffffa0101e3f>] ? mga_pci_probe+0x8f/0xd0 [mgag200]
 [<ffffffff8109ac70>] ? do_work_for_cpu+0x0/0x30
 [<ffffffff812b4d47>] ? local_pci_probe+0x17/0x20
 [<ffffffff8109ac88>] ? do_work_for_cpu+0x18/0x30
 [<ffffffff810a101e>] ? kthread+0x9e/0xc0
 [<ffffffff8100c28a>] ? child_rip+0xa/0x20
 [<ffffffff810a0f80>] ? kthread+0x0/0xc0
 [<ffffffff8100c280>] ? child_rip+0x0/0x20
mgag200 0000:7d:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16

efifb_destroy() called from remove_conflicting_theframebuffers().
This is race issue that plymoutd and remove_conflicting_framebuffers().
This issue fixed in plymouth by a upstream.
Below is fix in systemd. 
But, upstart of RHEL6 isn't fixed.

* Tue Aug 21 2012 Dave Airlie <airlied> 0.8.6.2-1.2012.07.23
 - fix plymouth race at bootup breaking efi/vesa handoff.
 - fix version number - its against fedora package policy to have 0.year

http://pkgs.fedoraproject.org/cgit/plymouth.git/commit/?h=f18&id=8ff5ec7dac2b93e8778513e922a09a7dffc0c898
http://pkgs.fedoraproject.org/cgit/plymouth.git/diff/plymouth-fix-udev-trigger.patch?h=f18&id=8ff5ec7dac2b93e8778513e922a09a7dffc0c898

    +diff -up plymouth-0.8.6.2/systemd-units/plymouth-start.service.in.dma plymouth-0.8.6.2/systemd-units/plymouth-start.service.in
    +--- plymouth-0.8.6.2/systemd-units/plymouth-start.service.in.dma	2012-08-21 09:11:22.906284758 +1000
    ++++ plymouth-0.8.6.2/systemd-units/plymouth-start.service.in	2012-08-21 09:11:32.707345054 +1000
    +@@ -2,7 +2,7 @@
    + Description=Show Plymouth Boot Screen
    + DefaultDependencies=no
    + Wants=systemd-ask-password-plymouth.path
    +-After=systemd-vconsole-setup.service systemd-udev-settle.service
    ++After=systemd-vconsole-setup.service systemd-udev-trigger.service
    + Before=systemd-ask-password-plymouth.service
    + ConditionKernelCommandLine=!plymouth.enable=0
    + ConditionPathExists=!@plymouthruntimedir@/pid

When mga200 driver is tested to avoid this issue.
'rd_NO_PLYMOUTH' is add as a kernel boot parameter of grub.conf(this disables plymouth).

if ! getarg rd_NO_PLYMOUTH; then
      ...
 　　[ -x /bin/plymouthd ] && /bin/plymouthd --attach-to-session
　　　/bin/plymouth --show-splash 2>&1 | vinfo fi
Comment 13 Jan Kurik 2017-12-06 10:17:17 UTC 
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/
Note You need to log in before you can comment on or make changes to this bug.