Bug 497853 - RHEL 5.3: mga driver uses weird 1280x768 default mode
RHEL 5.3: mga driver uses weird 1280x768 default mode
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xorg-x11-server (Show other bugs)
All Linux
high Severity high
: rc
: 5.5
Assigned To: Adam Jackson
Depends On:
Blocks: 499522 531112 603944
  Show dependency treegraph
Reported: 2009-04-27 11:11 EDT by Alan Matsuoka
Modified: 2010-06-14 19:33 EDT (History)
10 users (show)

See Also:
Fixed In Version: xorg-x11-server-1.1.1-48.70.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 603944 (view as bug list)
Last Closed: 2010-03-30 04:33:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
sosreport-akarlsso01.282593-682503-208d1f.tar.bz2 (1.83 MB, application/x-bzip2)
2009-04-27 11:11 EDT, Alan Matsuoka
no flags Details
sosreport-akarlsso02.282593-161056-cb706d.tar.bz2 (1.83 MB, application/x-bzip2)
2009-04-27 11:15 EDT, Alan Matsuoka
no flags Details
dmesg from sosreport (26.25 KB, text/plain)
2009-05-15 10:17 EDT, Matěj Cepl
no flags Details
messages from sosreport (169.98 KB, text/plain)
2009-05-15 10:17 EDT, Matěj Cepl
no flags Details
xorg.conf from sosreport (606 bytes, text/plain)
2009-05-15 10:18 EDT, Matěj Cepl
no flags Details
Xorg.0.log from sosreport (48.99 KB, text/plain)
2009-05-15 10:18 EDT, Matěj Cepl
no flags Details
xorg.0.log from el5.5 system (49.47 KB, text/x-log)
2010-03-10 12:29 EST, Peter Pols
no flags Details

  None (edit)
Description Alan Matsuoka 2009-04-27 11:11:38 EDT
Created attachment 341442 [details]

General Escalation Information

* State the problem

  1. Provide time and date of the problem

     N/A - can be produced at will.
Description of problem:

When RHEL5.3 is installed on PRIMERGY servers with Advanced Video Redirection (AVR) attached and without a real monitor, the AVR sceen is black in the inital login screen.

How reproducible:

Steps to Reproduce:
Install RHEL 5.2 or 5.3 on a recent PRIMERGY with iRMC AVR, without attaching a real Monitor to the VGA output.

Actual results:
Firstboot login screen is black in AVR.

Expected results:
Firstboot login screen is normally readable.

Additional info:
The root cause of the problem is that without an attached monitor, no DDC data is available. This is a restriction of the Kronos 2 / Pilot 2 hardware. The BMC has no access to the I2C bus used for DDC by the VGA hardware, it is thus impossible to emulate a DDC controller when no real monitor is attached.

In the absence of DDC data, the mga driver uses default monitor hsync 31-48KHz and vrefresh 56-75Hz, to "Jam in ranges big enough for 1024x768" (quote from a comment in
the mga driver sources). Unfortunately, with these defaults, the X server does *not* select 1024x768 but the very unusual  mode "1280x768@60 (47.7kHz)". Actually, 1024x768 is only the 3rd choice:

(**) MGA(0): *Default mode "1280x768": 80.1 MHz, 47.7 kHz, 60.0 Hz
(II) MGA(0): Modeline "1280x768"   80.14  1280 1344 1480 1680  768 769 772 795 -hsync +vsync
(**) MGA(0): *Default mode "1280x720": 74.5 MHz, 44.8 kHz, 60.0 Hz
(II) MGA(0): Modeline "1280x720"   74.48  1280 1336 1472 1664  720 721 724 746 -hsync +vsync
(**) MGA(0): *Default mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz
(II) MGA(0): Modeline "1024x768"   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync

The mode 1280x768 is currently unsupported by the AVR. The mode is added by the Red Hat patch "xorg-x11-server-Red-Hat-extramodes.patch", while the default monitor timings are created by "xorg-x11-server-Red-Hat-extramodes.patch".

Obviously, the combination of these two patches has the effect that the default timings used by the mga driver don't actually enable a default resolution of 1024x768. While we are working on getting the AVR to support the 1280x768 mode, this is clearly suboptimal and moreover, a similar situation could arise again if new extramodes are added.

