similar to: [PATCH] tone down the WARN_ON about unexpected APIC writes

OK, not strictly in keeping with the subject of the patch set but I needed this to build ;-) Should be merged into 02d-xen-apic-esp0.patch Signed-off-by: Ian Campbell <ian.campbell@xensource.com> diff -r 6fdbec59813e arch/i386/paravirt-xen/enlighten.c --- a/arch/i386/paravirt-xen/enlighten.c Wed Aug 23 15:08:37 2006 +0100 +++ b/arch/i386/paravirt-xen/enlighten.c Wed Aug 23 15:08:37 2006

Hi all, I'm pleased to announce a Xen paravirt_ops kernel available for testing at http://xenbits.xensource.com/ext/paravirt_ops/. These kernels are based on this morning's 2.6.21, along with all the paravirt_ops + Xen patches. The pre-built i386 kernel RPM is based on the FC6 configuration, and it has both Xen and VMI paravirt_ops support enabled. Unfortunately the RPM is a bit rough,

Hi all, I'm pleased to announce a Xen paravirt_ops kernel available for testing at http://xenbits.xensource.com/ext/paravirt_ops/. These kernels are based on this morning's 2.6.21, along with all the paravirt_ops + Xen patches. The pre-built i386 kernel RPM is based on the FC6 configuration, and it has both Xen and VMI paravirt_ops support enabled. Unfortunately the RPM is a bit rough,

Hi all, I'm pleased to announce a Xen paravirt_ops kernel available for testing at http://xenbits.xensource.com/ext/paravirt_ops/. These kernels are based on this morning's 2.6.21, along with all the paravirt_ops + Xen patches. The pre-built i386 kernel RPM is based on the FC6 configuration, and it has both Xen and VMI paravirt_ops support enabled. Unfortunately the RPM is a bit rough,

The addition of VMDq support to ixgbe completely broke normal RSS receive operation. Since RSS is the default operating mode, the driver would cause a kernel panic as soon as the interface was opened. This patch fixes the problem by correctly checking the VMDQ_ENABLED flag before attempting any VMDQ-specific call. Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> diff -r

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

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

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

Hi, Here is the patch fixing crash when apic=debug is used and APIC is not properly initialized. This issue appears during Xen Dom0 kernel boot (git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git, xen/stable-2.6.32.x head), however I think that patch is rather generic and should be applied to mainline kernel (it applies to Linux Kernel Ver. 2.6.35 and Ver. 2.6.32.19 with small fuzz).

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. >> > >> > commit b513a18cf1d705bd04efd91c417e79e4938be093 >> > Author: