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

[Guest]

This is the nice thing about AMD. They actually put in the effort to maintain their firmware. This is pretty quick, just like how they resolved GCC issues with Zen1.

[edwaleni]

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?

It's a good question.

Zen 2 went to tape in 4Q-2017
Zen 2 went to sampling 3Q-2018
Zen 2 was in internal testing as late as September 2018 when the Radeon team got their samples
Zen 2 was in OEM testing in March-May 2019.

Ubuntu 18 LTS released in April 2018
Ubuntu 18.10 released in October 2018
Ubuntu 19.04 released in April 2019 (which is where the issue presents itself)

So my take was that the early releases of Ubuntu 19 were too late as it occurred when Zen 2 was in OEM testing.

[Guest]

So, among the newer distro, only Debian is able to boot with the new Ryzen?

[ThoreauHD]

Debian is kernel 4.19. They are essentially on the first rev of 18.04 ubuntu LTS. Those all work atm.

[Venemo]

It's a good question.

Zen 2 went to tape in 4Q-2017
Zen 2 went to sampling 3Q-2018
Zen 2 was in internal testing as late as September 2018 when the Radeon team got their samples
Zen 2 was in OEM testing in March-May 2019.

Ubuntu 18 LTS released in April 2018
Ubuntu 18.10 released in October 2018
Ubuntu 19.04 released in April 2019 (which is where the issue presents itself)

So my take was that the early releases of Ubuntu 19 were too late as it occurred when Zen 2 was in OEM testing.

I assume it wouldn't be too hard to make an automated system which has the development version of each major distro, and see if they still boot up.

[starshipeleven]

why? because: 1) ~2nd largest market share

Not on distros using the latest kernel, bro.

2) server silicon will be mostly identical anyway

Server silicon will be shipped months from now, after the consumer hardware has done "beta testing" for it.

3) hundreds of millions if not billion $$$ investment - you want to test it with everything at hand to make sure you do not screw this up

Apparently, the "consumer" hardware is part of the testing process to save some buck.

4) nicer to test and script than WinDOS anyway

You can run bash on Windows too, although you are most likely going to be writing C or even assembler for the test themselves.

[cjcox]

I would say something evil about systemd, but we're not allowed to.

What I can say is that it's double-plus-good.

[pal666]

I agree however, that systemd should not try to re-implement the kernel's job and instead just use /dev/{u,}random as the Linux kernel already mixes and sanitizes not as random values.

outside of your fantasy world systemd did use /dev/random and had stalled boots waiting for entropy in some cases, which were fixed by usage of rdrand. urandom is pseudorandom, you don't need any kernel or hardware help for that, so even bringing it up here is incredibly clueless. and btw what makes you think kernel doesn't use rdrand? /dev/random doesn't grow on trees, it has to be implemented somehow and modern kernels do use rdrand

[pal666]

How do you know this is an AMD bug?

maybe unlike you he has some clue?

Clearly somebody did not bother to read the architecture manual.

clearly somebody can't parse few asm lines

So maybe AMD decided that it was no harm in changing the behavior to permit stupid software to work?

maybe your tinfoil hat is too tight?

[pal666]

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?

it can and such fallback was implemented as soon as such misbehaviour of amd rdrandr was discovered.
or you asked whether systemd should be able to predict any possible future misbehaviour in any possible future cpu? no, systemd doesn't have crystal ball