bubbl3

Members
  • Posts

    126
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

bubbl3's Achievements

Apprentice

Apprentice (3/14)

19

Reputation

1

Community Answers

  1. Issue is resolved for me with the fix in 6.12.9: root@Tower:~# grep -c ^processor /proc/cpuinfo 128 Thanks everyone
  2. That's not what I asked, can you try to boot a different USB drive with a different OS?
  3. Ok, but what about now, does another bootable usb boot automatically?
  4. Did you try another bootable USB? Like another drive and/or another OS, or both at the same time. Just to make sure it's a bios issue.
  5. Recommended steps if you have the ability to get another drive: Take disk out of the server and keep in safe space Install new 6TB drive and follow rebuild process If rebuild successful proceed RMA faulty drive When drive comes back from RMA, keep it as spare
  6. Believe the SOLVED label should be removed from this report :D
  7. He run the one you need too:
  8. model name : AMD EPYC 7V12 64-Core Processor SMT disabled: root@Tower:~# grep -c ^processor /proc/cpuinfo 64 SMT enabled: root@Tower:~# grep -c ^processor /proc/cpuinfo 128
  9. That's what I'm wondering, will ask Synd to share his diagnostics later when he's online.
  10. The puzzling thing is that according to the conversation we were having yesterday this is not affecting everyone with 64 cores / 128 threads CPUs, which makes me think the high core count is just one of the factors.
  11. For sake of completion, disabling SMT seems to be a better workaround if that's an option in your setup: https://forums.unraid.net/bug-reports/stable-releases/6128-no-webgui-run-full-r2854/?do=findComment&comment=27345
  12. @AppleJon disabling SMT indeed solved the issue, but seems to be a mitigation as 75% usage of /run is still abnormal: /run/udev/data still taking way too much space: Now wondering why other Threadripper/EPYC users with similar core counts are not affected.
  13. Looks stable at around 34MB, it only increases (few KB, nothing much) if i plug in a new device, like usb storage, etc. or if I run more docker containers.
  14. I think the abnormal allocation under /run/udev/data is affecting everyone, it just doesn't fill the 32MB for people with lower core counts and lower pci-e lanes + associated devices. Please fix the allocation issue, must be a bug introduced with 6.12.8 as it wasn't happening in 6.12.6, or give us a way to increase the size of /run that is not a line in the go file as there are services failing before that runs and it's messy and potentially unstable to fix it that way. Atm only 2 users reported it, but i bet since the release was on Friday, many high core count and pci-e lanes users did not upgrade yet, for sure there are many that I know of on Discord with similar systems which are gonna have the same issue. TLDR: if you're one of those users, do not upgrade yet