ReillyBrogan None of them will help. A couple were compiling error warnings, one of them was a revert (which we already have in our 5.10.5 kernel), and others were related to device removal not initialization. For 5.10.6, it's basically the same deal, the two additional patches I added in our 5.10.5 kernels just happened to get landed in 5.10.6, no additional changes.
You can track the issues that I've linked earlier in the thread.
@Chrym Nope. None of the changes in 5.10.x will fix performance related issues. There are issues filed on the drm/amd issue tracker related to reduced performance, which have not been resolved, and some of those are actually regressions in Mesalib and not the kernel itself. We can't update to 20.3.x yet because there isn't a 20.3.x release that includes the radeonsi changes to fix some of the significant performance regressions in specific games (not normal workloads). I'm not aware of that specific regression existing prior to Mesalib 20.3 though.
None of that is to say I won't update our linux-lts, linux-current, and internal linux-next. Just wanting everyone's expectations to be reasonable.
@Lucien_Lachance I'd try adding the following line before the ExecStart
in the gdm.service
file and temporarily removing the second luks encrypted drive if possible, just so we can see how narrow of a race condition it is: ExecStartPre=/bin/sleep 3
This will basically prevent gdm from starting for 3 or so seconds. If that works, we can try narrowing it down to 2
seconds, followed by just 1
second. The kernel should be pretty quick about initializing your device.
Additionally, it might be beneficial for us to get systemd's chart of the boot process, what services are spun up, when, and how long they take.
sudo eopkg install -y imagemagick && sudo systemd-analyze plot > boot-chart.svg && convert -resize 1400 -quality 80 boot-chart.svg boot-chart.jpg
Then upload the boot-chart.jpg file to an image hosting website, such as via https://imgbb.com/upload