[PATCH] acpi/acpica: fix Thunderbolt hotplug

2016-03-29 Thread Prarit Bhargava
J. Wysocki" Cc: Len Brown Cc: linux-a...@vger.kernel.org Cc: de...@acpica.org Signed-off-by: Prarit Bhargava --- drivers/acpi/acpica/dsmethod.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c index 1982310..93799db 1006

Re: [PATCH 1/2] cpu hotplug, add CONFIG_PERMANENT_CPU_TOPOLOGY and keep topology directory for lifetime of CPU [v2]

2015-10-30 Thread Prarit Bhargava
On 10/27/2015 11:50 AM, Thomas Renninger wrote: > On Wednesday, October 21, 2015 12:06:37 PM Prarit Bhargava wrote: > > ... > >> +config PERMANENT_CPU_TOPOLOGY >> +bool "Permanent CPU Topology" >> +depends on HOTPLUG_CPU >> +d

[PATCH 0/3 v3] Add CONFIG_PERMANENT_CPU_TOPOLOGY

2015-10-30 Thread Prarit Bhargava
used as such within the kernel They must be zero'd out when the CPU is offline. Patch 1/3 simply combines topology.c and cpu.c and introduces no new functionality. It is a staging patch for 2/3. Patch 3/3 is a simple cleanup. Prarit Bhargava (3): drivers/base, Combine topology.c and cpu.

[PATCH 2/3] cpu hotplug, add CONFIG_PERMANENT_CPU_TOPOLOGY

2015-10-30 Thread Prarit Bhargava
The information in /sys/devices/system/cpu/cpuX/topology directory is useful for userspace monitoring applications and in-tree utilities like cpupower & turbostat. When down'ing a CPU the /sys/devices/system/cpu/cpuX/topology directory is removed during the CPU_DEAD hotplug callback in the kernel.

[PATCH 1/3] drivers/base, Combine topology.c and cpu.c

2015-10-30 Thread Prarit Bhargava
eter Anvin" Cc: x...@kernel.org Cc: Greg Kroah-Hartman Cc: Len Brown Cc: Borislav Petkov Cc: Andy Lutomirski Cc: Zhu Guihua Cc: Denys Vlasenko Cc: "Jan H. Schönherr" Cc: Boris Ostrovsky Cc: "Paul E. McKenney" Signed-off-by: Prarit Bhargava --- drivers/base/Makef

[PATCH 3/3] drivers/base, cpu, remove hotplugable_cpu_attr_groups

2015-10-30 Thread Prarit Bhargava
hotplugable_cpu_attr_groups is not different from common_cpu_attr_groups, and can be removed. This patchset renames common_cpu_attr_groups to cpu_attr_groups. Cc: Greg Kroah-Hartman Cc: Thomas Renninger Signed-off-by: Prarit Bhargava --- drivers/base/cpu.c | 16 ++-- 1 file

Re: [PATCH 1/2] cpufreq, intel_pstate, Fix limits->max_policy_pct rounding error

2015-11-20 Thread Prarit Bhargava
On 11/20/2015 08:18 AM, Viresh Kumar wrote: > On 20-11-15, 07:32, Prarit Bhargava wrote: >> I have a Intel (6,63) processor with a "marketing" frequency (from >> /proc/cpuinfo) of 2100MHz, and a max turbo frequency of 2600MHz. I >> can execute >> >>

Re: [PATCH 1/2] cpufreq, intel_pstate, Fix limits->max_policy_pct rounding error

2015-11-20 Thread Prarit Bhargava
On 11/20/2015 10:19 AM, Viresh Kumar wrote: > On 20-11-15, 10:10, Prarit Bhargava wrote: >>>>limits->max_policy_pct = clamp_t(int, limits->max_policy_pct, 0 , 100); >>> >>> And put this after the later one ? >>> >>>>

Re: [PATCH 1/2] cpufreq, intel_pstate, Fix limits->max_policy_pct rounding error

2015-11-20 Thread Prarit Bhargava
On 11/20/2015 03:02 PM, Pandruvada, Srinivas wrote: > On Fri, 2015-11-20 at 10:43 -0500, Prarit Bhargava wrote: >> >> On 11/20/2015 10:19 AM, Viresh Kumar wrote: >>> On 20-11-15, 10:10, Prarit Bhargava wrote: >>>>>> limits->max_policy

Re: [PATCH] x86, msr: Allow read access to /dev/cpu/X/msr

