Upgrade to 6.9.2, Getting freezes requiring hard reboot every week or so


Recommended Posts

Hi All,

 

Wondering if I could get some support for 6.9.2. I previously upgraded and was freezing every 24 hours or so so I rolled back to 6.8.3 (I did not change the config in the go file so this was my fault). I have recently tried 6.9.2 again and the system is now freezing at least once a week.

I am using intel iGPU transcoding on my i3-9100, the setup is pretty basic in all with only a few dockers running.

 

The 2 periods I was on 6.8.3 (~12 months total) the system has been 100% rock solid but for some reason 6.9.2 doesn't like my system. As far as I can tell there is no useful information in the syslog.

I rebooted at 19:09 on July 22.

If anyone can point e in the right direction it would be excellent. 

syslog firefly-diagnostics-20210722-2358.zip

  • Like 1
Link to comment
54 minutes ago, Tristankin said:

As far as I can tell there is no useful information in the syslog.

There are a couple of call traces but can't see the reason, could be the kernel doesn't like your board, the number one issue for crashes on v6.9.2 appears to be this:

Though this is usually visible in the syslog, still might be worth checking if it applies to you.

Link to comment

Took me a while to find the setting for host access. This has been disabled the whole time I am pretty sure.

 

image.png.1bc7a530ff1e7035f5209201b170f85d.png

 

There are quite a few networks in all as I have had to push jackett, radarr and sonarr clients through deluge since the proxy has been disabled. I also have a few dockers that are setup for external access through swag and only plex which appears on the host network.
image.thumb.png.c6d5328abfce1bfad68c6c0bbec0a4dd.png

 

Let me know if you see anything stupid though...
 

Link to comment

There's nothing logged, this usually points to a hardware issue, one thing you can try it to boot the server in safe mode with all docker/VMs disable, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.

Link to comment

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?

Edited by Tristankin
Link to comment

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?

Link to comment

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.

Edited by Tristankin
  • Like 1
Link to comment

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....

Edited by Tristankin
Link to comment

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.

Link to comment
  • 2 weeks later...
  • 1 month later...

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.

Edited by Tristankin
Link to comment
2 hours ago, kingy444 said:

mmmm - wonder if i could be experiencing a similar bug with samba

 

I am running much older intel kit on an i3-3220 but started having weird stabiity recently  - just posted this and waiting for some feedback

 

 

Is your system freezing? This does not seem relevant to the current thread.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.