InternetD

Did anyone try to enforce xe drivers for Intel Alchemist GPUs? I'm asking since this here sounds interesting for power saving.

Just here to say thank you for the custom docker. Maybe: beware that you need different CUDA versions depending on the GPU you have. We just also just got a driver split thanks to Nvidia EOLing Pascal. Meaning you would need to provide a legacy (frozen) and a more up to date docker option or tag as long as the Unraid kernel supports the legacy stuff. For video codec acceleration alone beware that not every GPU supports every setting from ffmepg equally (not meaning codecs, but like Advanced NVENC Options like quantization, b-frames and such).

Greetings, just bumping because 5.2 is out. Thanks for your work!

Wel it doesnt seem that ports on the tunnel can reach the qbitorrent docker. My VPN provider gives me port 59963 UDP and TCP but I cant get it through to qbitorrent.

@Mainfrezzer Well looks like I did an error on my side yesterday and got the web gui worked (forgot to change the related setting/port within the qbittorent webgui itself). How do I pass the needed port from the wireguard client toward qbitorrent?

I tried to change the port in either one but said web gui stays unreachable. I'm looking right now into it again to see if I have not goofed a port or something.

https://github.com/linuxserver/docker-qbittorrent/pkgs/container/qbittorrent

If you meant that, yes I did.

Thank you, I will give it a try. Edit: @Mainfrezzer Your docker works well, but sadly the web interface of the other docker I want to use refuses to work even after mapping all ports required accordingly within the template of your docker. I need to find a fix for that.

Thank you for the fast response. So If I understand your docker, it comes with proxy/socks I need to connect to? It is only partly useful for my case since I need the "route" to be dead on interface disconnect and I'm not sure how I can implement this on Unraid.

Hello, I want to use IPV6 with my VPN provider within the custom docker network created for wg0. Unraid/Docker seems to have generated only an IPV4 subnet for the related custom network. Also it seems that in root/config/wireguard/wg0.cfg no ipv6 route is added (interface up) or deleted (interface down): PostUp=ip -4 route flush table 200 PostUp=ip -4 route add default via 10.133.136.143 dev wg0 table 200 PostUp=ip -4 route add 192.168.231.0/24 via 192.168.231.1 dev br0 table 200 PostDown=ip -4 route flush table 200 PostDown=ip -4 route add unreachable default table 200 PostDown=ip -4 route add 192.168.231.0/24 via 192.168.231.1 dev br0 table 200 Greetings and thank you in advance.

The pcie bug is only a display one and well known for Intel Arc. lspci shows since years only pcie gen1 x1 but the cards are still functioning normally with their full bus.

