It Looks Like Raven Ridge Desktop APUs Will Work Better With Linux 4.17

[R41N3R]

I will test this then again. Last time all kernels failed badly (4.15..4.17), on Arch Linux they just crashed during mode setting. At least without SDDM they booted to the command line.

I found the time to test my Ryzen 2200G and ASRock AB350M Pro4. Linux 4.15 on Arch Linux works with the kernel parameter amdgpu.dc=1, it boots to SDDM and I can work in Plasma-Wayland, but the desktop effects are not accelerated by the GPU. Linux 4.16-git and Linux-amd-staging-drm-next just fail to load during mode setting, it hangs and shows only a solid white block in the center from left to right on the screen.

[Sonadow]

We have some COTS desktop hardware in house now and have been able to duplicate some of the issues others have been seeing. Normally COTS hardware and our in-house engineering boards behave pretty similarly but there seems to have been more divergence with Raven.

How was this allowed to happen? Aren't manufacturers supposed to follow the reference specs quite closely?

If this keeps up, maybe AMD should really start to consider selling its own reference design boards. That will teach the manufacturers never to muck around with the low-level specifications.

[edwaleni]

My bad. I meant to include it.

MSI B350M PRO-VDH

I already pinged MSI to request a change in their BIOS so that it can boot into safe mode with an older AGESA so it can be flashed. By the fact the BIOS had to reboot the board twice to recognize the Raven Ridge install makes me think they can't do it. The boot sequence on the A-Series is very quick. The sequence under the Raven Ridge is much longer before you see a screen. Watching the boot monitor, it turns on everything, stops the CPU briefly (along with the CPU fan), then restarts it, then completes.

If I didn't know better I would say the BIOS checks to see if it is a A-Series first, stops and restarts it as a Ryzen. MSI does warn you that after the RR upgrade, UEFI will take awhile to load on first boot.

In one case after resetting the CMOS, I couldn't get video on the VGA port. After some tweaks UEFI came up finally, but was full of artifacts and wouldn't accept changes. I finally had to dig out of storage an old Radeon HD4550 PCIe and boom, everything worked and UEFI went back to defaults. In case anyone asks, the NVidia card did not work in this circumstance.

As far as I can tell, its telling me something is on IRQ7 that can't be shared and the Vega doesn't like it. Also of note, the Vega is not an IGP on Raven Ridge. It is attached via an internal 16x lane in the SOC. Also something I haven't seen before, UEFI has a cryptomining above 4Gb option.

Win 10 Creators Update fixed the "Inadequate Resources" error on the Vega. So I can't trace it to a particular KB or library that was changed. So I will have to chalk it up to a Windows kernel change that was bundled in the update. I was reluctant to let the update pass through due to reports of driver breakage, especially ones written for Win 8.1, Seeing Linux needed some specific kernel changes to support the CPU, this isn't all that surprising. "Something" in Raven Ridge is unique to such a degree it needed something tweaked.

All of the GPU Compute jobs run just fine and I will load up the PTS beta and run a few more to confirm.