iLaurens

This solved my xorg crash loop issue as well. Thanks for sharing!

I'm considering getting one of those AMD Ryzen AI Max+ 395 mini-pcs with 128GB of shared (V)RAM. It's based on Ryzen 8000 APU series / gfx1151 / rocm 3.5. Any idea of this is already or will be supported? Not sure if I should pull the trigger on the purchase right now for a unraid system...

The quirk did fix it, fortunately! Indeed stability is far more important than performance. If this performance benchmark is worth anything, it seems I only random read operations are beneficial. However since this is typically bulk storage for large files I don't think that really matters.

I added it now and giving it another go. Let's see if it solves the issue. The enclosure is a terramaster d6-320 and it seems it also might have something to do with the usb controller not getting enough power by the looks of this thread. If the quirk doesn't fix it then i'll buy a new gen3.2 gen 2 USB C cable and powered usb hub.

I have been getting similar issues since 7.0.1 during parity check and/or rebuild with an external USB enclosure with 3 HDDs. The issue takes down the entire USB bus, and even the flash USB stick with unraid OS on it gets disconnected. This is the bit of my logs where things clearly go downhill: Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#15 uas_eh_abort_handler 0 uas-tag 12 inflight: CMD IN Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#15 CDB: opcode=0x88 88 00 00 00 00 01 39 91 8e 98 00 00 00 c8 00 00 Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#14 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD IN Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#14 CDB: opcode=0x88 88 00 00 00 00 01 39 91 8a 98 00 00 04 00 00 00 Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#13 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD IN Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#13 CDB: opcode=0x88 88 00 00 00 00 01 39 91 88 f0 00 00 01 a8 00 00 Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#12 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD IN Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#12 CDB: opcode=0x88 88 00 00 00 00 01 39 91 84 f0 00 00 04 00 00 00 Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#11 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#11 CDB: opcode=0x88 88 00 00 00 00 01 39 91 79 28 00 00 04 00 00 00 Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#10 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD IN Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#10 CDB: opcode=0x88 88 00 00 00 00 01 39 91 81 30 00 00 03 c0 00 00 Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#9 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD IN Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#9 CDB: opcode=0x88 88 00 00 00 00 01 39 91 7f 20 00 00 02 10 00 00 Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#8 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD IN Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#8 CDB: opcode=0x88 88 00 00 00 00 01 39 91 7d 28 00 00 01 f8 00 00 Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#7 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#7 CDB: opcode=0x88 88 00 00 00 00 01 39 91 78 d8 00 00 00 50 00 00 Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#6 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#6 CDB: opcode=0x88 88 00 00 00 00 01 39 91 71 28 00 00 03 b0 00 00 Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#5 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#5 CDB: opcode=0x88 88 00 00 00 00 01 39 91 6f 60 00 00 01 c8 00 00 Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#4 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN Mar 21 00:11:21 Tower kernel: sd 2:0:0:0: [sdc] tag#4 CDB: opcode=0x88 88 00 00 00 00 01 39 91 74 d8 00 00 04 00 00 00 Mar 21 00:12:06 Tower kernel: sd 2:0:0:0: [sdc] tag#17 uas_eh_abort_handler 0 uas-tag 13 inflight: CMD IN Mar 21 00:12:06 Tower kernel: sd 2:0:0:0: [sdc] tag#17 CDB: opcode=0x85 85 08 0e 00 00 00 01 00 00 00 00 00 00 00 ec 00 Mar 21 00:12:06 Tower kernel: scsi host2: uas_eh_device_reset_handler start Mar 21 00:12:06 Tower kernel: usb 2-2.3.2: reset SuperSpeed Plus Gen 2x1 USB device number 5 using xhci_hcd Mar 21 00:12:06 Tower kernel: scsi host2: uas_eh_device_reset_handler success Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN: TRB error for slot 9 ep 2 on endpoint Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN Event TRB for slot 9 ep 2 with no TDs queued? Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN: TRB error for slot 9 ep 2 on endpoint Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN Event TRB for slot 9 ep 2 with no TDs queued? Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN waiting for error on ep to be cleared Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 data in submit err -22 uas-tag 4 inflight: s-in a-cmd s-cmd Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 CDB: opcode=0x88 88 00 00 00 00 01 39 91 a5 b8 00 00 04 00 00 00 Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN waiting for error on ep to be cleared Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 data in submit err -22 uas-tag 4 inflight: s-in a-cmd s-cmd work Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 CDB: opcode=0x88 88 00 00 00 00 01 39 91 a5 b8 00 00 04 00 00 00 Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN waiting for error on ep to be cleared Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 data in submit err -22 uas-tag 4 inflight: s-in a-cmd s-cmd work Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 CDB: opcode=0x88 88 00 00 00 00 01 39 91 a5 b8 00 00 04 00 00 00 Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN waiting for error on ep to be cleared Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 data in submit err -22 uas-tag 4 inflight: s-in a-cmd s-cmd work Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 CDB: opcode=0x88 88 00 00 00 00 01 39 91 a5 b8 00 00 04 00 00 00 Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN waiting for error on ep to be cleared Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 data in submit err -22 uas-tag 4 inflight: s-in a-cmd s-cmd work Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 CDB: opcode=0x88 88 00 00 00 00 01 39 91 a5 b8 00 00 04 00 00 00 Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN waiting for error on ep to be cleared Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 data in submit err -22 uas-tag 4 inflight: s-in a-cmd s-cmd work Mar 21 00:12:08 Tower kernel: sd 2:0:0:0: [sdc] tag#22 CDB: opcode=0x88 88 00 00 00 00 01 39 91 a5 b8 00 00 04 00 00 00 Mar 21 00:12:08 Tower kernel: xhci_hcd 0000:02:00.0: WARN waiting for error on ep to be cleared and this is my output from `lsusb -vt` command: /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/10p, 480M ID 1d6b:0002 Linux Foundation 2.0 root hub |__ Port 002: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M ID 0bda:5420 Realtek Semiconductor Corp. |__ Port 003: Dev 004, If 0, Class=Hub, Driver=hub/4p, 480M ID 0bda:5420 Realtek Semiconductor Corp. |__ Port 006: Dev 003, If 0, Class=Wireless, Driver=btusb, 12M ID 8087:0aa7 Intel Corp. Wireless-AC 3168 Bluetooth |__ Port 006: Dev 003, If 1, Class=Wireless, Driver=btusb, 12M ID 8087:0aa7 Intel Corp. Wireless-AC 3168 Bluetooth |__ Port 007: Dev 009, If 0, Class=Mass Storage, Driver=uas, 480M ID 0781:5583 SanDisk Corp. Ultra Fit |__ Port 010: Dev 006, If 0, Class=Vendor Specific Class, Driver=cp210x, 12M ID 10c4:ea60 Silicon Labs CP210x UART Bridge /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M ID 1d6b:0003 Linux Foundation 3.0 root hub |__ Port 002: Dev 002, If 0, Class=Hub, Driver=hub/4p, 10000M ID 0bda:0420 Realtek Semiconductor Corp. |__ Port 003: Dev 003, If 0, Class=Hub, Driver=hub/4p, 10000M ID 0bda:0420 Realtek Semiconductor Corp. |__ Port 001: Dev 004, If 0, Class=Mass Storage, Driver=uas, 10000M ID 174c:235c ASMedia Technology Inc. |__ Port 002: Dev 005, If 0, Class=Mass Storage, Driver=uas, 10000M ID 174c:235c ASMedia Technology Inc. |__ Port 003: Dev 006, If 0, Class=Mass Storage, Driver=uas, 10000M ID 174c:235c ASMedia Technology Inc. /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 480M ID 1d6b:0002 Linux Foundation 2.0 root hub /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M ID 1d6b:0003 Linux Foundation 3.0 root hub /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 480M ID 1d6b:0002 Linux Foundation 2.0 root hub /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M ID 1d6b:0003 Linux Foundation 3.0 root hub tower-diagnostics-20250321-0917.zip

