[tip:sched/core] sched/x86: Update reschedule warning text

Commit-ID: 21173d0b4d2a0b9e9e5f3155cf2cfc5781a6f4b1 Gitweb: http://git.kernel.org/tip/21173d0b4d2a0b9e9e5f3155cf2cfc5781a6f4b1 Author: Prarit Bhargava AuthorDate: Tue, 18 Apr 2017 08:25:05 -0400 Committer: Ingo Molnar CommitDate: Thu, 20 Apr 2017 10:14:30 +0200 sched/x86: Update

[PATCH] x86/smp: Update reschedule warning text

Modify the reschedule warning to output the offline CPU value and a better debug message. Signed-off-by: Prarit Bhargava <pra...@redhat.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: "H. Peter Anvin" <h...@zytor.com>

[PATCH] x86/smp: Update reschedule warning text

Modify the reschedule warning to output the offline CPU value and a better debug message. Signed-off-by: Prarit Bhargava Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: Wanpeng Li Cc: Andrew Morton Cc: "Steven Rostedt (VMware)" C

Re: [PATCH] x86/irq: Do not check available vectors if current CPU has no irq to migrate

> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Ingo Molnar <mi...@redhat.com> > Cc: "H. Peter Anvin" <h...@zytor.com> > Cc: Prarit Bhargava <pra...@redhat.com> > Cc: "Rafael J. Wysocki" <rafael.j.wyso...@intel.com> &

Re: [PATCH] x86/irq: Do not check available vectors if current CPU has no irq to migrate

> > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: Prarit Bhargava > Cc: "Rafael J. Wysocki" > Cc: Len Brown > Cc: x...@kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Chen Yu > --- > arch/x86/kernel

[PATCH 2/2] hwrng: geode - Revert managed API changes

ter the first load of the driver. Revert the changes made by e9afc746299d ("hwrng: geode - Use linux/io.h instead of asm/io.h"). Signed-off-by: Prarit Bhargava <pra...@redhat.com> Fixes: 6e9b5e76882c ("hwrng: geode - Migrate to managed API") Cc: Matt Mackall

[PATCH 2/2] hwrng: geode - Revert managed API changes

ter the first load of the driver. Revert the changes made by e9afc746299d ("hwrng: geode - Use linux/io.h instead of asm/io.h"). Signed-off-by: Prarit Bhargava Fixes: 6e9b5e76882c ("hwrng: geode - Migrate to managed API") Cc: Matt Mackall Cc: Herbert Xu Cc: Corentin LABBE C

[PATCH 1/2] hwrng: amd - Revert managed API changes

and region after the first load of the driver. Revert the changes made by 31b2a73c9c5f ("hwrng: amd - Migrate to managed API"). Signed-off-by: Prarit Bhargava <pra...@redhat.com> Fixes: 31b2a73c9c5f ("hwrng: amd - Migrate to managed API"). Cc: Matt Mack

[PATCH 1/2] hwrng: amd - Revert managed API changes

and region after the first load of the driver. Revert the changes made by 31b2a73c9c5f ("hwrng: amd - Migrate to managed API"). Signed-off-by: Prarit Bhargava Fixes: 31b2a73c9c5f ("hwrng: amd - Migrate to managed API"). Cc: Matt Mackall Cc: Herbert Xu Cc: Corentin LABBE Cc

[PATCH 0/2] hwrng: revert managed API changes for amd and geode

grate to managed API"), and 6e9b5e76882c ("hwrng: geode - Migrate to managed API"). Signed-off-by: Prarit Bhargava <pra...@redhat.com> Fixes: 31b2a73c9c5f ("hwrng: amd - Migrate to managed API"). Fixes: 6e9b5e76882c ("hwrng: geode - Migrate to managed API

[PATCH 0/2] hwrng: revert managed API changes for amd and geode

grate to managed API"), and 6e9b5e76882c ("hwrng: geode - Migrate to managed API"). Signed-off-by: Prarit Bhargava Fixes: 31b2a73c9c5f ("hwrng: amd - Migrate to managed API"). Fixes: 6e9b5e76882c ("hwrng: geode - Migrate to managed API") Cc: Matt Mackall

Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

On 01/19/2017 06:49 AM, Greg Kroah-Hartman wrote: > On Thu, Jan 19, 2017 at 05:32:46AM -0500, Prarit Bhargava wrote: >> >> >> On 01/18/2017 05:25 PM, Ingo Molnar wrote: >>> >>> * Prarit Bhargava <pra...@redhat.com> wrote: >>> >>>&g

Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

On 01/19/2017 06:49 AM, Greg Kroah-Hartman wrote: > On Thu, Jan 19, 2017 at 05:32:46AM -0500, Prarit Bhargava wrote: >> >> >> On 01/18/2017 05:25 PM, Ingo Molnar wrote: >>> >>> * Prarit Bhargava wrote: >>> >>>> 4.9 is broken

Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

