Bug 497853

Created attachment 341442 [details]
sosreport-akarlsso01.282593-682503-208d1f.tar.bz2

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:
Always

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
 this.

 * 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
       engineer

 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

     Done.

  3. Attach other supporting data

     sosreport-akarlsso01.282593-682503-208d1f.tar.bz2
- When Xorg get to pick and chose Mode without influence

sosreport-akarlsso02.282593-161056-cb706d.tar.bz2
- 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
  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
 https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=282593&gid=1011&view_type=lifoall#eid_2899417

  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
     install.