<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Frequent lock ups for AMD RX 550 graphics card" href="https://bugs.freedesktop.org/show_bug.cgi?id=106671#c19">Comment # 19</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Frequent lock ups for AMD RX 550 graphics card" href="https://bugs.freedesktop.org/show_bug.cgi?id=106671">bug 106671</a> from <a class="email" href="mailto:Alan.W.Irwin1234@gmail.com" title="Alan W. Irwin <Alan.W.Irwin1234@gmail.com>"> Alan W. Irwin</a> <pre>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 this 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 dmesg 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 result at least encourages further testing with kernel 4.18.x, this is only one test, 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 exceeding 30 days have been common and similarly on the X-terminal, and the only reason 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 inconsistent shape due to the lockup. For what it is worth, the lockup symptoms this time were a bit different than 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 access 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 computer 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 login 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>