On 01/18/2017 12:20 PM, Greg Kroah-Hartman wrote: > On Wed, Jan 18, 2017 at 11:55:58AM -0500, Prarit Bhargava wrote: >> >> >> On 01/18/2017 11:33 AM, Greg Kroah-Hartman wrote: >>> On Wed, Jan 18, 2017 at 09:38:07AM -0500, Prarit Bhargava wrote: >>>> &g

Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

On 01/18/2017 12:20 PM, Greg Kroah-Hartman wrote: > On Wed, Jan 18, 2017 at 11:55:58AM -0500, Prarit Bhargava wrote: >> >> >> On 01/18/2017 11:33 AM, Greg Kroah-Hartman wrote: >>> On Wed, Jan 18, 2017 at 09:38:07AM -0500, Prarit Bhargava wrote: >>>> &g

Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

On 01/18/2017 05:25 PM, Ingo Molnar wrote: > > * Prarit Bhargava <pra...@redhat.com> wrote: > >> 4.9 is broken and requires additional patches beyond this patch. Applying >> this >> patch to 4.9 stable without those additional fixes will result in kern

Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

On 01/18/2017 05:25 PM, Ingo Molnar wrote: > > * Prarit Bhargava wrote: > >> 4.9 is broken and requires additional patches beyond this patch. Applying >> this >> patch to 4.9 stable without those additional fixes will result in kernel >> panics >

Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

On 01/18/2017 11:33 AM, Greg Kroah-Hartman wrote: > On Wed, Jan 18, 2017 at 09:38:07AM -0500, Prarit Bhargava wrote: >> >> >> On 01/18/2017 05:45 AM, Greg Kroah-Hartman wrote: >>> 4.9-stable review patch. If anyone has any objections, please let me know. &

Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

On 01/18/2017 11:33 AM, Greg Kroah-Hartman wrote: > On Wed, Jan 18, 2017 at 09:38:07AM -0500, Prarit Bhargava wrote: >> >> >> On 01/18/2017 05:45 AM, Greg Kroah-Hartman wrote: >>> 4.9-stable review patch. If anyone has any objections, please let me know. &

Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

ogical_proc_id 0 After 9d85eb9119f4: [3.919112] hswep_uncore_cpu_init: cpu 5 pkg 0 boot_cpu_data.logical_proc_id 0 [3.923391] hswep_uncore_cpu_init: cpu 5 pkg 0 cpu_data(0).logical_proc_id 0 This patch should not be applied to any stable branch. P. > ------ > > F

Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

ogical_proc_id 0 After 9d85eb9119f4: [3.919112] hswep_uncore_cpu_init: cpu 5 pkg 0 boot_cpu_data.logical_proc_id 0 [3.923391] hswep_uncore_cpu_init: cpu 5 pkg 0 cpu_data(0).logical_proc_id 0 This patch should not be applied to any stable branch. P. > ------ > &

Re: [PATCH] x86/mce: Fix initialization error warning

On 01/16/2017 06:32 PM, Borislav Petkov wrote: > On Mon, Jan 16, 2017 at 06:13:39PM -0500, Prarit Bhargava wrote: >> Yes, mce=off is the default for kdump: > > So fix kdump to disable MCA properly instead of sending me brown paper > bags. Sure, I'll take a shot at it. Thanks, P. >

Re: [PATCH] x86/mce: Fix initialization error warning

On 01/16/2017 06:32 PM, Borislav Petkov wrote: > On Mon, Jan 16, 2017 at 06:13:39PM -0500, Prarit Bhargava wrote: >> Yes, mce=off is the default for kdump: > > So fix kdump to disable MCA properly instead of sending me brown paper > bags. Sure, I'll take a shot at it. Thanks, P. >

Re: [PATCH] x86/mce: Fix initialization error warning

On 01/16/2017 05:43 PM, Borislav Petkov wrote: > On Mon, Jan 16, 2017 at 05:06:02PM -0500, Prarit Bhargava wrote: >> Yes, it was loud enough to generate a bug report from a user. > > Yeah, because all users are sane and we should do whatever they want - > no questions asked

Re: [PATCH] x86/mce: Fix initialization error warning

On 01/16/2017 05:43 PM, Borislav Petkov wrote: > On Mon, Jan 16, 2017 at 05:06:02PM -0500, Prarit Bhargava wrote: >> Yes, it was loud enough to generate a bug report from a user. > > Yeah, because all users are sane and we should do whatever they want - > no questions asked

Re: [PATCH] x86/mce: Fix initialization error warning

On 01/16/2017 04:56 PM, Borislav Petkov wrote: > On Mon, Jan 16, 2017 at 04:49:41PM -0500, Prarit Bhargava wrote: >> When booting kernel with mce=off a loud warning from the mce code >> is displayed. This causes confusion for end users. > > Is this what yo

