dg6464

Hi all, I upgraded this host from 7.2.x to 7.3.1 yesterday afternoon. It had been stable on 7.2.x for a long time, and these issues only began after the upgrade. I’m seeing two separate symptoms on 7.3.1 / kernel 6.18.33-Unraid: 1) Plex instability Shortly after upgrading, Plex went unstable and contributed to a host failure severe enough that I had to reboot Plex was using Intel Battlemage / Arc hardware transcoding at the time Since rebooting and switching Plex transcoding back to the Intel iGPU, Plex now appears stable That makes me suspect either: a 7.3.1 kernel / Intel driver issue Battlemage / Arc-specific instability or an issue with the newer Plex transcoder path interacting with the Intel stack on 7.3.1 Plex details: Container: plexinc/pms-docker:latest Digest: sha256:c37106c57fed7a6624f5dee5a3ce460ff011f09a2aa7f4ee9e8dbbd08ae1b87e Container OS: Ubuntu 24.04.4 Plex logs reference intel-compute-runtime 24.52.32224.5 Example Plex log during failure: Critical: libusb_init failed Abort was called at 134 line in file: ... intel-compute-runtime/24.52.32224.5 ... 2) UniFi OS VM hangs My Ubuntu-UnifiOS VM also became unstable only after the 7.3.1 upgrade VM still shows running in libvirt and remains present on br0 / ARP / FDB The issue happens after a short period of time; I can access the VM GUI and SSH for the first few minutes after boot After that, SSH / web management stop responding In one hung capture, a single QEMU thread is pegged: CPU 3/KVM ~100% vcpu.3.blocking.cur=no I also captured net.0.rx.drop=3172 In the minutes leading up to the hang, other non-pinned host CPU cores also spike hard, which does not happen with this VM shut down Important: This happened on older UniFi versions I then updated UniFi OS + Network Application to latest Behavior did not change What remains stable Windows 11 VM is stable Home Assistant VM is stable Other Docker containers are stable Plex appears stable now after moving transcoding off Arc/Battlemage and back to iGPU So this does not look like a full general host failure. It looks more like a 7.3.1 regression affecting specific workloads. Files attached unraid-diags-baseline-20260530-1334.zip unraid-diags-hang1-20260530-1351.zip unraid-diags-hang2-20260530-1410.zip unifi-vm-custom-captures-sanitized-20260530.zip Main questions Does this look like a known 7.3.1 regression involving Intel Arc/Battlemage, Plex transcoding, or KVM/libvirt/virtio networking? Would you recommend I downgrade to 7.2.7 as the next test to confirm whether both issues disappear there? Happy to troubleshoot further, post additional logs, or follow any recommended testing steps. unifi-vm-custom-captures-sanitized-20260530.zip unraid-diags-baseline-20260530-1334.zip unraid-diags-hang1-20260530-1351.zip unraid-diags-hang2-20260530-1410.zip

Just as a quick note... I got all of my new hardware set up, which includes an Arc B580, as well as an Intel Core 7 Ultra 265k, with 64GB DDR5 6400MHz RAM, running unRAID 7.1-rc1 beta with latest versions of Apps, Docker Containers, etc. I might just return the Battlemage Card... and the reason is the CPU is just an absolute beast from a transcoding perspective. That is especially when it comes to 4K Transcoding with HDR Tone Mapping, DoVi. Even more so when paired with the new experimental HEVC/x265 outbound transcoding functions "Enable HEVC video Encoding (experimental) - Enable transcoding using the HEVC codec if it is supported by the client." and "Enable HEVC Optimization (experimental) - If available, enable use of HEVC while optimizing your media. I was able to test at ~13 streams of content that were 4K Original Files (all H265/HEVC, most with HDR and/or DoVi) before the CPU was overloaded (or the wifi on my Macbook M3 Pro Max wasn't enough - I'm not sure which yet and didn't think to switch to a wired connection prior to testing). Curiously... I was able to do quite a bit more transcodes when I was using the new HEVC outbound experimental features, as it seems since these new CPU's do HEVC Encoding in hardware (note, this is for outbound experimental HEVC to the end clients... previously before selecting the experimental functions everything leaves a Plex server in x264 when being transcoded). Either way... unless you are planning to actually game with the B580 in parallel... I would just stick with the Core 7 Ultra 265k CPU for now, as it should meet most needs. Just as a quick test... I did actually "see" the B580 Battlemage card as a menu option in Plex in the Transcoder Page (since unRAID supports it on the 7.1-rc1 beta), but due to what is described above for Plex driver dependencies, Plex throws an error at the client when you attempt to transcode with the Battlemage card selected (but didn't reboot or anything). Any questions, I'd be happy to answer... or can put up a dedicated post for anyone curious just about the new Intel CPU's... it's too bad that it's looking like Nova Lake will be using LGA1954 and this socket will likely be abandoned.

