From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 106671] Frequent lock ups for AMD RX 550 graphics card Date: Mon, 24 Sep 2018 19:58:45 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0648965934==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id EEE4C6E341 for ; Mon, 24 Sep 2018 19:58:44 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0648965934== Content-Type: multipart/alternative; boundary="15378191240.6d6f9.23889" Content-Transfer-Encoding: 7bit --15378191240.6d6f9.23889 Date: Mon, 24 Sep 2018 19:58:44 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D106671 --- Comment #22 from Alan W. Irwin --- This last stability test lasted only 17.5 hours before the lockup. See the latest attached tarball for the relevant log files (which capture everything during this short up time) and dmesg output. As far as I can tell there is nothing in those log files relevant to the lockup, e.g., no burst of null a= scii characters like what occurred in the log files for the previous experiment. There are some segfaults associated with a cron task I have configured every morning starting at 4:32, but those always occur for that task (which is a complete build and test of CMake) so I don't think they are relevant. The actual lockup today happened with one inactive desktop running on the X-terminal and one active desktop running on the new box. (I was editing a file with Emacs.) Also, the symptoms of this lockup were more severe, i.e., ping did not work from the X-terminal to the new box. But as always there was no way to shut down the new box properly so I had to do that with the reset button. Since I bought the new box in May remote access from an X-terminal has only locked up twice (one of those detailed here), and after a relatively long period of time. So tests where the X-terminal use is the only way to access the new box seems in general much more stable than direct use (as in the present case with such a short time before the lockup). And I haven't tried sole use of the X-terminal for a while now, and that may be completely stab= le with the new kernel. So my conclusion remains that the problem is associat= ed with the Debian Buster graphics stack (and likely also the very latest grap= hics stack if someone will do some up time tests for modern AMD graphics cards f= or that stack) used to display and control the RX 550 card on the new box. I have now started a new test (as of 9:08:19 today) with all graphics stack versions and kernel parameters the same as for the previous test in hopes t= hat when the inevitable lockup comes the log files will be more informative.=20 Please let me know if you have some other experiment you would like me to t= ry. --=20 You are receiving this mail because: You are the assignee for the bug.= --15378191240.6d6f9.23889 Date: Mon, 24 Sep 2018 19:58:44 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Comme= nt # 22 on bug 10667= 1 from Alan W. Irwin
This last stability test lasted only 17.5 hours before the loc=
kup.  See the
latest attached tarball for the relevant log files (which capture everything
during this short up time) and dmesg output.  As far as I can tell there is
nothing in those log files relevant to the lockup, e.g., no burst of null a=
scii
characters like what occurred in the log files for the previous experiment.
There are some segfaults associated with a cron task I have configured every
morning starting at 4:32, but those always occur for that task (which is a
complete build and test of CMake) so I don't think they are relevant.

The actual lockup today happened with one inactive desktop running on the
X-terminal and one active desktop running on the new box.  (I was editing a
file with Emacs.) Also, the symptoms of this lockup were more severe, i.e.,
ping
did not work from the X-terminal to the new box.  But as always there was no
way to shut down the new box properly so I had to do that with the reset
button.

Since I bought the new box in May remote access from an X-terminal has only
locked up twice (one of those detailed here), and after a relatively long
period of time.  So tests where the X-terminal use is the only way to access
the new box seems in general much more stable than direct use (as in the
present case with such a short time before the lockup).  And I haven't tried
sole use of the X-terminal for a while now, and that may be completely stab=
le
with the new kernel.  So my conclusion remains that the problem is associat=
ed
with the Debian Buster graphics stack (and likely also the very latest grap=
hics
stack if someone will do some up time tests for modern AMD graphics cards f=
or
that stack) used to display and control the RX 550 card on the new box.

I have now started a new test (as of 9:08:19 today) with all graphics stack
versions and kernel parameters the same as for the previous test in hopes t=
hat
when the inevitable lockup comes the log files will be more informative.=20
Please let me know if you have some other experiment you would like me to t=
ry.


You are receiving this mail because:
  • You are the assignee for the bug.
= --15378191240.6d6f9.23889-- --===============0648965934== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0648965934==--