Bug 85866

Summary: Desktop environment becomes unresponsive, but mouse can move after distro update
Product: Mesa Reporter: boombatower <jimmy>
Component: Drivers/Gallium/radeonsiAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED DUPLICATE QA Contact:
Severity: major    
Priority: medium    
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: xorg.log from crash.
xorg.log closed and dropped to tty
glxinfo
dmesg after crash

Description boombatower 2014-11-04 16:35:10 UTC
Created attachment 108908 [details]
xorg.log from crash.

Seems to happen at random intervals after I updated. Some as short as 2 minutes other after an hour or two.

Running openSUSE 13.2 (3.16.6-2-desktop kernel). Radeon HD 7970 card. Monitors has made a difference in the past, so: 2 x 24" (1920x1200) + 1 x 30" (2560x1600). Have not had an issues prior to this on previous driver.

I'll add more detail if I run into it. Let me know if anything I can include in report to help.
Comment 1 boombatower 2014-11-04 17:17:50 UTC
Created attachment 108910 [details]
xorg.log closed and dropped to tty
Comment 2 Michel Dänzer 2014-11-05 06:07:25 UTC
Please attach the output of dmesg (preferably from after the problem occurred) and glxinfo.

What versions of the kernel and Mesa were you using before the update?
Comment 3 boombatower 2014-11-06 21:55:12 UTC
Created attachment 109063 [details]
glxinfo
Comment 4 boombatower 2014-11-06 21:55:43 UTC
Updated from openSUSE 13.1 (http://download.opensuse.org/distribution/13.1/repo/oss/suse/x86_64/) which was on kernel 3.11.6 and mesa 9.2.2.

I'll try and get dmesg next time it craps.
Comment 5 boombatower 2014-11-06 23:02:24 UTC
Alright, I am unable to get a dmesg log after crashes since my system is completely unresponsive...even to ssh from another machine.

I setup a watch -n 10 of dmesg to dump to file so I'll be able to grab it on reboot.

I have identified 3 district crash states. All three start the same way, everything freezes except mouse, then:

- screen will flash once or twice and drop to black screen
- screen will flash once or twice and drop to tty7 (instead of 8) which has boot log with last message saying (starting X)
- third state it will do the second one, but allow I can switch to another tty screen as the machine is responsive after that, just x is dead.

The Xorg log differs between the first two states (see attachments): "xorg.log from crash" (being state one), and "xorg.log closed and dropped to tty" (being state two).

I have seen the machine be stable for 12+ hours and then die while locked and displays off, other times it dies after 3-4 min, and others a couple hours. I cannot find a correlation between what I am doing (or applications open) when it dies (and the example of being entirely away seems to support that).

Is there some reasonable instructions for performing a git bisect? I am familiar with all sorts of development, but not a kernel developer. Is it safe to assume this is in the driver and not Xorg?
Comment 6 Aaron B 2014-11-07 02:34:08 UTC
Probably a duplicate of Bug 85647.
Comment 7 Michel Dänzer 2014-11-07 08:44:35 UTC
(In reply to boombatower from comment #5)
> Is there some reasonable instructions for performing a git bisect? I am
> familiar with all sorts of development, but not a kernel developer. Is it
> safe to assume this is in the driver and not Xorg?

Yes, but it might be in the kernel or in Mesa. So if you can try the previous version of the kernel or Mesa again first, that would help identify which it is.

Answering your question from IRC: Don't restrict git bisect to a subdirectory of the kernel or Mesa tree, unless you're 100% sure the problem was caused in there, or the bisection might give the wrong result.

Also, only declare a commit as good once you're 100% (or as close to that as reasonably possible) sure that it's not affected by the problem, or again the bisection might give the wrong result. Take your time to enjoy the commits where the problem doesn't occur. :)
Comment 8 boombatower 2014-11-10 02:36:44 UTC
Created attachment 109181 [details]
dmesg after crash

Captured dmesg after crash using technique I mentioned

watch -n 10 "dmesg --color=never --read-clear >> /home/boombatower/dmesg_cron.log"

Hopefully it is illuminating. I will try out the patch from other bug and see if it fixes the problem for me as it seems to have done for others.
Comment 9 boombatower 2014-11-10 03:59:56 UTC
Running patched Mesa! Ironically it actually crashed no less than 20 seconds after I installed patched version.

For other openSUSE 13.2 users:
  https://build.opensuse.org/package/show/home:boombatower:branches:openSUSE:13.2/Mesa
Comment 10 boombatower 2014-11-10 09:38:54 UTC
It is looking quite promising. I have done done just about everything and not freezing. I'll report back in a few days.
Comment 11 boombatower 2014-11-13 05:01:30 UTC
Definitely seems like the solution

*** This bug has been marked as a duplicate of bug 85647 ***

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.