Tristankin

Yeah, I am talking intel specific configurations. There are many people with intel systems with no logged issues on 6.9.3 who are getting the advice that it must be a hardware issue.

60 Days on 6.8.3 with no issues. Please recommend to other users on intel hardware with no obvious faults in the log to downgrade as the kernel used in the 6.9.x is not stable on consumer intel hardware. This should be the recommendation before replacing hardware as software is free and quite a simple test.

Try downgrading to 6.8.3, I had issues with 6.9.x on intel hardware, freezing every 1-2 days, now have 60 day uptime back on 6.8.3

Also try downgrading to 6.8.3, 6.9.x caused random freezes for me every 1-2 days and I now have 60 day uptime on 6.8.3. I think the 6.9.x issue is intel specific.

Before replacing hardware try downgrading to 6.8.3. I was having similar issues but 6.8.3 has been rock solid now for 35 days

Turn on save syslog to flash so we can see the reason the server is crashing. Check C states, turn off ram overclocking (anything above the spec on ark is overclocking) make sure psu sleep state is turned off in bios. Failing those look at downgrading to 6.8.3, this fixed mine, hard lock every 2 days on 6.9.x, today, 34 days uptime.

Yep, had the same here, either roll back or try 6.10-RC1

Do the standard stuff, check the C states, turn of psu idle control, check the ram is not overclocked. If none of that works roll back to 6.8.3. My system went from hard freezes every 2 days to now 24 day uptime.

23 Days and rock solid. Might be a good idea to recommend to people with intel hardware having freezing issues to downgrade or upgrade around the 6.9.x release.

Try downgrading to 6.8.3 or upgrading to 6.10-RC1. I was getting hangs every 2 days or so, now I am back on 6.8.3 the system has been rock solid for the last 23 days

You'll need to turn on persistent syslog and upload the results here. https://wiki.unraid.net/Manual/Troubleshooting#Persistent_Logs_.28Syslog_server.29

9 Days and still rock solid.

Tell me about it, The new 1MB aligned cache works on 6.8.3 fine though. Mine hung, not a reboot, nothing in syslog. So maybe it is different? Just a cheaper option than having to replace hardware.

Have you tried rolling back to 6.8.3? Was the only way to stop freezing on my server. Nothing in syslog, happening every 2 days or so. Now I am back on 6.8.3 the system has been rock solid for 9 days now.

Have you tried 6.8.3? I had to roll back to stop the random hangs.

From the searching around I have seen it could be down to macvlan issues, C state issues, maybe the occasional ram timing issues, but for this I think it is a kernel issue. Still I was not getting help trying to get to the bottom of it so the only course of action was to downgrade. (or turn off all docker application or run memtest for a few days) Which considering I have a lot of friends and family who rely on this server, was not something I wanted to entertain. I was hoping I could turn on some lower level logging to be able to catch something that syslog is missing. I hope 6.10 is more stable but I will be sticking to 6.8.3 till I can see days of time passing without people complaining about freezing issues.

5 days of uptime so far on 6.8.3, 6.9.2 was freezing every 2-3 days before the downgrade. No issues any more. I am almost certain that the issue is with 6.9.x and not a hardware problem. Downside is though that docker update requests don't work anymore on 6.8.3 because of case sensitivity. Have to adjust the code every time the computer needs a restart. Edit: fixed docker updates with go file patch, messy solution though....

I have had to roll back to 6.8.3 due to freezes on 6.9.x. Before you buy anything new give that a go too.

You will also want to set your syslog to copy to your flash drive and upload that too. after the next freeze. If you are having the same issue as I did there will be nothing in the log though.

I know it will help as this is what I have had to do in the past. As I mentioned before 100% rock solid on 6.8.3

It really depends on the storage requirements and the amount of time you will be seeding. My current setup uses 2 x 512GB nvme for cache and that takes care of the active downloads pretty well to reduce wear and the mover is going to push that data to the array. If your high water is set up ok, there should only be a couple of drives that are accessed until you hit your seed ratio. But if hitting the seed ratio taking too long then the files could be spread all across the array. Not sure there is a single solution that is going to work perfectly. You could force your downloads share onto a couple of disks dedicated for downloads in the array? Just thinking out loud.

Nothing? There are few reports of the same issue every day. Seems like a pretty high incidence to be just blamed on bad ram timings. Well looks like a rollback is the only solution then? Perhaps you guys should consider older LTS kernels for future releases to reduce potential bugs that aren't going to be solved. No need for cutting edge if we are sacrificing system stability.

You may need to set up your syslog archiving to the flash disk. This only shows log since the last reboot.

Looking into reports from the linux community and there seem to be intel gou hangs from the kernel. I am using intel passtrough to my plex docker. Has anyone looked into this?

And Again. Jul 29 15:20:48 Firefly kernel: BTRFS info (device nvme0n1p1): found 27965 extents, stage: move data extents Jul 29 15:20:50 Firefly kernel: BTRFS info (device nvme0n1p1): found 27965 extents, stage: update data pointers Jul 29 15:20:51 Firefly kernel: BTRFS info (device nvme0n1p1): balance: ended with status: 0 Jul 29 15:23:59 Firefly ool www[30420]: /usr/local/emhttp/plugins/dynamix/scripts/btrfs_scrub 'start' '/mnt/cache' '-r' Jul 29 15:23:59 Firefly kernel: BTRFS info (device nvme0n1p1): scrub: started on devid 2 Jul 29 15:23:59 Firefly kernel: BTRFS info (device nvme0n1p1): scrub: started on devid 3 Jul 29 15:25:06 Firefly kernel: BTRFS info (device nvme0n1p1): scrub: finished on devid 3 with status: 0 Jul 29 15:25:19 Firefly kernel: BTRFS info (device nvme0n1p1): scrub: finished on devid 2 with status: 0 Jul 29 21:06:50 Firefly emhttpd: spinning down /dev/sdg Jul 29 21:06:50 Firefly emhttpd: spinning down /dev/sdc Jul 29 23:01:30 Firefly emhttpd: read SMART /dev/sdg Jul 29 23:01:30 Firefly emhttpd: read SMART /dev/sdc Jul 30 04:48:07 Firefly crond[1708]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null Jul 30 16:30:28 Firefly kernel: microcode: microcode updated early to revision 0xde, date = 2020-05-25 Jul 30 16:30:28 Firefly kernel: Linux version 5.10.28-Unraid (root@Develop) (gcc (GCC) 9.3.0, GNU ld version 2.33.1-slack15) #1 SMP Wed Apr 7 08:23:18 PDT 2021 Jul 30 16:30:28 Firefly kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot Jul 30 16:30:28 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Jul 30 16:30:28 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Jul 30 16:30:28 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Jul 30 16:30:28 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' Jul 30 16:30:28 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' Jul 30 16:30:28 Firefly kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Jul 30 16:30:28 Firefly kernel: x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 Jul 30 16:30:28 Firefly kernel: x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 Jul 30 16:30:28 Firefly kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. I'm running out of options. There seem to be a lot of people with similar issues on intel gear. Is there anything else I can try or should I just go back to 6.8.3?