DL360 G6: Front and rear VGA ports behave differently (CentOS6)

[calsawyer]

I have at least 4 DL360 G6 servers behaving the same manner:

PXE installation of CentOS6.  Grub kernel line edited to disable rhgb, quiet.  Init set to 3.  From the front VGA connector, the boot progress display disappears around where "Starting Redhat" would be shown, the display blanks (but remains alive) and never returns to a simple login prompt.  For init 5, it will eventually land at GDM with display.  Performing a reboot from the GDM screen results in no shutdown status information being displayed - screen blanks again until the system re-enters POST.

Move the monitor to the rear VGA connector and everything mentioned above works great.  Is this intended behaviour in hardware or ...?

thanks

[Matti_Kurkela]

I guess the display disappears when the system transitions from the BIOS-initialized VGA text mode to native Linux fbconsole drivers. Perhaps the connectors are presented in hardware level as two separate displays (like the integral LCD vs. external display on most modern laptops) and the fbconsole driver just uses the primary display/connector by default?

The X server has more advanced multi-display support, and usually sends the same image to all connected displays until configured otherwise. When GDM is started, it normally starts up the local X server to provide GUI on the console, so that would explain why the display returns at that point.

The DL360 G6 seems to have an ATI display controller. Unfortunately it looks like the multihead support in the ATI fbconsole driver seems to be somewhat incomplete: I took a quick peek in the source code of the driver and found some parts that said "does not quite work yet, but useful for debugging". Seems to be work in progress though, but I guess that would be a fairly low priority for most driver developers.

[calsawyer]

Wow. Makes sense in a way and I see what you're getting at, Matti, but i should have said in the OP that CentOS5 has no problems with this -sorry.  I would have thought the VGA chipset's output was simply split/buffered and fed to the front and rear connectors?  Possible CentOS6 default display driver issue?

thanks,

- c sawyer

[Matti_Kurkela]

---

@calsawyer wrote:

[...]I would have thought the VGA chipset's output was simply split/buffered and fed to the front and rear connectors?  Possible CentOS6 default display driver issue?

Most display controller chips today offer at least two independent outputs, so I can see the designer thinking "why not use them". As you discovered, the ports have a degree of independence: the signals are clearly not simply hardwired to both ports from a single source.

The BIOS initializes the two outputs to display the same thing on both outputs (aka "clone mode") initially, but apparently something that RHEL/CentOS 6 does ends up switching that off. When the graphical boot option is switched off, I can see a two possible causes:

• If the available frame buffer console drivers recognize the display controller, they might be taking control of the display, transitioning it to frame buffer console mode and overriding the clone mode set by the BIOS. Looks like the default configuration seems to blacklist the frame buffer console modules (at least on my test VM), so these would not come into play unless specifically enabled.  If this was the cause, the fix would be to either configure the frame buffer console driver to use clone mode (if supported... depends on the driver used) or to disable the drivers and fall back to the traditional VGA text mode.
• If the system is not using the frame buffer console drivers, the display should still be in a basic VGA text mode. Fiddling with VGA modes or e.g. loading a new console font (for better Unicode/international character set support) might interfere with the clone mode configuration set up by the BIOS. I'm not really very knowledgeable on VGA programming, but I think the VGA BIOS might be involved; if that's true, it might be a firmware/BIOS issue too. If your current situation is this, switching to the frame buffer console mode might actually improve matters, if your display controller can be handled by the radeonfb driver.

Run "lsmod |grep -e aty -e radeon", and "cat /proc/fb": the output should identify if the system is in frame buffer console mode or not. 

If the radeonfb driver is currently loaded and in use, you might only need to add the mirroring option for the module. To do that, create a file named /etc/modprobe.d/display.conf with the following content:

options radeonfb mirror=1

Then run these commands:

depmod -a
mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname-r).img.old
dracut /boot/initramfs-$(uname-r).img $(uname -r)

 These will recreate the initramfs file, to ensure the configuration change is effective from the very beginning of the boot.

If the current configuration uses VGA text mode only, it might require more actions than just adding the above-mentioned option. You might test it first by temporarily stopping GDM, then running "modprobe radeonfb mirror=1" on the console. If this produces text console display on both VGA ports, adding the above-mentioned module configuration option and configuring the radeonfb module to load automatically should do the trick. However, it may be necessary to tweak the X11 configuration after that, unless the RHEL/CentOS 6 X server is smart enough to autodetect the change.

[calsawyer]

Brilliant, Matti.  I'll try these settings on one of the servers today and report back.

[calsawyer]

Sad to say that didn't work, Matti  Screen still blanks after boot kernel selection.  Oddly, on reboot/shutdown it magically reappears to display shutdown processes.

[calsawyer · Accepted solution]

Got it:
Installing elRepo's kmod-fglrx (which in turn installs fglrx-x11-drv) restored text-mode boot progress!

As part of the kmod driver install, "radeon.modeset=0" was appended to the kernel boot line in grub.conf

https://www.centos.org/modules/newbb/viewtopic.php?topic_id=32526

I think it's possible that this append might work with your suggested initramfs changes. I have a system that i can try that out on as a proof of concept, but installing the kmod is easier under kickstart than rebuilding initramfs.

will report back when i know more

many thanks

[calsawyer]

Yes, this works very well.  Kudos to Matti for the help and advice.