I know, it still doesn't answer the question about a possible limitation either within the Unraid kernel or overall LTS kernel until a certain version. Or even a possible i915 driver issue. As for now I only found information for Kernel 6.1 to 6.6, and not a lot in a combination with an Intel ARC (at least not on x86). Edit 1: I changed as a test to the xe driver but the issue persist: Sep 7 23:09:15 ProjectD kernel: Setting dangerous option force_probe - tainting kernel Sep 7 23:09:15 ProjectD kernel: i915 0000:09:00.0: I915 probe blocked for Device ID 56a5. Sep 7 23:09:15 ProjectD kernel: Setting dangerous option force_probe - tainting kernel Sep 7 23:09:15 ProjectD kernel: Console: switching to colour dummy device 80x25 Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: vgaarb: deactivate vga console Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] Found DG2/G11 (device ID 56a5) display version 13.00 stepping C0 Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] Using GuC firmware from i915/dg2_guc_70.bin version 70.44.1 Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=none:owns=none Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] Attempting to resize bar from 256MiB -> 8192MiB Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: BAR 2 [mem 0x7fe0000000-0x7fefffffff 64bit pref]: releasing Sep 7 23:09:15 ProjectD kernel: pcieport 0000:08:01.0: bridge window [mem 0x7fe0000000-0x7fefffffff 64bit pref]: releasing Sep 7 23:09:15 ProjectD kernel: pcieport 0000:07:00.0: bridge window [mem 0x7fe0000000-0x7fefffffff 64bit pref]: releasing Sep 7 23:09:15 ProjectD kernel: pcieport 0000:00:03.1: Assigned bridge window [mem 0x7fe0000000-0x7ff07fffff 64bit pref] to [bus 07-0a] cannot fit 0x200000000 required for 0000:08:01.0 bridging to [bus 09] Sep 7 23:09:15 ProjectD kernel: pcieport 0000:08:01.0: bridge window [mem 0x00000000 64bit pref] to [bus 09] requires relaxed alignment rules Sep 7 23:09:15 ProjectD kernel: pcieport 0000:00:03.1: Assigned bridge window [mem 0x7fe0000000-0x7ff07fffff 64bit pref] to [bus 07-0a] cannot fit 0x200000000 required for 0000:07:00.0 bridging to [bus 08-0a] Sep 7 23:09:15 ProjectD kernel: pcieport 0000:07:00.0: bridge window [mem 0x00000000 64bit pref] to [bus 08-0a] requires relaxed alignment rules Sep 7 23:09:15 ProjectD kernel: pcieport 0000:07:00.0: bridge window [mem size 0x200000000 64bit pref]: can't assign; no space Sep 7 23:09:15 ProjectD kernel: pcieport 0000:07:00.0: bridge window [mem size 0x200000000 64bit pref]: failed to assign Sep 7 23:09:15 ProjectD kernel: pcieport 0000:08:01.0: bridge window [mem size 0x200000000 64bit pref]: can't assign; no space Sep 7 23:09:15 ProjectD kernel: pcieport 0000:08:01.0: bridge window [mem size 0x200000000 64bit pref]: failed to assign Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: BAR 2 [mem size 0x200000000 64bit pref]: can't assign; no space Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: BAR 2 [mem size 0x200000000 64bit pref]: failed to assign Sep 7 23:09:15 ProjectD kernel: pcieport 0000:00:03.1: PCI bridge to [bus 07-0a] Sep 7 23:09:15 ProjectD kernel: pcieport 0000:00:03.1: bridge window [mem 0xfb000000-0xfc3fffff] Sep 7 23:09:15 ProjectD kernel: pcieport 0000:00:03.1: bridge window [mem 0x7fe0000000-0x7ff07fffff 64bit pref] Sep 7 23:09:15 ProjectD kernel: pcieport 0000:07:00.0: PCI bridge to [bus 08-0a] Sep 7 23:09:15 ProjectD kernel: pcieport 0000:07:00.0: bridge window [mem 0xfb000000-0xfc3fffff] Sep 7 23:09:15 ProjectD kernel: pcieport 0000:07:00.0: bridge window [mem 0x7fe0000000-0x7fefffffff 64bit pref] Sep 7 23:09:15 ProjectD kernel: pcieport 0000:08:01.0: PCI bridge to [bus 09] Sep 7 23:09:15 ProjectD kernel: pcieport 0000:08:01.0: bridge window [mem 0xfb000000-0xfc1fffff] Sep 7 23:09:15 ProjectD kernel: pcieport 0000:08:01.0: bridge window [mem 0x7fe0000000-0x7fefffffff 64bit pref] Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] Failed to resize BAR2 to 8192M (-ENOSPC). Consider enabling 'Resizable BAR' support in your BIOS Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: BAR 2 [mem 0x7fe0000000-0x7fefffffff 64bit pref]: assigned Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] VISIBLE VRAM: 0x0000007fe0000000, 0x0000000010000000 Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] Small BAR device Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] VRAM[0, 0]: Actual physical size 0x0000000180000000, usable size exclude stolen 0x000000017c800000, CPU accessible size 0x0000000010000000 Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] VRAM[0, 0]: DPA range: [0x0000000000000000-180000000], io range: [0x0000007fe0000000-7ff0000000] Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] VRAM: 0x0000000180000000 is larger than resource 0x0000000010000000 Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] Total VRAM: 0x0000007fe0000000, 0x0000000180000000 Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] Available VRAM: 0x0000007fe0000000, 0x000000017c800000 Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] Finished loading DMC firmware i915/dg2_dmc_ver2_08.bin (v2.8) Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] vcs1 fused off Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] vcs3 fused off Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] vcs4 fused off Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] vcs5 fused off Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] vcs6 fused off Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] vcs7 fused off Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] vecs2 fused off Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] vecs3 fused off Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] ccs0 fused off Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] ccs2 fused off Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] ccs3 fused off Sep 7 23:09:15 ProjectD kernel: [drm] Initialized xe 1.1.0 for 0000:09:00.0 on minor 0 Sep 7 23:09:15 ProjectD kernel: fbcon: xedrmfb (fb0) is primary device Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS. Sep 7 23:09:15 ProjectD kernel: Console: switching to colour frame buffer device 240x67 Sep 7 23:09:15 ProjectD kernel: xe 0000:09:00.0: [drm] fb0: xedrmfb frame buffer deviceEdit 2: Here some logs with i915: Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: [drm] Found DG2/G11 (device ID 56a5) display version 13.00 stepping C0 Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: [drm] VT-d active for gfx access Sep 7 23:56:21 ProjectD kernel: Console: switching to colour dummy device 80x25 Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: vgaarb: deactivate vga console Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: BAR 0 [mem 0xfb000000-0xfbffffff 64bit]: releasing Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: BAR 2 [mem 0x7fe0000000-0x7fefffffff 64bit pref]: releasing Sep 7 23:56:21 ProjectD kernel: pcieport 0000:08:01.0: bridge window [mem 0x7fe0000000-0x7fefffffff 64bit pref]: releasing Sep 7 23:56:21 ProjectD kernel: pcieport 0000:07:00.0: bridge window [mem 0x7fe0000000-0x7fefffffff 64bit pref]: releasing Sep 7 23:56:21 ProjectD kernel: pcieport 0000:00:03.1: Assigned bridge window [mem 0x7fe0000000-0x7ff07fffff 64bit pref] to [bus 07-0a] cannot fit 0x200000000 required for 0000:08:01.0 bridging to [bus 09] Sep 7 23:56:21 ProjectD kernel: pcieport 0000:08:01.0: bridge window [mem 0x00000000 64bit pref] to [bus 09] requires relaxed alignment rules Sep 7 23:56:21 ProjectD kernel: pcieport 0000:00:03.1: Assigned bridge window [mem 0x7fe0000000-0x7ff07fffff 64bit pref] to [bus 07-0a] cannot fit 0x200000000 required for 0000:07:00.0 bridging to [bus 08-0a] Sep 7 23:56:21 ProjectD kernel: pcieport 0000:07:00.0: bridge window [mem 0x00000000 64bit pref] to [bus 08-0a] requires relaxed alignment rules Sep 7 23:56:21 ProjectD kernel: pcieport 0000:07:00.0: bridge window [mem size 0x200000000 64bit pref]: can't assign; no space Sep 7 23:56:21 ProjectD kernel: pcieport 0000:07:00.0: bridge window [mem size 0x200000000 64bit pref]: failed to assign Sep 7 23:56:21 ProjectD kernel: pcieport 0000:08:01.0: bridge window [mem size 0x200000000 64bit pref]: can't assign; no space Sep 7 23:56:21 ProjectD kernel: pcieport 0000:08:01.0: bridge window [mem size 0x200000000 64bit pref]: failed to assign Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: BAR 2 [mem size 0x200000000 64bit pref]: can't assign; no space Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: BAR 2 [mem size 0x200000000 64bit pref]: failed to assign Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: BAR 0 [mem 0xfb000000-0xfbffffff 64bit]: assigned Sep 7 23:56:21 ProjectD kernel: pcieport 0000:00:03.1: PCI bridge to [bus 07-0a] Sep 7 23:56:21 ProjectD kernel: pcieport 0000:00:03.1: bridge window [mem 0xfb000000-0xfc3fffff] Sep 7 23:56:21 ProjectD kernel: pcieport 0000:00:03.1: bridge window [mem 0x7fe0000000-0x7ff07fffff 64bit pref] Sep 7 23:56:21 ProjectD kernel: pcieport 0000:07:00.0: PCI bridge to [bus 08-0a] Sep 7 23:56:21 ProjectD kernel: pcieport 0000:07:00.0: bridge window [mem 0xfb000000-0xfc3fffff] Sep 7 23:56:21 ProjectD kernel: pcieport 0000:07:00.0: bridge window [mem 0x7fe0000000-0x7fefffffff 64bit pref] Sep 7 23:56:21 ProjectD kernel: pcieport 0000:08:01.0: PCI bridge to [bus 09] Sep 7 23:56:21 ProjectD kernel: pcieport 0000:08:01.0: bridge window [mem 0xfb000000-0xfc1fffff] Sep 7 23:56:21 ProjectD kernel: pcieport 0000:08:01.0: bridge window [mem 0x7fe0000000-0x7fefffffff 64bit pref] Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: [drm] Failed to resize BAR2 to 8192M (-ENOSPC) Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: BAR 2 [mem 0x7fe0000000-0x7fefffffff 64bit pref]: assigned Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: [drm] Using a reduced BAR size of 256MiB. Consider enabling 'Resizable BAR' or similar, if available in the BIOS. Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=none Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: [drm] Finished loading DMC firmware i915/dg2_dmc_ver2_08.bin (v2.8) Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: [drm] GT0: GuC firmware i915/dg2_guc_70.bin version 70.44.1 Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: [drm] GT0: HuC firmware i915/dg2_huc_gsc.bin version 7.10.16 Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: [drm] GT0: GUC: submission enabled Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: [drm] GT0: GUC: SLPC enabled Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: [drm] GT0: GUC: RC enabled Sep 7 23:56:21 ProjectD kernel: [drm] Initialized i915 1.6.0 for 0000:09:00.0 on minor 0 Sep 7 23:56:21 ProjectD kernel: fbcon: i915drmfb (fb0) is primary device Sep 7 23:56:21 ProjectD kernel: Console: switching to colour frame buffer device 240x67 Sep 7 23:56:21 ProjectD kernel: i915 0000:09:00.0: [drm] fb0: i915drmfb frame buffer device

