I am on the latest stable build.

My Arc A310 shows in lspci

My board also has a BMC so the Aspeed 2500 also shows in lspci

lspci -k shows both the i915 and xe drivers as available but not bound and /dev/dri shows card0 which is the aspeed 2500.

I am told Arc is Plug and Play on unraid but I am not seeing it.

I have attached the diagnostics which have been anonymized.

mediamouse-diagnostics-20251017-1038.zip

Edited October 17, 2025Oct 17 by KRDucky
attached diagnostics

I just ran into this same issue. For me the solution with the ROMED8-2T board, was through the bios. Advanced -> Chipset and change primary graphic adapter to 'Onboard'.

Summary of your diagnostics:

- The Aspeed BMC (AST) is currently bound as the primary GPU: /sys/class/drm/card0 -> driver ast.

- The Intel Arc A310 (DG2) is present in lspci but has no kernel driver bound (Kernel driver in use: none).

- xe and i915 modules are loaded but neither is bound to the Arc card, so /dev/dri only exposes the Aspeed device.

Likely root cause:

- The board boots with the Aspeed BMC as primary VGA device, preventing the Arc A310 from being initialized as the active DRM GPU.

Immediate recommendations (in order):

1) BIOS: Set Primary Display / Init Display First to PCIe/PEG (disable "BMC/Aspeed as primary VGA"). Reboot and check lspci -k and /dev/dri. This is the cleanest fix.

2) If BIOS change is not available: try unbinding the AST driver and binding the Arc driver manually (SSH, root):

- echo 0000:22:00.0 > /sys/bus/pci/drivers/ast/unbind # (replace with actual Aspeed PCI address)

- echo 0000:2e:00.0 > /sys/bus/pci/drivers/xe/bind # (replace with Arc PCI address)

Then check lspci -k -s 2e:00.0 and ls -l /dev/dri. # (replace with Arc PCI address)

Useful checks to paste back if this doesn't work:

- lspci -k -s 2e:00.0 # (replace with Arc PCI address)

- ls -l /sys/class/drm/

- dmesg | egrep -i 'xe|i915|aspeed|ast|drm'

Bottom line:
It’s almost certainly just a BIOS configuration issue.

The diagnostics don’t show a driver or kernel problem. The system is treating the Aspeed BMC as the primary GPU, so the Arc A310 never gets initialized or bound to the xe driver. Once the BIOS is set to use PCIe/PEG as the primary display, the Arc should load normally and show up under /dev/dri without any manual binding.

Only if the BIOS cannot switch the primary GPU, the unbind/bind workaround is needed.

Already tried all those steps before posting. BIOS was already set to PEG.

Blacklisted AST modules causes server to not even boot

Forcing i915 or xe doesnt work either.

I replaced the motherboard and cpu altogether.

Thanks for the update — that changes the picture.

If PEG was already set and the system still initialized the BMC as the primary GPU, then it wasn’t a simple BIOS-priority issue. Many server boards with BMC ignore the PEG setting unless a secondary “Onboard/BMC VGA” or “Internal Graphics” toggle is disabled as well, so the behavior you saw is consistent with that.

Blacklisting AST breaking the boot also confirms that the board was hard-wired to rely on the BMC framebuffer during POST/boot, so the ARC never became the active DRM device, regardless of driver forcing.

Since replacing the motherboard and CPU fixed it, it strongly suggests a firmware/BIOS/BMC implementation problem on the previous board rather than an Unraid driver issue.

In short: you didn’t do anything wrong — the previous board simply wouldn’t hand off primary GPU to the ARC under Linux, even with the correct settings.

1 hour ago, enect said:

Thanks for the update — that changes the picture.

If PEG was already set and the system still initialized the BMC as the primary GPU, then it wasn’t a simple BIOS-priority issue. Many server boards with BMC ignore the PEG setting unless a secondary “Onboard/BMC VGA” or “Internal Graphics” toggle is disabled as well, so the behavior you saw is consistent with that.

Blacklisting AST breaking the boot also confirms that the board was hard-wired to rely on the BMC framebuffer during POST/boot, so the ARC never became the active DRM device, regardless of driver forcing.

Since replacing the motherboard and CPU fixed it, it strongly suggests a firmware/BIOS/BMC implementation problem on the previous board rather than an Unraid driver issue.

In short: you didn’t do anything wrong — the previous board simply wouldn’t hand off primary GPU to the ARC under Linux, even with the correct settings.

Thanks for the ChatGPT response.

1 hour ago, enect said:

Thanks for the update — that changes the picture.

If PEG was already set and the system still initialized the BMC as the primary GPU, then it wasn’t a simple BIOS-priority issue. Many server boards with BMC ignore the PEG setting unless a secondary “Onboard/BMC VGA” or “Internal Graphics” toggle is disabled as well, so the behavior you saw is consistent with that.

Blacklisting AST breaking the boot also confirms that the board was hard-wired to rely on the BMC framebuffer during POST/boot, so the ARC never became the active DRM device, regardless of driver forcing.

Since replacing the motherboard and CPU fixed it, it strongly suggests a firmware/BIOS/BMC implementation problem on the previous board rather than an Unraid driver issue.

In short: you didn’t do anything wrong — the previous board simply wouldn’t hand off primary GPU to the ARC under Linux, even with the correct settings.

Thanks for the ChatGPT response

7 hours ago, KRDucky said:

Thanks for the ChatGPT response

I use AI for translation since I'm from Germany. But it's a brilliant response when someone wants to help. Life needs people like that... ungrateful.

3 hours ago, enect said:

I use AI for translation since I'm from Germany. But it's a brilliant response when someone wants to help. Life needs people like that... ungrateful.

I posited that same question to chatgpt and it gave me an almost identical response.Not being ungrateful. Just being realistic. I don't post to forums until I have exhausted all other options.

4 hours ago, KRDucky said:

I posited that same question to chatgpt and it gave me an almost identical response.Not being ungrateful. Just being realistic. I don't post to forums until I have exhausted all other options.

Just to be clear — these are my observations. I’ve had first-hand experience with this kind of problem: I owned an ASRock Rack ROMED8-2T/BCM and returned it for exactly these kinds of issues. Later I ran a Supermicro H12SSL-CT, which was stable but got scrapped due to high idle power (I even posted about that in the German forum).

I recognized the situation in your case, wrote down my thoughts, and yes, I used AI to help phrase it in English. That doesn’t mean the insight isn’t mine — AI just helped shape it. This is reality now: tech evolves, tools assist, but the analysis is still human. Not everyone asking for help actually wants it, and that’s fine — just saying.

Honestly, my lifetime is too short to argue about this kind of stuff, so I’m done with the topic.

2 hours ago, enect said:

Just to be clear — these are my observations. I’ve had first-hand experience with this kind of problem: I owned an ASRock Rack ROMED8-2T/BCM and returned it for exactly these kinds of issues. Later I ran a Supermicro H12SSL-CT, which was stable but got scrapped due to high idle power (I even posted about that in the German forum).

I recognized the situation in your case, wrote down my thoughts, and yes, I used AI to help phrase it in English. That doesn’t mean the insight isn’t mine — AI just helped shape it. This is reality now: tech evolves, tools assist, but the analysis is still human. Not everyone asking for help actually wants it, and that’s fine — just saying.

Honestly, my lifetime is too short to argue about this kind of stuff, so I’m done with the topic.

Then surely you noticed where I mentioned I ended up replacing the entire board and CPU hence this is no longer an issue