On 2/21/19 8:48 AM, Peter Zijlstra wrote:
> On Thu, Feb 21, 2019 at 08:12:25AM -0500, Prarit Bhargava wrote:
>> Users cannot disable multiple CPU features with the kernel parameter
>> clearcpuid=. For example, "clearcpuid=154 clearcpuid=227" only disables
>> C
On 2/21/19 1:58 PM, Andi Kleen wrote:
> On Thu, Feb 21, 2019 at 02:37:45PM +0100, Peter Zijlstra wrote:
>> On Thu, Feb 21, 2019 at 08:12:25AM -0500, Prarit Bhargava wrote:
>>> Users cannot disable multiple CPU features with the kernel parameter
>>> clearcpuid=. F
only
a single value.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Andi Kleen
Cc: x...@kernel.org
Cc: linux-...@vger.kernel.org
---
.../admin-guide/kernel-parameters.txt | 10
arch/
On 2/4/19 10:55 AM, Theodore Y. Ts'o wrote:
> On Sun, Feb 03, 2019 at 08:09:37AM -0500, Prarit Bhargava wrote:
>> Ted, the bug I'm trying to fix is the warning:
>>
>> random: get_random_bytes called from start_kernel+0x8e/0x587 with crng_init=0
>>
>&g
On 2/1/19 10:02 PM, Theodore Y. Ts'o wrote:
> On Fri, Feb 01, 2019 at 01:08:31PM -0500, Prarit Bhargava wrote:
>> After 43838a23a05f ("random: fix crng_ready() test") early boot calls to
>> get_random_bytes() will warn on x86 because the crng is not initialized
back fro h...@zytor.com & ty...@mit.edu
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: "Theodore Ts'o"
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Rik van Riel
Cc: Andrew Morton
Cc: Philippe Ombredanne
On 1/6/19 9:09 AM, Buland Singh wrote:
> On 12/21/18 6:16 PM, Greg KH wrote:
>> On Fri, Dec 21, 2018 at 05:48:38PM +0530, Buland Singh wrote:
>>> On 12/20/18 7:39 PM, Greg KH wrote:
On Thu, Dec 20, 2018 at 07:12:55PM +0530, Buland Singh wrote:
> On 12/20/18 5:59 PM, Greg KH wrote:
>
On 11/19/2018 11:28 AM, Greg Kroah-Hartman wrote:
> 3.18-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Prarit Bhargava
>
> [ Upstream commit f69ffc5d3db8f1f03fd6d1df5930f9a1fbd787b6 ]
Greg, as previously men
On 10/31/2018 07:03 PM, Sasha Levin wrote:
> From: Prarit Bhargava
>
> [ Upstream commit f69ffc5d3db8f1f03fd6d1df5930f9a1fbd787b6 ]
>
> cpupower crashes on VMWare guests. The guests have the AMD PStateDef MSR
> (0xC0010064 + state number) set to zero. As a result fid and
On 10/25/2018 01:12 PM, patrickg wrote:
> Resurrecting w/ +prarit who was handling mentions in a RHEL bug report
> regarding this.
>
Patrick can you reply back with the entire patch?
Thanks,
P.
Commit-ID: 370a132bb2227ff76278f98370e0e701d86ff752
Gitweb: https://git.kernel.org/tip/370a132bb2227ff76278f98370e0e701d86ff752
Author: Prarit Bhargava
AuthorDate: Tue, 31 Jul 2018 07:27:39 -0400
Committer: Thomas Gleixner
CommitDate: Sun, 2 Sep 2018 14:10:54 +0200
x86/microcode: Make
r earlycon argumentsworks (no output as expected)
v2: Fix prototype.
v3: Change parameter to "spcr" and add error message to spcr init call.
v4: move spcr to x86 (really make it arch specific)
Signed-off-by: Prarit Bhargava
Cc: Petr Mladek
Cc: Sergey Senozhatsky
---
Docume
r earlycon argumentsworks (no output as expected)
v2: Fix prototype.
v3: Change parameter to "spcr" and add error message to spcr init call.
Signed-off-by: Prarit Bhargava
Cc: Mark Salter
Cc: Al Stone
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Pavel Machek
Cc: x..
On 08/17/2018 08:57 AM, Petr Mladek wrote:
> On Fri 2018-08-17 07:06:56, Prarit Bhargava wrote:
>> On 08/17/2018 06:50 AM, Sergey Senozhatsky wrote:
>>>> Like I mentioned to Petr, I'd like to know if you (or anyone else) has
>>>> strong
>>>> fe
c-8568-eaa3-d4b0c326c...@redhat.com
>
> On (08/17/18 06:36), Prarit Bhargava wrote:
>> On 08/17/2018 05:38 AM, Sergey Senozhatsky wrote:
>>> On (08/16/18 13:39), Prarit Bhargava wrote:
>>>>
>>>> + auto[X86] Enable ACPI SPCR console
>>>
On 08/17/2018 05:38 AM, Sergey Senozhatsky wrote:
> On (08/16/18 13:39), Prarit Bhargava wrote:
>>
>> +auto[X86] Enable ACPI SPCR console
>
> And arm64?
Hi Sergey, on arm64 if an SPCR is present the early co
On 08/17/2018 04:19 AM, Petr Mladek wrote:
> On Thu 2018-08-16 13:39:01, Prarit Bhargava wrote:
>> ACPI may contain an SPCR table that defines a default system console.
>> On ARM if the table is present then the SPCR console is enabled by default.
>> On x86 the SPCR console
r earlycon argumentsworks (no output as expected)
v2: Fix prototype.
Signed-off-by: Prarit Bhargava
Cc: Mark Salter
Cc: Al Stone
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Pavel Machek
Cc: x...@kernel.org
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: Steven Ros
On 08/16/2018 11:33 AM, Steven Rostedt wrote:
> On Thu, 16 Aug 2018 11:28:24 -0400
> Prarit Bhargava wrote:
>
>> On 08/16/2018 11:09 AM, Greg Kroah-Hartman wrote:
>>> On Thu, Aug 16, 2018 at 10:10:55AM -0400, Prarit Bhargava wrote:
>>>> ACPI may contain
On 08/16/2018 11:09 AM, Greg Kroah-Hartman wrote:
> On Thu, Aug 16, 2018 at 10:10:55AM -0400, Prarit Bhargava wrote:
>> ACPI may contain an SPCR table that defines a default system console.
>> On ARM if the table is present then the SPCR console is enabled by default.
>> On
r earlycon argumentsworks (no output as expected)
Signed-off-by: Prarit Bhargava
Cc: Mark Salter
Cc: Al Stone
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Pavel Machek
Cc: x...@kernel.org
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Cc: Kees Cook
On 08/08/2018 03:58 PM, Pavel Machek wrote:
> On Wed 2018-08-08 13:47:35, Prarit Bhargava wrote:
>> commit 5209654a46ee ("x86/ACPI/cstate: Allow ACPI C1 FFH MWAIT use on AMD
>> systems") allows use of FFH for ACPI C1 but tools like cpupower and turbostat
>&g
commit 5209654a46ee ("x86/ACPI/cstate: Allow ACPI C1 FFH MWAIT use on AMD
systems") allows use of FFH for ACPI C1 but tools like cpupower and turbostat
display INTEL for the cstate description.
Output "AMD" for AMD systems with FFH for ACPI C1.
Signed-off-by: Prarit Bhargav
On 08/01/2018 11:43 AM, Borislav Petkov wrote:
> (dropping stable@)
>
> On Tue, Jul 31, 2018 at 07:27:39AM -0400, Prarit Bhargava wrote:
>> I tested this on AMD Ryzen & Intel Broadwell system and dumped the
>> boot_cpu_data before and after a microcode update. On t
ing runtime.
>>
>> Update boot_cpu_data.microcode when the BSP's microcode is updated.
>>
>> Fixes: fa94d0c6e0f3 ("x86/MCE: Save microcode revision in machine check
>> records")
>> Suggested-by: Borislav Petkov
>> Signed-off-by: Prarit Bharg
Suggested-by: Borislav Petkov
Signed-off-by: Prarit Bhargava
Cc: sta...@vger.kernel.org
Cc: sir...@amazon.de
Cc: tony.l...@intel.com
---
Changes in v2: Use mc_amd->hdr.patch_id on AMD
arch/x86/kernel/cpu/microcode/amd.c | 4
arch/x86/kernel/cpu/microcode/intel.c | 4
2 files chang
On 07/30/2018 01:49 PM, Prarit Bhargava wrote:
> On systems where a runtime microcode update has occurred the microcode
> version output in a MCE log record is wrong because
> boot_cpu_data.microcode is not updated during runtime.
>
> Update boot_cpu_data.microcode when the BSP
microcode revision in machine check
records")
Suggested-by: Borislav Petkov
Signed-off-by: Prarit Bhargava
Cc: sta...@vger.kernel.org
Cc: sir...@amazon.de
Cc: tony.l...@intel.com
---
arch/x86/kernel/cpu/microcode/amd.c | 4
arch/x86/kernel/cpu/microcode/intel.c | 4
2 files change
On 07/03/2018 05:43 PM, Borislav Petkov wrote:
> On Tue, Jul 03, 2018 at 09:58:49AM -0700, Luck, Tony wrote:
>> On Tue, Jul 03, 2018 at 12:48:44PM -0400, Prarit Bhargava wrote:
>>> On systems where a runtime microcode update has occurred the
>>> microco
On 07/06/2018 02:44 PM, Don Zickus wrote:
> On Fri, Jul 06, 2018 at 11:31:13AM -0700, Joe Perches wrote:
>> On Fri, 2018-07-06 at 13:54 -0400, Don Zickus wrote:
>>> On Tue, Jun 26, 2018 at 01:16:11PM -0700, Joe Perches wrote:
>>>> On Tue, 2018-06-26 at 14:2
On 07/03/2018 12:58 PM, Luck, Tony wrote:
> On Tue, Jul 03, 2018 at 12:48:44PM -0400, Prarit Bhargava wrote:
>> On systems where a runtime microcode update has occurred the
>> microcode version is wrong because boot_cpu_data.microcode is
>> not updated during runtime.
On systems where a runtime microcode update has occurred the
microcode version is wrong because boot_cpu_data.microcode is
not updated during runtime.
Use the per-CPU microcode version in the MCE message.
Signed-off-by: Prarit Bhargava
Cc: Tony Luck
Cc: Borislav Petkov
Cc: Thomas Gleixner
Cc
On 06/26/2018 07:04 PM, Joe Perches wrote:
> On Tue, 2018-06-26 at 18:52 -0400, Prarit Bhargava wrote:
>>
>> On 06/26/2018 04:16 PM, Joe Perches wrote:
>>> On Tue, 2018-06-26 at 14:25 -0400, Prarit Bhargava wrote:
>>>> OSes have additional maintainers t
On 06/26/2018 04:16 PM, Joe Perches wrote:
> On Tue, 2018-06-26 at 14:25 -0400, Prarit Bhargava wrote:
>> OSes have additional maintainers that should be cc'd on patches or may
>> want to circulate internal patches.
>>
>> Parse the .get_maintainer.MAINTAINERS f
ut, or a '-' to indicate that the
entries should override the existing MAINTAINERS file.
Also add a help entry for the .get_maintainers.ignore file.
Signed-off-by: Prarit Bhargava
Cc: Joe Perches
Cc: dzic...@redhat.com
Cc: jtopp...@redhat.com
---
scrip
On 05/29/2018 12:07 PM, Theodore Y. Ts'o wrote:
> On Tue, May 29, 2018 at 11:01:07AM -0400, Prarit Bhargava wrote:
>> Kees, in early boot no pool is available so the stack canary is initialized
>> from
>> the TSC. Later in boot, the stack canary will use the the crn
On 05/29/2018 10:49 AM, Kees Cook wrote:
> On Tue, May 29, 2018 at 5:38 AM, Prarit Bhargava wrote:
>> After 43838a23a05f ("random: fix crng_ready() test") early boot calls
>> to get_random_bytes() will warn on each cpu on x86 because the crng
>> is not initiali
for better randomization of the stack
canary value so the warning is of no consequence.
Export crng_ready() for x86 and test if the crng is initialized before
calling get_random_bytes().
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc
On 02/12/2018 10:44 AM, Peter Zijlstra wrote:
> On Mon, Feb 12, 2018 at 10:18:06AM -0500, Prarit Bhargava wrote:
>>> But when I specify "earlyprintk=serial,ttyS0,115200" this SPCR crud will
>>> not interfere?
>>>
>>
>> I tested "early
On 02/12/2018 09:56 AM, Peter Zijlstra wrote:
> On Mon, Feb 12, 2018 at 08:47:57AM -0500, Prarit Bhargava wrote:
>>
>>
>> On 02/12/2018 08:34 AM, Peter Zijlstra wrote:
>>> On Thu, Jan 18, 2018 at 10:09:51AM -0500, Prarit Bhargava wrote:
>>>> config ACPI
On 02/12/2018 09:43 AM, Timur Tabi wrote:
> On 2/12/18 7:47 AM, Prarit Bhargava wrote:
>> ACPI SPCR is used by a vendor to define the serial console for a system. If
>> SPCR exists a user can add kernel parameter "earlycon" (no extra kernel
>> parameters) and t
On 02/12/2018 08:34 AM, Peter Zijlstra wrote:
> On Thu, Jan 18, 2018 at 10:09:51AM -0500, Prarit Bhargava wrote:
>> config ACPI_SPCR_TABLE
>> +bool "ACPI Serial Port Console Redirection Support"
>> +default y if X86
>> +help
>> +
The kernel panics on PV domains because native_smp_cpus_done() is
only called for HVM domains.
Calculate __max_logical_packages for PV domains.
Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate")
Signed-off-by: Prarit Bhargava
Tested-and-reported-by: Simon
On 02/07/2018 02:26 PM, Simon Gaiser wrote:
> Prarit Bhargava:
>> On 02/07/2018 01:44 PM, Simon Gaiser wrote:
>>> This breaks booting as Xen PV domain for me. The problem seems to be
>>> that native_smp_cpus_done() is never called on a PV domain. So
>>> __m
On 02/07/2018 01:44 PM, Simon Gaiser wrote:
> Prarit Bhargava:
>> A system booted with a small number of cores enabled per package
>> panics because the estimate of __max_logical_packages is too low.
>> This occurs when the total number of active cores across all package
On 01/22/2018 04:49 PM, Timur Tabi wrote:
> On 01/18/2018 09:09 AM, Prarit Bhargava wrote:
>> if (acpi_disabled) {
>> -if (earlycon_init_is_deferred)
>> +if (earlycon_acpi_spcr_enable)
>
> This patch works for me, so I can ACK it, but fir
y
by default. Modify acpi_parse_spcr() to allow options for initializing
the early console and console separately.
Signed-off-by: Prarit Bhargava
Cc: linux-a...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux...@vger.kernel.org
Cc: linux-ser...@vger.k
[Sorry everyone for the late response, I went away on vacation and pushed this
off until I returned.]
On 12/13/2017 07:45 AM, Lorenzo Pieralisi wrote:
> [+Mark, Graeme]
>
> In $SUBJECT, s/avialable/available
>
> On Mon, Dec 11, 2017 at 10:50:58AM -0500, Prarit Bhargava
if SMT is disabled.
topology_max_smt_threads() already returns the active number of threads.
Introduce topology_hw_smt_threads() which returns the maximum number of
threads. These are used to fix and replace references to smp_num_siblings.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: I
Oops. Forgot to cc everyone.
Please ignore.
P.
On 01/04/2018 06:26 AM, Prarit Bhargava wrote:
> Commit bbb65d2d365e ("x86: use cpuid vector 0xb when available for
> detecting cpu topology") changed the value of smp_num_siblings from the
> active number of threads in a
if SMT is disabled.
topology_max_smt_threads() already returns the active number of threads.
Introduce topology_hw_smt_threads() which returns the maximum number of
threads. These are used to fix and replace references to smp_num_siblings.
Signed-off-by: Prarit Bhargava
---
Documentation/x86/to
z, and the TSC refined calibration will
> update tsc_khz to correct for the difference.
>
> This patch restores correctness. Without it, all three of the
> issues above occur.
>
> Signed-off-by: Len Brown
> Cc: Prarit Bhargava
> Cc: # v4.9+
> ---
> arch/x86/ker
The ACPI SPCR code has been used to define an earlycon console for ARM64
and can be used for x86.
Modify the ACPI SPCR parsing code to account for console behaviour
differences between ARM64 and x86. Initialize the SPCR code from
x86 ACPI initialization code.
Signed-off-by: Prarit Bhargava
Cc
systems to test Qualcomm quirks, HPE Mantis system to test xgene
quirks. Tested several x86 systems with and without a SPCR to confirm
no changes in default behaviour.
[v2]: See 1/2 for code changes.
Signed-off-by: Prarit Bhargava
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc
Documention on the use of
the SPCR.
[v2]: Don't return an error in the baud_rate check of acpi_parse_spcr().
Keep ACPI_SPCR_TABLE selected for ARM64. Fix 8-bit port access width
mmio value. Move baud rate check earlier.
Signed-off-by: Prarit Bhargava
Cc: linux-...@vger.kernel.org
Cc: linux-k
On 12/07/2017 01:43 PM, Timur Tabi wrote:
> On Thu, Dec 7, 2017 at 11:29 AM, Prarit Bhargava wrote:
>> Other architectures can use SPCR to setup an early console or console but
>> the current code is ARM64 specific.
>>
>> Change the name of parse_spcr() to acp
On 12/08/2017 10:31 AM, Jeffrey Hugo wrote:
> On 12/8/2017 7:29 AM, Prarit Bhargava wrote:
>>
>>
>> On 12/08/2017 01:29 AM, Ingo Molnar wrote:
>>>
>>> * Prarit Bhargava wrote:
>>>
>>>> The SPCR (Serial Port Console Redirection) Table
On 12/08/2017 01:29 AM, Ingo Molnar wrote:
>
> * Prarit Bhargava wrote:
>
>> The SPCR (Serial Port Console Redirection) Table provides information
>> about the configuration of serial port. This information can be used
>> to configure the early console.
>
On 12/07/2017 01:43 PM, Timur Tabi wrote:
> On Thu, Dec 7, 2017 at 11:29 AM, Prarit Bhargava wrote:
>> Other architectures can use SPCR to setup an early console or console but
>> the current code is ARM64 specific.
>>
>> Change the name of parse_spcr() to acp
On 12/07/2017 01:46 PM, Timur Tabi wrote:
> On Thu, Dec 7, 2017 at 11:29 AM, Prarit Bhargava wrote:
>> -int __init acpi_parse_spcr(bool earlycon)
>> +int __init acpi_parse_spcr(bool earlycon, bool enable_console)
>> {
>> static char opts[ACPI_SPCR_OPTS_SI
code. Update the
Documention on the use of the SPCR earlycon.
This patch does not change arm64 behaviour.
Signed-off-by: Prarit Bhargava
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux...@vger.kernel.org
Cc: linux-a
The ACPI SPCR code has been used to define an earlycon console for arm64
and can be used for x86.
Modify the ACPI SPCR parsing code to account for console behaviour
differences between arm64 and x86. Initialize the SPCR code from
x86 ACPI initialization code.
Signed-off-by: Prarit Bhargava
Cc
earlycon parameter is defined and the SPCR exists , the serial port is not
configured. If the earlycon parameter is used both the early console
and the console are configured using the data from the SPCR.
Signed-off-by: Prarit Bhargava
Cc: linux-...@vger.kernel.org
Cc: linux-kernel
Commit-ID: 947134d9b00f342415af7eddd42a5fce7262a1b9
Gitweb: https://git.kernel.org/tip/947134d9b00f342415af7eddd42a5fce7262a1b9
Author: Prarit Bhargava
AuthorDate: Mon, 4 Dec 2017 11:45:21 -0500
Committer: Thomas Gleixner
CommitDate: Thu, 7 Dec 2017 10:28:22 +0100
x86/smpboot: Do not
A single socket, single core, single thread system has __max_smt_threads
set to 0 since smp_callin() is not called.
__max_smt_threads must be a minimum of 1.
Fixes: b1cbacc8663a ("x86/smpboot: Do not use smp_num_siblings in
__max_logical_packages calculation)
Signed-off-by: Prarit Bhargav
threads
set to 0 since smp_callin() is not called.
__max_smt_threads must be a minimum of 1.
Fixes: b1cbacc8663a ("x86/smpboot: Do not use smp_num_siblings in
__max_logical_packages calculation)
Signed-off-by: Prarit Bhargava
Cc: Jakub Kicinski
Cc: net...@vger.kernel.org
Cc: "net...@vg
: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate")
> Reported-by: Jakub Kicinski
> Signed-off-by: Prarit Bhargava Signed-off-by: Thomas Gleixner
> Tested-by: Jakub Kicinski
> Cc: net...@vger.kernel.org
> Cc: "net...@vger.k
Commit-ID: b1cbacc8663a4dce62e4ae501e859c82f4aeb1ca
Gitweb: https://git.kernel.org/tip/b1cbacc8663a4dce62e4ae501e859c82f4aeb1ca
Author: Prarit Bhargava
AuthorDate: Mon, 4 Dec 2017 11:45:21 -0500
Committer: Thomas Gleixner
CommitDate: Mon, 4 Dec 2017 23:03:48 +0100
x86/smpboot: Do not
On 12/04/2017 08:13 AM, Prarit Bhargava wrote:
>
>
> x86: Booting SMP configuration:
> node #0, CPUs:#1 #2 #3 #4
> node #1, CPUs:#5 #6 #7 #8 #9
> node #0, CPUs: #10 #11 #12 #13 #14
> node #1, CPUs: #15 #16 #17 #18 #19
> smp
On 12/04/2017 07:28 AM, Prarit Bhargava wrote:
>
>
> On 12/03/2017 08:28 PM, Jakub Kicinski wrote:
>> Same thing on rc2, bisected down to:
>>
>> commit b4c0a7326f5dc0ef7a64128b0ae7d081f4b2cbd1 (refs/bisect/bad)
>> Author: Prarit Bhargava
>> Date: Tue N
On 12/03/2017 08:28 PM, Jakub Kicinski wrote:
> Same thing on rc2, bisected down to:
>
> commit b4c0a7326f5dc0ef7a64128b0ae7d081f4b2cbd1 (refs/bisect/bad)
> Author: Prarit Bhargava
> Date: Tue Nov 14 07:42:57 2017 -0500
>
> x86/smpboot: Fix __max_logical_packages es
On 11/23/2017 07:58 AM, Petr Mladek wrote:
> On Wed 2017-11-15 19:15:38, Thomas Gleixner wrote:
>> For demonstration purposes only.
>>
>> Add a disgusting hack to work around the fact that high resolution clock
>> MONOTONIC accessors are not available during early boot and return stale
>> time st
Commit-ID: b4c0a7326f5dc0ef7a64128b0ae7d081f4b2cbd1
Gitweb: https://git.kernel.org/tip/b4c0a7326f5dc0ef7a64128b0ae7d081f4b2cbd1
Author: Prarit Bhargava
AuthorDate: Tue, 14 Nov 2017 07:42:57 -0500
Committer: Thomas Gleixner
CommitDate: Fri, 17 Nov 2017 16:22:31 +0100
x86/smpboot: Fix
On 11/14/2017 05:03 AM, Petr Mladek wrote:
> On Mon 2017-11-13 17:18:33, Linus Torvalds wrote:
>> On Mon, Nov 13, 2017 at 1:36 AM, Thomas Gleixner wrote:
>>> Linus,
>>>
>>> please pull the latest core-printk-for-linus git tree from:
>>>
>>>git://git.kernel.org/pub/scm/linux/kernel/git/tip/ti
stored.
Signed-off-by: Andi Kleen
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Dave Hansen
Cc: Piotr Luc
Cc: Kan Liang
Cc: Borislav Petkov
Cc: Stephane Eranian
Cc: Prarit Bhargava
Cc: Arvind Yadav
tten to a cpu's
cpu_data.
Signed-off-by: Andi Kleen
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Dave Hansen
Cc: Piotr Luc
Cc: Kan Liang
Cc: Borislav Petkov
Cc: Stephane Er
er Zijlstra
Cc: Andi Kleen
Cc: Dave Hansen
Cc: Piotr Luc
Cc: Kan Liang
Cc: Borislav Petkov
Cc: Stephane Eranian
Cc: Prarit Bhargava
Cc: Arvind Yadav
Cc: Andy Lutomirski
Cc: Christian Borntraeger
Cc: "Kirill A. Shutemov"
Cc: Tom Lendacky
Cc: He Chen
Cc: Mathias Krause
Cc: Tim C
ff-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Dave Hansen
Cc: Piotr Luc
Cc: Kan Liang
Cc: Borislav Petkov
Cc: Stephane Eranian
Cc: Prarit Bhargava
Cc: Arvind Yadav
Cc: Andy Lutomirski
On 11/12/2017 08:36 AM, Thomas Gleixner wrote:
> On Fri, 10 Nov 2017, Andi Kleen wrote:
All of that works. There is no way to make sure that a lookup is fully
serialized against a concurrent update. Even if the lookup holds
cpu_read_lock() the new package might arrive right after t
On 11/10/2017 10:01 AM, Andi Kleen wrote:
>>> All of that works. There is no way to make sure that a lookup is fully
>>> serialized against a concurrent update. Even if the lookup holds
>>> cpu_read_lock() the new package might arrive right after the unlock.
>>>
>>
>> Thanks Thomas.
>>
>> Andi, d
On 11/09/2017 07:43 PM, Thomas Gleixner wrote:
> On Sun, 5 Nov 2017, Prarit Bhargava wrote:
>> [v5]: Change kmalloc to GFP_ATOMIC to fix "sleeping function" warning on
>> virtual machines.
>
> What has this to do with virtual machines? The very same issue is on
&
: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Dave Hansen
Cc: Piotr Luc
Cc: Kan Liang
Cc: Borislav Petkov
Cc: Stephane Eranian
Cc: Prarit Bhargava
Cc: Arvind Yadav
Cc: Andy Lutomirski
Cc: Christian Borntraeger
Cc: "Kirill A. Shutemov"
pinlock to avoid concurrency
issues.
Signed-off-by: Andi Kleen
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Dave Hansen
Cc: Piotr Luc
Cc: Kan Liang
Cc: Borislav Petkov
Cc: Stephane
boot cpu's data to extrapolate the number of packages.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Dave Hansen
Cc: Piotr Luc
Cc: Kan Liang
Cc: Borislav Petkov
Cc: Stephane
er of active cores across
all packages to reproduce the bug above. Additional testing included
2 socket and 4 socket systems and hotplugging entire sockets in different
order.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc:
On 11/01/2017 12:56 PM, Thomas Gleixner wrote:
> On Wed, 25 Oct 2017, Prarit Bhargava wrote:
>> diff --git a/arch/x86/include/asm/processor.h
>> b/arch/x86/include/asm/processor.h
>> index b390ff76e58f..f4ab1edf4e24 100644
>> --- a/arch/x86/include/asm/processor.h
&g
: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Dave Hansen
Cc: Piotr Luc
Cc: Kan Liang
Cc: Borislav Petkov
Cc: Stephane Eranian
Cc: Prarit Bhargava
Cc: Arvind Yadav
Cc: Andy Lutomirski
Cc: Christian Borntraeger
Cc: "Kirill A. Shutemov"
physical package IDs
in synch.
[v4]: Keep logical mapping static by using hybrid approach of a small logical
to physical array and keeping logical cpu information in cpu_data.
Signed-off-by: Andi Kleen
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin&qu
boot cpu's data to extrapolate the number of packages.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Dave Hansen
Cc: Piotr Luc
Cc: Kan Liang
Cc: Borislav Petkov
Cc: Stephane
er of active cores across
all packages to reproduce the bug above. Additional testing included
2 socket and 4 socket systems and hotplugging entire sockets in different
order.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc:
: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Dave Hansen
Cc: Piotr Luc
Cc: Kan Liang
Cc: Borislav Petkov
Cc: Stephane Eranian
Cc: Prarit Bhargava
Cc: Arvind Yadav
Cc: Andy Lutomirski
Cc: Christian Borntraeger
Cc: "Kirill A. Shutemov"
physical package IDs
in synch.
[v4]: Keep logical mapping static by using hybrid approach of a small logical
to physical array and keeping logical cpu information in cpu_data.
Signed-off-by: Andi Kleen
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin&qu
er of active cores across
all packages to reproduce the bug above. Additional testing included
2 socket and 4 socket systems and hotplugging entire sockets in different
order.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc:
boot cpu's data to extrapolate the number of packages.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Dave Hansen
Cc: Piotr Luc
Cc: Kan Liang
Cc: Borislav Petkov
Cc: Stephane
On 10/20/2017 05:03 AM, Thomas Gleixner wrote:
> On Thu, 19 Oct 2017, Prarit Bhargava wrote:
>> static void remove_siblinginfo(int cpu)
>> {
>> -int sibling;
>> +int phys_pkg_id, sibling;
>> struct cpuinfo_x86 *c = &cpu_data(cp
: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Dave Hansen
Cc: Piotr Luc
Cc: Kan Liang
Cc: Borislav Petkov
Cc: Stephane Eranian
Cc: Prarit Bhargava
Cc: Arvind Yadav
Cc: Andy Lutomirski
Cc: Christian Borntraeger
Cc: "Kirill A. Shutemov"
boot cpu's data to extrapolate the number of packages.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Dave Hansen
Cc: Piotr Luc
Cc: Kan Liang
Cc: Borislav Petkov
Cc: Stephane
ar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Dave Hansen
Cc: Piotr Luc
Cc: Kan Liang
Cc: Borislav Petkov
Cc: Stephane Eranian
Cc: Prarit Bhargava
Cc: Arvind Yadav
Cc: Andy Lutomirski
Cc: Christian Borntraeger
Cc: "Kirill A. Shutemov&q
above. Additional testing included
2 socket and 4 socket systems and hotplugging entire sockets in different
order.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Dave Hansen
Cc: Pio
On 10/12/2017 02:44 AM, kernel test robot wrote:
> bin/lkp install job.yaml
[root@hpe-dl385gen10-02 lkp-tests]# ls
allotdaemon filters include Makefile pkgrepospec
bin distro Gemfile jobs monitors plot rootfs stats
cluster doc
101 - 200 of 1031 matches
Mail list logo