2015-06-30 Thread Prarit Bhargava
The MSR exposure seems to be okay with the following statements: - complete read of /dev/cpu/X/msr is bad, whitelist instead - needs to be dependent on either CPU version or reading MSRs for support. IIRC the Intel documentaton on the MSRs indicated that there are ways to check to see if a pa

Re: [PATCH] x86, msr: Allow read access to /dev/cpu/X/msr

2015-06-30 Thread Prarit Bhargava
On 06/30/2015 08:44 AM, Peter Zijlstra wrote: > On Tue, Jun 30, 2015 at 08:20:55AM -0400, Prarit Bhargava wrote: >> it seems like visiting changes on each of these packages (and the other >> packages that I'm sure I've missed) will be moderately difficult. >> >

Re: [PATCH] x86, bitops, variable_test_bit should return 1 not -1 on a match

2015-10-08 Thread Prarit Bhargava
On 08/21/2015 04:08 AM, H. Peter Anvin wrote: > Wrong fix, though. Instead we should change it to use the set instruction, > which would also make it easier to use the CC_SET/CC_OUT proposed macros to > use assembly out in the future. > > The downside with set is that it only sets a single by

Re: [PATCH] Fix cpupower reporting uninitialized values for offline cpus

2015-10-09 Thread Prarit Bhargava
ck on if the cpu was online. Thomas, any comment? Looks good to me. The description could be cleaned up a bit but I'll let the maintainer decide if they want a new one. Reviewed-by: Prarit Bhargava P. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel

x86: Complete data loss during NMI lockup

2019-03-18 Thread Prarit Bhargava
Kernel 4.18.0 has a partial data loss when an NMI occurs but 5.0.0 has complete data loss. I tested with this simple kernel lockup code on kernels 4.18.0 through 5.0.0. On 4.18.0 (and after) the expected lockup messages Uhhuh. NMI received for unknown reason 25 on CPU 0. Do you have a strange

Re: [PATCH 2/2] tools/power/x86/intel-speed-select: Display core count for bucket

2019-09-06 Thread Prarit Bhargava
On 9/5/19 7:37 PM, Srinivas Pandruvada wrote: > Read the bucket and core count relationship via MSR and display > when displaying turbo ratio limits. > > Signed-off-by: Srinivas Pandruvada > --- > .../power/x86/intel-speed-select/isst-core.c | 22 +++ > .../x86/intel-speed-se

Re: [PATCH 2/2] tools/power/x86/intel-speed-select: Display core count for bucket

2019-09-08 Thread Prarit Bhargava
On 9/7/19 2:18 PM, Andy Shevchenko wrote: > On Fri, Sep 6, 2019 at 10:47 PM Srinivas Pandruvada > wrote: >> >> On Fri, 2019-09-06 at 07:50 -0700, Srinivas Pandruvada wrote: >>> On Fri, 2019-09-06 at 16:46 +0300, Andy Shevchenko wrote: >>>> On Fri, S

[PATCH 2/8] tools/power/x86/intel-speed-select: Fix help option typo

2019-09-03 Thread Prarit Bhargava
Help is -h, not --h. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.kernel.org --- tools/power/x86/intel-speed-select/isst-config.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/power/x86/intel-speed-select/isst

[PATCH 0/8] tools-power-x86-intel-speed-select: Fixes and updates for output

2019-09-03 Thread Prarit Bhargava
. - avoiding reporting "0|1" as success|fail as these can be confusing for a user. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.kernel.org Prarit Bhargava (8): tools/power/x86/intel-speed-select: Fix package typo tools/power/x86/intel-sp

[PATCH 8/8] tools/power/x86/intel-speed-select: Output success/failed for command output

2019-09-03 Thread Prarit Bhargava
he command output to 'success' or 'failed'. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.kernel.org --- tools/power/x86/intel-speed-select/isst-display.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH 7/8] tools/power/x86/intel-speed-select: Output human readable CPU list

2019-09-03 Thread Prarit Bhargava
The intel-speed-select tool currently only outputs a hexidecimal CPU mask, which requires translation for use with kernel parameters such as isolcpus. Along with the CPU mask, output a human readable CPU list. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux

[PATCH 5/8] tools/power/x86/intel-speed-select: Switch output to MHz

2019-09-03 Thread Prarit Bhargava
These features are introduced on new processors that will never operate in the KHz range. Save some zeros and switch the output to MHz. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.kernel.org --- .../x86/intel-speed-select/isst-display.c

[PATCH 4/8] tools/power/x86/intel-speed-select: Simplify output for turbo-freq and base-freq