Re: [PATCH] x86/mce: Fix initialization error warning

On 01/16/2017 04:56 PM, Borislav Petkov wrote: > On Mon, Jan 16, 2017 at 04:49:41PM -0500, Prarit Bhargava wrote: >> When booting kernel with mce=off a loud warning from the mce code >> is displayed. This causes confusion for end users. > > Is this what yo

[PATCH] x86/mce: Fix initialization error warning

When booting kernel with mce=off a loud warning from the mce code is displayed. This causes confusion for end users. Add a check to see if MCE is available before outputting the warning message. Signed-off-by: Prarit Bhargava <pra...@redhat.com> Cc: Tony Luck <tony.l...@intel.com>

[PATCH] x86/mce: Fix initialization error warning

When booting kernel with mce=off a loud warning from the mce code is displayed. This causes confusion for end users. Add a check to see if MCE is available before outputting the warning message. Signed-off-by: Prarit Bhargava Cc: Tony Luck Cc: Borislav Petkov Cc: Thomas Gleixner Cc: Ingo

[tip:perf/urgent] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

Commit-ID: 6d6daa20945f3f598e56e18d1f926c08754f5801 Gitweb: http://git.kernel.org/tip/6d6daa20945f3f598e56e18d1f926c08754f5801 Author: Prarit Bhargava <pra...@redhat.com> AuthorDate: Thu, 5 Jan 2017 10:09:25 -0500 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate:

[tip:perf/urgent] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

Commit-ID: 6d6daa20945f3f598e56e18d1f926c08754f5801 Gitweb: http://git.kernel.org/tip/6d6daa20945f3f598e56e18d1f926c08754f5801 Author: Prarit Bhargava AuthorDate: Thu, 5 Jan 2017 10:09:25 -0500 Committer: Thomas Gleixner CommitDate: Wed, 11 Jan 2017 12:13:21 +0100 perf/x86/intel

Re: [tip:x86/urgent] perf/x86/intel/uncore: Do not use hard coded physical package id 0

On 01/11/2017 05:33 AM, tip-bot for Prarit Bhargava wrote: > Commit-ID: 42433049c51e326baa1f45c834af9572fdb65b35 > Gitweb: http://git.kernel.org/tip/42433049c51e326baa1f45c834af9572fdb65b35 > Author: Prarit Bhargava <pra...@redhat.com> > AuthorDate: Tue, 3 Jan 2

Re: [tip:x86/urgent] perf/x86/intel/uncore: Do not use hard coded physical package id 0

On 01/11/2017 05:33 AM, tip-bot for Prarit Bhargava wrote: > Commit-ID: 42433049c51e326baa1f45c834af9572fdb65b35 > Gitweb: http://git.kernel.org/tip/42433049c51e326baa1f45c834af9572fdb65b35 > Author: Prarit Bhargava > AuthorDate: Tue, 3 Jan 2017 14:24:31 -0500 > Com

[tip:x86/urgent] perf/x86/intel/uncore: Do not use hard coded physical package id 0

Commit-ID: 42433049c51e326baa1f45c834af9572fdb65b35 Gitweb: http://git.kernel.org/tip/42433049c51e326baa1f45c834af9572fdb65b35 Author: Prarit Bhargava <pra...@redhat.com> AuthorDate: Tue, 3 Jan 2017 14:24:31 -0500 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate:

[tip:x86/urgent] perf/x86/intel/uncore: Do not use hard coded physical package id 0

Commit-ID: 42433049c51e326baa1f45c834af9572fdb65b35 Gitweb: http://git.kernel.org/tip/42433049c51e326baa1f45c834af9572fdb65b35 Author: Prarit Bhargava AuthorDate: Tue, 3 Jan 2017 14:24:31 -0500 Committer: Thomas Gleixner CommitDate: Wed, 11 Jan 2017 11:29:37 +0100 perf/x86/intel

[tip:perf/urgent] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

Commit-ID: fa37361e291bfe528872b9aef5c8644a3fc7ff20 Gitweb: http://git.kernel.org/tip/fa37361e291bfe528872b9aef5c8644a3fc7ff20 Author: Prarit Bhargava <pra...@redhat.com> AuthorDate: Thu, 5 Jan 2017 10:09:25 -0500 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sat, 7

[tip:perf/urgent] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

Commit-ID: fa37361e291bfe528872b9aef5c8644a3fc7ff20 Gitweb: http://git.kernel.org/tip/fa37361e291bfe528872b9aef5c8644a3fc7ff20 Author: Prarit Bhargava AuthorDate: Thu, 5 Jan 2017 10:09:25 -0500 Committer: Ingo Molnar CommitDate: Sat, 7 Jan 2017 08:54:38 +0100 perf/x86/intel/uncore

[PATCH v2] perf/x86/intel/uncore: Remove hardcoded socket 0 in Haswell init code

: switched to using boot_cpu_data.logical_proc_id Signed-off-by: Prarit Bhargava <pra...@redhat.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: "H. Peter Anvin" <h...@zytor.com> Cc: x...@kernel.org Cc: Peter Zijlstra <pet...@infradead.org&

[PATCH v2] perf/x86/intel/uncore: Remove hardcoded socket 0 in Haswell init code

: switched to using boot_cpu_data.logical_proc_id Signed-off-by: Prarit Bhargava Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: Peter Zijlstra Cc: Kan Liang Cc: Borislav Petkov Cc: Harish Chegondi --- arch/x86/events/intel/uncore_snbep.c |2 +- 1 file change

Re: [PATCH] perf/x86/intel/uncore: Initialize with correct logical package ID

On 01/03/2017 02:24 PM, Prarit Bhargava wrote: > On multi-socket Intel v3 processor systems (aka Haswell) kdump can fail with: > > BUG: unable to handle kernel paging request at 006563a1 > IP: [] hswep_uncore_cpu_init+0x52/0xa0 > PGD 0 [2.313897] > Oops:

Re: [PATCH] perf/x86/intel/uncore: Initialize with correct logical package ID

On 01/03/2017 02:24 PM, Prarit Bhargava wrote: > On multi-socket Intel v3 processor systems (aka Haswell) kdump can fail with: > > BUG: unable to handle kernel paging request at 006563a1 > IP: [] hswep_uncore_cpu_init+0x52/0xa0 > PGD 0 [2.313897] > Oops:

Re: [PATCH] kernel/watchdog.c: Do not hardcode CPU 0 as the initial thread

On 12/01/2016 03:06 PM, Don Zickus wrote: > On Tue, Nov 29, 2016 at 08:15:21AM -0500, Prarit Bhargava wrote: >> When CONFIG_BOOTPARAM_HOTPLUG_CPU0 is enabled, the socket containing the >> boot cpu can be replaced. During the hot add event, the message >> >> NMI wa

Re: [PATCH] kernel/watchdog.c: Do not hardcode CPU 0 as the initial thread

On 12/01/2016 03:06 PM, Don Zickus wrote: > On Tue, Nov 29, 2016 at 08:15:21AM -0500, Prarit Bhargava wrote: >> When CONFIG_BOOTPARAM_HOTPLUG_CPU0 is enabled, the socket containing the >> boot cpu can be replaced. During the hot add event, the message >> >> NMI wa

[PATCH] perf/x86/intel/uncore: Initialize with correct logical package ID

logical package value will be incorrect. The code should not use 0 as the physical ID, and should use the boot cpu's physical package ID in this calculation. Signed-off-by: Prarit Bhargava <pra...@redhat.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redh

[PATCH] perf/x86/intel/uncore: Initialize with correct logical package ID

logical package value will be incorrect. The code should not use 0 as the physical ID, and should use the boot cpu's physical package ID in this calculation. Signed-off-by: Prarit Bhargava Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: Peter Z

[PATCH v2] x86/irq: Add additional unhandled IRQ debug information

andled irq source :00:16.0: pin = 1 possible unhandled irq source :05:00.0: pin = 1 [v2]: Fixed kbuild auto test warning for i386 Signed-off-by: Prarit Bhargava <pra...@redhat.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: "H. Pe

[PATCH v2] x86/irq: Add additional unhandled IRQ debug information

andled irq source :00:16.0: pin = 1 possible unhandled irq source :05:00.0: pin = 1 [v2]: Fixed kbuild auto test warning for i386 Signed-off-by: Prarit Bhargava Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: Rui Wang Cc: Paul Gortmaker Cc

[PATCH] x86/irq: Add additional unhandled IRQ debug information

andled irq source :00:16.0: pin = 1 possible unhandled irq source :05:00.0: pin = 1 Signed-off-by: Prarit Bhargava <pra...@redhat.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: "H. Peter Anvin" <h...@zytor.com> Cc: x...@k

[PATCH] x86/irq: Add additional unhandled IRQ debug information

andled irq source :00:16.0: pin = 1 possible unhandled irq source :05:00.0: pin = 1 Signed-off-by: Prarit Bhargava Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: Rui Wang Cc: Paul Gortmaker Cc: Denys Vlasenko Cc: Borislav Petkov Cc: Aar

Re: Odd build breakage in 4.9-rc7

On 11/30/2016 05:41 PM, Nicolas Pitre wrote: > On Wed, 30 Nov 2016, Linus Torvalds wrote: > >> On Wed, Nov 30, 2016 at 10:50 AM, Prarit Bhargava <pra...@redhat.com> wrote: >>> >>> It comes back. The steps to reproduce this are: >>> >>

Re: Odd build breakage in 4.9-rc7