From what I understand, the Plex Transcoding portion will be a bit longer based on this thread in the Plex Forum: &nbsphttps://forums.plex.tv/t/battlemage-support/910409 “The version of the Intel Media Driver Plex builds and bundles with Plex seems to be Version 24.1.5-3 and the battlemage initial support was added with Version 24.3.4. So we have to run a custom kernel and wait for Plex to update the Intel video driver to a version 24.3.4 or higher. The custom kernel alone didn’t work. There are reports of people getting BMG to work with jellyfin though. So that would answer your question about anyone getting BMG to work with any kernel” So it seems the VM passthrough will work with 7.1 since unRAID will recognize the device properly… it won’t be providing transcoding for Plex via a Plex Docker until Plex uses a newer driver build. Maybe you can pass through to the VM and run Plex from windows for now? Or has someone tested this successfully on 7.1 beta with Plex (via Docker) and a B580 Arc? Thanks!

Just a quick update... I did a fresh install of 6.9.2 (I have a second license for unRAID, so different USB key). The problem persisted... so it seems to be a hardware recognition issue on my end with the server I swapped to (still the same error in the logs, on a brand new 6.9.2 install). Likely too much of the PCIe bus populated with Dell HBA, PCIe to M.2 converter, NVIDIA P2000 Card, etc... for the Intel X520 to function properly (X520 functions fine in my Core i7 7700k system). I wasn't aware that there could be a lack of resources to even start hardware on some recent hardware (it's a HP Z420 Workstation)... and unfortunately there is no easy way to disable onboard hardware to see if it will fix the issue for me. I'll be upgrading to a new server once AMD Zen4 is out... so no sense in investigating. Unless anyone has any hardware/BIOS suggestions... I think we can consider the thread closed.

I will investigate how to roll back to 6.9, do so and report back... as my Tools --> Update OS only has 6.10.2 as a previous version. Thanks!

Attaching Diagnostics - apologies I didn't in the first post. unraid-1-diagnostics-20220622-1008.zip