2019-09-03 Thread Prarit Bhargava
displaying status of disabled, enabled, and unsupported. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.kernel.org --- .../x86/intel-speed-select/isst-display.c | 30 ++- 1 file changed, 16 insertions(+), 14 deletions(-) diff --g

[PATCH 6/8] tools/power/x86/intel-speed-select: Change turbo ratio output to maximum turbo frequency

2019-09-03 Thread Prarit Bhargava
The intel-speed-select tool currently outputs the turbo ratio for every bucket. Make the output more user-friendly by changing the output to the maximum turbo frequency. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.kernel.org --- .../x86/intel

[PATCH 1/8] tools/power/x86/intel-speed-select: Fix package typo

2019-09-03 Thread Prarit Bhargava
packag_ should be package_. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.kernel.org --- tools/power/x86/intel-speed-select/isst-display.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/power/x86/intel-speed

[PATCH 3/8] tools/power/x86/intel-speed-select: Fix cpu-count output

2019-09-03 Thread Prarit Bhargava
I have a system with 28 threads/socket but intel-speed-select reports a cpu-count of 29. Fix an off-by-one error in the cpu_count() function. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.kernel.org --- tools/power/x86/intel-speed-select/isst

Re: [PATCH 0/8] tools-power-x86-intel-speed-select: Fixes and updates for output

2019-09-04 Thread Prarit Bhargava
On 9/4/19 4:06 PM, Srinivas Pandruvada wrote: > On Tue, 2019-09-03 at 11:37 -0400, Prarit Bhargava wrote: >> Some general fixes and updates for intel-speed-select. Fixes include >> some >> typos as well as an off-by-one cpu count reporting error. Updates >

[PATCH v2 8/9] tools/power/x86/intel-speed-select: Output success/failed for command output

2019-09-05 Thread Prarit Bhargava
he command output to 'success' or 'failed'. v2: Remove help output line. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.kernel.org --- tools/power/x86/intel-speed-select/isst-config.c | 1 - tools/power/x86/intel-speed-select/iss

[PATCH v2 7/9] tools/power/x86/intel-speed-select: Output human readable CPU list

2019-09-05 Thread Prarit Bhargava
The intel-speed-select tool currently only outputs a hexidecimal CPU mask, which requires translation for use with kernel parameters such as isolcpus. Along with the CPU mask, output a human readable CPU list. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux

[PATCH v2 1/9] tools/power/x86/intel-speed-select: Fix package typo

2019-09-05 Thread Prarit Bhargava
packag_ should be package_. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.kernel.org --- tools/power/x86/intel-speed-select/isst-display.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/power/x86/intel-speed

[PATCH v2 0/9] tools-power-x86-intel-speed-select: Fixes and updates for output

2019-09-05 Thread Prarit Bhargava
. - avoiding reporting "0|1" as success|fail as these can be confusing for a user. v2: Add additional patch to fix memory leak and remove help text in 8/9. Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.kernel.org Prarit Bhargava (9): tools/power/x86/intel-speed-select: F

[PATCH v2 2/9] tools/power/x86/intel-speed-select: Fix help option typo

2019-09-05 Thread Prarit Bhargava
Help is -h, not --h. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.kernel.org --- tools/power/x86/intel-speed-select/isst-config.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/power/x86/intel-speed-select/isst

[PATCH v2 4/9] tools/power/x86/intel-speed-select: Simplify output for turbo-freq and base-freq

2019-09-05 Thread Prarit Bhargava
displaying status of disabled, enabled, and unsupported. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.kernel.org --- .../x86/intel-speed-select/isst-display.c | 30 ++- 1 file changed, 16 insertions(+), 14 deletions(-) diff --g

[PATCH v2 3/9] tools/power/x86/intel-speed-select: Fix cpu-count output

2019-09-05 Thread Prarit Bhargava
I have a system with 28 threads/socket but intel-speed-select reports a cpu-count of 29. Fix an off-by-one error in the cpu_count() function. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.kernel.org --- tools/power/x86/intel-speed-select/isst

[PATCH v2 5/9] tools/power/x86/intel-speed-select: Switch output to MHz

2019-09-05 Thread Prarit Bhargava
These features are introduced on new processors that will never operate in the KHz range. Save some zeros and switch the output to MHz. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.kernel.org --- .../x86/intel-speed-select/isst-display.c

[PATCH v2 6/9] tools/power/x86/intel-speed-select: Change turbo ratio output to maximum turbo frequency

2019-09-05 Thread Prarit Bhargava
The intel-speed-select tool currently outputs the turbo ratio for every bucket. Make the output more user-friendly by changing the output to the maximum turbo frequency. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.kernel.org --- .../x86/intel

[PATCH v2 9/9] tools/power/x86/intel-speed-select: Fix memory leak

2019-09-05 Thread Prarit Bhargava
cpumasks are allocated by calling the alloc_cpu_mask() function and are never free'd. They should be free'd after the commands have run. Fix the memory leaks by calling free_cpu_set(). Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Cc: David Arcari Cc: linux-kernel@vger.

Re: [PATCH v2 9/9] tools/power/x86/intel-speed-select: Fix memory leak

2019-09-05 Thread Prarit Bhargava
On 9/5/19 3:42 PM, Srinivas Pandruvada wrote: > On Thu, 2019-09-05 at 08:03 -0400, Prarit Bhargava wrote: >> cpumasks are allocated by calling the alloc_cpu_mask() function and >> are >> never free'd. They should be free'd after the commands have run. >&g

Re: [PATCH v2 9/9] tools/power/x86/intel-speed-select: Fix memory leak

2019-09-05 Thread Prarit Bhargava
On 9/5/19 3:42 PM, Srinivas Pandruvada wrote: > On Thu, 2019-09-05 at 08:03 -0400, Prarit Bhargava wrote: >> cpumasks are allocated by calling the alloc_cpu_mask() function and >> are >> never free'd. They should be free'd after the commands have run. >&g

[PATCH v2 0/7] Add CascadeLake-N Support

2019-10-03 Thread Prarit Bhargava
Bhargava Prarit Bhargava (7): intel-speed-select: Add int argument to command functions intel-speed-select: Make process_command generic intel-speed-select: Add check for CascadeLake-N models intel-speed-select: Add configuration for CascadeLake-N intel-speed-select: Implement

[PATCH v2 1/7] intel-speed-select: Add int argument to command functions

2019-10-03 Thread Prarit Bhargava
functions. Add int argument to the command function structure. Signed-off-by: Prarit Bhargava --- .../x86/intel-speed-select/isst-config.c | 216 +++--- 1 file changed, 88 insertions(+), 128 deletions(-) diff --git a/tools/power/x86/intel-speed-select/isst-config.c b/tools

[PATCH v2 4/7] intel-speed-select: Add configuration for CascadeLake-N

2019-10-03 Thread Prarit Bhargava
Create a 'dummy' pkg_dev struct for use by CascadeLake-N processors. This struct will be used in later patches to implement info and status calls for CascadeLake-N SST-BF. Signed-off-by: Prarit Bhargava --- .../x86/intel-speed-select/isst-config.c | 98 ++- ...

[PATCH v2 5/7] intel-speed-select: Implement CascadeLake-N help and command functions structures

2019-10-03 Thread Prarit Bhargava
: Prarit Bhargava --- .../x86/intel-speed-select/isst-config.c | 37 ++- 1 file changed, 27 insertions(+), 10 deletions(-) diff --git a/tools/power/x86/intel-speed-select/isst-config.c b/tools/power/x86/intel-speed-select/isst-config.c index 164c4e5e6ccb..3ab0edade5ec 100644

[PATCH v2 2/7] intel-speed-select: Make process_command generic

2019-10-03 Thread Prarit Bhargava
Make the process_command take any help command and command list. This will make it easier to help commands and a command list for CascadeLake-N. Signed-off-by: Prarit Bhargava --- .../x86/intel-speed-select/isst-config.c | 20 ++- 1 file changed, 11 insertions(+), 9

[PATCH v2 6/7] intel-speed-select: Implement 'perf-profile info' on CascadeLake-N

2019-10-03 Thread Prarit Bhargava
Add functionality for perf-profile info on CascadeLake-N. Signed-off-by: Prarit Bhargava --- .../x86/intel-speed-select/isst-config.c | 20 +++ .../x86/intel-speed-select/isst-display.c | 12 +++ tools/power/x86/intel-speed-select/isst.h | 1 + 3 files

[PATCH v2 7/7] intel-speed-select: Implement base-freq commands on CascadeLake-N

2019-10-03 Thread Prarit Bhargava
Add functionality for base-freq info|enable|disable info on CascadeLake-N. The enable command always returns success, and the disable command always returns failed because SST-BF cannot be enabled or disabled from the OS on CascadeLake-N. Signed-off-by: Prarit Bhargava --- .../x86/intel-speed

[PATCH v2 3/7] intel-speed-select: Add check for CascadeLake-N models

2019-10-03 Thread Prarit Bhargava
Three CascadeLake-N models (6252N, 6230N, and 5218N) have SST-PBF support. Return an error if the CascadeLake processor is not one of these specific models. v2: Add is_clx_n_platform() Signed-off-by: Prarit Bhargava --- .../x86/intel-speed-select/isst-config.c | 44 ++- 1

Re: [PATCH 1/7] intel-speed-select: Add int argument to command functions

2019-09-30 Thread Prarit Bhargava
On 9/26/19 4:21 PM, Srinivas Pandruvada wrote: > On Thu, 2019-09-26 at 08:54 -0400, Prarit Bhargava wrote: >> The current code structure has similar but separate command functions >> for >> the enable and disable operations. This can be improved by adding an >> int

Re: [PATCH v2 3/7] intel-speed-select: Add check for CascadeLake-N models

2019-10-04 Thread Prarit Bhargava
On 10/4/19 1:15 PM, Srinivas Pandruvada wrote: > On Thu, 2019-10-03 at 08:11 -0400, Prarit Bhargava wrote: >> Three CascadeLake-N models (6252N, 6230N, and 5218N) have SST-PBF >> support. >> >> Return an error if the CascadeLake processor is not one of these >&

[PATCH 6/7] intel-speed-select: Implement 'perf-profile info' on CascadeLake-N

2019-09-26 Thread Prarit Bhargava
Add functionality for perf-profile info on CascadeLake-N. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada --- .../x86/intel-speed-select/isst-config.c | 24 +++ .../x86/intel-speed-select/isst-display.c | 22 + tools/power/x86/intel-speed-select

[PATCH 7/7] intel-speed-select: Implement base-freq commands on CascadeLake-N

2019-09-26 Thread Prarit Bhargava
Add functionality for base-freq info|enable|disable info on CascadeLake-N. The enable command always returns success, and the disable command always returns failed because SST-BF cannot be enabled or disabled from the OS on CascadeLake-N. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada

[PATCH 4/7] intel-speed-select: Add configuration for CascadeLake-N

2019-09-26 Thread Prarit Bhargava
Create a 'dummy' pkg_dev struct for use by CascadeLake-N processors. This struct will be used in later patches to implement info and status calls for CascadeLake-N SST-BF. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada --- .../x86/intel-speed-select/isst-config.c

[PATCH 3/7] intel-speed-select: Add check for CascadeLake-N models

2019-09-26 Thread Prarit Bhargava
Three CascadeLake-N models (6252N, 6230N, and 5218N) have SST-PBF support. Return an error if the CascadeLake processor is not one of these specific models. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada --- .../x86/intel-speed-select/isst-config.c | 32 +-- 1

[PATCH 5/7] intel-speed-select: Implement CascadeLake-N help and command functions structures

2019-09-26 Thread Prarit Bhargava
: Prarit Bhargava Cc: Srinivas Pandruvada --- .../x86/intel-speed-select/isst-config.c | 37 ++- 1 file changed, 27 insertions(+), 10 deletions(-) diff --git a/tools/power/x86/intel-speed-select/isst-config.c b/tools/power/x86/intel-speed-select/isst-config.c index

[PATCH 1/7] intel-speed-select: Add int argument to command functions

2019-09-26 Thread Prarit Bhargava
functions. Add int argument to the command function structure. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada --- .../x86/intel-speed-select/isst-config.c | 184 +++--- 1 file changed, 69 insertions(+), 115 deletions(-) diff --git a/tools/power/x86/intel-speed-select

[PATCH 0/7] intel-speed-select: Add CascadeLake-N support

2019-09-26 Thread Prarit Bhargava
Add support for SST-BF on CascadeLake-N support. The CascadeLake-N processor only support SST-BF and not other SST functionality. Prarit Bhargava (7): intel-speed-select: Add int argument to command functions intel-speed-select: Make process_command generic intel-speed-select: Add check

[PATCH 2/7] intel-speed-select: Make process_command generic

2019-09-26 Thread Prarit Bhargava
Make the process_command take any help command and command list. This will make it easier to help commands and a command list for CascadeLake-N. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada --- .../x86/intel-speed-select/isst-config.c | 20 ++- 1 file changed

[PATCH 1/2] intel-speed-select: Display turbo-ratio-limits as a table

2019-09-23 Thread Prarit Bhargava
The output of the Turbo Ratio Limits is 75 lines long (each bucket has 3 lines and the headers). This can be shrunk down into a table that is easier to consume for both scripts and humans. Display Turbo Ratio Limits in a table. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada

[PATCH 0/2] intel-speed-select: Convert output to tables

2019-09-23 Thread Prarit Bhargava
The turbo ratio limits and turbo frequencies add a large amount of lines to the output. The output can be truncated into human and machine readable tables to reduce the number of lines of output. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada Prarit Bhargava (2): intel-speed-select

[PATCH 2/2] intel-speed-select: Display turbo frequencies in a table

2019-09-23 Thread Prarit Bhargava
The output of turbo frequencies is also long (each bucket has 3 lines and the headers). This can be shrunk down into a table that is easier to consume for both scripts and humans. Display the turbo and clip frequencies in a table. Signed-off-by: Prarit Bhargava Cc: Srinivas Pandruvada

Re: [PATCH v3 0/6] Add CascadeLake-N Support

2019-10-14 Thread Prarit Bhargava
e/disable > One of the patch for config only change folded to next one where it is > used. > > The patch 1 has nothing to do with the CLX-N. It saves some bytes in the > size. > Reviewed-by: Prarit Bhargava P.

Re: [PATCH v2] x86, random: Fix get_random_bytes() warning in x86 start_kernel

2019-02-08 Thread Prarit Bhargava
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

[PATCH v2] x86, random: Fix get_random_bytes() warning in x86 start_kernel

2019-02-01 Thread Prarit Bhargava
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

Re: [PATCH v2] x86, random: Fix get_random_bytes() warning in x86 start_kernel

2019-02-03 Thread Prarit Bhargava
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

Re: [PATCH] modules: fix livelock in add_unformed_module()

2019-05-22 Thread Prarit Bhargava
On 5/13/19 10:37 AM, Barret Rhoden wrote: > Hi - > Hey Barret, my apologies for not getting back to you earlier. I got caught up in something that took me away from this issue. > On 5/13/19 7:23 AM, Prarit Bhargava wrote: > [snip] >> A module is loaded once for each cpu.

Re: [PATCH] modules: fix livelock in add_unformed_module()

2019-05-13 Thread Prarit Bhargava
On 5/10/19 2:42 PM, Barret Rhoden wrote: > When add_unformed_module() finds an existing module with the same name, > it waits until the preexisting module finished loading. Prior to commit > f9a75c1d717f, this meant if the module was either UNFORMED or COMING, > we'd wait. That commit changed

[PATCH v2] modules: Only return -EEXIST for modules that have finished loading

2019-05-07 Thread Prarit Bhargava
erruptible() puts each thread to sleep until the a module finishes loading an executes the module_wq workqueue. The result is a long delay during the boot. Switching to wait_event_interruptible_timeout() resolves the sleep problem. Signed-off-by: Prarit Bhargava Cc: Jessica Yu Cc: Heiko Ca

Re: [-next] system hangs likely due to "modules: Only return -EEXIST for modules that have finished loading"

2019-04-26 Thread Prarit Bhargava
On 4/26/19 9:07 AM, Heiko Carstens wrote: > Hello Prarit, > > it looks like your commit f9a75c1d717f ("modules: Only return -EEXIST > for modules that have finished loading") _sometimes_ causes hangs on > s390. This is unfortunately not 100% reproducible, however the > mentioned commit seems to

Re: [-next] system hangs likely due to "modules: Only return -EEXIST for modules that have finished loading"

2019-04-26 Thread Prarit Bhargava
On 4/26/19 12:09 PM, Jessica Yu wrote: > +++ Heiko Carstens [26/04/19 17:07 +0200]: >> On Fri, Apr 26, 2019 at 09:22:34AM -0400, Prarit Bhargava wrote: >>> On 4/26/19 9:07 AM, Heiko Carstens wrote: >>> > Hello Prarit, >>> > >>> > it look

Re: [-next] system hangs likely due to "modules: Only return -EEXIST for modules that have finished loading"

2019-04-26 Thread Prarit Bhargava
On 4/26/19 12:09 PM, Jessica Yu wrote: > +++ Heiko Carstens [26/04/19 17:07 +0200]: >> On Fri, Apr 26, 2019 at 09:22:34AM -0400, Prarit Bhargava wrote: >>> On 4/26/19 9:07 AM, Heiko Carstens wrote: >>> > Hello Prarit, >>> > >>> > it look

Re: [-next] system hangs likely due to "modules: Only return -EEXIST for modules that have finished loading"