It is wrong that an extraordinary mode like 1280x768 is used in the absence of DDC data, where conservative settings are needed.

  2. Indicate the platform(s) (architectures) the problem is being
     reported against.

 Any (although I've only used x86_64)

  3. Provide clear and concise problem description as it is
     understood at the time of escalation

 * Observed behavior

 iRMC video redirection leaves you with a blank screen for X,
 because the mga driver picks a widescreen resolution that was
 not expected.

     FTS has identified that xorg-x11-server-Red-Hat-extramodes.patch
 and xorg-x11-server-Red-Hat-extramodes.patch combined causes

 * Desired behavior

 In the absense of DDC data from a monitor that can guide X to
 what resolutions are suitable, X should take a slightly more
 conservative approach to the resolutions it selects (1024x768 or
 800x600 would be considered "safe defaults").

  4. State specific action requested of SEG

     Have a look through the data, see if my workaround suggestions
     are adequate for now, and escalate to engineering for a fix.

  5. State whether or not a defect in the product is suspected

     Not so much a bug as "undesirable behaviour". Headless systems
     with a RSB will quite likely not entertain the idea of
     wide-screen resolutions much.

 * Provide Bugzilla if one already exists

 No BZ.

  6. If there is a proposed patch, make sure it is in unified diff
     format (diff -pruN)

 No patch.

  8. This is especially important for severity one and two
     issues. What is the impact to the customer when they experience
     this problem?

 The impact to our Partner is that the customer installing their
 servers, headless in a co-lo somewhere, using the iRMC remote
 Video function will be presented with what seems to be a faulty
 system when reaching the firstboot screen. (Yes, I know that
 with kickstarts you can disable that, but humour me.)

 You can "kill" the firstboot screen with C-A-Bs to make the
 installation progress to a point where you at least can get to a
 vc and log in, so you can fiddle with xorg.conf. This does not
 give an entirely smooth user-experience as the same problem
 affecting firstboot will affect GDM.

* Provide supporting info

  1. State other actions already taken in working the problem:

     * tech-list, google searches, fulltext, consulting with another

 I've been testing this out on a system here for
 certification. If you're quick, you can play with it before it
 is handed over to GPS for running the certification.

     * Provide any relevant data found

 Attached to the issue I'd hope, as well as in some earlier
 comments in the issue.

  2. Attach sosreport


  3. Attach other supporting data

- When Xorg get to pick and chose Mode without influence

- When Xorg is steered towards 4:3 type modes

With a 4:3 mode, the video redirection works. To test,

dhcp-132.gsslab.fab.redhat.com (, root/redhat) is the
system in question. dhcp-126.gsslab.fab.redhat.com ( is
the second NIC, also accessible.

http://dhcp-133.gsslab.fab.redhat.com (admin/admin) is the iRMC
interface. We have four weeks of time left on the temporary license
key for video redirection.

* install SUN java 1.6 or something that don't fail and throw
  exceptions at every opportunity

* Open in web browser the iRMC

* Twisty open Console Redirection, click Video Redirection

* Easiest way to do this, is use the Java WebStart to start video
  redirection (javaws).

* Once you see the console, you're ready to test.

If xorg.conf has the Modes line active, you should see the GDM login
screen no matter what, whether "Local Monitor" is on or off. If you
comment out Modes and restart GDM to pick up the changes, X will pick
a 1280x768 widescreen resolution, meaning console redirection fails.

At the moment, I've left Modes enabled, and even if I specify
1280x1024 in Modes, the console redirection will pick 1024x768, not
that I'm complaining. :)

I'd say that in the absence of DDC data to guide what modes are
suitable, picking a wide-screen mode such as 1280x768 is a very odd
choice and in this instance, it breaks the console redirection for a
system that in many instances will be running headless and will be
remotely managed. There are hack'ish workarounds (don't run X, don't
run firstboot, C-A-Bs firstboot and edit xorg.conf to prevent this
resolution being picked), but that's hopefully only temporary until
we've fixed this.

  4. Provide issue repro information:
     * List steps or...
     * ...reference the specific ticket update which contains the steps.
     * Provide location and access information for repro machine, if available

 Have a gander at my ramblings in

  5. List any known hot-fix packages on the system

     Clean RHEL5.3 install.

  6. List any customer applied changes from the last 30 days

     I've poluted it with some packages from Brew since
     then. kexec-tools, debuginfo's and devel kernel among other
     things. Not touched X though, so that is the same as from the
Comment 1 Alan Matsuoka 2009-04-27 11:15:23 EDT
Created attachment 341443 [details]
Comment 2 Matěj Cepl 2009-05-15 10:17:36 EDT
Created attachment 344157 [details]
dmesg from sosreport
Comment 3 Matěj Cepl 2009-05-15 10:17:54 EDT
Created attachment 344158 [details]
messages from sosreport
Comment 4 Matěj Cepl 2009-05-15 10:18:05 EDT
Created attachment 344159 [details]
xorg.conf from sosreport
Comment 5 Matěj Cepl 2009-05-15 10:18:18 EDT
Created attachment 344160 [details]
Xorg.0.log from sosreport
Comment 6 Adam Jackson 2009-10-28 17:35:02 EDT
This is an xserver bug, the mode list construction is a bit silly in this case, nothing to do with the driver though.  Component should be changed to xorg-x11-server.
Comment 10 Martin Wilck 2009-11-02 05:26:18 EST
(In reply to comment #8)
> Cond QA NAK hardware 5.5
> We do not have the hardware that this was originally reported on.  

Red Hat has received Kronos2 hardware from Fujitsu. Please contact ltroan@redhat.com for its whereabouts.

Comment 11 Martin Wilck 2009-11-02 05:41:08 EST
Sorry, I forgot about the shipping problem. The hardware is supposed to still sit in NY airport, probably in customs. This is being worked on.

Nevertheless, Red Hat should possess at least one ServerEngines Pilot 2 controller which is the same VGA-wise as Kronos 2.
Comment 14 Larry Troan 2010-02-03 13:44:48 EST
FTS kronos2 hardware **is** in Ajax's office. We paid a tidy ransom to free this hardware from JFK Customs since August. It arrived 23 December at 4PM in Westford.

NAK=hardware is INVALID. GSS, please raise as an exception.
Comment 23 Adam Jackson 2010-02-11 14:48:36 EST
This should be fixed by the same fix as bug #507536, present in xorg-x11-server-1.1.1-48.70.el5 and later.

Comment 25 Peter Pols 2010-03-10 11:24:51 EST
The problem further exists with EL5.5 (tested with 2.6.18-190.el5). The default
screen resolution is set to 1280x768.
Comment 26 Chris Ward 2010-03-10 11:34:04 EST
I'm not following you. Sorry. Could you please confirm, does the -190 kernel resolve this issue or is the issue still unresolved?
Comment 27 Peter Pols 2010-03-10 12:29:27 EST
Created attachment 399142 [details]
xorg.0.log from el5.5 system

Xorg.0.log from test with 2.6.18-190.el5 system
Comment 34 errata-xmlrpc 2010-03-30 04:33:50 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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