Hello unRAID Forum, Wondering if anyone else has experienced their NIC card no longer being detected under Network Settings after moving to 6.10.x (although this may be completely unrelated to moving to 6.10, however I am unsure)? I believe there were some mentions in release notes of bootup hardware detection changes for Mellanox NIC's specifically... however mine is an Intel X520 (I've also tried a Broadcom 10Gbps, which also did not detect in Network Settings). So it's possible I need to do some sort of network settings "reset", but I am not sure of the best steps to follow to do this properly. I did do a hardware migration recently, however the Intel X520 NIC was detected when I first migrated... but now only detects and uses the 1Gbps onboard NIC (which I am unable to disable in BIOS in an HP z420, which is annoying). The X520 is detected in Diagnostics as follows... so just isn't seen by the Network Settings as useable for some reason (please note: there is a physical connection to my 10Gbps switch and all lights are green/links up physically): <node id="network:0" class="network" handle="PCI:0000:05:00.0" modalias="pci:v00008086d000010FBsv00008086sd0000000Cbc02sc00i00"> <description>Ethernet controller</description> <product>82599ES 10-Gigabit SFI/SFP+ Network Connection</product> <vendor>Intel Corporation</vendor> <physid>0</physid> <subproduct>Intel Corporation</subproduct> <subvendor>Intel Corporation</subvendor> <businfo>pci@0000:05:00.0</businfo> <version>01</version> <width units="bits">32</width> <clock units="Hz">33000000</clock> <configuration> <setting id="latency" value="0" /> </configuration> <capabilities> <capability id="pm" >Power Management</capability> <capability id="msi" >Message Signalled Interrupts</capability> <capability id="msix" >MSI-X</capability> <capability id="pciexpress" >PCI Express</capability> <capability id="cap_list" >PCI capabilities listing</capability> </capabilities> <resources> <resource type="ioport" value="b020(size=32)" /> <resource type="memory" value="ef580000-ef5fffff" /> <resource type="memory" value="380000300000-3800003fffff" /> <resource type="memory" value="380000200000-3800002fffff" /> </resources> <hints> <hint name="icon" value="network" /> <hint name="pci.class" value="0x200" /> <hint name="pci.device" value="0x10FB" /> <hint name="pci.subdevice" value="0xC" /> <hint name="pci.subvendor" value="0x8086" /> <hint name="pci.vendor" value="0x8086" /> </hints> </node> <node id="network:1" class="network" handle="PCI:0000:05:00.1" modalias="pci:v00008086d000010FBsv00008086sd0000000Cbc02sc00i00"> <description>Ethernet controller</description> <product>82599ES 10-Gigabit SFI/SFP+ Network Connection</product> <vendor>Intel Corporation</vendor> <physid>0.1</physid> <subproduct>Intel Corporation</subproduct> <subvendor>Intel Corporation</subvendor> <businfo>pci@0000:05:00.1</businfo> <version>01</version> <width units="bits">32</width> <clock units="Hz">33000000</clock> <configuration> <setting id="latency" value="0" /> </configuration> <capabilities> <capability id="pm" >Power Management</capability> <capability id="msi" >Message Signalled Interrupts</capability> <capability id="msix" >MSI-X</capability> <capability id="pciexpress" >PCI Express</capability> <capability id="cap_list" >PCI capabilities listing</capability> </capabilities> <resources> <resource type="ioport" value="b000(size=32)" /> <resource type="memory" value="ef500000-ef57ffff" /> <resource type="memory" value="380000100000-3800001fffff" /> <resource type="memory" value="380000000000-3800000fffff" /> </resources> <hints> <hint name="icon" value="network" /> <hint name="pci.class" value="0x200" /> <hint name="pci.device" value="0x10FB" /> <hint name="pci.subdevice" value="0xC" /> <hint name="pci.subvendor" value="0x8086" /> <hint name="pci.vendor" value="0x8086" /> </hints> </node> </node> Any guidance would be greatly appreciated to getting my 10Gbps X520 back up and running. Thanks! Best Regards, dg6464

@Tristankin… how was the rollback to 6.8.3 from 6.10-rc’s? You mentioned some complications with dockers updating and such. My 6.10-rc4 system is fully updated from all aspects, plug-ins, dockers, etc. Has it been a tough process to roll back for you? If I have one more full crash… I may have to consider it.

Just adding, I was on 6.9.2 and tried 6.10-rc4. Both causing crashes almost daily that are hard lock-ups requiring full reboot (with parity check flag after)… but only on my Intel iGPU system. Same as users above - nothing in logs or syslog. I migrated from a 28-Core Dual Xeon to an i-7700k to use QuickSync, which works amazing when the system doesn’t lock up (almost unlimited transcodes… that even a 28-core Dual Xeon couldn’t keep up with on CPU, in software). Dual Xeon solid on 6.9.2 for months. Swap to i-7700k hard reboots required as per the thread above (i-7700k system has been running multiple months on Windows, Memtest86 multiple passes, Prime95 multiple days to stress test… so it’s not a hardware issue). I’ve got both systems, as well as two licenses for unRAID and am willing to troubleshoot further… but this largely seems like a kernel issue of some sort and requires some sort of lower-level logging to solve. If you need any more data or my to add to the bug report, happy to.