| Summary: | xf86-video-ati-git unstable | ||
|---|---|---|---|
| Product: | xorg | Reporter: | John <john.ettedgui> |
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> |
| Status: | CLOSED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
|
Description
John
2015-03-26 06:15:36 UTC
Created attachment 114635 [details]
dmesg after the restart of Xorg
Created attachment 114636 [details]
Xorg log after Xorg restarted
Created attachment 114637 [details]
Xorg log of the previous Xorg session, including the crash information
Does the patch from bug 89681 help? If not, can you get a backtrace of the crash with gdb, and double-check that the git bisect result is correct? It really doesn't make sense for that commit to be the culprit, in particular with DRI3 disabled. I got a crash in the commit I thought was safe, so I guess it's more randomized than I thought. I was fine for about an hour and then got it... The patch did not help either, although that other bug describes pretty much the behavior I am seeing (and I'm also using KDE if that matters). I'll try to find the correct git commit and then the backtrace. Thanks! Alright so far I've had that issue as early as commit: 6c3a721cde9317233072b573f9502348dcd21b16 DRI2: Use helper functions for DRM event queue management v3. I'll keep using a build at the previous commit for a day or so before calling it good, but I've already used it for about half a day without issue. So it's been about a day and still no issue on commit c3fa22a479e61d1899fa9d327d9c4e2a7f64b0c1 DRI2: Move radeon_dri2_flip_event_handler Since the problem is not as easy to trigger as I thought, it could not be it, but for now I'd say the problem came from the following commit: 6c3a721cde9317233072b573f9502348dcd21b16 DRI2: Use helper functions for DRM event queue management v3. Next step is to get the gdb backtrace, hopefully I can manage today. Thanks Created attachment 114690 [details]
gdb trace of Xorg crashing
Alright that was easier than I expected!
Though my distribution does not provide debug packages for Xorg... for now only the ddx driver has its debug information. I hope that's enough.
Created attachment 114693 [details]
new gdb log with debug symbols
Actually rebuilding Xorg with symbols was fairly easy.
Also, if that matters, my new quick way of getting it to crash is loading XBMC and then switching from window to fullscreen till it crashes, that usually takes few tries, but I don't think it's a sure way either.
Is this still an issue with current xf86-video-ati Git master? Created attachment 114716 [details]
new gdb log with latest git
I was unable to quickly crash it with xbmc, but it did quickly crash with wine/nine, so no master is still not good.
Created attachment 114717 [details]
xorg log with latest git
Created attachment 114718 [details]
and dmesg as well
Created attachment 114720 [details] [review] Use radeon_get_pixmap_handle() in radeon_dri2_schedule_flip() Does this patch fix it? No it's the same as latest master. Please attach another gdb backtrace with the patch applied. Alright. I just have to switch room for the 2nd computer everytime so I got lazy this time :) Alright. I just have to switch room for the 2nd computer everytime so I got lazy this time :) Created attachment 114722 [details]
gdb trace of Xorg crashing with that patch
Created attachment 114741 [details]
Only enable SYNC extension fences and the Present extension along with DRI3
Does this patch avoid the problem?
So far I have not seen any crash with this patch with xbmc or wine, so this may be the correct patch, but as I don't always crash let's give it a day or so before calling it correct. Also, should I try with DRI3 or stick to DRI2 for now? So it's been a few days now, I can't say that I tried really hard to make it crash, but so far I got no crash so I think the patch is good. Now I should turn on DRI3 and see what that changes. Fix pushed to Git. Leaving this report open until you confirm it doesn't happen with DRI3 enabled. commit 98fb4199e63fedd4607cddee64bf602d6398df81 Author: Michel Dänzer <michel.daenzer@amd.com> Date: Tue Mar 31 12:25:18 2015 +0900 Only enable SYNC extension fences and the Present extension along with DRI3 This avoids some trouble with the Gallium nine state tracker, which uses the Present extension even when DRI3 is disabled. Unfortunately I had it in a few minutes once I turned DRI3 on. I will attach logs once I get gdb running. Created attachment 114846 [details]
dri3 gdb log
Created attachment 114847 [details]
dri3 xorg log
Created attachment 114848 [details]
dri3 dmesg
This appears to be the issue that I was explaining to MrCooper. Same crash on DRI3 and Nine when Alt-Tabbing. Really strange. Let me know if I can help. If you can help, feel free to :) In this case, I wonder if the issues I had with wine, and the ones with xbmc were somewhat unrelated even if the end result was the same, as I usually was able to easily trigger one but not the other at times. I've been on dri2 since my last post and didn't have any Xorg crash... so Michel's latest patch has been great for DRI2, but I am still waiting for something on DRI3. Is there anything I can add to the report to help? Thanks! Created attachment 115107 [details] [review] Handle NULL bo in can_exchange() Does this patch fix the problem with DRI3 enabled? If yes, can you try reverting patch 114741 and seeing if the problem is still reproducible with DRI3 disabled? Thank you for the patch Michel. Unfortunately I am having some unrelated computer issue right now, and may not be able to test this for a few days. I'll get back to you as soon as I can. Thanks! (In reply to Michel Dänzer from comment #31) > Created attachment 115107 [details] [review] [review] > Handle NULL bo in can_exchange() > > Does this patch fix the problem with DRI3 enabled? > > If yes, can you try reverting patch 114741 and seeing if the problem is > still reproducible with DRI3 disabled? Hi Michel. The patch has no effect for me. X still dies when I Alt-Tab out of a game. I've linked below to some debug info from Wine that may be useful. I only see these PRESENT errors right before X crashes after the alt-tab. Log: http://pastebin.com/raw.php?i=zAM4YJuA Hope this helps, sarnex (In reply to sarnex from comment #33) > The patch has no effect for me. X still dies when I Alt-Tab out of a game. Please attach a gdb backtrace of the Xorg crash with that patch applied. (In reply to Michel Dänzer from comment #34) > (In reply to sarnex from comment #33) > > The patch has no effect for me. X still dies when I Alt-Tab out of a game. > > Please attach a gdb backtrace of the Xorg crash with that patch applied. Hi Michel, I've attached the backtrace. I got it twice and the backtrace was the same. Backtrace: http://pastebin.com/raw.php?i=KyjRtCaq Hope it helps, sarnex Thanks for doing this for me Sarnex! (In reply to sarnex from comment #35) > I've attached the backtrace. I got it twice and the backtrace was the same. > > Backtrace: http://pastebin.com/raw.php?i=KyjRtCaq Thanks, but for the future, when I say 'attach' I mean using the 'Add an attachment' link on this page. AFAIR you already pastebinned the same backtrace earlier on IRC, so it's probably not related to the patch and not the same crash as John's. Please file your own report. (In reply to Michel Dänzer from comment #37) > (In reply to sarnex from comment #35) > > I've attached the backtrace. I got it twice and the backtrace was the same. > > > > Backtrace: http://pastebin.com/raw.php?i=KyjRtCaq > > Thanks, but for the future, when I say 'attach' I mean using the 'Add an > attachment' link on this page. > > AFAIR you already pastebinned the same backtrace earlier on IRC, so it's > probably not related to the patch and not the same crash as John's. Please > file your own report. Done. Sorry for the ignorance and noise. Sarnex So I just tried with the new patch and it didn't crash when I alt-tabbed, BUT it kind of froze the UI. All I found was this line in Xorg.log: "[ 364.633] (II) AIGLX: Suspending AIGLX clients for VT switch". It could be unrelated to the patch so let me try a few more things before. oh and by froze the UI, I mean I could hear the music, when I alt-tabbed I got to see my other window, I could see the mouse moving, but that was it, I could not interact with anything, switch desktops or alt-tab back. I was able to switch VTs back and forth though. Just tried with the same xf86-video-ati-git package, but disabling DRI3 in xorg.conf and this time it worked fine... so I guess it's either DRI3 or the way nine uses it. Would there be any use in a gdb trace as Xorg didn't crash this time? I'm not sure if I'd even get something... Note that the problem actually happens during a DRI2 page flip operation. Any idea whether it's the app or compositor (which one are you using, BTW?) which is falling back to DRI2? I am unable to answer that question, it's too deep for me, maybe Sarnex can. But I am using kwin_x11 as my compositor. Is there any special settings you'd like me to try there? Does the current master branch of git://people.freedesktop.org/~daenzer/xf86-video-ati help for this? This branch is partially better, so we have some progress! The good part is it doesn't seem to crash with your new changes. I have not tried it extensively, but with the standard master I usually crash X at my first-tab. The bad part is I don't really get a correct alt-tab behavior, meaning if I tab out of the game I expect to only see the other window (konsole in my case), but with this branch it keeps flipping back and forth between the 2. I can alt-tab fine between chromium windows though. Oh with this branch and dri3 on, I get visual corruptions inside of XBMC/Kodi, but only in the menus, not while playing a movie. Switching dri3 off removes that problem. I've updated that branch again, does it work better now? I just tried and the behavior is the same. Something I have noticed though, is that I can alt-tab fine during the in-game-loading screen, but past it I get the issue... No idea what this means but it might help. Is there any native DRI3 app you think I should try, to see if my issue at this point is not in nine instead of the ddx? Thank you for keeping at this! (In reply to John from comment #48) > Is there any native DRI3 app you think I should try, to see if my issue at > this point is not in nine instead of the ddx? Apps don't use DRI3 or DRI2 directly. If you enable DRI3 for the Mesa build, OpenGL apps should use DRI3. With current Mesa Git, the debugging output enabled by LIBGL_DEBUG=verbose explicitly says whether it's using DRI3 or DRI2. I don't have nine set up yet, but I was able to reproduce issues when running kwin with DRI3 and xbmc with DRI2 (via LIBGL_DRI3_DISABLE=1) and switching between fullscreen and windowed mode in xbmc, which those changes fix for me. Can you confirm that? (In reply to Michel Dänzer from comment #49) > Apps don't use DRI3 or DRI2 directly. If you enable DRI3 for the Mesa build, > OpenGL apps should use DRI3. With current Mesa Git, the debugging output > enabled by LIBGL_DEBUG=verbose explicitly says whether it's using DRI3 or > DRI2. > Cool! > I don't have nine set up yet, but I was able to reproduce issues when > running kwin with DRI3 and xbmc with DRI2 (via LIBGL_DRI3_DISABLE=1) and > switching between fullscreen and windowed mode in xbmc, which those changes > fix for me. Can you confirm that? Hmmm, I had issues with XBMC going fullscree to window a while back, but you fixed them, so I am not sure what you are asking me to confirm here. I just tried with dri3 enabled and LIBGL_DRI3_DISABLE=1 and kodi behaves fine, or did you want me to switch to the standard branch before testing this? (In reply to John from comment #50) > (In reply to Michel Dänzer from comment #49) > > With current Mesa Git, the debugging output enabled by LIBGL_DEBUG=verbose > > explicitly says whether it's using DRI3 or DRI2. > > > Cool! Does it say DRI3 or DRI2 for you? Branch updated again with another attempt, does that work better? It said what I expected (dri3 when not using the disable command option, dri2 when using it). I'll try your new branch and report a bit later. Thanks! It's the same behavior with the latest pull from your branch. So I had not tested this in a while, but it seems to be fixed now. I just did a quick alt-tab test with Heroes Of the Storm and it looked fine. I have no clue what fixed it, since then there's been changes in the DDX, Mesa and Linux.. but maybe it is time to close this. (In reply to John from comment #54) > So I had not tested this in a while, but it seems to be fixed now. > I just did a quick alt-tab test with Heroes Of the Storm and it looked fine. Great, resolving this report as fixed, thanks for the update. Please reopen this report if the problem occurs again. BTW, you did test with DRI3 enabled, right? :) I believe so yes :) |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.