On 10/06/2015 03:36 PM, Bjorn Helgaas wrote:
> Hi Sasha,
>
> On Sun, Oct 04, 2015 at 05:49:29PM -0400, Sasha Levin wrote:
>> Commit 63692df1 ("PCI: Allow numa_node override via sysfs") didn't check that
>> the numa node provided by userspace is valid. Passing a node number too high
>> would atte
es: a04759924e25 ("[cpufreq] intel_pstate: honor user space min_perf_pct
override on resume")
Cc: Kristen Carlson Accardi
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
Signed-off-by: Prarit Bhargava
---
drivers/cpufreq/intel_pstate.c |7 +--
1 file
On 10/07/2015 02:51 AM, Doug Smythies wrote:
>
> And before patch I get, using primitives and not cpupower:
> Executive Summary: Everything works fine (or at least as I thought it was
> supposed to).
>
> root@s15:/home/doug/temp# grep .
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
On 10/06/2015 07:06 PM, Rafael J. Wysocki wrote:
> On Wednesday, October 07, 2015 12:43:55 AM Rafael J. Wysocki wrote:
>> On Tuesday, October 06, 2015 05:49:07 PM Prarit Bhargava wrote:
>>> Intel CPUs will not enter higher p-states when after switching from the
>>>
On 10/06/2015 07:06 PM, Rafael J. Wysocki wrote:
> On Wednesday, October 07, 2015 12:43:55 AM Rafael J. Wysocki wrote:
>> On Tuesday, October 06, 2015 05:49:07 PM Prarit Bhargava wrote:
>>>
>>> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel
On 10/07/2015 10:04 AM, Doug Smythies wrote:
>
> On 2015.10.07 03:00 Prarit Bhargava wrote:
>> On 10/07/2015 02:51 AM, Doug Smythies wrote:
>>>
>>> And before patch I get, using primitives and not cpupower:
>>> Executive Summary: Everything work
Doug, please apply and test.
My result is:
\# initial load of driver, set to PERFORMANCE governor by default.
[ 21.406525] intel_pstate_set_policy[1001] min_perf_pct = 100
[ 21.421288] intel_pstate_set_policy[1001] min_perf_pct = 100
[ 21.436038] intel_pstate_set_policy[1001] min_perf_pct
On 10/07/2015 08:18 AM, Prarit Bhargava wrote:
>
>
> On 10/06/2015 07:06 PM, Rafael J. Wysocki wrote:
>> On Wednesday, October 07, 2015 12:43:55 AM Rafael J. Wysocki wrote:
>>> On Tuesday, October 06, 2015 05:49:07 PM Prarit Bhargava wrote:
>
>
>
>&
On 10/07/2015 11:40 AM, Doug Smythies wrote:
>
> Do we agree or disagree that the root issue seems to be (from your test)?:
>
> \# echo 100 > /sys/devices/system/cpu/intel_pstate/min_perf_pct
>
> [ 21.483436] store_min_perf_pct[453] min_sysfs_pct = 100
> [ 21.489373] store_min_perf_pct[45
On 10/07/2015 02:52 PM, Doug Smythies wrote:
> On 2015.10.07 08:46 Prarit Bhargava wrote:
>> On 10/07/2015 11:40 AM, Doug Smythies wrote:
>>>
>>> Do we agree or disagree that the root issue seems to be (from your test)?:
>>>
>>> \# echo 100 > /
On 10/07/2015 02:52 PM, Doug Smythies wrote:
> On 2015.10.07 08:46 Prarit Bhargava wrote:
>> On 10/07/2015 11:40 AM, Doug Smythies wrote:
>>>
>>> Do we agree or disagree that the root issue seems to be (from your test)?:
>>>
>>> \# echo 100 > /
On 10/07/2015 06:05 PM, Rafael J. Wysocki wrote:
> On Wednesday, October 07, 2015 05:31:25 PM Prarit Bhargava wrote:
>>
>> On 10/07/2015 02:52 PM, Doug Smythies wrote:
>>> On 2015.10.07 08:46 Prarit Bhargava wrote:
>>>> On 10/07/2015 11:40 AM, Doug Smythi
On 10/07/2015 06:26 PM, Doug Smythies wrote:
> On 2015.10.07 15:06 Rafael J. Wysocki wrote:
>> On Wednesday, October 07, 2015 05:31:25 PM Prarit Bhargava wrote:
>>> On 10/07/2015 02:52 PM, Doug Smythies wrote:
>>>> On 2015.10.07 08:46 Prarit Bhargava wrote:
>
re-ping on this. Just making sure this wasn't dropped on the floor.
P.
On 08/24/2015 02:22 PM, Prarit Bhargava wrote:
> This issue was noticed while debugging a CPU hotplug issue. On x86
> with (NR_CPUS > 1) the cpu_online() define is cpumask_test_cpu().
> cpumask_test_cpu() s
On 10/07/2015 06:26 PM, Doug Smythies wrote:
> On 2015.10.07 15:06 Rafael J. Wysocki wrote:
>> On Wednesday, October 07, 2015 05:31:25 PM Prarit Bhargava wrote:
>>> On 10/07/2015 02:52 PM, Doug Smythies wrote:
>>>> On 2015.10.07 08:46 Prarit Bhargava wrote:
>
Heikki, Tomas?
P.
On 08/14/2015 09:05 AM, Prarit Bhargava wrote:
> 2nd try on this ...
>
> P.
>
> ---8<---
>
> scripts/mod/file2alias.c:add_uuid() munges a UUID into a single string
> which does not conform to the standard little endian UUID. This patch
> chan
On 08/29/2015 05:21 PM, Winkler, Tomas wrote:
>>
>> Hi Prarit,
>>
>> On Fri, Aug 28, 2015 at 07:50:52AM -0400, Prarit Bhargava wrote:
>>> Heikki, Tomas?
>>
>> I'm afraid I don't know much about Intel's Management Engine
>> Inte
On 08/29/2015 05:21 PM, Winkler, Tomas wrote:
>>
>> Hi Prarit,
>>
>> On Fri, Aug 28, 2015 at 07:50:52AM -0400, Prarit Bhargava wrote:
>>> Heikki, Tomas?
>>
>> I'm afraid I don't know much about Intel's Management Engine
>> Inte
di
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
Cc: Doug Smythies
Signed-off-by: Prarit Bhargava
---
drivers/cpufreq/intel_pstate.c | 120 +---
1 file changed, 75 insertions(+), 45 deletions(-)
diff --git a/drivers
On 10/14/2015 05:09 PM, Kristen Carlson Accardi wrote:
> On Wed, 14 Oct 2015 07:41:59 -0400
> Prarit Bhargava wrote:
>
>> On systems that initialize the intel_pstate driver with the performance
>> governor, and then switch to the powersave governor will not trans
On 10/14/2015 08:29 PM, Rafael J. Wysocki wrote:
> On Wednesday, October 14, 2015 07:59:38 PM Prarit Bhargava wrote:
>>
>> On 10/14/2015 05:09 PM, Kristen Carlson Accardi wrote:
>>> On Wed, 14 Oct 2015 07:41:59 -0400
>>> Prarit Bhargava wrote:
>&g
show_bug.cgi?id=1271225
against Fedora to remove the 94cpufreq file that causes the problem. It
should be noted that pm-utils is obsoleted with newer versions of systemd.
Cc: Kristen Carlson Accardi
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
Cc: Doug Smythie
he CPU is offline.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Greg Kroah-Hartman
Cc: Borislav Petkov
Cc: Len Brown
Cc: Andy Lutomirski
Cc: Zhu Guihua
Cc: Denys Vlasenko
Cc: "Jan H. Schönherr"
Cc: Boris Ostrovsky
Cc: Prarit Bharga
r, and adds an additional minor cleanup to
drivers/base/cpu.c.
[v2]: core_siblings, and thread_siblings are "numa siblings that are online"
and "thread siblings that are online" and are used as such within the kernel.
They must be zero'd out when the CPU is offline.
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
On 10/15/2015 04:16 PM, Michal Marek wrote:
> Otherwise make tags can't parse them:
>
> ctags: Warning: arch/ia64/kernel/smp.c:60: null expansion of name pattern "\1"
> ctags: Warning: drivers/xen/events/events_2l.c:41: null expansion of name
> pattern "\1"
> ctags: Warning: drivers/acpi/processo
On 10/21/2015 03:52 PM, Michal Marek wrote:
> Dne 21.10.2015 v 21:27 Prarit Bhargava napsal(a):
>> On 10/15/2015 04:16 PM, Michal Marek wrote:
>>> Otherwise make tags can't parse them:
>>>
>>> ctags: Warning: arch/ia64/kernel/smp.c:60: null expansion of
On 10/22/2015 08:06 AM, Michal Marek wrote:
> On 2015-10-22 13:31, Prarit Bhargava wrote:
>>
>>
>> On 10/21/2015 03:52 PM, Michal Marek wrote:
>>> Dne 21.10.2015 v 21:27 Prarit Bhargava napsal(a):
>>>> On 10/15/2015 04:16 PM, Michal Marek wrote:
ccardi
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
Signed-off-by: Prarit Bhargava
---
drivers/cpufreq/intel_pstate.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_ps
On 09/02/2015 10:45 PM, Luis R. Rodriguez wrote:
> On Mon, Aug 31, 2015 at 11:05:33AM -0500, Stuart Hayes wrote:
>> Increase the range of chunk sizes tried in mtrr_cleanup() so it is able
>> to map large memory configs into MTRRs.
>>
>> Currently, mtrr_cleanup() will fail with large memory config
On 09/03/2015 01:59 PM, Luis R. Rodriguez wrote:
> On Thu, Sep 03, 2015 at 08:17:02AM -0400, Prarit Bhargava wrote:
>>
>>
>> On 09/02/2015 10:45 PM, Luis R. Rodriguez wrote:
>>> On Mon, Aug 31, 2015 at 11:05:33AM -0500, Stuart Hayes wrote:
>>>>
ead group, by
socket group and didn't see any issues.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Greg Kroah-Hartman
Cc: Borislav Petkov
Cc: Len Brown
Cc: Andy Lutomirski
Cc: Zhu Guihua
Cc: Denys Vlasenko
Cc: "Jan H. Schönherr"
s Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Greg Kroah-Hartman
Cc: Borislav Petkov
Cc: Len Brown
Cc: Andy Lutomirski
Cc: Zhu Guihua
Cc: Denys Vlasenko
Cc: "Jan H. Schönherr"
Cc: Boris Ostrovsky
Cc: Prarit Bhargava
Cc: "Paul E. McK
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
On 10/19/2015 11:04 AM, Prarit Bhargava wrote:
> 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/cp
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
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..
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
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/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
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
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/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
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
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
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
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
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
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 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
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 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 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 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
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/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
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
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/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
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
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 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 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.
license issue, if it is still
needed and actually used by anyone, we can add it back later once the
license is cleared up.
Looks good:
Acked-by: Christoph Hellwig
Ditto.
Acked-by: Prarit Bhargava
P.
On 9/26/23 04:02, Greg KH wrote:
On Tue, Sep 26, 2023 at 12:34:03AM -0700, Christoph Hellwig wrote:
On Fri, Sep 15, 2023 at 09:39:05AM -0400, Prarit Bhargava wrote:
To be clear, I am not asking for their removal, however, I do think a better
license should be issued for these files. The files
Prevent bogus softlockup warnings when dumping lock debug info during a
sysrq-t.
Signed-off-by: Prarit Bhargava <[EMAIL PROTECTED]>
diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index 734da57..376b398 100644
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -3183,8 +3183,10 @@
When dumping memory via sysrq-m it is possible to take a bogus NMI watchdog
or softlockup watchdog because the dump can take a long time on big memory
systems.
Occasionally tickle the watchdog when doing the dump.
Signed-off-by: Prarit Bhargava <[EMAIL PROTECTED]>
diff --git a/arch/i
> x86_64_defconfig + CONFIG_DMA_ENGINE=y + CONFIG_INTEL_IOATDMA=y
>
> patch is against linux-next 3.19.0-rc1 -next-20141226
>
Seems straightforward to me, although I don't think I've ever seen a failure in
this code.
Acked-by: Prarit Bhargava
P.
> Signed-off-by: Nicholas M
On 12/23/2014 12:52 PM, Nicholas Mc Guire wrote:
> The successive init_completion calls should be reinit_completion here.
>
Hi Nicholas,
I know enough about this code to break it ;) ... what condition did you hit that
led you to this patch?
P.
> patch is against 3.18.0 linux-next
>
> Signed
On 01/06/2015 10:38 AM, Jiang, Dave wrote:
- if (dma->device_tx_status(dma_chan, cookie, NULL) != DMA_COMPLETE) {
+ if (tmo == 0 || dma->device_tx_status(dma_chan, cookie, NULL)
+ != DMA_COMPLETE) {
>>>
>>> Can you please do:
>>> + if (tmo == 0 ||
>>> +
On 01/08/2015 09:16 AM, Nicholas Mc Guire wrote:
> wait_for_completion_timeout reaching timeout was being ignored,
> fail the self-test if timeout condition occurs.
>
> v2: fixup of coding style issues.
>
> Signed-off-by: Nicholas Mc Guire
Reviewed-by: Prarit Bhargava
P.
f sha1>
> ("")'
> and if the git commit sha1 is unique, show
> the right sha1 to use with the actual title
>
> Signed-off-by: Joe Perches
> Original-patch-by: Prarit Bhargava
> ---
Acked-by: Prarit Bhargava
P.
--
To unsubscribe from this list: send th
On 03/19/2015 05:36 PM, Shuah Khan wrote:
> On 03/19/2015 02:27 PM, Shuah Khan wrote:
>> On 03/19/2015 02:25 PM, Jonathan Corbet wrote:
>>> On Thu, 19 Mar 2015 12:24:41 -0600
>>> Shuah Khan wrote:
>>>
Hi Jon,
Would you like to review the change and Ack it, so I can
take the c
On 03/26/2015 12:29 PM, John Stultz wrote:
> On Thu, Mar 26, 2015 at 4:31 AM, Prarit Bhargava wrote:
>> On 03/25/2015 07:44 PM, John Stultz wrote:
>>> + printf("%-22s %s missing CAP_WAKE_ALARM?:
>>> [UNSUPPORTED]\n",
>>> +
On 03/26/2015 01:33 PM, Tyler Baker wrote:
> On 26 March 2015 at 09:29, John Stultz wrote:
>> On Thu, Mar 26, 2015 at 4:31 AM, Prarit Bhargava wrote:
>>> On 03/25/2015 07:44 PM, John Stultz wrote:
>>>> + printf("%-22s %s missing CAP_WAK
On 04/02/2015 02:02 PM, John Stultz wrote:
> On Thu, Apr 2, 2015 at 3:18 AM, Prarit Bhargava wrote:
>> On 03/26/2015 01:33 PM, Tyler Baker wrote:
>>> I realize this may be a good amount of work, so I'd like to help out.
>>> Perhaps working John to convert h
support for ACPI CPU hotplug
> ACPI: Add _OST support for ACPI memory hotplug
> ACPI: Add _OST support for ACPI container hotplug
> ACPI: Set hotplug _OST support bit to _OSC
I have a few systems on which I can do some _OST CPU and Memory hotplug. These
systems are newer Intel systems in w
e changed,
> rather then every update_wall_time call.
>
> This also provides WARN_ONs to detect if future changes break
> the invariants.
>
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Richard Cochran
> Cc: Prarit Bhargava
> Cc: Thomas Gleixner
> Signed-off-b
John,
We've identified an issue with ABSOLUTE timers and the leap second that
effects, AFAICT, all kernels.
This is the scenario. Suppose you have a userspace program that has an
ABSOLUTE timer that will expire @ midnight (00:00:00) UTC. The timer expiry
should occur at the end of the leap seco
On 05/27/2015 03:16 PM, Joe Perches wrote:
> On Wed, 2015-05-27 at 21:06 +0200, Borislav Petkov wrote:
>> On Wed, May 27, 2015 at 10:07:34AM -0700, Joe Perches wrote:
>>> This code can memmove from beyond the x86_model_id field.
>>
>> ... in the theoretical case where some model ID has more than 64
On 06/11/2015 10:51 AM, Doug Smythies wrote:
>
> On 2015.06.10 16:46 Rafael J. Wysocki wrote:
>> On Wednesday, June 10, 2015 09:18:45 AM Prarit Bhargava wrote:
>>> I looked into switching to div64_s64() instead of the 32-bit version in
>>> div_fp(), however, thi
On 06/11/2015 10:51 AM, Doug Smythies wrote:
>
> On 2015.06.10 16:46 Rafael J. Wysocki wrote:
>> On Wednesday, June 10, 2015 09:18:45 AM Prarit Bhargava wrote:
>>> I looked into switching to div64_s64() instead of the 32-bit version in
>>> div_fp(), however, thi
On 06/11/2015 12:17 PM, Doug Smythies wrote:
>
> On 2015.06.11 08:01 Prarit Bhargava wrote:
>> On 06/11/2015 10:51 AM, Doug Smythies wrote:
>>>
>>> On 2015.06.10 16:46 Rafael J. Wysocki wrote:
>>>> On Wednesday, June 10, 2015 09:18:45 AM Prarit Bharga
t; Since those few lockdep traces that I've seen all implicated selinux,
> I'm hoping that we can use the __shmem_file_setup(,,,S_PRIVATE) which
> v3.13's commit c7277090927a ("security: shmem: implement kernel private
> shmem inodes") introduced to avoid LSM checks
On 06/12/2015 10:52 AM, Dave Jones wrote:
> On Thu, Jun 11, 2015 at 03:54:52PM -0700, John Stultz wrote:
> > So this is a second round at trying to address the issue, trying
> > to integrate feedback from Ingo and Thomas, trying to simplify
> > what I can. I've also split out the changes so ea
On 06/12/2015 10:59 AM, Dave Jones wrote:
> On Fri, Jun 12, 2015 at 10:55:57AM -0400, Prarit Bhargava wrote:
>
> > > > This series has only had limited testing, so I wanted to send
> > > > it out for initial review and comment. Folks can grab this tree
>
can grab this tree
> via git for testing here:
> https://git.linaro.org/people/john.stultz/linux.git dev/early-leap-timer
>
I'm testing this on a few more large CPU count systems. So far, so good ...
P.
> Thoughts and feedback would be appreciated!
> thanks
> -john
>
> Cc
On 06/15/2015 09:10 AM, Prarit Bhargava wrote:
>
>
> On 06/11/2015 06:54 PM, John Stultz wrote:
>> So this is a second round at trying to address the issue, trying
>> to integrate feedback from Ingo and Thomas, trying to simplify
>> what I can. I've also spli
ux...@vger.kernel.org
Signed-off-by: Prarit Bhargava
---
drivers/cpufreq/intel_pstate.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 6414661..b153d86 100644
--- a/drivers/cpufreq/intel_pstate.c
On 06/15/2015 06:12 PM, Kristen Carlson Accardi wrote:
> On Mon, 15 Jun 2015 13:43:29 -0400
> Prarit Bhargava wrote:
>
>> The kernel may delay interrupts for a long time which can result in timers
>> being delayed. If this occurs the intel_pstate driver will crash wit
After building the tests in the timers directory each executable shows up
in 'git-status' as a new file. This patch adds a .gitignore file to the
directory.
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Shuah Khan
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
---
too
On 06/05/2015 05:04 AM, Richard Cochran wrote:
> On Fri, Jun 05, 2015 at 09:29:13AM +0200, Peter Zijlstra wrote:
>> That leaves the question; for who is this exact second edge important?
>
> Distributed applications using the UTC time scale.
>
> Many control applications are done with a 1 milli
On 06/02/2015 12:02 AM, Viresh Kumar wrote:
> On 01-06-15, 09:36, Prarit Bhargava wrote:
>> This patchset was originally submitted and acked here
>>
>> http://marc.info/?l=linux-kernel&m=140203008832333&w=2
>>
>> but lost at some point.
>>
>&g
gt; Thougths and feedback would be appreciated!
Testing now ...
P.
> thanks
> -john
>
> Cc: Prarit Bhargava
> Cc: Daniel Bristot de Oliveira
> Cc: Richard Cochran
> Cc: Jan Kara
> Cc: Jiri Bohac
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Shuah Khan
On 05/29/2015 04:24 PM, John Stultz wrote:
> As Prarit reported here:
> https://lkml.org/lkml/2015/5/27/458
>
> Since the leapsecond is applied at timer tick time, and not
> the actual second edge, ABS_TIME CLOCK_REALTIME timers set for
> right after the leapsecond could fire a second early, sin
q
governors which also use the names performance and powersave. This patch
better differentiates between the two sets of governors and gives an
explanation of how the internal P-state governors behave differently from
one another.
Also fix two minor typos.
Cc: Jonathan Corbet
Cc: Prarit Bhargava
On 06/01/2015 01:02 PM, John Stultz wrote:
> On Mon, Jun 1, 2015 at 4:57 AM, Prarit Bhargava wrote:
>>
>> John, native testing went well across many 32-bit and 64-bit AMD and Intel
>> boxes. However, virtual (specifically KVM) guests failed with some sort of
>> corr
201 - 300 of 1067 matches
Mail list logo
