All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Michael Marineau <mike@marineau.org>, dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org, Ben Skeggs <bskeggs@redhat.com>
Subject: Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects
Date: Wed, 19 Nov 2014 09:10:45 +0100	[thread overview]
Message-ID: <546C5085.1020300@canonical.com> (raw)
In-Reply-To: <CAHW-aUcEipi+NeU3wapLABV41Sud7Qy_=EYXCei9Dmf18SxuZA@mail.gmail.com>

Hey,

On 19-11-14 07:43, Michael Marineau wrote:
> On 3.18-rc kernel's I have been intermittently experiencing GPU
> lockups shortly after startup, accompanied with one or both of the
> following errors:
> 
> nouveau E[   PFIFO][0000:01:00.0] read fault at 0x000734a000 [PTE]
> from PBDMA0/HOST_CPU on channel 0x007faa3000 [unknown]
> nouveau E[     DRM] GPU lockup - switching to software fbcon
> 
> I was able to trace the issue with bisect to commit
> 809e9447b92ffe1346b2d6ec390e212d5307f61c "drm/nouveau: use shared
> fences for readable objects". The lockups appear to have cleared up
> since reverting that and a few related followup commits:
> 
> 809e9447: "drm/nouveau: use shared fences for readable objects"
> 055dffdf: "drm/nouveau: bump driver patchlevel to 1.2.1"
> e3be4c23: "drm/nouveau: specify if interruptible wait is desired in
> nouveau_fence_sync"
> 15a996bb: "drm/nouveau: assign fence_chan->name correctly"

Weird. I'm not sure yet what causes it.

http://cgit.freedesktop.org/~mlankhorst/linux/commit/?h=fixed-fences-for-bisect&id=86be4f216bbb9ea3339843a5658d4c21162c7ee2

On the EDITED patch from fixed-fences-for-bisect, can you do the following:

In nouveau/nv84_fence.c function nv84_fence_context_new, remove

fctx->base.sequence = nv84_fence_read(chan);

and add back

nouveau_bo_wr32(priv->bo, chan->chid * 16/4, 0x00000000);

If that fails you should compile your kernel with trace events, to get some debugging info from the fences. I'll post debugging info if this does not fix it.

~Maarten
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Michael Marineau <mike@marineau.org>, dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org, Ben Skeggs <bskeggs@redhat.com>,
	David Airlie <airlied@linux.ie>
Subject: Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects
Date: Wed, 19 Nov 2014 09:10:45 +0100	[thread overview]
Message-ID: <546C5085.1020300@canonical.com> (raw)
In-Reply-To: <CAHW-aUcEipi+NeU3wapLABV41Sud7Qy_=EYXCei9Dmf18SxuZA@mail.gmail.com>

Hey,

On 19-11-14 07:43, Michael Marineau wrote:
> On 3.18-rc kernel's I have been intermittently experiencing GPU
> lockups shortly after startup, accompanied with one or both of the
> following errors:
> 
> nouveau E[   PFIFO][0000:01:00.0] read fault at 0x000734a000 [PTE]
> from PBDMA0/HOST_CPU on channel 0x007faa3000 [unknown]
> nouveau E[     DRM] GPU lockup - switching to software fbcon
> 
> I was able to trace the issue with bisect to commit
> 809e9447b92ffe1346b2d6ec390e212d5307f61c "drm/nouveau: use shared
> fences for readable objects". The lockups appear to have cleared up
> since reverting that and a few related followup commits:
> 
> 809e9447: "drm/nouveau: use shared fences for readable objects"
> 055dffdf: "drm/nouveau: bump driver patchlevel to 1.2.1"
> e3be4c23: "drm/nouveau: specify if interruptible wait is desired in
> nouveau_fence_sync"
> 15a996bb: "drm/nouveau: assign fence_chan->name correctly"

Weird. I'm not sure yet what causes it.

http://cgit.freedesktop.org/~mlankhorst/linux/commit/?h=fixed-fences-for-bisect&id=86be4f216bbb9ea3339843a5658d4c21162c7ee2

On the EDITED patch from fixed-fences-for-bisect, can you do the following:

In nouveau/nv84_fence.c function nv84_fence_context_new, remove

fctx->base.sequence = nv84_fence_read(chan);

and add back

nouveau_bo_wr32(priv->bo, chan->chid * 16/4, 0x00000000);

If that fails you should compile your kernel with trace events, to get some debugging info from the fences. I'll post debugging info if this does not fix it.

~Maarten

  reply	other threads:[~2014-11-19  8:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-19  6:43 3.18-rc regression: drm/nouveau: use shared fences for readable objects Michael Marineau
2014-11-19  8:10 ` Maarten Lankhorst [this message]
2014-11-19  8:10   ` Maarten Lankhorst
2014-11-19 15:18   ` Tobias Klausmann
2014-11-19 23:08   ` Tobias Klausmann
2014-11-20  8:41     ` Maarten Lankhorst
2014-11-20  8:41       ` Maarten Lankhorst
2014-11-20  4:06   ` Michael Marineau
2014-11-20  8:53     ` Maarten Lankhorst
2014-11-20  8:53       ` Maarten Lankhorst
2014-11-21 19:13       ` Michael Marineau
2014-11-22  0:19       ` Michael Marineau
2014-11-22 16:56         ` Maarten Lankhorst
2014-11-22 16:56           ` Maarten Lankhorst
2014-11-22 19:45           ` Michael Marineau
2014-11-22 20:16             ` Michael Marineau
2014-11-25  7:43               ` Maarten Lankhorst
2014-11-25  7:43                 ` Maarten Lankhorst
2014-11-26 20:29                 ` Michael Marineau
2014-11-27  1:18                   ` Tobias Klausmann
2014-11-27  8:33                     ` Maarten Lankhorst
2014-11-27  8:33                       ` Maarten Lankhorst
2014-11-30 21:10                       ` Michael Marineau
  -- strict thread matches above, loose matches on Subject: below --
2014-11-29  0:51 Ian Kumlien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=546C5085.1020300@canonical.com \
    --to=maarten.lankhorst@canonical.com \
    --cc=bskeggs@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike@marineau.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.