Eric F
2013-Jun-30 17:42 UTC
[Nouveau] IMPORTANT : Regression since kernel > 3.4 as regards suspend to RAM while using 3D accel
Hello, Been wondering why I could never resume from s2r. That's because I always use 3D accel (compiz, cairo-dock). I have tested each Arch kernel releases, hoping each time to get s2r to work. Tired of this, I decided to use 3.4 LTS... 3.4.50 ... And guess what ? I could resume from suspend to RAM 100% of the time !!! I know it may be a hard work for you, but suspend to RAM while using 3D accel only works with this kernel (and maybe 3.4.51, will give a try). Suspend to RAM is important for battery saving for laptops. I use GT555M nvc3. Best regards, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20130630/dc0ad45a/attachment.html>
Ilia Mirkin
2013-Jun-30 18:16 UTC
[Nouveau] IMPORTANT : Regression since kernel > 3.4 as regards suspend to RAM while using 3D accel
On Sun, Jun 30, 2013 at 1:42 PM, Eric F <3rik.gm at gmail.com> wrote:> Hello, > > Been wondering why I could never resume from s2r. That's because I always > use 3D accel (compiz, cairo-dock). I have tested each Arch kernel releases, > hoping each time to get s2r to work. > > Tired of this, I decided to use 3.4 LTS... 3.4.50 > ... And guess what ? I could resume from suspend to RAM 100% of the time !!! > > I know it may be a hard work for you, but suspend to RAM while using 3D > accel only works with this kernel (and maybe 3.4.51, will give a try). > > Suspend to RAM is important for battery saving for laptops. > I use GT555M nvc3.It appears that some of the information was left out above from an investigation session we had over IRC. Resume actually works fine (from a strict kernel standpoint). However some (all?) of the channels that were active at the time of the suspend are now hung, and there are "failing to idle channel" messages for compiz and cairo-dock when X is killed (and X has the appearance of being hung, since compiz has hung): http://ix.io/6qt (hm, also note that the channel values are identical for compiz and cairo-dock, not sure if that's expected). If compiz and cairo-dock aren't running, then the resume works fine. It seems like some fence work went into v3.5 (e.g. 5e120f6e4b3f35b741c5445dfc755f50128c3c44, others), which could be related. Other invasive changes like c420b2dc8dc3cdd507214f4df5c5f96f08812cbe which affect FIFO handling could be related as well. My guess is that some semaphore write never happens, and the channels are forever stuck waiting for some semaphore. -ilia
Eric F
2013-Jul-06 07:27 UTC
[Nouveau] IMPORTANT : Regression since kernel > 3.4 as regards suspend to RAM while using 3D accel
Hello, After bisection I found the first bad commit : 5e120f6e4b3f35b741c5445dfc755f50128c3c44 is the first bad commit commit 5e120f6e4b3f35b741c5445dfc755f50128c3c44 Author: Ben Skeggs <bskeggs at redhat.com> Date: Mon Apr 30 13:55:29 2012 +1000 drm/nouveau/fence: convert to exec engine, and improve channel sync Now have a somewhat simpler semaphore sync implementation for nv17:nv84, and a switched to using semaphores as fences on nv84+ and making use of the hardware's >= acquire operation. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> :040000 040000 8f2ca4ddf4969c75f688a96fdb152e449fda4852 da67a1bd8d608577e659a26715cf8af3644d8efe M drivers bad kernel name : 3.4.0-1-ARCH-00591-g5e120f6-dirty Strangely, when I git checkout with the bad commit, it says : "HEAD is now at 5e120f6... drm/nouveau/fence: convert to exec engine, and improve channel sync" But I checked, this commit 5e120f6e4b3f35b741c5445dfc755f50128c3c44 is the first bad one. Thanks for your future help, Eric 2013/6/30 Eric F <3rik.gm at gmail.com>> Hello, > > Been wondering why I could never resume from s2r. That's because I always > use 3D accel (compiz, cairo-dock). I have tested each Arch kernel releases, > hoping each time to get s2r to work. > > Tired of this, I decided to use 3.4 LTS... 3.4.50 > ... And guess what ? I could resume from suspend to RAM 100% of the time > !!! > > I know it may be a hard work for you, but suspend to RAM while using 3D > accel only works with this kernel (and maybe 3.4.51, will give a try). > > Suspend to RAM is important for battery saving for laptops. > I use GT555M nvc3. > > Best regards, > > Eric >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20130706/a9fdbb88/attachment.html>
Ilia Mirkin
2013-Jul-06 20:57 UTC
[Nouveau] IMPORTANT : Regression since kernel > 3.4 as regards suspend to RAM while using 3D accel
On Sat, Jul 6, 2013 at 3:27 AM, Eric F <3rik.gm at gmail.com> wrote:> Hello, > > After bisection I found the first bad commit : > > 5e120f6e4b3f35b741c5445dfc755f50128c3c44 is the first bad commit > commit 5e120f6e4b3f35b741c5445dfc755f50128c3c44 > Author: Ben Skeggs <bskeggs at redhat.com> > Date: Mon Apr 30 13:55:29 2012 +1000 > > drm/nouveau/fence: convert to exec engine, and improve channel sync > > Now have a somewhat simpler semaphore sync implementation for nv17:nv84, > and a switched to using semaphores as fences on nv84+ and making use of > the hardware's >= acquire operation. > > Signed-off-by: Ben Skeggs <bskeggs at redhat.com> > > :040000 040000 8f2ca4ddf4969c75f688a96fdb152e449fda4852 > da67a1bd8d608577e659a26715cf8af3644d8efe M drivers > > bad kernel name : 3.4.0-1-ARCH-00591-g5e120f6-dirty > > Strangely, when I git checkout with the bad commit, it says : > "HEAD is now at 5e120f6... drm/nouveau/fence: convert to exec engine, and > improve channel sync" > > But I checked, this commit 5e120f6e4b3f35b741c5445dfc755f50128c3c44 is the > first bad one.It looks as though there were a few follow-on fixes to the nvc0 fence code, at least one of them directly suspend-related. What if you try them together, i.e. something like git branch testing 5e120f6e4 git checkout testing git cherry-pick 906c033e2 git cherry-pick d6ba6d215 and then test that kernel? Do you still see the issues? If so, then the fixes were incomplete. If the issues go away, then some second issue was introduced at some later point. -ilia
Seemingly Similar Threads
- IMPORTANT : Regression since kernel > 3.4 as regards suspend to RAM while using 3D accel
- Tessellation shaders get MEM_OUT_OF_BOUNDS errors / missing triangles
- [Bug 50121] New: [Regression] NV34 Fx5200 fails to resume with commit 5d720f2450
- [Bug 53101] New: Fedora 17 "PFIFO - playlist update failed" on boot
- Tessellation shaders get MEM_OUT_OF_BOUNDS errors / missing triangles