| Bug ID | 93879 |
|---|---|
| Summary | kernel 4.4.0 causes application lockup and unusable interfaces with radeon hardware |
| Product | DRI |
| Version | XOrg git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | critical |
| Priority | medium |
| Component | DRM/Radeon |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | jimmy@boombatower.com |
Created attachment 121320 [details]
sh -c "cat /proc/version; ./scripts/ver_linux; cat /proc/cpuinfo; cat
/proc/modules; cat /proc/ioports; cat /proc/iomem; lspci -vvv; cat
/proc/scsi/scsi" > env_info
While running Plasma 5 on 4.4.0 the following occurs periodically:
- chromium locks up
- plasma desktop locks up
- unable to enter password on plasma lock screen
A trigger for locking chromium up seems to be to resize the window by dragging
to screen edges (top to fullscreen, left to tack up left half of screen, etc).
Otherwise, it also seems to somewhat randomly freeze over time.
Reverting to 4.3.x resolves the issues.
Environment
-----------
Distro: openSUSE Tumbleweed (20160121) (x86_64)
Kernel version: 4.4.0-1.2 (works on <= 4.3.3-6)
OpenGL renderer string: Gallium 0.4 on AMD TAHITI (DRM 2.43.0, LLVM 3.7.0)
OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.1.0
Xorg version: 7.6_1.18.0-5.2
xf86-video-ati version: 7.6.1-1.2
DRI3 enabled
Hardware: Radeon HD 7970 ghz
output from kernel bug reporting guide attached
Sounds like it could be the problem discussed in http://lists.freedesktop.org/archives/dri-devel/2016-January/098821.html .
Come to think of it, I did experience that one day but never again.
I am having similar issue on AMD HD 7870 GPU, openSUSE Tumbleweed, and Kernel 4.4.0-1.2. I cannot say for sure the trigger, however, once the screen locks requiring a password, the password field becomes disabled although mouse and keyboard remain fully functional. In fact, it would seem the entire lock screen becomes unresponsive to both mouse and keyboard, and CTRL+ALT+Backspace needs to be employed in order to restart the session.
Can you guys try reverting the commits referenced in http://lists.freedesktop.org/archives/dri-devel/2016-January/098823.html ? Alternatively, can you bisect?
I had planned to test reverting those commits, but after reading through the thread it seems those commits simply further exposed symptoms of a larger issue that I believe was fixed in http://lists.freedesktop.org/archives/dri-devel/2016-January/097880.html. I am running a 4.4.0 kernel with that patch applied and so far have not seen the issues I described. Although, ironically, on my first boot I had the stuck login screen as described in the thread.
(In reply to boombatower from comment #5) > I had planned to test reverting those commits, but after reading through the > thread it seems those commits simply further exposed symptoms of a larger > issue that I believe was fixed in > http://lists.freedesktop.org/archives/dri-devel/2016-January/097880.html. > > I am running a 4.4.0 kernel with that patch applied and so far have not seen > the issues I described. Although, ironically, on my first boot I had the > stuck login screen as described in the thread. Different issues.
Happens for me sometimes too. Just some minutes ago when I right clicked on the network-manager icon the whole desktop froze more or less. I could move the mouse pointer some times but nothing was clickable. Could switch to tty1 but even that was super-slow recognizing keyboard inputs. Needed to strg+alt+2xbackspace to kill X. After that everything fine. Latest openSUSE Tumbleweed x64 on AMD APU A8 7600 Which logs do you need?
(In reply to langkamp from comment #7) > Which logs do you need? Does your problem only happen with 4.4 kernels, not 4.3 or older? If so, please try reverting the changes referenced in comment 4. Otherwise, please file your own report.
(In reply to Michel Dänzer from comment #8) > (In reply to langkamp from comment #7) > > Which logs do you need? > > Does your problem only happen with 4.4 kernels, not 4.3 or older? If so, > please try reverting the changes referenced in comment 4. Otherwise, please > file your own report. Just found the culprit. At least this time it was a memory leak in a beta of kdeconnect. It ate up all my memory so the system needed to swap like crazy. It does only happen when the pc is idling for some time. And this happened with older kernel too. This morning it was the same cause (I remember kswapd was active), but I overlooked the memory consumption in top - sorry - my bad. So no problem here. Maybe its chromium related. I use firefox. I can later check if I can reproduce with chromium on 4.4, I am currently on 4.2 kernel
I have been running a patch radeon module (the reverted commits mentioned) on 4.4.0 kernel and have not seen the issues. See this for the specific revert patches applied: - https://build.opensuse.org/package/show/home:tiwai:bnc962535/radeon I'd suggest that Franklin tests it since we have spoken in IRC and see the same symtoms.
I tried again with 4.4.0 Tumbleweed on my APU system. I can not trigger the problem here. Resizing chromium and snapping to the edges etc. all works. Tried every kwin combination of EGL GLX and openGL 3.1 2.0. So APU Systems may have never been affected (or the mesa-update 11.1.1 yesterday evening helped).
| What | Removed | Added |
|---|---|---|
| Resolution | --- | MOVED |
| Status | NEW | RESOLVED |
-- 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/692.