Red Hat Bugzilla – Bug 497853
RHEL 5.3: mga driver uses weird 1280x768 default mode
Last modified: 2010-06-14 19:33:13 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.
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.
Firstboot login screen is black in AVR.
Firstboot login screen is normally readable.
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
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
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
6. If there is a proposed patch, make sure it is in unified diff
format (diff -pruN)
8. This is especially important for severity one and two
issues. What is the impact to the customer when they experience
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 (10.33.8.132, root/redhat) is the
system in question. dhcp-126.gsslab.fab.redhat.com (10.33.8.126) 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
* 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
Created attachment 341443 [details]
Created attachment 344157 [details]
dmesg from sosreport
Created attachment 344158 [details]
messages from sosreport
Created attachment 344159 [details]
xorg.conf from sosreport
Created attachment 344160 [details]
Xorg.0.log from sosreport
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.
(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 firstname.lastname@example.org for its whereabouts.
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.
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.
This should be fixed by the same fix as bug #507536, present in xorg-x11-server-1.1.1-48.70.el5 and later.
The problem further exists with EL5.5 (tested with 2.6.18-190.el5). The default
screen resolution is set to 1280x768.
I'm not following you. Sorry. Could you please confirm, does the -190 kernel resolve this issue or is the issue still unresolved?
Created attachment 399142 [details]
xorg.0.log from el5.5 system
Xorg.0.log from test with 2.6.18-190.el5 system
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.