Linux 5.5-rc6 Released With Some Notable Radeon Graphics Fixes Plus Other Random Work

Kernel driver faults. Computer becomes unresponsive. Sometimes amdgpu manages to reset itself, but context of all graphics applications including your desktop is lost and they're effectively dead. There are multiple reports of this on Bugzilla/Gitlab.

Ah, the same crap I faced on my R9 390. So the status quo hasn't changed one bit, contrary to bridgman's and AMD fans' assertions.

As soon as a decently powerful Intel Xe dGPU is released, I'll just ditch this stupid AMD card.

[aht0]

Okay, tnx. I won't bother checking it in depth when you say so. Tnx for the heads-up.

[BS86]

Was it actually caused by a bug in the previous release candidates of kernel 5.5 that got fixed just now (I can't see anything in the commit log), or is it caused by something else? Or is it not fixed and I just haven't triggered the bug yet somehow?

i really hope that it was fixed. Will try when I am home again tonight (It's 8 AM here) I don't think that the fix will have anything with clock in its name or description. I think it is/was a side effect or regression of some other change.

I could try it, Asus ROG board, Ryzen/discrete Vega rig.

Would be great! But if rc6 already fixed it, it might not be needed.

Edit: the problem IS fixed in rc6. 5 reboots and no clock reset. With rc5 it is still reproducible.

[aht0]

I have a very strange problem with the 5.5 Kernels so far: 8 out of 10 times when I reboot or shutdown, the system clock is reset to 1.1.2017 00:00 in BIOS.
That behaviour does not happen on Kernels 5.4.10 and earlier, and it also does not happen on Windows.

Things already done:
- Replaced mainboard battery (as it happens only with Kernel 5.5, that obviously did not fix it - but I realized that my mainboard only resets the time and date when removing the battery)
- checked for BIOS updates (none there: 5406 is installed and the latest version)
- linux-firmware is also up-to date (20200107 on Manjaro)

My relevant hardware: Asus ROG Strix X470-F Gaming and a Ryzen 2700X, full UEFI/GPT setup.

I only noticed that behaviour because on every boot after the clock reset happening, systemd-fsck kicks in for all partitions and that displays a message during boot for my rotation harddisk and slows down booting (the trigger for the fsck is the system time being earlier than the last mount time). If it would be a SSD only system, I would not even notice the behaviour because the NTP service already synced when the GUI displays the clock. The only way to see it is by checking the BIOS clock.

Does anyone else notice that behavior or can check if their hardware clock in BIOS is reset after rebooting with a 5.5 Kernel?

Edit: If it is important: Asus uses American Megatrends BIOS'es.

I could try it, Asus ROG board, Ryzen/discrete Vega rig.

[BS86]

I'm having a similar problem with my Asus ROG Strix X570-F Gaming, which I've bought for my new Ryzen 3950X at the end of November last year. It's always resetting the clock to 2019-01-01

Well, that sounds EXACTLY like my problem. For my X470, 1.1.2017 is the earliest possible date. For yours, it is 1.1.2019. Looking forward to your findings with 5.4.

I have absolutely no idea what in the kernel would cause that behaviour. I suspect something that "talks" to the UEFI, but what exactly it is, no idea.

I have a Vega64 which also gets better with each kernel, but so far, I am back to 5.4 because of that reset - issue.

[archola]

I will check this later today with an older kernel when I get the time and come back with the results.

I'm a bit confused now. I've built 5.5-rc6 (while using 5.5-rc5) after writing my previous post, upgraded the rest of the system, rebooted, corrected the hardware clock because it was of course reset, and booted into both 5.5-rc6 and 5.4.11 several times throughout the day, but the clock didn't reset even once after that. This is a bit surprising, because it happened all the time previously. Was it actually caused by a bug in the previous release candidates of kernel 5.5 that got fixed just now (I can't see anything in the commit log), or is it caused by something else? Or is it not fixed and I just haven't triggered the bug yet somehow?

[lowlands]

Same here, a system with Vega 56 GPU and no issues besides a minor problem I do not use (not my particular use case), my system after hibernating (when the system wakes up) the GPU goes 100% fan speed and stays with a black screen.

I usually turn off that particular function since I either turn off the computer or have it on to be used thus does not count as a problem for me.

Which distro do you use? With Fedora you need to specify the resume=<device> in grub or it won't come back properly after hibernate.

[aufkrawall]

*sigh*, still no progress with this:

https://gitlab.freedesktop.org/drm/amd/issues/1001

[archola]

I have a very strange problem with the 5.5 Kernels so far: 8 out of 10 times when I reboot or shutdown, the system clock is reset to 1.1.2017 00:00 in BIOS.
That behaviour does not happen on Kernels 5.4.10 and earlier, and it also does not happen on Windows.

My relevant hardware: Asus ROG Strix X470-F Gaming and a Ryzen 2700X, full UEFI/GPT setup.

Interesting... I'm having a similar problem with my Asus ROG Strix X570-F Gaming, which I've bought for my new Ryzen 3950X at the end of November last year. It's always resetting the clock to 2019-01-01, which is annoying when I rarely boot into Windows, as it doesn't update the time on boot automatically via network like systemd does. That's how I noticed it and that's why I didn't care that much on Linux, because it was basically a non-issue.

I was already using kernel 5.5 when I upgraded my system in early December, so I haven't checked whether this is related to the recent kernel, as I haven't used an older one since I'm also using a 5700XT and want to use the latest AMDGPU stuff. I will check this later today with an older kernel when I get the time and come back with the results.

[Sethox]

What works on my machine (Vega 56 GPU) is lowering the power limit by 15-25 watts. At -15 watts, the performance on The Witcher 3 (using DXVK) appears to be equivalent to what it would be without the reduction. If I enable HBAO+, though, the game will still eventually crash.

Same here, a system with Vega 56 GPU and no issues besides a minor problem I do not use (not my particular use case), my system after hibernating (when the system wakes up) the GPU goes 100% fan speed and stays with a black screen.

I usually turn off that particular function since I either turn off the computer or have it on to be used thus does not count as a problem for me.