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.
Created attachment 341443 [details] sosreport-akarlsso02.282593-161056-cb706d.tar.bz2
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 ltroan for its whereabouts. Martin
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. MODIFIED
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. http://rhn.redhat.com/errata/RHBA-2010-0259.html