I have been hugely disappointed in the AMD RX 550 because it continues to frequently lock up my Debian Buster system. The latest chapter in this three-month saga (for the full story see <https://bugs.freedesktop.org/show_bug.cgi?id=106671>) is an upgrade to kernel-4.17.17 and mesa-18.1.6 resulted in two kernel lockups in the first 9 hours after the update just from ordinary desktop use. That is a huge disappointment because you would think the long-standing good cooperation between AMD and Linux and X developers would result in an outstanding amdgpu driver. But my experience shows that is far from the case (at least for the RX 550). I know the issue is caused by the RX 550 because if I avoid using it (by remotely accessing my new box from an X-terminal), the new box is completely stable. I noticed a similar recent topic here for the RX 560 (although that sounds like worse instabilities than in my case) , and I have also seen a Phoronix article comment from one of the senior members here claiming something to the effect that most modern AMD graphics cards caused Linux lockups, but kernel-4.17 would fix that (which it didn't in my case). So does anybody hear have some inside knowledge concerning when these apparently common Linux kernel lockup issues will get fixed for AMD graphics?
Announcement
Collapse
No announcement yet.
Frequent Linux kernel lockups for the AMD RX 550 graphics card
Collapse
X
-
Other question is whether you updated the rest of the graphics stack or just kernel & Mesa (libdrm, maybe X driver, microcode etc..) ?
Before going much further I would suggest testing with a distro that includes an up-to-date driver stack with compatible components, even as a live CD.
Are there ever any graphics driver related messages in the log after a lockup ? In the dmesg output you attached to the bugzilla ticket it seems like the system ran without error for ~1.5 days, threw a lot of CD drive errors, and then stopped.Test signature
Comment
-
This is a fully updated Debian Buster = Testing system, i.e., the rolling release whose package components are promoted from Debian Unstable following a fairly stringent set of rules. So Debian Buster package components and all their dependencies have been tested for a short while by the community of Debian Unstable users. As a result, Debian Buster = Testing is not that far (perhaps one or two months behind) the latest versions of all components of the complete Linux graphics driver stack. So Debian Buster has kernel-4.17.17, mesa-18.1.6, libdrm-2.4.93, xserver-xorg-video-amdgpu-18.0.1-1, firmware-amd-graphics-20180518-1, etc., from the graphics stack. Let me know if you if there are any other relevant graphics stack package version numbers you need to know, but you can also conveniently look them up using the search engine at <debian.org/distrib/packages> while confining your search to Debian Buster = Testing versions.
Responding to your questions about log data, I assume dmesg output is irrelevant because that simply records the current working results as opposed to the bad kernel-lockup results from before. Also, I don't have a good record of exactly when I had to hit the reset button as opposed to a more normal boot. So looking at /var/log/messages, for example, which does contain the date range where I had to set reset twice to get out of a lockup, there are a number of boots (starting with a line that identifies the Linux version as 4.17.17) that might be relevant, but it is not obvious to me which of those was due to a kernel freeze. Let me know if you would like me to attach that or any other relevant log file to see if you can spot anything relevant to those two lockups in those log files.
By the way, I assume kernel lockup has an extremely specific technical meaning, but in my case what I mean by the term is the direct screen froze, mouse and keyboard quit working (so I could not, for example, use ctl-alt-backspace to exit X as per usual), there was no external access to this locked up computer over my LAN using ssh, and the disk activity light quit flashing. So the only method of getting control of the computer again was to hit the reset button.
Comment
-
Originally posted by debianxfce View Post
My distribution uses Oibaf ppa Mesa git and latest AMD drm-next-4.xx-wip kernel.
Could you reply to the other part of my question? That is, what modern AMD graphics cards (yours or good reports from others) work without lockups for your distribution?
Comment
-
Originally posted by airwin View PostResponding to your questions about log data, I assume dmesg output is irrelevant because that simply records the current working results as opposed to the bad kernel-lockup results from before.Test signature
Comment
-
Originally posted by debianxfce View Post
Using latest open source software amdgpu drivers works fine with Asus RX560 2GB and Debian sid Xfce. Other software than amdgpu drivers can cause lockups, the Chrome browser can freeze the whole system when graphics acceleration is in use. I test my distribution with Rocket League and Rise of the Tomb Rider games.
Comment
Comment