Ryzen 2200G Still Not Reliable in 4.18rc2, when will it work?

[bryanbr]

@bryanbr
It's weird that you get old agesa version on X470. Some say you need to get at least 1.0.0.3b. Had access to it for my board on 2018/5/2 https://www.asrock.com/MB/AMD/Fatal1...index.asp#BIOS

The latest agesa for my X470 boards is 1.0.0.2c. Here's the Gigabyte board (my Asrock 470 board is also limited to 1.0.0.2c):

https://www.gigabyte.com/Motherboard/X470-AORUS-ULTRA-GAMING-rev-10#support-dl-bios

If this is BIOS issue (the pre-GRUB boot freezes), then I suppose we have to wait for Gigabyte and Asrock to provide a fix.

[jomegaA]

I set the clock to 3.6 GHz with 1.2125v as CPU voltage and also turned down the case fans to 800 rpm. RAM clocked to 3200 MHz with 18/18/18/38 with 1.35v as DRAM voltage.

Posivite: Stable and very quite even with the stock fan. Suspend and Resume works good. Graphics do not pose any problems yet and can confirm with Phoronix Unigine/heaven test and that gave me 20 frames on average.

Negative: Pre-grub freeze (quite often) and there may also have other freezes after selecting OS to boot (but very seldom).

[Kano]

As I do not own any newer AMD CPU I would at least like to know if the problematic systems use CSM or not. Without CSM you could even boot a kernel without GRUB (via EFI stub). If the problem is at the next step and system hangs during GPU init via amdgpu it should be enought to use "nomodeset" for a basic boot check.

[SupposedlyFunny]

Tested the drm-next-4.19-wip (last week wasn't able to compile it) and the hangs are still present, kernel crashes inside "drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c"...

[makam]

Is APU support usually this slow?

Can anyone tell why this is so slow?

[bryanbr]

Is APU support usually this slow?

Can anyone tell why this is so slow?

It's really a matter of economics. AMD only has so many resources. They've always been a struggling little David against the mighty Intel Goliath.

They know how many APUs they will sell to Linux users. Probably somewhat of a blip on their financial statements. Linux for AMD is about servers and virtuals. Those systems don't ship with an APU. Linux on the desktop is a niche market.

This was a known issue at launch within AMD. Maybe not to everyone, but certainly to the people in the know. To pretend that all of those motherboard companies and all of the limited but still somewhat extensive resources at AMD, wouldn't know that their new APUs freeze prior to boot on Linux is probably not realistic.

If the issues are BIOS related, there's only so much AMD can do. Their hands are somewhat tied by how many resourcess the motherboard companies can devote to deploying updated BIOSes. And the motherboard companies were probably interested in fixing other issues. To their credit they have been releasing new AM4 BIOS that probably were tailored to fix critiical non-APU related issues.

Now given that I'm sure these issues will be fixed relatively quickly. It would be interesting to chart or see the data on how quickly such issues were fixed previously in Linux APU and BIOS and kernel world.

[makam]

It's really a matter of economics. AMD only has so many resources. They've always been a struggling little David against the mighty Intel Goliath.

They know how many APUs they will sell to Linux users. Probably somewhat of a blip on their financial statements. Linux for AMD is about servers and virtuals. Those systems don't ship with an APU. Linux on the desktop is a niche market.

This was a known issue at launch within AMD. Maybe not to everyone, but certainly to the people in the know. To pretend that all of those motherboard companies and all of the limited but still somewhat extensive resources at AMD, wouldn't know that their new APUs freeze prior to boot on Linux is probably not realistic.

If the issues are BIOS related, there's only so much AMD can do. Their hands are somewhat tied by how many resourcess the motherboard companies can devote to deploying updated BIOSes. And the motherboard companies were probably interested in fixing other issues. To their credit they have been releasing new AM4 BIOS that probably were tailored to fix critiical non-APU related issues.

Now given that I'm sure these issues will be fixed relatively quickly. It would be interesting to chart or see the data on how quickly such issues were fixed previously in Linux APU and BIOS and kernel world.

From what I have heard Windows users also had lots of issues with the latest Ryzen APUs.

[SupposedlyFunny]

With recent drm-next-4.19-wip seems I finally have reliable boots on the 2400G, before it was like 1 in 5 attempts minimum.

Yay!

[bryanbr]

With recent drm-next-4.19-wip seems I finally have reliable boots on the 2400G, before it was like 1 in 5 attempts minimum.

Yay!

How does one build (or install) drm-next-4.19-wip on a mint machine?

I use Ukuu to install kernels. I haven't actually built a kernel since Redhat version 5.

[SupposedlyFunny]

I'm using Debian stable, ignoring build dependency, I started with a shallow clone of the AMD development kernel branch

git clone -b drm-next-4.19-wip --depth 1 git://people.freedesktop.org/~agd5f/linux

I think I modified a couple of config options (one was about disabling memory encryption) and then built the Debian packages with

make bindeb-pkg LOCALVERSION=-yourlocalversion