Op 23-09-14 om 07:35 schreef Ben Skeggs: > On Tue, Sep 23, 2014 at 2:23 AM, Ted Percival <ted at tedp.id.au> wrote: >> On 09/22/2014 03:08 AM, Maarten Lankhorst wrote: >>> This fixes a regression introduced by "drm/nouveau: rework to new fence >>> interface" >>> (commit 29ba89b2371d466). >>> >>> The fence sequence should not be reset after creation, the old value is >>> used instead. >>> On destruction the final value is written, to prevent another source of >>> accidental >>> wraparound in case of a channel being destroyed after a hang, and >>> unblocking any other >>> channel that may wait on the about-to-be-deleted channel to signal. >>> >>> I'm nothing if not optimistic about any hope of recovery from that. ;-) >>> >>> Reported-by: Ted Percival <ted at tedp.id.au> >>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> > Acked-by: Ben Skeggs <bskeggs at redhat.com> > > I'm still seeing issues with suspend, even with this patch, and the > one you pastebinned recently. > Annoying, and I'm out of ideas. The pastebinned patch is posted to dri-devel as: [PATCH 2/8] drm/nouveau: specify if interruptible wait is desired in nouveau_fence_sync.
Could you bisect to where the suspend issues started? With this patch applied after "drm/nouveau: rework to new fence interface", and the other patch applied after "drm/nouveau: use shared fences for readable objects" ~Maarten
