Redman

UPDATE: Rolled back to 7.3.4, same container, same model. Kernel is back to 6.18.58-Unraid and GPU inference works again: qwen3:8b at 64K context, 4 runs after rollback: 64.14, 61.49, 63.05, 63.11 tok/s (my earlier 7.3.4 results were 55.9–61.2 tok/s). On 7.4.0 (kernel 6.18.60) the same test fails at every context size from 16K to 64K with an allocation error. So the regression reproduces with the OS version as the only change. Also checked on 7.4.0 before rolling back: boot files verified against their .sha256 files, xe firmware (bmg_guc_70.bin, bmg_huc.bin) byte-identical to 7.3.4's, no extra kernel parameters or xe/i915 modprobe overrides. I'm holding at 7.3.4 until I hear some sort of update regarding this breaking change gets resolved in future release.

After updating from 7.3.4 to 7.4.0, GPU compute on my Intel Arc B580 no longer works in Docker. Two different stacks that ran fine on 7.3.4 now fail with Level Zero allocation errors. The kernel log shows no errors. I am reporting it in case others are affected and to ask whether anything in the 6.18.58 -> 6.18.60 kernel or the 7.4.0 image could explain it. SYSTEM - Unraid 7.4.0 (kernel 6.18.60-Unraid, confirmed with uname -r). Previously 7.3.4 (6.18.58-Unraid), updated 2026-10-24. - GPUs: Intel Arc B580 12 GB (xe driver, 0d:00.0, /dev/dri/renderD128 + card0) used for compute; Intel Arc A310 (i915, 06:00.0) used for transcoding. - 78.5 GiB RAM (about 47 GiB free at the time of the tests). - Containers get /dev/dri/renderD128 and /dev/dri/card0. The test containers were created with plain "docker run" (no memory limit). WORKED ON 7.3.4 (kernel 6.18.58) 1) Ollama 0.9.3 (IPEX-LLM build, uberchuckie/ollama-intel-gpu:stable), qwen3:8b, context 65536: 4 benchmark runs on 2026-10-25: 55.88, 61.18, 58.29, 58.57 tok/s (average 58.5). About 11.5 GB of the card's 12.8 GB in use at 64K; 9.09 GB at 16K. 2) Upstream llama.cpp SYCL (ghcr.io/ggml-org/llama.cpp:server-intel, oneAPI 2026.1), Qwen3.6-35B-A3B IQ3_XXS: -c 65536 -np 1 -ngl 99 --n-cpu-moe 10 -fa on -ctk q8_0 -ctv q8_0 Started healthy in about 80 s, 11.5 GB card usage at 64K, 28-39 tok/s generation depending on context. Restarted several times on 2026-11-02 to 2026-11-04 without problems. Context: 7.3.3 (kernel 6.18.54) had made the same workloads about 60% slower (24.3 vs 64.1 tok/s); 7.3.4 recovered them. So this card/stack has been sensitive to 6.18.x point releases before. ON 7.4.0 (2026-11-14, kernel 6.18.60) 1) Ollama (IPEX) cannot load any model, at any context size (16384, 32768, 49152, 65536 all fail identically). A container restart does not help. ggml_backend_sycl_buffer_type_alloc_buffer: can't allocate 850335744 Bytes of memory on device alloc_tensor_range: failed to allocate SYCL0 buffer of size 850335744 llama_model_load: error loading model: unable to allocate SYCL0 buffer API reply: {"error":"llama runner process has terminated: error loading model: unable to allocate SYCL0 buffer ..."} 2) llama.cpp (same image and flags as above) loads for about 4 minutes (was about 80 s), then aborts in the first decode: terminate called after throwing an instance of 'sycl::_V1::exception' what(): level_zero backend failed with error: 38 (UR_RESULT_ERROR_OUT_OF_HOST_MEMORY) (raised from a kernel submission, ggml_sycl_op_rms_norm_fused -> sycl::handler::finalize) CHECKED/RULED OUT - Not a capacity problem: /sys/kernel/debug/dri/0000:0d:00.0/vram0_mm shows size 12809404416, usage 481116160 (idle), visible_avail 11757MiB; a 16K context fails exactly like 64K. - Not one runtime: two separate userland stacks (old IPEX Ollama and upstream llama.cpp with oneAPI 2026.1) fail differently but both at allocation level. - dmesg: no xe error, GuC reset or wedged message after boot. Boot lines look normal (VRAM usable 0x2fb800000, GuC bmg_guc_70.bin 70.72.1, HuC 8.2.10), plus "xe 0000:0d:00.0: [drm] Can't init xe mei late bind missing mei component". I do not know whether that line was also present on 7.3.4 (I did not save that boot log). - The 7.4.0 release notes list kernel 6.18.60 and no Intel GPU / xe / Docker engine change, and no new known issues. NOT KNOWN - Root cause, and whether it is the kernel, something else in the 7.4.0 image, or an interaction with the userland runtimes in the containers. - Whether the A310 (transcoding) or other GPU containers are affected. I have not tested. Is anyone else on 7.4.0 with an Arc (Alchemist/Battlemage) card seeing compute failures in containers (Ollama, llama.cpp, OpenVINO, etc.)? Did anything in the xe driver, its configuration or module parameters change between 6.18.58 and 6.18.60 in the Unraid build?

My SAB container updated to latest version at 12am this morning (11/7/25 6:21am is the time now here) container just keeps restarting with : sabnzb warning SIGTERM signalled exit request signal 15 exit code 143, disabled health check still happening, am currently rolling back to previous release which seemed stable to see if that fixes issue for me ***this seems to of fixed the restart loop, also was an “Warning” about 7za being missing I think it was, that is also gone…..so far

