ASUS Pro WS WRX90E-SAGE SE - expected behavior with onboard VGA and discrete GPU?

[davidtmyers]

For those of you with WRX90E/WRX80E motherboards: are you able to run discrete GPUs while also keeping the onboard VGA feature enabled for iKVM purposes (i.e., the VGA_SW on the motherboard set to “Enabled”)?

Briefly: I performed a minimal install of Debian 12 Bookworm a few weeks ago, and it’s been working great. I skipped installing a desktop environment at the time and have been using the machine entirely headless via SSH without issue.

I will occasionally use the motherboard’s web-based iKVM when I’m remote/not in the office and need to tweak a setting in the BIOS or boot into an OS that doesn’t support SSH (FreeDOS).

I’m now trying to install a dedicated GPU so I can run a desktop environment (KDE) when I’m local to the machine. Unfortunately, I can’t seem to get anything to actually render to that GPU. I’ve confirmed the GPU, the cables, and the monitor all work, and when loading up the Debian LiveCD with GNOME, the discrete GPU showed a splash screen along with the onboard GPU. This would seem to indicate both can be driven simultaneously. Perhaps I’m missing a key step in installing KDE on top of a Debian minimal install?

The GPU is old (ATI/AMD Radeon X300 SE, which uses the RV370 driver), but is definitely supported and detected by the kernel and Debian.

The Issue
Whenever I boot, the monitor plugged into my discrete GPU stays in its power-save state. Once the kernel loads, the monitor exits its power-save state, turns its backlight on, but the screen remains completely blank (no text cursor, no mouse cursor, and certainly no greeter/login-screen or DE). I am, however, able to SSH into the machine just fine.

The Question
How do I get KDE up and running on this machine with this AMD Radeon X300 SE GPU?

What I’ve Done

1. Started with a Minimal Install from the netinst .ISO
2. Ensured /etc/apt/sources.list contains the correct repositories (i.e., main, contrib, and non-free-firmware):
   deb http://deb.debian.org/debian bookworm main contrib non-free-firmware
deb-src http://deb.debian.org/debian bookworm main contrib non-free-firmware
3. Installed AMD-related firmware, drivers, packages, etc.:
   apt-get install firmware-amd-graphics amd64-microcode xserver-xorg-video-radeon
4. Installed KDE:
   apt-get install plasma-desktop plasma-nm

Potentially Helpful Info
In the spirit of trying to simplify the debug process, here’s a few relevant outputs:

The card appears to be correctly showing up on the PCIe bus (note the “e1:00” entry in the output below):

root@workstation:~# lspci
[...]
e1:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV370 [Radeon X300]
e1:00.1 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] RV370 [Radeon X300 SE]
e2:00.0 PCI bridge: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge (rev 06)
e3:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 52)
e4:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Device 14ac (rev 01)
e4:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Device 14c9 (rev da)
[...]

The kernel appears to be able to correctly detect and probe the card (note the “Device-1” entry in the output below).
The kernel also appears to be correctly detecting the monitor plugged into the card (note the “Monitor-3” entry in the output below).

root@workstation:~# inxi -GSaz --vs
inxi 3.3.26-00 (2023-03-28)
System:
  Kernel: 6.1.0-18-amd64 arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
    parameters: BOOT_IMAGE=/BOOT/debian@/vmlinuz-6.1.0-18-amd64 root=ZFS=/ROOT/debian ro
    root=ZFS=workstation-rpool/ROOT/debian quiet
  Console: pty pts/0 Distro: Debian GNU/Linux 12 (bookworm)
Graphics:
  Device-1: AMD RV370 [Radeon X300] driver: radeon v: kernel alternate: radeonfb,amdgpu
    arch: Rage-9 code: Radeon IGP process: TSMC 110nm built: 2003-08 pcie: gen: 1 speed: 2.5 GT/s
    lanes: 16 ports: active: VGA-2 empty: DVI-I-1 bus-ID: e1:00.0 chip-ID: 1002:5b60
    class-ID: 0300
  Device-2: ASPEED Graphics Family driver: ast v: kernel ports: active: DP-1,VGA-1 empty: none
    bus-ID: e3:00.0 chip-ID: 1a03:2000 class-ID: 0300
  Display: server: X.org v: 1.21.1.7 with: Xwayland v: 22.1.9 driver: gpu: ast,radeon
    note: X driver n/a tty: 318x98
  Monitor-1: DP-1 size-res: N/A in console modes: max: 640x480 min: 800x600
  Monitor-2: VGA-1 size-res: N/A in console modes: max: 1024x768 min: 640x480
  Monitor-3: VGA-2 model: Dell 2007FP serial: <filter> built: 2007 res: 1600x1200 dpi: 99
    gamma: 1.2 size: 367x275mm (14.45x10.83") diag: 514mm (20.2") ratio: 4:3, 5:4 modes:
    max: 1600x1200 min: 720x400
  API: OpenGL Message: GL data unavailable in console for root.

