enect

Sorry, da hatte ich mich verschrieben... Ziel war und getestet hab ich nach der "Aufteilung" den D128 mit geladenen xe-Treiber an frigate zu geben (nicht den D130). Aber ich hab dann die Hardwarebeschleunigung in frigate nicht zum laufen bekommen, obwohl dazu auch nen bisschen was in der friagte docu steht. Nur mit i915 läuft es bei mir. Das i915 SR-IOV PlugIn hat bei mir bisher nicht sauber funktioniert. Aber gut, vielleicht muss ich das unter 7.3 nochmal testen. Hatte halt gehofft, mit dem Kernel 6.18 das PlugIn zu umgehen. Edit: Lese grad, dass SR-IOV im xe-treiber wohl gar nicht für die iGPUs gedacht ist und somit da meine Test-Fehlerquelle liegen kann.

Hab heute das Update auf 7.3 gemacht und i915.force_probe=!a780 xe.force_probe=a780 xe.max_vfs=2 getestet. Musste dann noch im go - file helfen. # SR-IOV VFs für den xe-Treiber erzeugen sleep 10 echo 2 > /sys/bus/pci/devices/0000:00:02.0/sriov_numvfs logger "SR-IOV: 2 VFs fuer Intel iGPU (xe) erfolgreich erzeugt" danach hatte ich das sichtbare ergebnis unter ls -l /dev/dri Aber ich bin auch im ersten Docker (frigate) gescheitert und konnte da die D130 nicht aktivieren. Er hat es nicht geschluckt... Keine Ahnung.

Danke das du deine Lösung postet, die in der Praxis -wie du selber schreibst- etwas umständlich ist. Ich schaffe es selbst noch nicht, auf 7.3 zu gehen und meine Tests zu machen... wäre aber jetzt auch davon ausgegangen, dass mit Kernel 6.18 und 14th Intel einiges besser wird. Hast du zufällig 915.force_probe=!a780 xe.force_probe=a780 xe.max_vfs=2 probiert, also inkl. dem Definieren der VF? Nach Reboot sollte man dann sehen, ob er die VFs bereit stellt ls -l /dev/dri Das Plex den xe nicht schluckt, ist natürlich ein anderes Thema. Ziel wäre schon, ohne das PlugIn klar zu kommen und dem 6.18 Kernel inkl. xe allein zu nutzen.

I haven't upgraded to 7.3 yet, but shouldn't the xe driver work now with 7.3 and kernel 6.18.28? That is, if I block 915 and force xe using the parameters 915.force_probe=!a780 xe.force_probe=a780 xe.max_vfs=2... If this is working, I should be able to see the expected result by running ls -l /dev/dri, and subsequently—in this example—assign a VF to the VM and another to Docker. Or am I overlooking something? Oh, in my case there's an Intel 14700 in the background...

Schau dir mal die iOS oder Android App "FileBrowser Professional" von stratospherix an. Kostet zwar ca. 15 EUR. Aber als ich von Synology auf Unraid umgestiegen bin, hat diese App fast alle Synolgy-Apps ersetz. Inkl. Bildbetrachtung, Sicherung der Bilder mit Routtinen usw... auch ein sehr guter Filebrowser.

ich nutze binhex-krusader zum entpacken. schau mal unter apps nach

I'm the guy with the script from the other thread. I searched and tested extensively... nothing worked if you want to use HDD temperatures as a trigger. I also tried modifying the IPMItools plugin... to no avail. The only thing is, my IPMI card from the mainboard has three temperature sensors. You could put one on an HDD and control it based on that. But that's inaccurate if you have many HDDs. I'd be happy to give you my current script, which has been refined over several months. Analyze it with AI and test it if you like. I'm very happy with it now, and after all this time, I have a lot of confidence in it. Fan_Control (at startup of array): Fan_Control Fan_Control_Secure_Mode (at stopping of array): Fan_Control_Secure_Mode

Nur zur Info. Hab mein Script mal hier vorsichtshalber gelöscht, weil ich einen gravierenden Nachteil gegenüber das existierende Plugin gefunden habe. Das PlugIn greift früh ein und erstellt die RAM Disk. Dann laufen auch andere Sachen fehlerfrei durch. Bei meinem gebastelten Script unter User Script entstehen Fehler in der GUI von user script. Er verliert die Zuordnung zu anderen Scripts und kann sie nicht mehr sauber verfolgen und leicht schlimmeres. Daher ist meine Lösung schrott und ich investiere keine Zeit, wenn jemand schon was funktionierndes gebastelt hat.

Oh OK. Kannst du mir bitte den Namen sagen? Wäre dann vermutlich komfortabler.

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.

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.

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.

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.

Yes – your diagnostics clearly show Machine Check Events (MCEs). That’s exactly what the Fix Common Problems plugin is warning you about. mce: [Hardware Error]: Machine check events logged [Hardware Error]: Corrected error, no action required. Fix Common Problems: Error: Machine Check Events detected on your server mcelog: ERROR: AMD Processor... Please use the edac_mce_amd module instead. What this means: These are corrected hardware errors reported by the CPU. The system didn’t crash, but it indicates a potential hardware issue that shouldn’t be ignored if it becomes frequent. On AMD systems, mcelog is basically unreliable and often throws useless messages — the Linux kernel recommends using the edac_mce_amd module instead. Most common causes: Too aggressive memory settings (EXPO/XMP) Slight system instability (RAM, CPU, PSU) Outdated BIOS with older AMD microcode Recommended steps: If EXPO/XMP is enabled → try disabling it for a while This alone fixes most MCE reports on AMD systems. Update BIOS Many AMD MCE issues are microcode bugs fixed in BIOS updates. Run a full Memtest86 overnight (4+ passes) If errors show up → RAM or memory controller issue. Check PSU quality & voltages Weak/unstable PSUs can trigger MCEs. Bottom line: Your server is not in immediate danger, but the CPU is reporting corrected hardware faults. Keep an eye on it. If these messages become more frequent, then it’s time to take action. Your system is running an AMD Ryzen 5 5600X. This CPU is known to occasionally report corrected Machine Check Events under Linux, especially when: EXPO/XMP memory profiles are enabled, BIOS is outdated, or the system is slightly undervolted/unstable. This isn’t unique to your hardware – it’s a common behavior on Zen 3 CPUs. Many users with 5600X/5800X/5900X/5950X see the same warnings when memory tuning is too aggressive or when the board’s early BIOS revisions had microcode issues.

Bin jetzt kein Experte, aber ich hatte mal ein sehr ähnliches Fehlerbild, als ich über powertop mittels autotune gearbeitet habe. Bei manuellen setzen über Tunables hab ich gemerkt, dass meine Netzwerkkarte (onboard) sich damit nicht vertragen haben. Sobald die "schlafen" gehen sollte, ist u.a. die Weboberfäche eingeschlafen und nicht mehr erreichbar gewesen. Das selbe auch über autotweak, wenn ich dort Ethernet angetastet habe. Vielleicht völlig an deinem Problem vorbei, aber vielleicht doch hilfreich...