Tristankin

Ah well, guess I will have to roll back to 6.8.3 again.

Thought I would give 6.12.6 a go as I am starting to worry about the age and vulnerability of some of the containers I have to hold back to keep compatibility with an ancient version of docker on 6.8.3. I got about 7 hours before the machine froze up. 6.8.3 has not frozen once on me, including the latest stint from April till now. I added the options i915 enable_dc=0 to the i915.conf file. I do not have intel GPU top installed. cat /sys/module/i915/parameters/enable_dc returns 0 Should I be looking at disabling power well? Attached are the latest syslog and diagnostics. syslog-previous firefly-diagnostics-20231222-2218.zip

Try blacklisting the gpu and removing intel gpu top. You may be experiencing the following issue.

I'm running 9th gen so probably won't help. That and I have given up trying to fix the issue and sticking to 6.8.3 for as long as I can keep my docker containers going. I tried for 4 months of crashes (so far this year, many more months on 6.9.x) and being told it's my hardware so I will have to budget an upgrade of the platform some time in the future. (funny how many unraid systems are running on apparently bad hardware)

VT-d did work for a bit, definitely decreased the number of freezes but did not stop them outright. Now that I am back on 6.8.3 I have had 3 weeks uptime without a single crash. This is a repeat of what happened after the upgrade to 6.9.2 was causing the same crashes and I went back to 6.8.3 for 6 months, again without a single crash. Issue is now the docker version is so old on 6.8.3 that I am getting incompatibilities on containers, forcing me to go with different version or rolling back to ones ~6 months old. (specifically the *arrs). If someone could repackange 6.8.3 with an updated version of docker I am sure I could get a few more years out of the system (maybe call it 6.8.4?) So it seems now I have the choice between stability and security/new features. One possible difference is the IOMMU mode, for some time now that Unraid uses pass-through mode, before is used DMA translation mode, IIRC Ubuntu still uses that one. Is there anything I can do to test this? I imagine this is a kernel level adjustment?

I have moved to a completely different client and rolled back to the 4.3.9 version as listed here: https://forums.unraid.net/bug-reports/stable-releases/crashes-since-updating-to-v611x-for-qbittorrent-and-deluge-users-r2153/page/8/#comments They seem to get more in their logs though....

I have tried 6.9.x, 6.10.x, and 6.11.x with the same result. If something was fixed I would have thought it would have happened across those versions. I have just changed from deluge to binhex/arch-qbittorrentvpn:4.3.9-2-01 after seeing the freeze reports under stable releases. I have been trying to find a solution to this issue for the past 2 years. None of this is particularly fun.

Good for them I guess. What about the people in this thread that are reporting the same issue? So my options are now, run out of date software or replace my hardware.

Would it be possible to run a 4.19 kernel on the latest build? Could help identify the cause?

The system is 100% stable with 6.8.3. 6 months when it was the latest version, and then another 6 months after trying to upgrade to 6.9.x and then downgrading to 6.8.3 again. Unless it is a hardware fault that only occurs with a 5.x kernel then no.

Does it have to be written to the log before tail can work? I'm getting nothing in the syslog to flash. Do you think that the log in ram isn't written to the flash quickly enough?

Turns out I didn't have to wait too long Nothing. No response to input devices. Reset button doesn't work. Long press of the power button is the only thing that shuts it down. root@Firefly:~# cat /sys/class/graphics/*/modes U:1920x1080p-0 root@Firefly:~# cat /sys/class/graphics/*/virtual_size 1920,1080 I checked the res on the box after reboot and putting the dummy plug back in. I assume this means the dummy plug is fine. Anything else I should be checking?

Only the single physical NIC, 2 x docker bridges, one for swag reverse proxy. You are right, I have to give this a go. I am just wary of the power usage having a monitor on 24/7.

And again today Apr 1 08:33:04 Firefly crond[1067]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null Apr 1 10:33:38 Firefly emhttpd: spinning down /dev/sde Apr 1 10:33:45 Firefly emhttpd: spinning down /dev/sdb Apr 1 10:35:39 Firefly emhttpd: spinning down /dev/sdh Apr 1 10:35:39 Firefly emhttpd: spinning down /dev/sdg Apr 1 10:35:39 Firefly emhttpd: spinning down /dev/sdc Apr 1 11:42:40 Firefly emhttpd: read SMART /dev/sdh Apr 1 11:42:40 Firefly emhttpd: read SMART /dev/sdc Apr 1 13:26:28 Firefly emhttpd: spinning down /dev/sdf Apr 1 13:41:59 Firefly emhttpd: spinning down /dev/sdj Apr 1 13:52:28 Firefly emhttpd: read SMART /dev/sde Apr 1 14:09:10 Firefly emhttpd: read SMART /dev/sdf Apr 1 15:37:59 Firefly emhttpd: spinning down /dev/sdh Apr 1 15:37:59 Firefly emhttpd: spinning down /dev/sdc Apr 1 16:25:51 Firefly kernel: microcode: microcode updated early to revision 0xf0, date = 2021-11-12 Apr 1 16:25:51 Firefly kernel: Linux version 5.19.17-Unraid (root@Develop) (gcc (GCC) 12.2.0, GNU ld version 2.39-slack151) #2 SMP PREEMPT_DYNAMIC Wed Nov 2 11:54:15 PDT 2022 Apr 1 16:25:51 Firefly kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot Attached diagnostics just in case. I am really starting to run out of ideas... firefly-diagnostics-20230401-1628.zip

Not sure I am out of the woods yet, Got another freeze after 15 days uptime. I have just turned on syslog to flash so I will see if there is anything recorded but I doubt it.