Similarly, there seems to be no problem probing the card for additional info (note the “*-display:0” entry in the output below):

root@workstation:~# lshw -C display
  *-display:0               
       description: VGA compatible controller
       product: RV370 [Radeon X300]
       vendor: Advanced Micro Devices, Inc. [AMD/ATI]
       physical id: 0
       bus info: pci@0000:e1:00.0
       logical name: /dev/fb1
       version: 00
       width: 32 bits
       clock: 33MHz
       capabilities: pm pciexpress msi vga_controller bus_master cap_list rom fb
       configuration: depth=32 driver=radeon latency=0 resolution=1600,1200
       resources: irq:272 memory:c0000000-cfffffff ioport:f000(size=256) memory:d8330000-d833ffff memory:d8300000-d831ffff
  *-display:1 UNCLAIMED
       description: Display controller
       product: RV370 [Radeon X300 SE]
       vendor: Advanced Micro Devices, Inc. [AMD/ATI]
       physical id: 0.1
       bus info: pci@0000:e1:00.1
       version: 00
       width: 32 bits
       clock: 33MHz
       capabilities: pm pciexpress cap_list
       configuration: latency=0
       resources: memory:d8320000-d832ffff
  *-display
       description: VGA compatible controller
       product: ASPEED Graphics Family
       vendor: ASPEED Technology, Inc.
       physical id: 0
       bus info: pci@0000:e3:00.0
       logical name: /dev/fb0
       version: 52
       width: 32 bits
       clock: 33MHz
       capabilities: pm msi vga_controller cap_list fb
       configuration: depth=32 driver=ast latency=0 resolution=1024,768
       resources: irq:24 memory:d4000000-d7ffffff memory:d8000000-d803ffff ioport:e000(size=128)

Lastly, the card also appears to be detected properly based on relevant DRM output from dmesg:

