Jump to content

Tristankin

Members
  • Posts

    154
  • Joined

  • Last visited

Posts posted by Tristankin

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

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

  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.

    • Thanks 1
  4. 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.

    • Like 1
  5. 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?

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

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


     

×
×
  • Create New...