Nouveau - Jun 2013 - 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>

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

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>

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