Getting the Radeon R9 280X Working on Modern Linux

LAB NOTE 001 // R9 280X // AMDGPU // RADV // ARCH LINUX

SEPTEMBER 2026

Running a Radeon R9 280X on a modern Linux system sounds straightforward, but this old Tahiti GPU turned into one of the first real troubleshooting experiments on Mainframe.

What started as occasional crashes eventually led me through different kernels, the legacy Radeon driver, AMDGPU, Vulkan and RADV before I arrived at the configuration I’m currently using.

---

01 // THE PROBLEM

After installing Arch Linux on Mainframe, everything initially appeared to be working normally. The R9 280X was detected, the desktop worked and I could use the system without any obvious problems.

Things started getting interesting when I began using the machine more heavily. I started experiencing seemingly random crashes where the graphical session would suddenly disappear and I would be thrown back to the login screen. At first, I wasn’t sure whether the problem was related to XFCE, the graphics driver or even the old hardware itself.

Looking through the system logs eventually pointed me towards the GPU. The kernel was reporting graphics ring timeouts, VM faults and repeated GPU resets. One particularly telling message reported that VRAM had been lost following a GPU reset.

Some of the messages recorded in the logs included:

ring gfx timeout
VRAM is lost due to GPU reset

The crashes also appeared in connection with graphical processes such as Xorg and, during gaming tests, Steam’s steamwebhelper. At this point, the problem was clearly pointing towards the graphics stack rather than simply being an XFCE issue.

---

02 // TESTING THE LTS KERNEL

Since the crashes appeared to be related to the graphics stack, one of the first things I wanted to test was whether the problem was specific to the current Arch Linux kernel. At the time, Mainframe was running the regular Arch kernel, so I installed the Linux LTS kernel to compare the behaviour without changing the rest of the system.

After booting the LTS kernel, I checked which driver was actually controlling the R9 280X.

spci -k | grep -A 3 -E "VGA|3D"

The important output from the troubleshooting was:

Kernel driver in use: radeon
Kernel modules: radeon, amdgpu

This immediately revealed an important difference. Under the LTS kernel, the Tahiti GPU had bound to the older radeon kernel driver instead of amdgpu.

That created another problem. Vulkan through RADV was no longer working correctly. When I tried to test Vulkan, it failed with:

VK_ERROR_INCOMPATIBLE_DRIVER

This was important because I wanted Mainframe to be capable of running games through Steam and Proton. For this old AMD GPU, having working Vulkan support was therefore more than just an interesting experiment—it was something I actually needed.

---

03 // FORCING AMDGPU

The LTS kernel gave me another useful clue. The R9 280X was capable of using AMDGPU, but the system was loading the older Radeon driver instead. Since I wanted working Vulkan support through RADV, I decided to explicitly tell the kernel which driver should handle the card.

The R9 280X is based on AMD’s Tahiti architecture, which belongs to the Southern Islands generation. On this hardware, Linux can expose both the radeon and amdgpu kernel modules, so I needed to disable Southern Islands support in Radeon and enable it in AMDGPU.

I did this by adding the following kernel parameters:

radeon.si_support=0 amdgpu.si_support=1

Because Mainframe uses GRUB, I added these parameters to /etc/default/grub. My final configuration looked like this:

GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet radeon.si_support=0 amdgpu.si_support=1"
GRUB_CMDLINE_LINUX=""

Before regenerating the GRUB configuration, I also checked the file for syntax errors:

ash -n /etc/default/grub

After rebooting into the LTS kernel, I checked the GPU driver again. This time the result was exactly what I wanted:

Kernel driver in use: amdgpu
Kernel modules: radeon, amdgpu

The R9 280X was now running on AMDGPU while using the LTS kernel. The next question was whether Vulkan and RADV were working correctly again.

---

04 // VULKAN $ RADV

With the R9 280X now running on AMDGPU, the next step was to check whether Vulkan was working again. This was especially important for Mainframe because Vulkan is required by DXVK when running many Windows games through Steam and Proton.

I tested the Vulkan installation using:

vulkaninfo --summary

This time, instead of the VK_ERROR_INCOMPATIBLE_DRIVER error I had encountered while using the Radeon driver, Vulkan successfully detected the R9 280X through Mesa’s RADV driver.

The important part of the output showed:

AMD Radeon R9 200 / HD 7900 Series (RADV TAHITI)
Mesa RADV

The device was also reporting Vulkan API 1.3 support, confirming that the old Tahiti GPU was now successfully running with the modern AMDGPU and RADV graphics stack.

Seeing Vulkan working on a graphics card from this generation was one of those moments that reminded me why I started the Mainframe project in the first place. The R9 280X may be old hardware, but with the right Linux configuration it can still use a surprisingly modern graphics stack.

TESTING STEAM

The next test was Steam. Earlier, Deus Ex: Human Revolution Director’s Cut had failed to start because Proton and DXVK couldn’t find a usable Vulkan device while the card was running on the Radeon driver.

After switching back to AMDGPU, Steam began building Vulkan shaders for the game, which was a good indication that RADV was now being detected correctly by the gaming stack.

---

04 // CURRENT RESULT

Mainframe is currently running the Linux LTS kernel with the R9 280X using AMDGPU and RADV. Vulkan is working again, and the system can use the modern Linux gaming stack despite the age of the GPU.

I’m continuing to use and test the system to see how stable this configuration remains over time.

Check back once in a while to see if anything changes.