similar to: NVAC - WARN_ON(nvbo->pin_refcnt > 0);

Displaying 20 results from an estimated 200 matches similar to: "NVAC - WARN_ON(nvbo->pin_refcnt > 0);"

2017 Feb 14
1
NVAC: WARN_ON(nvbo->pin_refcnt > 0);
Hello fellows! Signal finally goes through ION's HDMI, however # chvt from 5 "graphical" to 3 "textual", and then at the very end of reboot, WARN emerges: ... nouveau 0000:01:00.0: DRM: EVO timeout ------------[ cut here ]------------ WARNING: CPU: 1 PID: 701 at drivers/gpu/drm/nouveau/nouveau_bo.c:137 nouveau_bo_del_ttm+0x7f/0x90 [nouveau] Modules linked in: ... nouveau
2014 Oct 13
2
v3.17, i915 vs nouveau: possible recursive locking detected
============================================= [ INFO: possible recursive locking detected ] 3.17.0 #50 Not tainted --------------------------------------------- Xorg/1170 is trying to acquire lock: (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa010ae93>] i915_gem_unmap_dma_buf+0x33/0xc0 [i915] but task is already holding lock: (&dev->struct_mutex){+.+.+.}, at:
2014 Jun 08
0
lockdep splat while exiting PRIME
Hi, While trying PRIME, I got a lockdep warning after exiting glxgears. Is it harmful? The command was: DRI_PRIME=1 glxgears Offload provider is a GT425M (NVC0), output sink is an Intel i5-460M. Kind regards, Peter dmesg: ============================================= [ INFO: possible recursive locking detected ] 3.15.0-rc8-custom-00058-gd2cfd31 #1 Tainted: G O
2014 Oct 16
0
[Intel-gfx] v3.17, i915 vs nouveau: possible recursive locking detected
We need ww mutexes and need to rewrite i915 a bit fo fix this all. I.e. known issue. As long as your userspace isn't nasty nothing bad will ever happen though. -Daniel On Mon, Oct 13, 2014 at 08:40:33PM +0200, Marcin ?lusarz wrote: > ============================================= > [ INFO: possible recursive locking detected ] > 3.17.0 #50 Not tainted >
2010 Jan 02
2
Kernel warnings
Hi, I've been getting these warnings in syslog since I've been running (Linux) kernels 2.6.31.x and up (I'm currently at 2.6.32.2), they do not show up on 2.6.30.x kernels. Dovecot versions involved were/are 1.2.x, I'm currently at 1.2.9. My system is running Slackware 13.0, but this also happened with 12.2. ------------[ cut here ]------------ WARNING: at
2018 Dec 19
0
[PATCH 08/10] drm/virtio: drop fencing in virtio_gpu_resource_create_ioctl
There is no need to wait for completion here. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 51 +--------------------------------- 1 file changed, 1 insertion(+), 50 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c index 52d6ec2dde..65ac61f86a 100644 ---
2011 Aug 22
0
[PATCH] tone down the WARN_ON about unexpected APIC writes
These occurrences are largely benign these days and tainting the kernel for them is a bit aggressive. Mostly they relate to failing to setup perf which I think we are all aware is something which needs attention on the Xen/pvops side. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 974a528..55e3cc7 100644 ---
2010 Feb 01
0
[PATCH] btrfsck: Remove superfluous WARN_ON
Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp btrfs-progs-unstable/btrfsck.c btrfs-progs-2/btrfsck.c --- btrfs-progs-unstable/btrfsck.c 2009-09-28 15:54:55.980479398 +0800 +++ btrfs-progs-2/btrfsck.c 2010-01-31 09:46:24.645485459 +0800 @@ -581,7 +581,6 @@ again: } ret = insert_existing_cache_extent(dst, &ins->cache); if (ret == -EEXIST) { - WARN_ON(src ==
2019 Jan 28
1
[PATCH] drm/nouveau: Don't WARN_ON VCPI allocation failures
This is much louder then we want. VCPI allocation failures are quite normal, since they will happen if any part of the modesetting process is interrupted by removing the DP MST topology in question. So just print a debugging message on VCPI failures instead. Signed-off-by: Lyude Paul <lyude at redhat.com> Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2
2019 Sep 03
0
[PATCH AUTOSEL 4.19 070/167] drm/nouveau: Don't WARN_ON VCPI allocation failures
From: Lyude Paul <lyude at redhat.com> [ Upstream commit b513a18cf1d705bd04efd91c417e79e4938be093 ] This is much louder then we want. VCPI allocation failures are quite normal, since they will happen if any part of the modesetting process is interrupted by removing the DP MST topology in question. So just print a debugging message on VCPI failures instead. Signed-off-by: Lyude Paul
2019 Sep 13
0
[PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
Hi Greg, This feels like it's missing a From: line. commit b513a18cf1d705bd04efd91c417e79e4938be093 Author: Lyude Paul <lyude at redhat.com> Date: Mon Jan 28 16:03:50 2019 -0500 drm/nouveau: Don't WARN_ON VCPI allocation failures Is this an artifact of your notification-of-patches process and I never noticed before, or was the patch ingested incorrectly? Cheers, -ilia
2019 Sep 13
0
[PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: > On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > > Hi Greg, > > > > This feels like it's missing a From: line. > > > > commit b513a18cf1d705bd04efd91c417e79e4938be093 > > Author: Lyude Paul <lyude at redhat.com> > > Date: Mon Jan 28 16:03:50 2019 -0500 > >
2019 Sep 13
0
[PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 11:01:11AM -0400, Sasha Levin wrote: > On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote: > > On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: > > > On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > > > > Hi Greg, > > > > > > > > This feels like it's missing a From: line.
2019 Sep 13
0
[PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 11:01 AM Sasha Levin <sashal at kernel.org> wrote: > > On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote: > >On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: > >> On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > >> > Hi Greg, > >> > > >> > This feels like it's
2019 Jul 16
1
[PATCH v3 2/3] drm: plumb attaching dev thru to prime_pin/unpin
From: Rob Clark <robdclark at chromium.org> Needed in the following patch for cache operations. Signed-off-by: Rob Clark <robdclark at chromium.org> --- v3: rebased on drm-tip drivers/gpu/drm/drm_gem.c | 8 ++++---- drivers/gpu/drm/drm_internal.h | 4 ++-- drivers/gpu/drm/drm_prime.c | 4 ++--
2019 Jul 16
1
[PATCH v3 2/3] drm: plumb attaching dev thru to prime_pin/unpin
From: Rob Clark <robdclark at chromium.org> Needed in the following patch for cache operations. Signed-off-by: Rob Clark <robdclark at chromium.org> --- v3: rebased on drm-tip drivers/gpu/drm/drm_gem.c | 8 ++++---- drivers/gpu/drm/drm_internal.h | 4 ++-- drivers/gpu/drm/drm_prime.c | 4 ++--
2019 Jul 16
1
[PATCH v3 2/3] drm: plumb attaching dev thru to prime_pin/unpin
From: Rob Clark <robdclark at chromium.org> Needed in the following patch for cache operations. Signed-off-by: Rob Clark <robdclark at chromium.org> --- v3: rebased on drm-tip drivers/gpu/drm/drm_gem.c | 8 ++++---- drivers/gpu/drm/drm_internal.h | 4 ++-- drivers/gpu/drm/drm_prime.c | 4 ++--
2016 Jan 07
6
[Bug 93634] New: WARN_ON triggered on DPMS event
https://bugs.freedesktop.org/show_bug.cgi?id=93634 Bug ID: 93634 Summary: WARN_ON triggered on DPMS event Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at
2017 Aug 09
6
[Bug 102135] New: WARN_ON hit when loading G71 with v4.13-rc3
https://bugs.freedesktop.org/show_bug.cgi?id=102135 Bug ID: 102135 Summary: WARN_ON hit when loading G71 with v4.13-rc3 Product: xorg Version: unspecified Hardware: PowerPC OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee:
2019 Sep 13
2
[PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
[ Upstream commit b513a18cf1d705bd04efd91c417e79e4938be093 ] This is much louder then we want. VCPI allocation failures are quite normal, since they will happen if any part of the modesetting process is interrupted by removing the DP MST topology in question. So just print a debugging message on VCPI failures instead. Signed-off-by: Lyude Paul <lyude at redhat.com> Fixes: f479c0ba4a17