similar to: [Bug 93634] New: WARN_ON triggered on DPMS event

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 ---

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 ==

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

------------[ cut here ]------------ WARNING: CPU: 3 PID: 692 at drivers/gpu/drm/nouveau/nouveau_bo.c:137 nouveau_bo_del_ttm+0x7f/0x90 [nouveau] Modules linked in: ... nouveau mxm_wmi video i2c_algo_bit ttm drm_kms_helper drm wmi ... CPU: 3 PID: 692 Comm: Xorg Not tainted 4.10.8-1002.fc24.x86_64 #1 ... Call Trace: dump_stack+0x63/0x86 __warn+0xcb/0xf0 warn_slowpath_null+0x1d/0x20

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

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

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

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 > >

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.

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

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:

[ 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

https://bugs.freedesktop.org/show_bug.cgi?id=103383 Bug ID: 103383 Summary: "xset dpms force on" does not unblank laptop screen after "xset dpms force off" is run (or system enters sleep mode) Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: All

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 > > drm/nouveau: Don't WARN_ON VCPI allocation failures > >Is this an artifact of your

This workbox was thrown together with only a little bit of thought as to what the role would ultimately be, and at the time, I did not think it would ever wind up serving linux applications. Error #1 (my fault) Having a healthy pocketbook when I went into pick things up, I had already decided I wanted a good relatively mid-range graphics card, and I chose the ATI X600. (Error #2) As it turns

This reverts commit 98c9e4edb58374f18249e5c9c53b392fb8b4a1d1. AFAIK it's no longer needed. Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- src/drmmode_display.c | 3 --- src/nv_driver.c | 2 -- src/nv_type.h | 1 - 3 files changed, 0 insertions(+), 6 deletions(-) diff --git a/src/drmmode_display.c b/src/drmmode_display.c index 7c45d9c..a91741d

https://bugs.freedesktop.org/show_bug.cgi?id=85570 alexander korolev <kilork at yandex.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|Other |x86-64 (AMD64) -- You are receiving this mail because: You are the assignee for the bug. -------------- next

Hi, I'm Yves and I'm new to this list. I use Wine as Win98 but without Windows, on a ReiserFS directory. Every once in a while, I try to run a dos program in wcmd (unix compiled & launched). My main purpose is to test Atari ST emulators. Always, the dos program wants to access memory in "real mode". There's something about the first 64Ko of memory, then it always ends

https://bugs.freedesktop.org/show_bug.cgi?id=106662 Bug ID: 106662 Summary: nouveau DPMS poblem with DRI3 (GM107) Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

The code claims to grab a runtime PM ref when at least one CRTC is active, but that's not actually the case as we grab a runtime PM ref whenever a CRTC is enabled regardless of it's DPMS state. Meaning that we can end up keeping the GPU awake when there are no screens enabled, something we don't really want to do. Note that we fixed this same issue for nv50 a while ago in: commit