On 11/30/2016 05:41 PM, Nicolas Pitre wrote: > On Wed, 30 Nov 2016, Linus Torvalds wrote: > >> On Wed, Nov 30, 2016 at 10:50 AM, Prarit Bhargava wrote: >>> >>> It comes back. The steps to reproduce this are: >>> >>> 1. checkout latest linux.gi

Re: Odd build breakage in 4.9-rc7

On 11/30/2016 05:41 PM, Nicolas Pitre wrote: > On Wed, 30 Nov 2016, Linus Torvalds wrote: > >> On Wed, Nov 30, 2016 at 10:50 AM, Prarit Bhargava <pra...@redhat.com> wrote: >>> >>> It comes back. The steps to reproduce this are: >>> >>

Re: Odd build breakage in 4.9-rc7

On 11/30/2016 05:41 PM, Nicolas Pitre wrote: > On Wed, 30 Nov 2016, Linus Torvalds wrote: > >> On Wed, Nov 30, 2016 at 10:50 AM, Prarit Bhargava wrote: >>> >>> It comes back. The steps to reproduce this are: >>> >>> 1. checkout latest linux.gi

Re: Odd build breakage in 4.9-rc7

On 11/30/2016 01:36 PM, Linus Torvalds wrote: > On Wed, Nov 30, 2016 at 10:28 AM, Prarit Bhargava <pra...@redhat.com> wrote: > ]> >> In my case I tracked this to commit 3637efb00864 ("x86/mce: Add PCI quirks to >> identify Xeons with machine check r

Re: Odd build breakage in 4.9-rc7

On 11/30/2016 01:36 PM, Linus Torvalds wrote: > On Wed, Nov 30, 2016 at 10:28 AM, Prarit Bhargava wrote: > ]> >> In my case I tracked this to commit 3637efb00864 ("x86/mce: Add PCI quirks to >> identify Xeons with machine check recovery") which adds the inclu

Re: Odd build breakage in 4.9-rc7

On 11/30/2016 01:18 PM, Linus Torvalds wrote: > On Wed, Nov 30, 2016 at 9:24 AM, Jarod Wilson wrote: >> >> Now, if I omit the -j8 and do a single-threaded build, then things work >> fine. Prarit bisected this failure to commit >> 9a6fb28a355d2609ace4dab4e6425442c647894d, and

Re: Odd build breakage in 4.9-rc7

On 11/30/2016 01:18 PM, Linus Torvalds wrote: > On Wed, Nov 30, 2016 at 9:24 AM, Jarod Wilson wrote: >> >> Now, if I omit the -j8 and do a single-threaded build, then things work >> fine. Prarit bisected this failure to commit >> 9a6fb28a355d2609ace4dab4e6425442c647894d, and indeed, when

[PATCH v2] ACPI / APEI: Fix NMI notification handling

g NMI_HANDLED and only calling the work queue if NMI_HANDLED has been set. v2: Borislav, setting of NMI_HANDLED moved & cleaned up changelog. Fixes: 2383844d4850 ("GHES: Elliminate double-loop in the NMI handler") Signed-off-by: Prarit Bhargava <pra...@redhat.com> Cc: Bo

[PATCH v2] ACPI / APEI: Fix NMI notification handling

g NMI_HANDLED and only calling the work queue if NMI_HANDLED has been set. v2: Borislav, setting of NMI_HANDLED moved & cleaned up changelog. Fixes: 2383844d4850 ("GHES: Elliminate double-loop in the NMI handler") Signed-off-by: Prarit Bhargava Cc: Borislav Petkov Cc: Rafael J. Wysocki

[PATCH] ACPI / APEI: Fix NMI notification handling

e-loop in the NMI handler") by properly returning NMI_HANDLED and only calling the work queue if NMI_HANDLED has been set. Fixes: 2383844d4850 ("GHES: Elliminate double-loop in the NMI handler") Signed-off-by: Prarit Bhargava <pra...@redhat.com> Cc: Borislav Petkov <b...@suse.de> C

[PATCH] ACPI / APEI: Fix NMI notification handling

e-loop in the NMI handler") by properly returning NMI_HANDLED and only calling the work queue if NMI_HANDLED has been set. Fixes: 2383844d4850 ("GHES: Elliminate double-loop in the NMI handler") Signed-off-by: Prarit Bhargava Cc: Borislav Petkov Cc: Rafael J. Wysocki Cc: Len Brown Cc: Pau

[PATCH] kernel/watchdog.c: Do not hardcode CPU 0 as the initial thread

be used to set and clear the value of firstcpu_err. firstcpu_err is set when the first watchdog thread is enabled, and cleared when the last watchdog thread is disabled. This patch is based on top of linux-next akpm-base. Signed-off-by: Prarit Bhargava <pra...@redhat.com> Cc: Borislav Pet

