| Bug ID | 99236 |
|---|---|
| Summary | System (seems to) completely freezes when interacting with ja= va swing applications. |
| Product | DRI |
| Version | DRI git |
| Hardware | x86 (IA32) |
| OS | Linux (All) |
| Status | NEW |
| Severity | major |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | tmp6154@yandex.ru |
I'm not completely certain whether it's related to AMD GPU dri= ver or not, but it's rather strange issue that I can get stable reproduce for. I'm running a Gentoo system with AMD Radeon RX 480, with git AMD GPU driver= and git version of mesa. When interacting with scrollable JTextAreas in Java Sw= ing application, I get a stably reproducible issue (100%). Since this affects multiple java swing applications (e.g. eclipse), including the program I'm developing at the time, I can attempt to put together a reproducer java app= , if that's needed. For first 2-3 seconds, mouse cursor moves jittery, then it stops to move at= all and display keeps displaying same frozen state. Nothing appears to work, including Ctrl+Alt+F1, etc. But despite machine looking completely locked u= p, in fact, it's not. I can ssh into it and issue reboot command. During that time, display doesn't shows any signs of life until the moment when machine reboots (but I can hear KDE shutdown sound). This occurs only under JRE8, both icedtea and oracle variants. Under JRE7 i= ssue doesn't trigger. If memory serves, JRE8 brought improvements to hardware-accelerated GUI rendering. This is especially strange, since Swing= GUI framework renders it's own GUI widgets. Considering that even Ctrl+Alt+F1 doesn't work, I suppose problem happens on kernel level, possibly in AMD GPU driver.
| What | Removed | Added |
|---|---|---|
| Summary | System (seems to) completely freezes when interacting with j= ava swing applications. | System (seems to) completely freeze when interacting with ja= va swing applications. |
| What | Removed | Added |
|---|---|---|
| Hardware | x86 (IA32) | x86-64 (AMD64) |
Created attachm=
ent 128721 [details]
dmesg output from faulty session
Here's my dmesg. From these lines:
[ 675.891897] amdgpu 0000:01:00.0: GPU fault detected: 147 0x00004802
[ 675.891899] amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR=20=
=20
0x00000000
[ 675.891900] amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x02048002
[ 675.891902] VM fault (0x02, vmid 1) at page 0, read from 'TC4' (0x544334=
00)
(72)
[ 675.892003] amdgpu 0000:01:00.0: GPU fault detected: 147 0x00004802
[ 675.892004] amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR=20=
=20
0x00000000
[ 675.892006] amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x02048002
It's obvious that something went terribly wrong inside AMD GPU.
Created attachmen=
t 128722 [details]
Xorg.0.log from faulty session
This is Xorg log. It doesn't seem that X noticed the fault at all. Moreover,
with `ps -e` over ssh I can see X process and all other GUI programs still
running just fine. So it seems that only GPU driver has failed, other stuff
doesn't seem to be affected.
Created attach=
ment 128723 [details]
Java Swing reproducer application
Here's Java sources of a reproducer mini-application for the issue. Running=
it
and pressing the button results for me in AMD GPU fault, similar to ones I'=
ve
already attached logs for. Works in 100% cases (2/2) if run under JRE8.
| What | Removed | Added |
|---|---|---|
| Component | DRM/AMDgpu | Drivers/Gallium/radeonsi |
| Product | DRI | Mesa |
| QA Contact | dri-devel@lists.freedesktop.org | |
| Version | DRI git | unspecified |
It's most likely a Mesa driver issue. Can you try running Xephyr something like this: GALLIUM_DDEBUG=3D"pipelined 2000" Xephyr :99 -glamor -screen 102= 4x768 and then run the reproducer app with DISPLAY=3D:99 . After the hang, a file should appear in ~/ddebug_dumps/. Please attach that file here.
Yes, no problem. However, my XOrg was compiled without Xephyr,= so I rebuilt it. Unfortunately, I've decided to update mesa to latest commit as well, but it seems that one of recent commits breaks everything (I get an unusable deskt= op which looks white and can see gray outlines of KDE taskbar, mouse cursor and login password box cursor). So, I had to temporarily revert to 13.0.3 mesa.= But there some useful info. First, on 13.0.3 I cannot reproduce fault with reproducer app. Second, reproducer app looks same under 13.0.3 both on Java= 7 and Java 8. I found it strange that under Java 7 swing app looks like it sh= ould (Metal look & feel) and under Java 8 it looked different (white buttons= instead of default metallic). But it appears that this was just a rendering artefac= t. I will try to get back to working mesa commit and reproduce the problem with Xephyr now.
Created attachment 128804 [details]
Comparison of reproducer app under java 8 and java 7 with git mesa
Checked out two days old revision of mesa. Attached screenshot of what I me=
ant
about reproducer app.
Will try running it in Xephyr.
Attempted to run reproducer app in Xephyr. It appears exactly = like on host with Java 8 in attached screenshot. I.e. with white button. However, clicking the button just adds the text into textarea, as programmed, while doing this directly on host's Xorg hangs the system. I think it's possible that app alone is not enough to reproduce the issue, = KDE and it's window manager might be at play here, too. But it's strange, becau= se this seems to occur on adding text to JTextArea, which is rendered by Swing= and should be least affected by WM and DE (except for window border, which is absent in Xephyr, since no WM runs there). But if that's mesa-only bug, shouldn't Ctrl+Alt+F1 work? Here GPU appears to have stopped output completely (most likely, fullscreen tty opens, but GPU shows same picture as on moment of freeze).
Any chance you can bisect Mesa? (In reply to Vitaly Ostrosablin from comment #8) > But if that's mesa-only bug, shouldn't Ctrl+Alt+= F1 work? Here GPU appears to > have stopped output completely (most likely, fullscreen tty opens, but= GPU > shows same picture as on moment of freeze). A GPU hang tends to cause the Xorg process to hang as well, which prevents = VT switching from working.
Yes, will try to bisect mesa. Unfortunately, in looks like I'l= l have to do that manually, since Gentoo doesn't seem to have bisect tools for portage. So fa= r I can say following initial info: 1) Bug wasn't introduced at least until November 30, 2016. 2) White button artefact doesn't seem to be related to hang. In Nov 30 comm= it button is white, but pressing it doesn't hang the system. 3) On Dec 20, 2016, hang was already introduced.
Further narrowed date range: between Dec 6 and Dec 12.
Looks like it broke on Dec 07. There was a lot of radeonsi-rel= ated commits, but I had difficulty compiling a working mesa out of them. On Dec 6, there was = no bug. No commits on Dec 7 seems to work, they're segfaulting. Then later on = Dec 8, mesa can be compiled an started, but issue is already present.
Vitaly - commit id's please. Dates are largely meaningless - t= he default date shown by git has little to do with when the commit made it into a particular tree, even with mesa's rebase policy.
85a3057f651a1c56348f1af18343d9cc0a5c93f3 used to work fine. After that, in at most 3 commits to future from this point something was br= oken and mesa didn't run (checked on 4c8c13b3568c82e503a10ddcb846b4c96261ec4c). One of commits further in history I tried was 132b69c4edb824c70c98f8937c63e49b04f3adff, which didn't work as well. After it, there was a huge batch of radeonsi commits. c7dc1b010ae581f532240b661cb3d1c82e117e7e is not runnable, too. bd56de88dfb192310f3432a3c0e0ddc3469c6d55 is runnable (probably, was fixed somewhere earlier) and java reproducer app hangs system there.
For any commits that you can't test, run git bisect skip Eventually, git bisect will either show the commit which introduced the problem, or the minimal set of candidates.
Have successfully updated to latest mesa. Seems like issue was= fixed recently.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |
(In reply to Vitaly Ostrosablin from comment #16) > Have successfully updated to latest mesa. Seems = like issue was fixed > recently.