Updating to V7.0.1 and my logs are now being spammed by another message: 2025/03/13 12:37:31 [alert] 5099#5099: worker process 3036554 exited on signal 6 ker process: ./nchan-1.3.7/src/store/spool.c:479: spool_fetch_msg: Assertion `spool->msg_status == MSG_INVALID' failed. 2025/03/13 12:37:31 [alert] 5099#5099: worker process 3036587 exited on signal 6 ker process: ./nchan-1.3.7/src/store/spool.c:479: spool_fetch_msg: Assertion `spool->msg_status == MSG_INVALID' failed. 2025/03/13 12:37:33 [alert] 5099#5099: worker process 3036591 exited on signal 6 ker process: ./nchan-1.3.7/src/store/spool.c:479: spool_fetch_msg: Assertion `spool->msg_status == MSG_INVALID' failed. 2025/03/13 12:37:35 [alert] 5099#5099: worker process 3036643 exited on signal 6 ker process: ./nchan-1.3.7/src/store/spool.c:479: spool_fetch_msg: Assertion `spool->msg_status == MSG_INVALID' failed. 2025/03/13 12:37:36 [alert] 5099#5099: worker process 3036675 exited on signal 6

I'll contribute with my research. It is clearly the nchan plugin that is causing trouble. Unfortunately it seems abandonware because there is several issues the author of nchan is aware off and decides not to fix, and instead spin a complete v2 into a new and separate software from nginx. I have been looking at two solutions. 1. Can we stop nchan from memory leaking? 2. Can we stop nchan from spamming the system log if memory leaks anyway? As others have posted there is nchan_shared_memory_size that might help. I wanted to replicate the issue fast for my debugging, so I tried setting memory really low (2M instead of the default 128M). I left on some tabs on overnight and to my surprise I have not been getting any nchan memory errors. The nchan author mentions that messages send to nchan are garbage collected. With 128M, the garbage collector doesn't seem to do its job well but with the pressure of only having 2MB of memory it seems it might be managing the limited memory more effectively. Now 16 hours is perhaps to short to draw any conclusions. I will monitor this more. However I also wanted to see if I can stop errors from reaching the system log. The messages are published by the unraid system to the /pub/ endpoint (in particular /etc/cpuload seems to receive high frequency messages even if nothing is using the WebUI). So I changed the nginx config for this location to log into a separate file. I am not sure if the memory errors also get caught and redirected to this new log file, but time will tell. If others want to also test my solution and have it persist on each reboot, you can add the following lines at the top of /boot/config/go (after which you should reboot for the changes to take effect): # Fix nchan memory leak sed -z 's|nchan publishers\n\t#|nchan publishers\n\t#\n\tnchan_shared_memory_size 2M;|' -i /etc/rc.d/rc.nginx sed -z 's|nchan_publisher;|nchan_publisher;\n\t error_log /var/log/nginx/nchan_error.log;|' -i /etc/rc.d/rc.nginx

