All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
To: Maarten Lankhorst <maarten.lankhorst@canonical.com>,
	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 16:18:58 +0100	[thread overview]
Message-ID: <546CB4E2.3010707@mni.thm.de> (raw)
In-Reply-To: <546C5085.1020300@canonical.com>

On 19.11.2014 09:10, Maarten Lankhorst wrote:
> 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

Hey,
as mentioned in IRC the new fencing hangs my GPU for a while as well (nve7).
Bisected back to  86be4f216bbb9ea3339843a5658d4c21162c7ee2
, EDITED

from the fixed-fences-for-bisect branch mentioned above.

Original bisect on linus brach brought me to:
29ba89b2371d466ca68973525816cf10debc2655
drm/nouveau: rework to new fence interface

Michael if you are going to bisect the "fixed-fences-for-bisect" branch, 
maybe take a closer look if you come anywhere near that commit, if that 
does or does not trigger the GPU hangs for you!

Tobias

  reply	other threads:[~2014-11-19 15:18 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
2014-11-19  8:10   ` Maarten Lankhorst
2014-11-19 15:18   ` Tobias Klausmann [this message]
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=546CB4E2.3010707@mni.thm.de \
    --to=tobias.johannes.klausmann@mni.thm.de \
    --cc=airlied@linux.ie \
    --cc=bskeggs@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@canonical.com \
    --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.