https://bugs.freedesktop.org/show_bug.cgi?id=95261
Bug ID: 95261 Summary: R5 M330 GPU lockup with DPM + high power states Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: andrzej.mendel@gmail.com
Created attachment 123454 --> https://bugs.freedesktop.org/attachment.cgi?id=123454&action=edit /var/log/syslog at the moment of hangup (photo)
System: Ubuntu 16.06 with Mesa git (padoka ppa) and kernel 4.6-rc6 GPU: Intel HD 5500 + AMD R5 M330 - all command below run with DRI_PRIME=1
I get GPU hangups, which result in freeze after a soft reset, whenever the load is high enough to push the GPU into higher power states.
If I run, for example, glmark2, only the first frame gets rendered and then the GPU lockups. After ~30s system freezes with information about GPU soft reset as the last message in syslog (see attachment)
If I run a non-GPU-intensive commands (say, glxgears with vsync), then the GPU stays in low power states and I do not get this hangup. If I force lower power states (echo battery > /sys/class/drm/card1/device/power_dpm_state), I don't get this hangup even with glmark2.
If I force high power states (echo performance > /sys/class/drm/card1/device/power_dpm_state; echo high > /sys/class/drm/card1/device/power_dpm_force_performance_level; echo on > /sys/class/drm/card1/device/power/control) then I do not get the hangup as long as there is no activity at all on the GPU. A simple glxgears is enough to trigger a hangup in this situation.
This bug is present since at least kernel 4.2.
I would appreciate any info on how to debug this further and will provide more info if requested.
https://bugs.freedesktop.org/show_bug.cgi?id=95261
--- Comment #1 from Andrzej Mendel-Nykorowycz andrzej.mendel@gmail.com --- Created attachment 123455 --> https://bugs.freedesktop.org/attachment.cgi?id=123455&action=edit lspci -nn
https://bugs.freedesktop.org/show_bug.cgi?id=95261
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #123454|text/plain |image/jpg mime type| |
https://bugs.freedesktop.org/show_bug.cgi?id=95261
--- Comment #2 from Alex Deucher alexdeucher@gmail.com --- Please attach your xorg log and dmesg output.
https://bugs.freedesktop.org/show_bug.cgi?id=95261
--- Comment #3 from Andrzej Mendel-Nykorowycz andrzej.mendel@gmail.com --- Created attachment 123456 --> https://bugs.freedesktop.org/attachment.cgi?id=123456&action=edit Xorg.0.log
https://bugs.freedesktop.org/show_bug.cgi?id=95261
--- Comment #4 from Andrzej Mendel-Nykorowycz andrzej.mendel@gmail.com --- Created attachment 123457 --> https://bugs.freedesktop.org/attachment.cgi?id=123457&action=edit dmesg
https://bugs.freedesktop.org/show_bug.cgi?id=95261
--- Comment #5 from Andrzej Mendel-Nykorowycz andrzej.mendel@gmail.com --- I've checked with Mesa 10.4.7 and kernel 3.17 (the earliest versions I could compile or run, respectively) and get the same lockup.
https://bugs.freedesktop.org/show_bug.cgi?id=95261
--- Comment #6 from harzerkas@gmail.com --- Can confirm this bug with a R5 M240 on a Thinkpad T450.
https://bugs.freedesktop.org/show_bug.cgi?id=95261
--- Comment #7 from Alex Deucher alexdeucher@gmail.com --- Does it work any better with my drm-next-4.8-wip branch: https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.8-wip and the new smu firmware here: http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/comm...
https://bugs.freedesktop.org/show_bug.cgi?id=95261
--- Comment #8 from Andrzej Mendel-Nykorowycz andrzej.mendel@gmail.com --- (In reply to Alex Deucher from comment #7)
Does it work any better with my drm-next-4.8-wip branch: https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.8-wip and the new smu firmware here: http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/ commit/?id=9693ff6d749dcf1dfd81f0f6b227ab07a3d76c90
Unfortunately, no, I get the same hangup with any GPU intensive application. I've put new firmware files in /lib/firmware/radeon and I believe it is being loaded (the filesize reported is that of hainan_k_smc.bin):
Jun 10 16:02:49 Sulejman kernel: [ 511.257607] [drm:radeon_ucode_print_smc_hdr] SMC Jun 10 16:02:49 Sulejman kernel: [ 511.257608] [drm:radeon_ucode_print_common_hdr] size_bytes: 61932 Jun 10 16:02:49 Sulejman kernel: [ 511.257609] [drm:radeon_ucode_print_common_hdr] header_size_bytes: 36 Jun 10 16:02:49 Sulejman kernel: [ 511.257610] [drm:radeon_ucode_print_common_hdr] header_version_major: 1 Jun 10 16:02:49 Sulejman kernel: [ 511.257610] [drm:radeon_ucode_print_common_hdr] header_version_minor: 0 Jun 10 16:02:49 Sulejman kernel: [ 511.257611] [drm:radeon_ucode_print_common_hdr] ip_version_major: 6 Jun 10 16:02:49 Sulejman kernel: [ 511.257612] [drm:radeon_ucode_print_common_hdr] ip_version_minor: 0 Jun 10 16:02:49 Sulejman kernel: [ 511.257613] [drm:radeon_ucode_print_common_hdr] ucode_version: 0x01337baa Jun 10 16:02:49 Sulejman kernel: [ 511.257614] [drm:radeon_ucode_print_common_hdr] ucode_size_bytes: 61676 Jun 10 16:02:49 Sulejman kernel: [ 511.257614] [drm:radeon_ucode_print_common_hdr] ucode_array_offset_bytes: 256 Jun 10 16:02:49 Sulejman kernel: [ 511.257615] [drm:radeon_ucode_print_common_hdr] crc32: 0x9624ad7c Jun 10 16:02:49 Sulejman kernel: [ 511.257616] [drm:radeon_ucode_print_smc_hdr] ucode_start_addr: 65536
https://bugs.freedesktop.org/show_bug.cgi?id=95261
--- Comment #9 from harzerkas@gmail.com --- I also tried the drm-next branch and the new firmwares, didn't help me either.
https://bugs.freedesktop.org/show_bug.cgi?id=95261
Martin Peres martin.peres@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |MOVED Status|NEW |RESOLVED
--- Comment #10 from Martin Peres martin.peres@free.fr --- -- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/717.
dri-devel@lists.freedesktop.org