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 05:21:18 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1055106413==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [IPv6:2610:10:20:722:a800:ff:fe98:4b55]) by gabe.freedesktop.org (Postfix) with ESMTP id 88FBF6E1D2 for ; Mon, 24 Sep 2018 05:21:18 +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 --===============1055106413== Content-Type: multipart/alternative; boundary="15377664780.125Eb8.20555" Content-Transfer-Encoding: 7bit --15377664780.125Eb8.20555 Date: Mon, 24 Sep 2018 05:21:18 +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 #19 from Alan W. Irwin --- Despite a new kernel, this instability issue has continued. Kernel 4.18.6 locked up after 8+ days of up time on our principal computer that has the RX 550 graphics card installed. (I will refer to this computer as the "new" computer, our other working Linux computer that is used to display X results from the new computer as the X-terminal, and our old principal computer (powered down permanently now) as the "old" computer.) The lockup of the new computer occurred some time in the early morning and (since two users use t= his machine at one time) with one inactive XFCE desktop being displayed on our X-terminal and one inactive XFCE desktop being displayed directly on the new computer. The only symptom of the lockup I could spot in the log files was= a burst of null bytes in each log file. For what it is worth that symptom is new. See the attached crash_report_20180923.tar.gz for the log file and dm= esg details. This result of 8+ days of up time for direct graphics desktop use of the new computer is slightly better than the almost 7 days of up time achieved for = the previous similar test for kernel 4.17.7. Although the present up time resu= lt at least encourages further testing with kernel 4.18.x, this is only one te= st, and the next test might give a substantially shorter or longer up time. In = any case this result is still far from ideal since such lockups never occurred = on the old computer that this new computer replaced and also do not currently occur for the X-terminal. That is, on the old principal box up times excee= ding 30 days have been common and similarly on the X-terminal, and the only reas= on I rebooted in those cases was power interruptions or the installation of a new kernel. For the present case of the new box, the lockups mean the only recovery possible is to hit the reset button with all that implies about journal recovery and potential file deletion for files that are in inconsis= tent shape due to the lockup. For what it is worth, the lockup symptoms this time were a bit different th= an before. The new computer had a frozen display (rather than blank before), = and frozen mouse and keyboard (as before). The X-terminal used to remotely acc= ess a desktop running on the new computer had a frozen display (rather than blanked) with working keyboard (and maybe mouse, but I didn't record that) = so I could exit the local X and get to the Linux console where ping to the new computer actually worked (as opposed to ping not working at all for the previous lockup). So because networking was working, ssh to the new comput= er didn't time out. However, it ran for 20+ minutes with no sign of a login so the net result was the same as for previous lockups; there was no way to lo= gin to the new computer from another computer to shut down the new computer normally so the only method of shutting it down was to hit the reset button. --=20 You are receiving this mail because: You are the assignee for the bug.= --15377664780.125Eb8.20555 Date: Mon, 24 Sep 2018 05:21:18 +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 # 19 on bug 10667= 1 from Alan W. Irwin 
Despite a new kernel, this instability issue has continued.  K=
ernel 4.18.6
locked up after 8+ days of up time on our principal computer that has the RX
550 graphics card installed.  (I will refer to this computer as the "n=
ew"
computer, our other working Linux computer that is used to display X results
from the new computer as the X-terminal, and our old principal computer
(powered down permanently now) as the "old" computer.) The lockup=
 of the new
computer occurred some time in the early morning and (since two users use t=
his
machine at one time) with one inactive XFCE desktop being displayed on our
X-terminal and one inactive XFCE desktop being displayed directly on the new
computer.  The only symptom of the lockup I could spot in the log files was=
 a
burst of null bytes in each log file.  For what it is worth that symptom is
new.  See the attached crash_report_20180923.tar.gz for the log file and dm=
esg
details.

This result of 8+ days of up time for direct graphics desktop use of the new
computer is slightly better than the almost 7 days of up time achieved for =
the
previous similar test for kernel 4.17.7.  Although the present up time resu=
lt
at least encourages further testing with kernel 4.18.x, this is only one te=
st,
and the next test might give a substantially shorter or longer up time. In =
any
case this result is still far from ideal since such lockups never occurred =
on
the old computer that this new computer replaced and also do not currently
occur for the X-terminal.  That is, on the old principal box up times excee=
ding
30 days have been common and similarly on the X-terminal, and the only reas=
on I
rebooted in those cases was power interruptions or the installation of a new
kernel.  For the present case of the new box, the lockups mean the only
recovery possible is to hit the reset button with all that implies about
journal recovery and potential file deletion for files that are in inconsis=
tent
shape due to the lockup.

For what it is worth, the lockup symptoms this time were a bit different th=
an
before.  The new computer had a frozen display (rather than blank before), =
and
frozen mouse and keyboard (as before).  The X-terminal used to remotely acc=
ess
a desktop running on the new computer had a frozen display (rather than
blanked) with working keyboard (and maybe mouse, but I didn't record that) =
so I
could exit the local X and get to the Linux console where ping to the new
computer actually worked (as opposed to ping not working at all for the
previous lockup).  So because networking was working, ssh to the new comput=
er
didn't time out.  However, it ran for 20+ minutes with no sign of a login so
the net result was the same as for previous lockups; there was no way to lo=
gin
to the new computer from another computer to shut down the new computer
normally so the only method of shutting it down was to hit the reset button=
.

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