2019-04-26 Thread Prarit Bhargava
On 4/26/19 2:10 PM, Prarit Bhargava wrote: > > > On 4/26/19 12:09 PM, Jessica Yu wrote: >> +++ Heiko Carstens [26/04/19 17:07 +0200]: >>> On Fri, Apr 26, 2019 at 09:22:34AM -0400, Prarit Bhargava wrote: >>>> On 4/26/19 9:07 AM, Heiko Carstens wrote: >

Re: [-next] system hangs likely due to "modules: Only return -EEXIST for modules that have finished loading"

2019-04-26 Thread Prarit Bhargava
On 4/26/19 3:45 PM, Prarit Bhargava wrote: > > > On 4/26/19 2:10 PM, Prarit Bhargava wrote: >> >> >> On 4/26/19 12:09 PM, Jessica Yu wrote: >>> +++ Heiko Carstens [26/04/19 17:07 +0200]: >>>> On Fri, Apr 26, 2019 at 09:22:34AM -0400, Prarit

Re: [-next] system hangs likely due to "modules: Only return -EEXIST for modules that have finished loading"

2019-04-27 Thread Prarit Bhargava
On 4/27/19 6:24 AM, Heiko Carstens wrote: > On Fri, Apr 26, 2019 at 08:20:52PM -0400, Prarit Bhargava wrote: >> Heiko and Jessica, >> >> The issue doesn't appear to be with my patch AFAICT. The s390_trng fails to >> load and then the kernel occasionally ha

Re: [-next] system hangs likely due to "modules: Only return -EEXIST for modules that have finished loading"

2019-04-27 Thread Prarit Bhargava
On 4/27/19 6:24 AM, Heiko Carstens wrote: > > diff --git a/kernel/module.c b/kernel/module.c > index 410eeb7e4f1d..48748cfec991 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -3585,6 +3585,7 @@ again: > finished_loading(mod->name)); >

[PATCH] kernel/module: Reschedule while waiting for modules to finish loading

2019-04-29 Thread Prarit Bhargava
iko Carstens Fixes: linux-next commit f9a75c1d717f ("modules: Only return -EEXIST for modules that have finished loading") Signed-off-by: Prarit Bhargava Cc: Jessica Yu --- kernel/module.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/module.c b/kernel/module.c index

Re: [PATCH] kernel/module: Reschedule while waiting for modules to finish loading

2019-04-30 Thread Prarit Bhargava
On 4/30/19 3:51 AM, Jessica Yu wrote: > +++ Prarit Bhargava [29/04/19 11:17 -0400]: >> Heiko, do you want a Signed-off-by or a Reported-by?  Either one works >> for me. >> >> P. > > I think you forgot to CC Heiko :) #oops. I forgot that git-send-email

Re: linux-next: Fixes tag needs some work in the modules tree