so i did post this earlier but it didn't seem to upload, i think what had happened was the router gave my server IP to another device and as my server IP was static couldn't load its WebUI as the other device connected via the IP did not have a WebUI to load, i found this out the long way lol, downloaded Unraid, installed Unraid on a new USB but with super.dat copied across, inserted new USB and removed old, connected server to another network and booted up server, WebUI and everything else was available, the shut down server and swapped back the USB to original/Primary and booted up still connected to the secondary network, loaded Unraid with plugins and docker disabled and changed the network IP attainment to DHCP from static, rebooted Unraid server and the server booted up and received a new IP address, WebUI was available via this new IP, logged into router and set the IP address as reserved for the server and set as static on the server and sat down with the router and had a very stern conversation about responsibilities and expectations, felt like talking to a brick wall but hoping some of it went through lol anyhow, something that shouldn't have happened, happened, now it has been corrected all is sorted, thank god I'm a "move" guy and not a "delete" guy when it comes to troubleshooting thank you for those who looked into my issue and offered advise and assistance, you are appreciated.

no effect, have downloaded unraid onto separate usb, will attempt to run and access via WebUI to rule out hardware issue, if working have added super.dat to usb to retain data, may just go from there.

restart no affect, have removed all plugins and network.cfg in hope some miss configuration may be at play, if after restart no effect will remove reverse proxy container incase conflict with port is the error, will post results.

disabled use of ssl and attempted to access WebUI, no luck will restart server and attempt again.

Yes, 192.168.0.177 is the ip of my server I’m trying to bring up on the WebUI unsuccessfully, not 100% on 192.168.122.1/24 but being virbr0 I’m willing to bet it’s the network for my VM’s but they are not running so assuming this is why the network is down

My server is running unraids latest 7.0.0 and yesterday everything was normal but late night started to seem a little laggy so thought i would let it rest a couple hours but when i restated the server no WebUI access remotely over the local network, i can boot to terminal, boot to GUI, boot without plugins (this allows for WebUI but is in safe mode), boot without plugins and docker but with GUI but apart from when i load in safe mode without plugins can not get WebUI remotely, thought it may be a plugin related issue so moved the plugin .plg files away temporarily to see if this affected boot result, did not, moved back, have run diagnostics extended, attached, any help would be appreciated, have also confirmed no other devices on network are trying to share the 192. address of server so no conflicts there. darktower-diagnostics-20250114-2008.zip

@ConnerVT sorry tried to reply but it just did a quote 🤷🏼‍♂️ so the intel arc I am going to use is the intel arc a310, it to is a single slot card powered by the pcie but is $180 here I. Australia, the p400 & t400 range from $250-$300 so if the arc is overkill I guess I’m getting more bang for my buck 🤷🏼‍♂️ I ordered some HGST from goharddrive this morning, awesome deal, not a lot on postage, ordering from US and shipping to Australia is still cheaper than buying refurbished in Australia, crazy world 🤪

Also since I do not yet have the server build completed and I am intending on using the server as a media server I am leaning heavily towards an intel arc gpu due to AV1 and capabilities, I know there have been compatibility issues in the past with the kernel in unraid with these gpu’s but am seeing that unraid 7 has solved this and was thinking that I would start with unraid 7 and go from there to match the need, unless you have any recommendations for gpu’s that won’t break the bank, I am planning on trying to set the media server up with jelly fun and as much direct play as possible but need to be prepared for some transcoding as one of the kids may want to watch something using his Xbox

Thank you @ConnerVT & @foo_fighter for the further information, creating a second server to act as a backup may cost more in the initial stage but a better idea than cloud as the back up will be performed locally and things like internet outages or bandwidth won’t be as much of a concern if I set this up to take place after midnight, if the average rip takes up to 100gb of space on a 16tb drive that’s roughly 160 movies that would need to be re ripped and at 2-3 how’s to rip and compress I don’t fancy spending 2 weeks replacing lost data nor do I have the time so will look into this, I have been seeing a lot of feedback about people using reconditioned enterprise drives with around 16tb capacity, is this something you would recommend against? they are significantly cheaper this way, I’m in Australia and reconditioned is roughly $200 apposed to new which is around $500-$600 each.

@foo_fighter so would you recommend higher capacity drives in an unsaid array using zfs format and work towards having a mirrored setup or a backup within the cloud sort of thing?

I have @foo_fighter, but thank you for the suggestion, my concern is that if I go with a raidz1 and have a 18tb drive failure the rebuild time on that would be substantially longer than a 6-8 tb drive, if another drive failed during this time it would result in data loss, also replacing a 6-8 tb drive now and then would be cheaper and quicker than replacing a 18tb drive now and then, this is why I’m going to go with 6-8 tb drives to a make up a total of 10 drives but split them into 2 vdevs that make up the one pool 😊

Hello everyone, firstly I’m sorry if my particular question has been asked before but I am building a media server first most but with others services, I have everything ready to go but the hard drives, I have almost 1,000 movies which are a mix of blue-rays 4K and UHD’s so will be needing by my estimation 10 drives that are 8tb each, I’m thinking I will use 2 pools in raidz1 or raidz2 on zfs, my question is since unraid spins up and spins down drives should I not be getting drives that are nas for the storage drives but nas drives for the parody drives AND if I should be getting nas drives for the entirety of the server since unraid is software raid and not hardware raid do I need to use the likes of for instance WD red pro or would the likes of WD red plus be ok being that I would be using 10 and not 8, WD red plus states up to 8 connected drives but I’m thinking that’s for hardware nas. any advise would be appreciated 🙂