[PATCH] kernel/watchdog.c: Do not hardcode CPU 0 as the initial thread

be used to set and clear the value of firstcpu_err. firstcpu_err is set when the first watchdog thread is enabled, and cleared when the last watchdog thread is disabled. This patch is based on top of linux-next akpm-base. Signed-off-by: Prarit Bhargava Cc: Borislav Petkov Cc: Tejun Heo Cc

Re: [PATCH] kernel/watchdog.c: Only output hw-PMU message once

On 11/21/2016 12:48 PM, Don Zickus wrote: > On Mon, Nov 21, 2016 at 11:35:19AM -0500, Prarit Bhargava wrote: >> When CONFIG_BOOTPARAM_HOTPLUG_CPU0 is enabled, the socket containing the >> boot cpu can be replaced. During the hot add event, the message >> >> NMI wa

Re: [PATCH] kernel/watchdog.c: Only output hw-PMU message once

On 11/21/2016 12:48 PM, Don Zickus wrote: > On Mon, Nov 21, 2016 at 11:35:19AM -0500, Prarit Bhargava wrote: >> When CONFIG_BOOTPARAM_HOTPLUG_CPU0 is enabled, the socket containing the >> boot cpu can be replaced. During the hot add event, the message >> >> NMI wa

[PATCH] kernel/watchdog.c: Only output hw-PMU message once

and the message has caused confusion for users of systems that support socket removal. This patch modifies the message so that it only outputs a single time during runtime. Signed-off-by: Prarit Bhargava <pra...@redhat.com> Cc: Borislav Petkov <b...@suse.de> Cc: Tejun Heo <t...@kern

[PATCH] kernel/watchdog.c: Only output hw-PMU message once

and the message has caused confusion for users of systems that support socket removal. This patch modifies the message so that it only outputs a single time during runtime. Signed-off-by: Prarit Bhargava Cc: Borislav Petkov Cc: Tejun Heo Cc: Don Zickus Cc: Hidehiro Kawai Cc: Thomas Gleixner

Re: [PATCH] arch/x86: Don't try to poke disabled/non-existent APIC

right fix, but at least my > P3 machine boots again. > > Cc: sta...@vger.kernel.org > Cc: Ingo Molnar <mi...@redhat.com> > Cc: "H. Peter Anvin" <h...@zytor.com> > Cc: x...@kernel.org > Cc: Prarit Bhargava <pra...@redhat.com> > Cc: Peter Zijlstra

Re: [PATCH] arch/x86: Don't try to poke disabled/non-existent APIC

3 machine boots again. > > Cc: sta...@vger.kernel.org > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: x...@kernel.org > Cc: Prarit Bhargava > Cc: Peter Zijlstra > Cc: Len Brown > Cc: Borislav Petkov > Cc: Andi Kleen > Cc: Jiri Olsa > Cc: Ju

Re: [PATCH] arch/x86: Remove second call to topology_update_package_map()

On 10/12/2016 06:06 PM, Tim Chen wrote: > On Wed, 2016-10-12 at 16:54 -0400, Prarit Bhargava wrote: >> >> On 10/12/2016 03:51 PM, Tim Chen wrote: >>> >>> On Wed, 2016-10-12 at 11:06 -0400, Prarit Bhargava wrote: >>>> >>&g

Re: [PATCH] arch/x86: Remove second call to topology_update_package_map()

On 10/12/2016 06:06 PM, Tim Chen wrote: > On Wed, 2016-10-12 at 16:54 -0400, Prarit Bhargava wrote: >> >> On 10/12/2016 03:51 PM, Tim Chen wrote: >>> >>> On Wed, 2016-10-12 at 11:06 -0400, Prarit Bhargava wrote: >>>> >>&g

Re: [PATCH] arch/x86: Remove second call to topology_update_package_map()

On 10/12/2016 03:51 PM, Tim Chen wrote: > On Wed, 2016-10-12 at 11:06 -0400, Prarit Bhargava wrote: >> >> On 10/12/2016 10:36 AM, Prarit Bhargava wrote: >>> >>> This was noticed during the investigation of >>> >>> http://git.kernel.org/tip/2a51

Re: [PATCH] arch/x86: Remove second call to topology_update_package_map()

On 10/12/2016 03:51 PM, Tim Chen wrote: > On Wed, 2016-10-12 at 11:06 -0400, Prarit Bhargava wrote: >> >> On 10/12/2016 10:36 AM, Prarit Bhargava wrote: >>> >>> This was noticed during the investigation of >>> >>> http://git.kernel.org/tip/2a51

Re: [PATCH] arch/x86: Remove second call to topology_update_package_map()

On 10/12/2016 10:36 AM, Prarit Bhargava wrote: > This was noticed during the investigation of > > http://git.kernel.org/tip/2a51fe083eba7f99cbda72f5ef90cdf2f4df882c > > A note for reviewers on the cleanup in smp_init_package_map(): The > per_cpu variable x86_bios_cpu_api