2019-04-30 Thread Prarit Bhargava
On 4/30/19 6:10 PM, Stephen Rothwell wrote: > Hi all, > > In commit > > 7e470ea99bcd ("kernel/module: Reschedule while waiting for modules to > finish loading") > > Fixes tag > > Fixes: linux-next commit f9a75c1d717f ("modules: Only return -EEXIST for > modules that have finished loadi

[PATCH v2] kernel/module: Reschedule while waiting for modules to finish loading

2019-04-30 Thread Prarit Bhargava
EXIST for modules that have finished loading") Signed-off-by: Prarit Bhargava Cc: Jessica Yu Cc: Heiko Carstens --- kernel/module.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/module.c b/kernel/module.c index 410eeb7e4f1d..48748cfec991 100644 --- a/kernel/module.c +++ b/kerne

Re: [PATCH v2] kernel/module: Reschedule while waiting for modules to finish loading

2019-04-30 Thread Prarit Bhargava
On 4/30/19 6:18 PM, Prarit Bhargava wrote: > On a s390 z14 LAR with 2 cpus about stalls about 3% of the time while > loading the s390_trng.ko module. > > Add a reschedule point to the loop that waits for modules to complete > loading. > Sorry, sent in error. P. > v

[PATCH v3] kernel/module: Reschedule while waiting for modules to finish loading

2019-04-30 Thread Prarit Bhargava
T for modules that have finished loading") Signed-off-by: Prarit Bhargava Cc: Jessica Yu Cc: Heiko Carstens --- kernel/module.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/module.c b/kernel/module.c index 410eeb7e4f1d..48748cfec991 100644 --- a/kernel/module.c +++ b/kerne

Re: [PATCH v3] kernel/module: Reschedule while waiting for modules to finish loading

2019-05-01 Thread Prarit Bhargava
On 4/30/19 6:22 PM, Prarit Bhargava wrote: > On a s390 z14 LAR with 2 cpus about stalls about 3% of the time while > loading the s390_trng.ko module. > > Add a reschedule point to the loop that waits for modules to complete > loading. > > v3: cleanup Fixes line. Je

Re: [PATCH v3] kernel/module: Reschedule while waiting for modules to finish loading

2019-05-02 Thread Prarit Bhargava
On 5/2/19 5:48 AM, Jessica Yu wrote: > +++ Prarit Bhargava [01/05/19 17:26 -0400]: >> >> >> On 4/30/19 6:22 PM, Prarit Bhargava wrote: >>> On a s390 z14 LAR with 2 cpus about stalls about 3% of the time while >>> loading the s390_trng.ko module. >>

Re: [PATCH v3] kernel/module: Reschedule while waiting for modules to finish loading

2019-05-02 Thread Prarit Bhargava
On 5/2/19 8:41 AM, Prarit Bhargava wrote: > > > On 5/2/19 5:48 AM, Jessica Yu wrote: >> +++ Prarit Bhargava [01/05/19 17:26 -0400]: >>> >>> >>> On 4/30/19 6:22 PM, Prarit Bhargava wrote: >>>> On a s390 z14 LAR with 2 cpus about stalls ab

Re: [PATCH AUTOSEL 5.2 13/85] kernel/module.c: Only return -EEXIST for modules that have finished loading

2019-07-26 Thread Prarit Bhargava
On 7/26/19 9:38 AM, Sasha Levin wrote: > From: Prarit Bhargava > > [ Upstream commit 6e6de3dee51a439f76eb73c22ae2ffd2c9384712 ] > > Microsoft HyperV disables the X86_FEATURE_SMCA bit on AMD systems, and > linux guests boot with repeated errors: > Hey Sasha, I'd p

[PATCH] x86/resctrl: Fix panic on systems that do not enable local MBM

2019-06-10 Thread Prarit Bhargava
dwith update loop if the system has local MBM enabled. Signed-off-by: Prarit Bhargava Cc: Fenghua Yu Cc: Reinette Chatre Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: x...@kernel.org --- arch/x86/kernel/cpu/resctrl/monitor.c | 3 +++ 1 file changed,

Re: [GIT PULL] Modules updates for v5.3

2019-07-19 Thread Prarit Bhargava
On 7/18/19 3:20 PM, Linus Torvalds wrote: > On Thu, Jul 18, 2019 at 4:33 AM Jessica Yu wrote: >> >> Modules updates for v5.3 >> >> - Fix bug where -EEXIST was being returned for going modules > > Hmm. > > I have pulled this, but this change makes me a bit nervous. > > I have this dim memory

[PATCH] x86/fpu: Parse comma separated list passed in clearcpuid

2019-02-21 Thread Prarit Bhargava
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/

Re: [PATCH] x86/fpu: Parse comma separated list passed in clearcpuid

2019-02-21 Thread Prarit Bhargava
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

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

2016-12-06 Thread Prarit Bhargava
ssible unhandled 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 Petko

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

2016-12-06 Thread Prarit Bhargava
ssible unhandled 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 Gor

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

2017-01-05 Thread Prarit Bhargava
ation. v2: 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 f

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

2017-01-18 Thread Prarit Bhargava
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 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

2017-01-18 Thread Prarit Bhargava
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

2017-01-19 Thread Prarit Bhargava
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 >&g

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

2017-01-19 Thread Prarit Bhargava
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

2017-01-19 Thread Prarit Bhargava
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

[PATCH] x86/mce: Fix initialization error warning

2017-01-16 Thread Prarit Bhargava
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

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

2017-01-16 Thread Prarit Bhargava
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

2017-01-16 Thread Prarit Bhargava
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

2017-01-16 Thread Prarit Bhargava
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 RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

2016-07-15 Thread Prarit Bhargava
On 07/15/2016 07:25 AM, Stanislaw Gruszka wrote: > On Thu, Jul 14, 2016 at 09:44:22AM +, Grumbach, Emmanuel wrote: >>> If I understad correctly this error happen 100% of the time, not only during >>> init. Hence seems there is an issue here, i.e. cur_ucode is not marked >>> correctly as IWL_U

<    3   4   5   6   7   8   9   10   11   >