-
Posts
154 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Tristankin
-
-
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.- 1
-
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.- 1
-
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?
-
Yeah, it is a bit hard to tell if the kernel panic isn't even appearing. I have tried turning off all C states in the BIOS and underclocking the ram since the last reboot. Not sure what else to try without taking the server offline for days turning off dockers and doing memory tests, I have a lot of family and friends relying on the uptime.
-
And again.
Jul 28 13:03:19 Firefly smbd[7089]: daemon_ready: daemon 'smbd' finished starting up and ready to serve connections Jul 28 13:03:19 Firefly root: /usr/sbin/winbindd -D Jul 28 13:03:19 Firefly winbindd[7102]: [2021/07/28 13:03:19.158615, 0] ../../source3/winbindd/winbindd_cache.c:3203(initialize_winbindd_cache) Jul 28 13:03:19 Firefly winbindd[7102]: initialize_winbindd_cache: clearing cache and re-creating with version number 2 Jul 28 13:03:19 Firefly winbindd[7102]: [2021/07/28 13:03:19.159091, 0] ../../lib/util/become_daemon.c:135(daemon_ready) Jul 28 13:03:19 Firefly winbindd[7102]: daemon_ready: daemon 'winbindd' finished starting up and ready to serve connections Jul 28 19:56:22 Firefly kernel: microcode: microcode updated early to revision 0xde, date = 2020-05-25 Jul 28 19:56:22 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 28 19:56:22 Firefly kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot Jul 28 19:56:22 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Jul 28 19:56:22 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Jul 28 19:56:22 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Jul 28 19:56:22 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' Jul 28 19:56:22 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' Jul 28 19:56:22 Firefly kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Jul 28 19:56:22 Firefly kernel: x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 Jul 28 19:56:22 Firefly kernel: x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 Jul 28 19:56:22 Firefly kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. Jul 28 19:56:22 Firefly kernel: BIOS-provided physical RAM map:
This time I disabled suspend to ram in the bios and lowered the ram clock to 2133 (i3-9100 2400MT/s is not overclocking)
Any other suggestions?
-
You seem to have the same issue as I do. Any chance you are running intel hardware?
-
Your issue seems to be very similar to mine. I am also seeing nothing before the freeze requiring a hard reset. For me it has only happened with 6.9.x. I rolled back to 6.8.3 and the problem was gone. I thought it might have been my fault because I did not change the go file for plex, but even with the go file changes it is still restarting. Might go back to 6.8.3 again.
-
Is there a lower level log that I can turn on to perhaps catch some mor einformation?
-
The roll back to 6.8.3 fixed the issue completely last time. I would doubt it is a hardware issue if the old version works for 12 months total including the roll back without a single freeze.
I was hoping to help find an issue with 6.9 but I guess I will just roll back again? -
Another freeze last night, both times now the mover was the last thing to run.
Jul 27 05:02:46 Firefly crond[1711]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null
Random Reboots without reasons
in General Support
Posted
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.