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==--