Would it be possible to include OpenSSH package inside this image? It would allow me to sync git projects more easily with my Github account using SSH. For now I manually installed it inside the container, but I can imagine this would be nice to have included by default. edit: opened a pull request to do exactly this: https://github.com/binhex/arch-pycharm/pull/3

I noticed AMD's vega 11 is not supported (used by AMD 2400G APU). Is this intentional or maybe a forgotten mention?

I figured out what the likely culprit is. I see from your github that the nextgen PIA servers also require a new method of obtaining a port. Hence the two functions: `get_incoming_port_nextgen` and `get_incoming_port_legacy`. The nextgen function is only chosen if the VPN_REMOTE_SERVER env variable contains `privacy.network`. However when I explicitly set an IP in my openvpn config (from the nextgen servers) it will still select the old `get_incoming_port_legacy`. Could you possibly add an optional docker environment var that forces the get_incoming_port_nextgen to be selected? Maybe make it such that: if [[ "${VPN_REMOTE_SERVER}" == *"privacy.network"* || "${FORCE_PIA_NEXTGEN:-false}" == "true"]]; then Notice how I set a default value for FORCE_PIA_NEXTGEN (but you can also set default in Dockerfile). So you can leave it out of your dockerman definition and people need not know it even exists. However people that know about this environment variable setting (perhaps if you put it in the FAQ) could use this to force nextgen functionality. This would help people like me that want a static VPN IP from PIA.

@binhex great work for fixing it. It all works like a charm again with PIA port forwarding. Been a big fan of this for a long time already. There is just one thing that used to work that does not work anymore; connecting to a specific IP of PIA's VPN severs. Before next-gen, I could replace the domain name (example: de-frankfurt.privacy.network) and replace it with an IP to ensure I'd get the same public IP assigned after a restart of the container. The connection to PIA still works when I select a specific IP, but the port forwarding somehow fails. It says that the port serving page of PIA refuses the connection (http://209.222.18.222:2000/?client_id=xxxx). I have no idea why the port forwarding suddenly breaks when trying to fix the IP in the openvpn configuration file, but is this something you could still have a look at? Some torrent sites are really paranoid and require me to provide a static IP The domain names rotate between a set of IPs for each region so you'll almost always have a different public IP after restarting the container or if the connection resets.

Will you also update PIA VPN connection with older versions of deluge? I prefer to stick with Deluge 1.3 because of the Windows Thin Client and some plugins not working in 2.0.

Having the same issues with port forwarding. Any western-european servers that have kept their port-forwarding abilities? I tried Swiss, french and german servers with no luck...