Announcement

Collapse
No announcement yet.

AMD Releases BIOS Fix To Motherboard Partners For Booting Newer Linux Distributions

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Danny3 View Post
    OK, it's not systemd's fault, but can't systemd be smart enough to fallback to another thing if the CPU doesn't have this function or it's broken?
    I understand that it's for security, but making the whole system unbootable is insane when the processor has this kind of problem.
    Yes it sure can. Systemd already works fine if the CPU does NOT have this instruction (nor advertises it).

    The issue here is that CPUs that advertise this instruction should fucking work. This is not some quirk of a realtek cheap shit ethernet chipset, it's a serious malfunction of an instruction of the main system CPU, where the Linux kernel runs.

    The best course of action in this case is locking down everything and force the manufacturer to fix his shit.

    Comment


    • #22
      Originally posted by Venemo View Post
      Does this mean that during the development of the Zen 2 products, there was not a single person in AMD who actually booter a newer Linux distro to see if it works with the new chip?
      That's not surprising, what is surprising is that none tested that this CPU instruction actually works at all.

      From the PR it seems that this is also the reason why they had issues with Destiny or other games.

      Comment


      • #23
        Originally posted by starshipeleven View Post
        Yes it sure can. Systemd already works fine if the CPU does NOT have this instruction (nor advertises it).

        The issue here is that CPUs that advertise this instruction should fucking work. This is not some quirk of a realtek cheap shit ethernet chipset, it's a serious malfunction of an instruction of the main system CPU, where the Linux kernel runs.

        The best course of action in this case is locking down everything and force the manufacturer to fix his shit.
        100% agreed.
        That being said, it doesn't change the fact that my Debian Sid install which I replaced systemd with sysvinit on would have sailed through this fiasco without issue, had I swapped its HDD onto a Ryzen 2 board.

        I get that it's not really systemd's fault for trusting hardware manufacturers to actually provide functional hardware that does what it says it will do, but I still take great pleasure in finding cases where systemd simply fails to work without indicating why (like on my 2006 imac, where I can only boot a systemd distro approximately 50% of the time, and has been that way since 2013 when I first put a distro on it. The other half of the time it hangs mid-boot, and even in a verbose (non-quiet) boot I see no useful information to debug it).
        Last edited by wyatt8740; 12 July 2019, 12:11 PM.

        Comment


        • #24
          Originally posted by Danny3 View Post
          OK, it's not systemd's fault, but can't systemd be smart enough to fallback to another thing if the CPU doesn't have this function or it's broken?
          I understand that it's for security, but making the whole system unbootable is insane when the processor has this kind of problem.
          The systemd developers they should still put a fallback with probably longer boot time or a bit less security instead of just stopping the whole boot process.
          Lennart already explained why use RDRAND instead /dev/Xrandom in short and simplified the kernel /dev/Xrandom don't have entropy enough that early in the boot process hence is useless.

          Also RDRAND is a freaking X86 opcode, add fallback to this is as stupid as try to add a fallback to JMP or MOV instructions, at that point something is obviously extremely wrong and you should crash, send fireworks, call your cats mama and scream while running in circles

          Comment


          • #25
            Originally posted by josh_walrath View Post
            Yay! No need to wait for a new kernel.

            I wonder: do mobos get OTA updates? Like, if there's a mobo sitting in a box in a warehouse that I could buy right now, would it get the new BIOS that precludes the problem? Because, otherwise... :C
            My older X370 Asus board allows for getting the latest bios from the internet via the UEFI, so no actual OS required to update

            Comment


            • #26
              Is there any more info somewhere?

              Comment


              • #27
                Originally posted by edwaleni View Post
                AMD should work fast. Zen 2 is selling very, very well. See the lines at MicroCenter the morning of the release.
                On Newegg it's been sold out since release

                Comment


                • #28
                  Originally posted by starshipeleven View Post
                  That's not surprising, what is surprising is that none tested that this CPU instruction actually works at all.

                  From the PR it seems that this is also the reason why they had issues with Destiny or other games.
                  I mean, it does work. AFAIK it just "forgets" to store some state that is expected by some software like systemd.

                  Comment


                  • #29
                    Originally posted by AsuMagic View Post

                    I mean, it does work. AFAIK it just "forgets" to store some state that is expected by some software like systemd.
                    Wrong. It clearly doesn't work as advertised. Getting a random number returns -1, which might be in spec. There is no indication of a fault. Software can workaround by reasking if -1 is returned, but it shouldn't need to. This is clearly broken behaviour.

                    Nonetheless: There is a solution, and it's been here fast. Good Job, AMD.

                    Comment


                    • #30
                      Originally posted by Hibbelharry View Post

                      Wrong. It clearly doesn't work as advertised. Getting a random number returns -1, which might be in spec. There is no indication of a fault. Software can workaround by reasking if -1 is returned, but it shouldn't need to. This is clearly broken behaviour.

                      Nonetheless: There is a solution, and it's been here fast. Good Job, AMD.
                      As much as I love AMD; I would not call no action for 4+ years fast: https://bugzilla.kernel.org/show_bug.cgi?id=85911 Also what is with this bug in previous generation CPUs after suspend / resume?

                      Comment

                      Working...
                      X