From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org
Subject: [Bug 67878] New: Hardware freeze after resume from suspend
Date: Wed, 07 Aug 2013 21:48:12 +0000
Message-ID:
Priority
medium
Bug ID
67878
Assignee
nouveau@lists.freedesktop.org
Summary
Hardware freeze after resume from suspend
QA Contact
xorg-team@lists.x.org
Severity
critical
Classification
Unclassified
OS
Linux (All)
Reporter
bgamari@gmail.com
Hardware
x86-64 (AMD64)
Status
NEW
Version
unspecified
Component
Driver/nouveau
Product
xorg
Created attachment 83798 [details]
dmesg output from boot to attempted resume
On a Dell Latitude E6400 with nVidia G98M and 3.10 kernel I find that the
machine will reproducibly resume from suspend with a non-responsive X session.
Given attempts I can eventually get to a somewhat functional VT. dmesg output
attached.
lspci gives the following device details,
01:00.0 VGA compatible controller: NVIDIA Corporation G98M [Quadro NVS 160M]
(rev a1) (prog-if 00 [VGA controller])
Subsystem: Dell Device 0233
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at f5000000 (32-bit, non-prefetchable) [size=16M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
Memory at f2000000 (64-bit, non-prefetchable) [size=32M]
I/O ports at df00 [size=128]
[virtual] Expansion ROM at f4000000 [disabled] [size=128K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [128] Power Budgeting <?>
Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
Kernel driver in use: nouveau
It seems that Bug #62835 (https://bugs.freedesktop.org/show_bug.cgi?id=62835) might be related.
This thread might also be related http://www.spinics.net/lists/dri-devel/msg32782.html.
Created attachment 83799 [details]
End of log from resume with debug=trace
It seems 3D/compositing might be to blame here; suspending while running metacity seems to resume correctly.
The same issue can be reproduced with 3.8. Interestingly, 3.5 seems to work correctly, even with compiz.
From discussions with xexaxo in #nouveau, it seems that this might be a similar regression to what happened in 3.8 (described in bug #59057). My plan is as follows, 1) Verify that 3.8.11 works 1.1) If not, verify that 3.8.1 works and bisect to find the broken release 1.2) If so, check whether 3.9 works 2) Bisect backwards from the first broken release to 3.8.11 (or whichever release was tested to work)
The 3.8.11 kernel fails in the same way that 3.10 does, trying 3.8.1 next.
Rereading bugs #59057 and #62835, it's not entirely clear whether the bug was actually ever fixed; it may be that the reporter simply worked around it. Comment #33 of Bug #59057 (https://bugs.freedesktop.org/show_bug.cgi?id=59057#c33) actually refers to commit e5a58edc94a20a7ef4b7db67c166c4ca0588bad0 (46c13c131d3b73080aa0f50f45e834a9ab3c0e71 in Linus's tree) as working. Going to test this and surrounding commits to verify this.
Tested 46c13c131d3b73080aa0f50f45e834a9ab3c0e71. Things appear to fail in a similar way to the resume failure upon starting compiz.
One factor that I've neglected to mention thusfar is that I've been using my
own mesa build in the above tests,
$ glxinfo
...
OpenGL version string: 2.1 Mesa 9.2.0-devel (git-5a7bdd4)
After reverting to Ubuntu's packaged mesa,
$ glxinfo
...
OpenGL version string: 2.1 Mesa 9.1.4
Resume appears to work as expected.
The mesa tests mentioned above were conducted on a 3.10 kernel. In the mesa 9.1
case there is nothing interesting spit out by nouveau to dmesg. Only a few
status messages,
[ 312.871019] nouveau [ DRM] suspending fbcon...
[ 312.871023] nouveau [ DRM] suspending display...
[ 312.871049] nouveau [ DRM] unpinning framebuffer(s)...
[ 312.871108] nouveau [ DRM] evicting buffers...
[ 313.133858] nouveau [ DRM] waiting for kernel channels to go
idle...
[ 313.133883] nouveau [ DRM] suspending client object trees...
[ 313.134682] nouveau [ DRM] suspending kernel object tree...
...
[ 317.178155] nouveau [ DRM] re-enabling device...
[ 317.178170] nouveau [ DRM] resuming kernel object tree...
[ 317.178176] nouveau [ VBIOS][0000:01:00.0] running init tables
[ 317.287651] serial 00:08: activated
[ 317.357172] nouveau [ DRM] resuming client object trees...
[ 317.357691] nouveau [ DRM] resuming display...
I can confirm that mesa 9.1.4 on a 3.10 kernel can successfully resume, even while running glxgears on compiz. The messages mentioned in Comment 12 are the only things produced by nouveau in dmesg.
Confirmed that 72916698b056d0559263e84372bb45cd83a1c2c2 is bad. Unfortunately
this is a merge base. Here is the bisection log,
git bisect start
# bad: [5a7bdd4b4173958c53109517b7c95f1039623e7e] docs: Add items for GL4.4
git bisect bad 5a7bdd4b4173958c53109517b7c95f1039623e7e
# good: [e64febb4b71475b35765f0dc168df22655444a7f] docs: 9.1.4 release
notes
git bisect good e64febb4b71475b35765f0dc168df22655444a7f
# bad: [72916698b056d0559263e84372bb45cd83a1c2c2] r600g: fix segfault with
old kernel
git bisect bad 72916698b056d0559263e84372bb45cd83a1c2c2
Unfortunately I'm now having trouble reproducing the working conditions with mesa 9.1.4. Returning to mapping out kernel version. It appears that 3.6 works correctly.
Confirmed that a clean 3.8 build exhibits the issue. Starting a bisection between 3.7 and 3.8.
Linux commit 992956189de58cae9f2be40585bc25105cd7c5ad is bad.
(In reply to comment #18) > Linux commit 992956189de58cae9f2be40585bc25105cd7c5ad is bad. That seems thoroughly unlikely. commit 992956189de58cae9f2be40585bc25105cd7c5ad Author: Eric W. Biederman <ebiederm@xmission.com> Date: Mon Dec 17 17:19:36 2012 -0800 efi: Fix the build with user namespaces enabled. This doesn't apply to your situation on many levels... this is a build fix... to efi vars... I bet if you checkout to 992956189de58cae9f2be40585bc25105cd7c5ad^ then you will still have a bad kernel. You should probably redo the bisect, but look at the bisect log (git bisect log) and keep all your "bad" commits, since they are likely indeed bad. But you may have been a bit too eager in calling out the "good" kernels. (See git help bisect for how to start with a bunch of bad commits.) While you're at it, you may want to re-test whether 3.7 really is good.
@Ilia, I should have been more specific. These next few comments are largely just notes recording the state of my bisection. By "bad" I mean that I have tested the commit and it exhibits the issue, not that it is the first bad commit. Currently I have around 10 more bisection steps to go before the culprit is hopefully identified.
Linux commit 2b8318881ddbcb67c5e8d2178b42284749442222 appears to work.
Linux kernel 3c2e81ef344a90bb0a39d84af6878b4aeff568a2 exhibits the issue.
640631d04cd2cfbb4792d6a8fc5fcab14ee273a5 is bad. 9fabd4eedeb904173d05cb1ced3c3e6b9d2e8137 is good.
74b6685089591fa275929109f7b839bf386890a0 is good. bd3b49f25a3eae2d91432247b7565489120b6bcf is bad.
2d8b9ccbcee694c9ce681ec596df642e52ddcb15 is bad. b6e4ad200a726a32c7083f491383713bc8680f86 is good.
47057302f075578618ea36fc3c4c97a5a6f97f00 is good. 4f6029da58ba9204c98e33f4f3737fe085c87a6f is bad.
647bf61d0399515c526c125450cadaade79b1988 is good. f9887d091149406de5c8b388f7e0bb6932dd621b is good.