Re: [PATCH] arch/x86: Remove second call to topology_update_package_map()

On 10/12/2016 10:36 AM, Prarit Bhargava wrote: > This was noticed during the investigation of > > http://git.kernel.org/tip/2a51fe083eba7f99cbda72f5ef90cdf2f4df882c > > A note for reviewers on the cleanup in smp_init_package_map(): The > per_cpu variable x86_bios_cpu_api

[PATCH] arch/x86: Remove second call to topology_update_package_map()

y. This patch drops the later call in smp_init_package_map() and moves smp_init_package_map() out of smp_store_boot_cpu_info(). Signed-off-by: Prarit Bhargava <pra...@redhat.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: "H. Peter Anvin"

[PATCH] arch/x86: Remove second call to topology_update_package_map()

y. This patch drops the later call in smp_init_package_map() and moves smp_init_package_map() out of smp_store_boot_cpu_info(). Signed-off-by: Prarit Bhargava Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: Peter Zijlstra Cc: Len Brown Cc: Borislav P

[tip:x86/urgent] arch/x86: Handle non enumerated CPU after physical hotplug

Commit-ID: 2a51fe083eba7f99cbda72f5ef90cdf2f4df882c Gitweb: http://git.kernel.org/tip/2a51fe083eba7f99cbda72f5ef90cdf2f4df882c Author: Prarit Bhargava <pra...@redhat.com> AuthorDate: Mon, 3 Oct 2016 13:07:12 -0400 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate

[tip:x86/urgent] arch/x86: Handle non enumerated CPU after physical hotplug

Commit-ID: 2a51fe083eba7f99cbda72f5ef90cdf2f4df882c Gitweb: http://git.kernel.org/tip/2a51fe083eba7f99cbda72f5ef90cdf2f4df882c Author: Prarit Bhargava AuthorDate: Mon, 3 Oct 2016 13:07:12 -0400 Committer: Thomas Gleixner CommitDate: Fri, 7 Oct 2016 15:22:15 +0200 arch/x86: Handle non

Re: [PATCH] arch/x86: Fix kdump on x86 with physically hotadded CPUs

On 10/05/2016 12:14 PM, Jiri Olsa wrote: > On Tue, Oct 04, 2016 at 04:38:16PM +0200, Thomas Gleixner wrote: >> On Tue, 4 Oct 2016, Prarit Bhargava wrote: >>> On 10/04/2016 06:58 AM, Thomas Gleixner wrote: >>>> While it is the right thing to initialize the package m

Re: [PATCH] arch/x86: Fix kdump on x86 with physically hotadded CPUs

On 10/05/2016 12:14 PM, Jiri Olsa wrote: > On Tue, Oct 04, 2016 at 04:38:16PM +0200, Thomas Gleixner wrote: >> On Tue, 4 Oct 2016, Prarit Bhargava wrote: >>> On 10/04/2016 06:58 AM, Thomas Gleixner wrote: >>>> While it is the right thing to initialize the package m

Re: [PATCH] arch/x86: Fix kdump on x86 with physically hotadded CPUs

On 10/04/2016 10:38 AM, Thomas Gleixner wrote: > On Tue, 4 Oct 2016, Prarit Bhargava wrote: >> On 10/04/2016 06:58 AM, Thomas Gleixner wrote: >>> While it is the right thing to initialize the package map in that case, it >>> still papers over a robustness issue in t

Re: [PATCH] arch/x86: Fix kdump on x86 with physically hotadded CPUs

On 10/04/2016 10:38 AM, Thomas Gleixner wrote: > On Tue, 4 Oct 2016, Prarit Bhargava wrote: >> On 10/04/2016 06:58 AM, Thomas Gleixner wrote: >>> While it is the right thing to initialize the package map in that case, it >>> still papers over a robustness issue in t

Re: [PATCH] arch/x86: Fix kdump on x86 with physically hotadded CPUs

On 10/04/2016 06:58 AM, Thomas Gleixner wrote: > On Mon, 3 Oct 2016, Prarit Bhargava wrote: >> BUG: unable to handle kernel paging request at 00841f1f >> IP: [] uncore_change_context+0xd4/0x180 > ... >> [] ? uncore_cpu_starting+0x130/0x130 >> [] unc

Re: [PATCH] arch/x86: Fix kdump on x86 with physically hotadded CPUs

On 10/04/2016 06:58 AM, Thomas Gleixner wrote: > On Mon, 3 Oct 2016, Prarit Bhargava wrote: >> BUG: unable to handle kernel paging request at 00841f1f >> IP: [] uncore_change_context+0xd4/0x180 > ... >> [] ? uncore_cpu_starting+0x130/0x130 >> [] unc

