I have a Ryzen 3 1300X at the moment and it’s always had this soft lock freezing bug on Linux. I used to dual-boot Windows on this machine and Windows never had the same problem, so I think it is an issue with the Linux kernel (I’ve also replaced nearly every bit of hardware that I originally built the PC with, except for the CPU and motherboard, so it probably is an issue the kernel has with my CPU, or possibly the motherboard firmware).

I’ve changed the kernel parameters as suggested by the Arch Wiki. The bug is pretty inconsistent about happening so only time will tell if this solves the issue. But if it doesn’t solve the issue, I’d honestly consider just getting a new CPU that doesn’t have this issue, as completely freezing up, unable to get to a tty or anything, and only being able to power off by physically holding down the power button, is a pretty major issue, even if it only happens sometimes.

So if I do get a new CPU, or maybe just for when I’m next buying a CPU for reasons unrelated to this bug (been considering an upgrade to something that’s better for compiling anyway), are there any good options out there? Intel is investing $25 billion into Israel and the BNC has called for “divestment and exclusion” from it (it’s not officially on the BDS consumer boycott list, but I’m still very much not comfortable buying from Intel). But the Arch Wiki article seems to suggest this bug is applicable to Ryzen CPUs in general, or at least it never specifies a particular model or range of models. So maybe I’m limited to non-Ryzen AMD CPUs?

I’m guessing this is one of the situations where two companies have a complete duopoly over the market and there isn’t an all-round good solution, but thought I’d ask in case anyone had some useful input.

      • communism@lemmy.mlOP
        link
        fedilink
        arrow-up
        0
        ·
        9 months ago

        Do you know if it’s limited to first gen Ryzens? I’m looking into getting a Ryzen 5 5600X and I want to be sure I’m not gonna have the same issue

        • ֆᎮ⊰◜◟⋎◞◝⊱ֆᎮ@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          1
          ·
          9 months ago

          Yes, AMD was replacing Ryzens that had that bug. I’m not sure if they are anymore though. But it’s 100% a confirmed thing. I have not heard anything Zen 2 and newer having this problem and have no experienced any Linux issues with my 3000, 5000 and 7000 series CPUs.

  • d3Xt3r@lemmy.nzM
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    9 months ago

    I have a Zen 2, Zen 3+ and a Zen 4 system and they all work well very with various Linux distros (Arch, Fedora) and recent kernels.

    It’s very likely that your bug is specific to early Ryzen CPUs/chipsets. A couple of folks on those reports mentioned their issues went away after a motherboard/BIOS upgrade. So I think you’ll be fine if you went for a more recent AMD CPU+mobo.

  • flashgnash@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    9 months ago

    Am I the only one of the opinion tech companies that don’t produce any kind of military equipment should not have any political leaning whatsoever?

  • addie@feddit.uk
    link
    fedilink
    arrow-up
    1
    ·
    9 months ago

    Ah, that sounds a bit unfortunate. I’ve run AMD CPUs on Linux desktops with Bulldozer / Piledriver / Ryzen 7, my current laptop is a Ryzen 7 as well, never run into that at all. Hopefully the Arch wiki will sort you out. If not that, the third option would be ‘install Linux on an M-series Mac’ - don’t know how feasible it is at the moment, and paying the ‘Mac premium for hardware and software integration and then overwriting the software’ doesn’t make a lot of sense to me.

  • bzLem0n@lemmy.ca
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    9 months ago

    I have a system with a Ryzen 1700 with the same issue and have found the only reliable way to run it is by installing and enabling the disable-c6-systemd package from the AUR. The other fixes provided in the wiki article you linked are correct but aren’t sufficient on my system, the CPU keeps reenabling the C6 state on its own and the disable-c6-systemd package works to counter that. The reason it works on Windows is they’ve disabled the C6 state by default for the CPU.

    • Buffalox@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      9 months ago

      This is amazing to find out now after 7 years:) I actually adjusted voltage manually on my Ryzen R5 1600, and it became 100% reliable, apparently the fix you mention prevent voltage below 1v at idle. I wondered why my CPU wasn’t reliable unless I made manual OC with some voltage tweaks?

      I never looked it up, because my OC solved the issue, but I always thought it was a bit weird.

    • communism@lemmy.mlOP
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      9 months ago

      Ah, thanks. I’m using runit not systemd (although this was happening on systemd when I was on systemd too) but I saw amd-disable-c6 in the AUR so I’ve installed that now, fingers crossed it works (the fixes in the Arch Wiki article haven’t fixed it for me, it just happened again rip)

      Edit: nvm, looks like that package is a systemd service

      • bzLem0n@lemmy.ca
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        9 months ago

        The package is just a systemd unit to run the command python zenstates --c6-disable so if you install the zenstates-git package and get runit to run that command at startup it would be equivalent.

        • communism@lemmy.mlOP
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          9 months ago

          Thank you!!

          Edit: Tried running that, I’m getting the error that /dev/cpu/0/msr doesn’t exist. dev/cpu doesn’t seem to exist at all on my machine. Hm

          Edit 2: You need to run sudo modprobe msr. All good now :)

  • ProgrammingSocks@pawb.social
    link
    fedilink
    arrow-up
    0
    ·
    9 months ago

    This is pointless. Your tax dollars are doing MUCH more for Israel than what products you buy. Boycotts are a capitalist distraction from the real systemic issues.

    • onlinepersona@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      9 months ago

      Buhruh! Why not just stop voting since “your vote is only a drop in the ocean” or “it only legitimises a broken system”?

      Every action towards progress counts. It’s better than nothing, which is what people do if you ask them to change the world in one go. Change is gradual, change is slow, change can be achieved by the small actions of many. Not everybody has the time to “tackle the systemic issues” you perceive to be true nor does everybody agree that those are the core issues.

      Belittling action, no matter how small, is discouraging and counterproductive.

      CC BY-NC-SA 4.0

    • communism@lemmy.mlOP
      link
      fedilink
      arrow-up
      0
      ·
      9 months ago

      Not when there’s an organised boycott, called for by Palestinians. You can do multiple things at once. Not buying something takes 0 hours of your time lol

      • Shareni@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        9 months ago

        Not buying something takes 0 hours of your time lol

        It takes so little time you needed to make a post to ask for help lol

        • catnash [she/her, ae/aer]@lemmy.blahaj.zone
          link
          fedilink
          arrow-up
          0
          arrow-down
          1
          ·
          9 months ago

          Making a post takes a minute. Responses will take less than a minute. They were crowdsourcing specific and quite niche knowledge. In that time between making the post and reading them after a wait OP was able to do literally anything else instead of searching and trying to pull out decent looking CPUs they couldn’t guarantee. If you were buying any CPU you would hopefully look for reviews or comparisons, BDS or not, to inform you.