Hallo everyone, I'm running an Intel Arc A380 on a Ryzen 7 2700x (under 7.1.3) . Under Linux it shouldn't be a problem to get ReBAR working as long "Above 4G decoding" is enabled under the UEFI and pci=realloc is used in the kernel command line. With dmesg | grep BAR I'm getting: i915 0000:09:00.0: [drm] Failed to resize BAR2 to 8192M (-ENOSPC)and BAR stays at 256MiB. While looking on the Internet it seems that Ubuntu 24.04 and older (kernel 6.6 and older) to have the same issue. So it seem to be a kernel limitation? Will a future Unraid kernel support ReBAR with that method? I ran the CPU in the past in my desktop with a Vega64 which did ReBAR under Arch just fine. The UEFI limitation should only matter on Windows or until you run a really, really old Intel platform without the stated "Above 4G decoding". Greetings and thank you in advance.

So far I know amd_pstate is not on per default because of various possible hardware and UEFI configurations. Your UEFI must have CPPC enabled (something the kernel can't do by itself), for example possibly found in CBS > NBIO > SMU > CPPC. So you still need to put amd_pstate=active as a boot entry and choose either the powersave or performance governor after booting. I would choose the former until your workload require that extra few ms latency. The only incompatibility I know are the entry for CPU governors that can override each other. As for myself I have have stopped using Autotweak because of random USB stability issues either after days, sometimes after weeks of use. For now I enforce sleep on my NVIDIA GPU and limit the cTDP of my CPU while also allowing my disks to spin off. An alternative would be installing and using powertop: allow L0 and L1 in your UEFI PCIE settings to be sure, use --auto-tune-dump once and blacklist NVME, USB and any device known to be notorious as a user script. The NVME Issue was gone with a newer device since I reached far over the max TBW value and replaced said NVME in time.

Hallo again, a way to blacklist either USB completely or single USB devices would be nice. Greetings.

UASP and fstrim works fine on the 7.0.0-beta.1, closing the thread for now.

I use a PNY HP x911w Solid State Flash Drive (128GB, 32GB pSLC cache) after a manual installation. I got hardware wear leveling support confirmed by the PNY/HP consumer support and TRIM should come within the 6.13 update. The stick itself require USB 3.1 gen2 or 3.2 for full speed support, but should also work just fine on USB 3.0 or lower (just with limited bandwidth). Do it's job just fine since January. I used a (2019) Sandisk USB stick beforehand which ran fine but I replaced because of the performance and being a few years old.

Good, i will see in the beta and then report

On 6.12.10 UASP driver seems not do be used here. Edit: here are the related logs to the flash drive:

Hello, my flash drive support TRIM: vfat support trim since kernel 4.19 so it would be nice to use it on my flash drive as well. fstrim -v refuse to work on /boot: Do i point it toward the wrong directory? Greetings and thank you in advance.

Still no luck for me, Must be some deeper incompatibility issue specific with my mainboard/NVMe combination. Thank you anyway If I'm not wrong kernel.org must have an ASPM blacklist somewhere in their kernel code since you can report buggy devices on the mailing list. It may be wise to not override this list until getting desperate. If you can get your hands on it it may be good to implement/update it with each Unraid release since your plugin might ignore it.

Sadly it still doesnt work. Even with 0 the NVMe keeps crashing so i guess its a whole another issue on L1.1 and L2.2 that is pcie related.

nvme_core.default_ps_max_latency_us=0 as a bootflag should do the trick against buggy NVMe low power state.

Thanks for the answer. I use amd_pstate since a while without any issue whatsoever on other devices with fitting hardware and of course newer kernel. As for ASPM i wasnt sure if blacklisting is possible as it seems it need to be driver specific. For example the amdgpu driver allows to do so with amdgpu.aspm=0 The NVMe is uptodate, so no luck here. But its nearing its end of life anyway so i will keep attention on the next purchase. For example the newer KIOXIA NVMe with TLC and DRAM supports officially L1.1 and L1.2.