[PATCH] nouveau: Skip unvailable ttm page entries

:00.0: DRM: ttm_dma: Zero Alloc: 0 nouveau :01:00.0: DRM: ttm_dma: Swapped: 0 Signed-off-by: Tobias Klausmann --- drivers/gpu/drm/nouveau/nouveau_bo.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c

[PATCH] nouveau: forward error generated while resuming objects tree

-functioning state. Signed-off-by: Tobias Klausmann --- drivers/gpu/drm/nouveau/nouveau_drm.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 5020265bfbd9..56a107f3a0e1 100644

Re: [Nouveau] [PATCH] drm/nouveau/therm/gp100: Do not report temperature when subdev is shadowed

in hwmon. On Fri, Jan 26, 2018 at 2:40 PM, Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de> wrote: Not sure if i understand completely what you intend to say here, with this we prevent hwmon from reporting utterly wrong temperature values returning an error (we could return -EBUSY or som

Re: [Nouveau] [PATCH] drm/nouveau/therm/gp100: Do not report temperature when subdev is shadowed

Klausmann <tobias.johannes.klausm...@mni.thm.de> wrote: This fixes wrong temperature outputs e.g. 511°C if the card is asleep. Signed-off-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de> --- drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c | 4 +++- 1 file changed, 3 inse

[PATCH] drm/nouveau/therm/gp100: Do not report temperature when subdev is shadowed

This fixes wrong temperature outputs e.g. 511°C if the card is asleep. Signed-off-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de> --- drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouvea

Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

On 12/18/17 7:06 PM, Mike Galbraith wrote: Greetings, Kernel bound workloads seem to trigger the below for whatever reason.  I only see this when beating up NFS.  There was a kworker wakeup latency issue, but with a bandaid applied to fix that up, I can still trigger this. Hi, i have seen

Re: Regression in TTM driver w/Linus' master

On 11/24/17 4:35 PM, Christian König wrote: Am 24.11.2017 um 16:17 schrieb Tobias Klausmann: On 11/24/17 3:54 PM, Daniel Vetter wrote: On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote: On 11/23/17 2:58 AM, Dave Airlie wrote: On 23 November 2017 at 11:17, Laura Abbott <l

Re: Regression in TTM driver w/Linus' master

On 11/24/17 3:54 PM, Daniel Vetter wrote: On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote: On 11/23/17 2:58 AM, Dave Airlie wrote: On 23 November 2017 at 11:17, Laura Abbott <labb...@redhat.com> wrote: Hi, Fedora QA testing reported a panic when booting up VMs usin

Re: Regression in TTM driver w/Linus' master

On 11/23/17 2:58 AM, Dave Airlie wrote: On 23 November 2017 at 11:17, Laura Abbott wrote: Hi, Fedora QA testing reported a panic when booting up VMs using qmeu vga drivers (https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ) [ 30.108507] [ cut

Re: [Nouveau] [PATCH] drm/nouveau/mpeg: print more debug info when rejecting dma objects

Hi, Lgtm! Reviewed-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de> On 8/6/17 4:19 AM, Ilia Mirkin wrote: > Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> > --- > > This was helpful when debugging our earlier mpeg woes. May as well have it > ups

Re: [PATCH 17/29] drm/nouveau: switch to drm_*{get,put} helpers

Looks good to me! Reviewed-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de> On 8/3/17 1:58 PM, Cihangir Akturk wrote: > drm_*_reference() and drm_*_unreference() functions are just > compatibility alias for drm_*_get() and drm_*_put() adn should not be > used by new c

[PATCH] drm: disable vblank only if it got previously enabled

b0 e8 38 fa ed c6 44 0f b6 [ 12.768508] ---[ end trace d9bb853af3659bd5 ]--- Signed-off-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de> --- drivers/gpu/drm/drm_vblank.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_vblank.c b/dri

Re: [Nouveau] [PATCH] drm: disable vblank only if it got previously enabled

it up. > Otherwise we're back to the old style vblank horror show. > > Thanks, Daniel > >> On Wed, Jul 19, 2017 at 1:25 PM, Tobias Klausmann >> <tobias.johannes.klausm...@mni.thm.de> wrote: >>> mimic the behavior of vblank_disable_fn(), another caller of >&g

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

The conversion is a nice catch, but i'd like to have a bit more context, see below! With a better description: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de> On 7/14/17 5:10 PM, Karol Herbst wrote: Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE usage we

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On 7/14/17 3:41 PM, Mike Galbraith wrote: On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:  All DRM did was to slip a WARN_ON_ONCE() that nouveau triggers into a kernel module where such things no longer warn, they blow the box out of the water. BTW, turn that irksome WARN_ON_ONCE()

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On 7/12/17 7:19 PM, Mike Galbraith wrote: On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote: On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith wrote: On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: Some display

[Nouveau] [PATCH] ram/gf100-: error out if a ridiculous amount of vram is detected

Any idea on how to solve the problem. other than just reporting it? But for now this adds a helpful error message... you may add my R-b. On 20.05.2015 22:01, Ilia Mirkin wrote: > Some newer chips have trouble coming up, and we get bad MMIO reads from > them, like 0xbadf100. This ends up

3.18-rc regression: drm/nouveau: use shared fences for readable objects

On 26.11.2014 21:29, Michael Marineau wrote: > On Mon, Nov 24, 2014 at 11:43 PM, Maarten Lankhorst > wrote: >> Hey, >> >> Op 22-11-14 om 21:16 schreef Michael Marineau: >>> On Nov 22, 2014 11:45 AM, "Michael Marineau" wrote: On Nov 22, 2014 8:56 AM, "Maarten Lankhorst" < >>>

3.18-rc regression: drm/nouveau: use shared fences for readable objects

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

3.18-rc regression: drm/nouveau: use shared fences for readable objects

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][:01:00.0]

I915 DRI_PRIME Bug

99a0c147e69ddcd1 ]--- Thanks, Tobias Klausmann ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel

I915 DRI_PRIME Bug

0x90 [i915] [] ? dma_buf_release+0x23/0x80 [] ? __fput+0xcd/0x230 [] ? task_work_run+0x97/0xd0 [] ? do_notify_resume+0x79/0xa0 [] ? int_signal+0x12/0x17 ---[ end trace 99a0c147e69ddcd1 ]--- Thanks, Tobias Klausmann