root@workstation:~# dmesg | grep "drm"
[   18.752590] systemd[1]: Starting [email protected] - Load Kernel Module drm...
[   18.769951] ACPI: bus type drm_connector registered
[   18.770566] systemd[1]: [email protected]: Deactivated successfully.
[   18.770625] systemd[1]: Finished [email protected] - Load Kernel Module drm.
[   19.066537] ast 0000:e3:00.0: [drm] P2A bridge disabled, using default configuration
[   19.066539] ast 0000:e3:00.0: [drm] AST 2600 detected
[   19.066544] ast 0000:e3:00.0: [drm] Using analog VGA
[   19.066545] ast 0000:e3:00.0: [drm] dram MCLK=396 Mhz type=1 bus_width=16
[   19.066838] [drm] Initialized ast 0.1.0 20120228 for 0000:e3:00.0 on minor 0
[   19.069353] fbcon: astdrmfb (fb0) is primary device
[   19.092079] ast 0000:e3:00.0: [drm] fb0: astdrmfb frame buffer device
[   19.108911] [drm] radeon kernel modesetting enabled.
[   19.111395] [drm] initializing kernel modesetting (RV380 0x1002:0x5B60 0x1002:0x3000 0x00).
[   19.178823] [drm] GPU not posted. posting now...
[   19.290331] [drm] Generation 2 PCI interface, using max accessible memory
[   19.290358] [drm] Detected VRAM RAM=256M, BAR=256M
[   19.290359] [drm] RAM width 128bits DDR
[   19.290368] [drm] radeon: 256M of VRAM memory ready
[   19.290369] [drm] radeon: 512M of GTT memory ready.
[   19.290379] [drm] GART: num cpu pages 131072, num gpu pages 131072
[   19.290577] [drm] radeon: 1 quad pipes, 1 Z pipes initialized
[   19.291378] [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
[   19.291558] [drm] radeon: irq initialized.
[   19.291563] [drm] Loading R300 Microcode
[   19.294760] [drm] radeon: ring at 0x00000000A0001000
[   19.294779] [drm] ring test succeeded in 1 usecs
[   19.294849] [drm] ib test succeeded in 0 usecs
[   19.294939] [drm] Radeon Display Connectors
[   19.294940] [drm] Connector 0:
[   19.294940] [drm]   VGA-2
[   19.294940] [drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[   19.294941] [drm]   Encoders:
[   19.294941] [drm]     CRT1: INTERNAL_DAC1
[   19.294942] [drm] Connector 1:
[   19.294942] [drm]   DVI-I-1
[   19.294942] [drm]   HPD1
[   19.294942] [drm]   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[   19.294943] [drm]   Encoders:
[   19.294943] [drm]     CRT2: INTERNAL_DAC2
[   19.294943] [drm]     DFP1: INTERNAL_TMDS1
[   19.347766] [drm] fb mappable at 0xC00C0000
[   19.347780] [drm] vram apper at 0xC0000000
[   19.347781] [drm] size 7680000
[   19.347781] [drm] fb depth is 24
[   19.347781] [drm]    pitch is 6400
[   19.347826] radeon 0000:e1:00.0: [drm] fb1: radeondrmfb frame buffer device
[   19.347830] [drm] Initialized radeon 2.50.0 20080528 for 0000:e1:00.0 on minor 1
[   19.475545] [drm] amdgpu kernel modesetting enabled.

[voltara]

According to this video bios collection your card does not have UEFI support.

Does enabling legacy bios mode change the behavior? There are also CSM (compatibility support module) settings you might want to experiment with.

[davidtmyers]

Oh no! If that’s the case, perhaps it’s time to retire this GPU after 20 excellent years of service.

Is UEFI support required to display even text consoles or simple VGA-graphics desktops (a la 1024x768 resolutions)?

What’s strange is that this card displays images (a Debian 12 splash screen) when running off of the Debian 12 Gnome LiveCD.

I will explore enabling Legacy BIOS Mode and see if that changes the behavior, though honestly - I’d much rather stick to a UEFI BIOS now and just buy a new GPU if necessary.

Would you mind sharing what GPU and what OS you’re running with on your WRX90E/WRX80E?

[voltara]

I have the ASUS WRX90E board. The GPU is a GTX1080 (released in 2016) that I carried over from my previous desktop. I also had trouble initially with getting anything to display through the DisplayPort outputs (HDMI was ok), but nvidia had a vbios patch to fix the issue. It works now that I applied the patch, though still not 100% of the time.

The OS is Ubuntu 23.10. I normally stick with LTS releases, but I made an exception for PipeWire support.

[davidtmyers]

Thanks voltara. A few quick questions for you just to confirm some behavior I’m seeing on my end:

1. Are you running your GTX 1080 as the only discrete GPU in your WRX90E?

2. When your machine boots up, do you see the UEFI BIOS and GRUB output on the monitor connected to your GTX 1080, or do you only get output after the kernel loads?

3. Did you end up fiddling with the VGA_SW switch on the motherboard at any point in time?

4. When you access the web-based iKVM via the BMC/IPMI feature that our motherboards come with, do you get any output? If so, do you see a text-based TTY console or does it mirror what’s shown on your GTX 1080?

[davidtmyers]

I’d also welcome input from anyone else running WRX90E boards: are you able to run a discrete GPU while also preserving your ability to use the iKVM feature? What setting is your VGA_SW switch on your motherboard?

[voltara]

Sorry it took a while to respond. I had to wait until a workload finished before I could reboot and test things.

Yes, the GTX 1080 is the only discrete GPU.

I’ll answer this based on a HDMI connection, because I have a 50-50 success rate booting on DisplayPort:

• On boot, I see everything on my monitor connected to the GTX1080, starting with the ASUS logo and the prompt to press “Del or F2 for Setup”.
• Most of these screens are also visible on the Remote KVM. The KVM doesn’t manage to connect soon enough to see the “Del or F2” screen. At one point during the boot process (around the “pushing firmware to odata server” screen), the KVM loses connection and reconnects.
• As soon as the OS takes over, the KVM goes dark with No Signal.
• If I’m on DisplayPort and the boot “fails”, everything gets output to the KVM including the OS. (But nothing is displayed on the monitor.)

I did experiment with the VGA_SW. The reason is Ubuntu insists on using it as a second display, so my desktop extends off the right edge of my monitor (and my mouse pointer can escape into that region as well.) I tried disabling the VGA display in Ubuntu’s Display GUI, but it didn’t work. I was able to disable it with an xrandr command, but that won’t survive a reboot.

Right now VGA_SW is on, but I might end up turning it off due to the annoyance of it. I set up Serial Port Console Redirection, and it does pretty much everything I would need anyway.

[davidtmyers]

No apologies necessary - I definitely know what it’s like to wait for workloads to finish. That’s part of the reason why I upgraded to this motherboard (more PCIe slots for more accelerators)!

Thank you for very clearly describing the behavior you see during boot. On the off-chance that you, or someone else stumbles across this thread looking to confirm their experiences, I’ll share the behavior I’m seeing:

• Starting from a Powered Off state, I will log into the iKVM and go to “Remote Control” in the left hand side navigation pane. I will then click “Launch H5Viewer” to open up the HTML5-based KVM.
  

  

• When I click “Power On Server” from the “Power” drop-down menu at the top, I see the AMI UEFI BIOS splash screen within 30-32 seconds. Note: this is longer than normal because I’ve disabled some “quick POST” settings in the UEFI BIOS - see below. At this time, the monitor connected to my GPU is off/in its power-save state (amber power light) and has not been woken up yet by a video signal. This may be because my GPU is 20 years old (AMD RV370 [Radeon X300] - see inxi output in my original post) and doesn’t have UEFI support.
  

  

• The AMI UEFI BIOS screen stays present in the iKVM for 10+ more seconds, at which point, the iKVM screen briefly goes black and then states “Pushing firmware to OData server.” That screen appears at the 50-52 second mark. The monitor attached to my discrete GPU continues to be off/in it’s low-powered state. I can only see what’s going on thanks to the iKVM.
  

  

• Next, we hit GRUB at the 50-52 second mark. The monitor attached to my discrete GPU continues to be in its power-save state and is not yet displaying a picture. Were it not for my laptop and my iKVM, I would still see nothing while sitting at my desk.
  

  

• After the GRUB countdown ends and we begin loading the kernel, we hit the default login screen for a KDE install of Debian 12.5 Bookworm at 55-57 seconds. Again, I can’t actually see this on the monitor on my desk, which is still dark/in its low-power state. I only know this because I can see it on the iKVM, which I’ve logged into on my laptop.
  

  

• Using the iKVM, I log into my user account and lo and behold, suddenly the power LED on my monitor goes from amber to green (indicating it’s received a signal and is leaving its low-powered state), and I’m presented with a desktop on my physical monitor. At the exact same time, the iKVM immediately transitions to “No Signal”.
  

  

This is obviously annoying for a few reasons:

1. If I don’t have the iKVM up and running when I’m ready to log in, I have to log in “blind”.
2. When I move this machine into production, I intend to enable full disk encryption. This will also force me to type my decryption password during boot “blind”.
3. If there are any errors mentioned during POST, I’m not going to see them unless I’m monitoring iKVM.

I suspect some of these issues will be resolved if I get a more recent GPU with UEFI support. My current GPU was designed in 2004 and released in 2005 by ATI (prior to the AMD acquisition), so perhaps 20 years of service is good enough.

Re: the extra desktop, once I log in, I get similar behavior as you: Debian 12.5 KDE treats the iKVM as another screen and “extends” a 640x480 desktop onto it. However, different from what you’re experiencing, I am able to successfully disable the display to prevent my mouse from getting lost over there. This appears to be permanent and survives reboots.

Re: my VGA_SW, I also currently have that set as “Enabled”. I’ve read that setting it to “Disabled” will completely solve all of these problems, but it comes at the cost of sacrificing the iKVM functionality, and honestly that can be key when you need to remotely manage the machine from home.

As mentioned above, here’s my boot settings in my BIOS (Boot → Boot Configuration). You’ll note that I’ve disabled Fast Boot, the logo display, extended the duration of the POST Report, etc.

[qqk]

@davidtmyers

I’d also welcome input from anyone else running WRX90E boards: are you able to run a discrete GPU while also preserving your ability to use the iKVM feature?

No. Once you have a running OS, you should remotely manage it via RDP/VNC/etc.

The nVidia GT 710 series has nice, single-slot cards that have a UEFI-compatible video BIOS and are available used in the ~$20 shipped range.

[davidtmyers]

Eh, I respectfully disagree.

Sure, when things are working perfectly, managing whatever workloads are running on boards like these (7 PCIe slots) can definitely be done at the OS layer (SSH, RDP, VNC, NoMachine, etc.)

But things don’t always work perfectly (as evidenced by many of the posts on these forums regarding this board) and thus having an iKVM solution that always works - regardless of whether a discrete GPU is plugged in or not - is useful. This is how some of the Supermicro boards have behaved in the past, and I just assumed (perhaps wrongly) that’s how ASUS’s IPMI implementation would behaved as well.

And let’s not forget that there are certainly many high-value use cases and workloads where remotely managing boards like these at the OS level may not even be possible because the OS may not support these types of remote access technologies. (And that’s assuming you’re even running an OS in the first place!) You may be surprised to learn that a lot of next-gen industrial machinery and devices still run on variations of DOS (FreeDOS being one) and that a 7 PCIe motherboard like this can control an entire production line.

Also, HW dev, accelerator card dev, and any low level peripheral work often times means you’re spending just as much time in a UEFI shell or some proprietary debug environment or some vendor-supplied hardware dev environment as you are in a traditional OS. There’s no SSH, RDP, VNC, or NoMachine available in a lot of these closer-to-the-hardware environments where Serial + VGA out is often the best you’re going get, hence the value of having an iKVM that always works regardless of whether a discrete GPU is plugged in or not.

Regardless, I agree with you though on the point that a more modern GPU will likely help. I’ve been out of the GPU game for 2 decades (can you tell?) but have heard NVIDIA cards are… difficult. If all we’re trying to do is display a Wayland-based desktop environment (currently KDE), I imagine a recent-ish (last ~3 years) offering from AMD or Intel will mean default Linux kernel support will be good enough.