Linux 5.9-rc8 Is Out With PCIe IDs for AMDs Upcoming Sienna Cichlid GPUs

From LinuxReviews
Jump to navigationJump to search

We have examined the latest Linux 5.9 release candidate and found that it is actually possible to use it to boot and start X or Wayland on machines with Intel processors using Intel integrated graphics with this latest kernel release-candidate. That is an improvement since the total train-wreck disaster released as Linux 5.9-rc7.

written by 윤채경 (Yoon Chae-kyung)  2020-10-05 - last edited 2020-10-06. © CC BY

Linux kernel 5.9-rc8 booting on a machine with a Intel CPU.

The previous Linux 5.9 release candidate, Linux 5.9-rc7, would just crash the i915 driver for Intel graphics as soon as X or Wayland or anything else graphical was started. That has been fixed in Linux 5.9-rc8. We tested it on two machines with Intel CPUs using integrated Intel graphics and they appear to work just fine. Linux 5.9-rc8 will still hang after 5-10 minutes without booting with either the intel_idle.max_cstate=1 kernel parameter or the ahci.mobile_lpm_policy=1 kernel parameter or both on many, mostly laptop, Intel machines using Intel graphics. That's not new to Linux 5.9, that's been a problem since Linux 5.0 was released ages ago.

The change-log since Linux 5.9-rc7 looks fairly dull with one slightly interesting exception: Linus Torvalds pulled a small commit adding PCI IDs for the upcoming line of AMD Sienna Cichlid graphics cards (The Radeon RX6000 series). That confirms that Sienna Cichlid will be dedicated graphics cards, not APUs. There is still no kernel support for mysterious upcoming VanGogh and Dimgrey Cavefish GPUs. Supports for those has already been added to both the Mesa RadeonSI driver and LLVM. Kernel support for "Vangogh" and "Dimgrey Cavefish" will probably arrive during the Linux 5.10 merge window which opens up after Linux 5.9 is released next weekend.

Linus Torvalds expects to be able to release a final Linux 5.9 kernel next weekend. He had this to say in the Linux 5.9-rc8 announcement:

"So things have been pretty calm, and rc8 is fairly small. I'm still waiting for a networking pull with some fixes, so it's not like I could have made a final 5.9 release even if I had wanted to, but there was nothing scary going on this past week, and it all feels ready for a final 5.9 next weekend.

In fact, a lot of the emails I'm seeing are about the next merge window, and I already have one pull request ready to go, which is all good. That's how it's all supposed to work.

Anyway, the changes in rc8 are mostly driver fixlets, with some AMD GPU header file updates being a fairly noticeable part of the patch. That's not some scary big change - it' just the usual register definition update (and much smaller than the wholesale big ones we've had).

Outside of the driver stuff, we do have a few filesystem fixes (btrfs and nfs), and a couple of core fixes (tiny fallout from the VM changes, but also a pipe splice race fixlet for stable and a couple of epoll fixes). And slime other small noise (small arch and DT fixes). Quite a small diffstat overall - which it obviously should be this late in the release.

One final push for testing this week, Linus"

Linus Torvalds on the LKML

Torvalds neglected to mention that Linux 5.9-rc7 broke graphical environments on all machines using Intel graphics in his announcement. That's quite understandable, such a massive face-losing mistake is best swept under the rug.

Those of you who want to try Linux 5.9-rc8 can acquire the technology from

(4 votes)



15 months ago
Score 0++

Here some embarrassing truth: I've compiled the kernel with the GCC optimization patch, the out-of-tree it87 module and lately the OpenRGB patches and some ZSTD patches.

Linux 5.9-rc8 did randomly crash on me upon installation. Very unfortunate. Kernel expert Alex Deucher from the AMD Open Source Lab asked me to reproduce it. First step was obviously to compile and install a plain vanilla Linux 5.9-rc8 with no patches and run it with no fun acpi_enforce_resources=lax or amdgpu.ppfeaturemask=0xfffd7fff boot parameters. I then ran lots of GPU stressing things in a loop. 12 hours later two boxes were still fine. That would indicate that it's not a vanilla kernel problem, which is why I removed the stuff about AMD from this article. Sometimes we're just wrong. It happens.

As for the root cause of those random crashes: Finding the cause should be easy enough. It is like a matter of enabling things one by one until it breaks.
Add your comment
LinuxReviews welcomes all comments. If you do not want to be anonymous, register or log in. It is free.