[PATCH] arch/x86: Fix kdump on x86 with physically hotadded CPUs

(). The comment beside the call to smp_store_boot_cpu_info() states that the completed call results in "Final full version of the data". Signed-off-by: Prarit Bhargava <pra...@redhat.com> Fixes: 1f12e32f4cd5 ("x86/topology: Create logical package id") Cc: Thomas Gleixner <t.

[PATCH] arch/x86: Fix kdump on x86 with physically hotadded CPUs

(). The comment beside the call to smp_store_boot_cpu_info() states that the completed call results in "Final full version of the data". Signed-off-by: Prarit Bhargava Fixes: 1f12e32f4cd5 ("x86/topology: Create logical package id") Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On 09/28/2016 02:48 AM, Peter Zijlstra wrote: > On Tue, Sep 27, 2016 at 11:26:14AM -0400, Prarit Bhargava wrote: >> I see now that the issue is not understanding the difference between physical >> and soft thread removal. I will write that up and get back to everyone. >

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On 09/28/2016 02:48 AM, Peter Zijlstra wrote: > On Tue, Sep 27, 2016 at 11:26:14AM -0400, Prarit Bhargava wrote: >> I see now that the issue is not understanding the difference between physical >> and soft thread removal. I will write that up and get back to everyone. >

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On 09/27/2016 09:49 AM, Greg Kroah-Hartman wrote: > On Tue, Sep 27, 2016 at 07:45:56AM -0400, Prarit Bhargava wrote: >> On 09/26/2016 07:57 AM, Borislav Petkov wrote: >>> $ echo 0 > /sys/devices/system/cpu/cpu2/online >> >> This results in the topology directo

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On 09/27/2016 09:49 AM, Greg Kroah-Hartman wrote: > On Tue, Sep 27, 2016 at 07:45:56AM -0400, Prarit Bhargava wrote: >> On 09/26/2016 07:57 AM, Borislav Petkov wrote: >>> $ echo 0 > /sys/devices/system/cpu/cpu2/online >> >> This results in the topology directo

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On 09/26/2016 07:59 AM, Peter Zijlstra wrote: > On Mon, Sep 26, 2016 at 07:45:37AM -0400, Prarit Bhargava wrote: >>> But then code which reads those will have to *know* that those cores are >>> offline - otherwise it would be confused by what it is reading there. >> &g

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On 09/26/2016 07:59 AM, Peter Zijlstra wrote: > On Mon, Sep 26, 2016 at 07:45:37AM -0400, Prarit Bhargava wrote: >>> But then code which reads those will have to *know* that those cores are >>> offline - otherwise it would be confused by what it is reading there. >> &g

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On 09/26/2016 07:57 AM, Borislav Petkov wrote: > On Mon, Sep 26, 2016 at 07:45:37AM -0400, Prarit Bhargava wrote: >> When offline, /sys/devices/system/cpuX/cpu/online is 0. The problem is that >> when online is 0, topology disappears so there is no way to determine _t

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On 09/26/2016 07:57 AM, Borislav Petkov wrote: > On Mon, Sep 26, 2016 at 07:45:37AM -0400, Prarit Bhargava wrote: >> When offline, /sys/devices/system/cpuX/cpu/online is 0. The problem is that >> when online is 0, topology disappears so there is no way to determine _t

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On 09/22/2016 08:10 AM, Borislav Petkov wrote: > On Thu, Sep 22, 2016 at 07:59:08AM -0400, Prarit Bhargava wrote: >> System boots with (usually) with 2 threads/core. Some performance users want >> one thread per core. Since there is no "noht" option anymore, users u

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On 09/22/2016 08:10 AM, Borislav Petkov wrote: > On Thu, Sep 22, 2016 at 07:59:08AM -0400, Prarit Bhargava wrote: >> System boots with (usually) with 2 threads/core. Some performance users want >> one thread per core. Since there is no "noht" option anymore, users u

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On 09/21/2016 10:01 AM, Borislav Petkov wrote: > On Wed, Sep 21, 2016 at 09:32:47AM -0400, Prarit Bhargava wrote: >> This is not the right thing to do [1]. The topology directory should exist >> as >> long as the thread is present in the system. The thread (and i

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On 09/21/2016 10:01 AM, Borislav Petkov wrote: > On Wed, Sep 21, 2016 at 09:32:47AM -0400, Prarit Bhargava wrote: >> This is not the right thing to do [1]. The topology directory should exist >> as >> long as the thread is present in the system. The thread (and i

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On 09/21/2016 09:04 AM, Borislav Petkov wrote: > On Wed, Sep 21, 2016 at 07:39:31AM -0400, Prarit Bhargava wrote: >> The information in /sys/devices/system/cpu/cpuX/topology >> directory is useful for userspace monitoring applications and in-tree >> utilities like

<    1   2   3   4   5   6   7   8   9   10   >