On 07/31/2014 06:13 PM, Saravana Kannan wrote:
> On 07/31/2014 02:08 PM, Prarit Bhargava wrote:
>>
>>
>> On 07/31/2014 04:38 PM, Saravana Kannan wrote:
>>> On 07/31/2014 01:30 PM, Prarit Bhargava wrote:
>>>>
>>>>
>>>>
]: changed acpi_no_memhotplug to bool
[v3]: cleaned up Documentation/kernel-parameters.txt
[v4]: add __initdata to acpi_no_memhotplug
[v5]: remove kexec, kdump only
Signed-off-by: Prarit Bhargava
Acked-by: Toshi Kani
Acked-by: Vivek Goyal
Cc: Vivek Goyal
Cc: Len Brown
Cc: "Rafael J. Wysocki
On 01/16/2014 08:26 PM, Rafael J. Wysocki wrote:
> On Thursday, January 16, 2014 10:35:51 AM Prarit Bhargava wrote:
>> When booting a kdump kernel on a system that has specific memory hotplug
>> regions the boot will fail with warnings like:
>
> The timestamps are still p
cpumask stack safe variant.
Signed-off-by: Prarit Bhargava
Cc: Andi Kleen
Cc: Michel Lespinasse
Cc: Seiji Aguchi
Cc: Yang Zhang
Cc: Paul Gortmaker
Cc: Janet Morgan
Cc: Tony Luck
Cc: Ruiv Wang
Cc: Gong Chen
Cc: H. Peter Anvin
Cc: Gong Chen
Cc: x...@kernel.org
Cc: Fengguang Wu
---
arch/x86
On 01/18/2014 10:50 PM, Len Brown wrote:
> On Thu, Dec 19, 2013 at 7:27 PM, Prarit Bhargava wrote:
>> From the Intel Software Developer's Manual section 14.7.4,
>>
>> "For server platforms, PP1 domain is not supported, but its PP0 domain
>> suppo
cpumask stack safe variant.
Signed-off-by: Prarit Bhargava
Cc: Andi Kleen
Cc: Michel Lespinasse
Cc: Seiji Aguchi
Cc: Yang Zhang
Cc: Paul Gortmaker
Cc: Janet Morgan
Cc: Tony Luck
Cc: Ruiv Wang
Cc: Gong Chen
Cc: H. Peter Anvin
Cc: Gong Chen
Cc: x...@kernel.org
Cc: Fengguang Wu
[v2]: switch
Roland McGrath
Cc: Oleg Nesterov
Cc: kgdb-bugrep...@lists.sourceforge.net
Signed-off-by: Prarit Bhargava
---
include/linux/module.h | 13 ++--
kernel/debug/kdb/kdb_main.c |2 +-
kernel/module.c | 74 ++-
kernel/tracepoint.c
On 09/30/2014 03:57 PM, Oleg Nesterov wrote:
> On 09/30, Prarit Bhargava wrote:
>>
>> MODULE_STATE_UNFORMED needs to be separated into two states; one for the
>> module load (MODULE_STATE_LOAD), and one for the module delete
>> (MODULE_STATE_DELETE).
>
> And pe
with dma_mapping_error().
Cc: Dan Williams
Cc: Vinod Koul
Cc: Dave Jiang
Cc: Bartlomiej Zolnierkiewicz
Cc: Kyungmin Park
Cc: dmaeng...@vger.kernel.org
Signed-off-by: Prarit Bhargava
---
drivers/dma/ioat/dma_v3.c | 35 +--
1 file changed, 29 insertions(+), 6 dele
Zheng
Cc: Seiji Aguchi
Cc: Yang Zhang
Cc: Andi Kleen
Cc: "Steven Rostedt (Red Hat)"
Cc: Li Fei
Cc: gong.c...@linux.intel.com
Signed-off-by: Prarit Bhargava
---
arch/x86/kernel/apic/io_apic.c | 28 ++--
arch/x86/kernel/irq.c |9 +++--
On 04/24/2014 07:04 PM, John Stultz wrote:
> Continuing the sporadic work on improving the timekeeping
> frequency steering logic when NOHZ is enabled, I've made a number
> of changes to my re-implementation of Miroslav's patch (most
> recently posted here: https://lkml.org/lkml/2014/2/12/401 ),
w/ 3.15-rc,
> you'll need to revert b399fe355b30d01 to get the simulator building)
> comparing this patchset to Miroslav's patch to show we're getting in
> the right order of magnitude.
>
>
Tested-by: Prarit Bhargava
P.
--
To unsubscribe from this list: send t
On 05/13/2014 02:43 AM, Jianyu Zhan wrote:
> Hi, Marek.
>
Jianyu,
> Since previous one has got no replies. I resend it again.
> This patch purely add regex pattern only. And I've tested it, it works.
>
> ---<8---
> Currently, no regular expression replacement pattern for PageCgroug*
^^^ *Cgr
d the
IRQ_MOVE_CLEANUP_VECTOR (0x20).
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Seiji Aguchi
Cc: Andi Kleen
Cc: "K. Y. Srinivasan"
Cc: "Steven Rostedt (Red Hat)"
Cc: Yinghai Lu
Acked-by: Prarit Bhargava
Signed-off-by: Yin
isable()that is only called in from
check_irq_vectors_for_cpu_disable(). This makes
the code alot easier to read.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Prarit Bhargava
Cc: Seiji Aguchi
Cc: Andi Kleen
Cc: "K. Y. Srinivasan"
Cc: &q
takes into account
the numa-awareness of an irq when reassigning the irq.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Seiji Aguchi
Cc: Andi Kleen
Cc: "K. Y. Srinivasan"
Cc: "Steven Rostedt (Red Hat)"
Cc: Yinghai Lu
Pr
isable()that is only called in from
check_irq_vectors_for_cpu_disable(). This makes
the code alot easier to read.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Prarit Bhargava
Cc: Andi Kleen
Cc: "K. Y. Srinivasan"
Cc: "Steven Rostedt (Red
takes into account
the numa-awareness of an irq when reassigning the irq.
Prarit Bhargava (1):
x86, make check_irq_vectors_for_cpu_disable() aware of numa node irqs
Yinghai Lu (1):
x86, irq: get correct available vectors for cpu disable
arch/x86/kernel/irq.c | 158
d the
IRQ_MOVE_CLEANUP_VECTOR (0x20).
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Prarit Bhargava
Cc: Andi Kleen
Cc: "K. Y. Srinivasan"
Cc: "Steven Rostedt (Red Hat)"
Cc: Yinghai Lu
Cc: "Elliott, Robert (Server Storage)"
On 03/19/2014 08:54 AM, Igor Mammedov wrote:
> On Wed, 19 Mar 2014 07:51:05 -0400
> Prarit Bhargava wrote:
>
>>
>>
>> On 03/18/2014 02:49 PM, Igor Mammedov wrote:
>>> On Tue, 18 Mar 2014 08:21:19 -0400
>>> Prarit Bhargava wrote:
>>>
>
Cc: Rob Landley
Cc: Andrew Morton
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
---
Documentation/kernel-parameters.txt |4
init/main.c | 16
2 fi
On 03/26/2014 12:34 PM, Josh Boyer wrote:
> On Wed, Mar 26, 2014 at 10:00 AM, Prarit Bhargava wrote:
>> When a module is built into the kernel, the modules's module_init()
>> function becomes an initcall. Debugging built in kernel modules is
>> typically do
On 04/14/2014 06:40 PM, Andi Kleen wrote:
>> Let's not leak all those blacklist entries when we're finished?
>
> It's difficult, because you cannot free bootmem after bootmem is
> finished.
>
> For the rare debug case some leaking should be acceptable.
>
Andrew, FWIW I agree with Andi on this
Weinberger
Cc: Andi Kleen
Cc: Josh Boyer
Cc: Rob Landley
Cc: Andrew Morton
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
[v2]: A few people recommended that I add code to allow for a list of
init
On 06/02/2014 12:30 PM, Paul Gortmaker wrote:
> On 14-06-02 07:51 AM, Prarit Bhargava wrote:
>> I have a system on which I have disabled threading in the BIOS, and I am
>> booting
>> the kernel with the option "idle=poll".
>>
>> The kernel displays
r
Cc: Andrew Morton
Cc: Andi Kleen
Cc: Dave Jones
Cc: Torsten Kaiser
Cc: Jan Beulich
Cc: Jan Kiszka
Cc: Toshi Kani
Cc: Andrew Jones
Signed-off-by: Prarit Bhargava
Prarit Bhargava (2):
x86, Clean up smp_num_siblings calculation
x86, disable ht flag when hyperthreading
gs of smp_num_siblings and fix it in two patches.
Cc: Oren Twaig
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Borislav Petkov
Cc: Paul Gortmaker
Cc: Andrew Morton
Cc: Andi Kleen
Cc: Dave Jones
Cc: Torsten Kaiser
Cc: Jan Beulich
Cc: Jan Kiszka
h
Cc: Jan Kiszka
Cc: Toshi Kani
Cc: Andrew Jones
Signed-off-by: Prarit Bhargava
---
arch/x86/kernel/smpboot.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index e5ab30b..2eaadf0 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/
On 07/25/2014 12:27 AM, Viresh Kumar wrote:
> On 24 July 2014 23:24, Prarit Bhargava wrote:
>> The closer I looked at commit 955ef483, the more questions I have. The first
>> thing is that it appears that the stacktrace includes function calls that
>> are not, and never h
On 07/25/2014 07:32 AM, Prarit Bhargava wrote:
>
>
> On 07/25/2014 12:27 AM, Viresh Kumar wrote:
>> On 24 July 2014 23:24, Prarit Bhargava wrote:
>>> The closer I looked at commit 955ef483, the more questions I have. The
>>> first
>>> thing is th
AMD defines a "Package" as the hardware processor itself. Each Package contains
multiple Nodes, and each Node has multiple Compute Units. Each Compute Unit can
have up to 2 cores that [with the 62xx and 63xx] do not have multiple Threads.
That is, to determine the number of CPUs that Linux sees,
On 06/30/2014 09:13 AM, Borislav Petkov wrote:
> On Mon, Jun 30, 2014 at 08:50:47AM -0400, Prarit Bhargava wrote:
>> AMD defines a "Package" as the hardware processor itself. Each Package
>> contains
>> multiple Nodes, and each Node has multiple Compute Un
On 06/30/2014 09:38 AM, Borislav Petkov wrote:
> On Mon, Jun 30, 2014 at 09:29:05AM -0400, Prarit Bhargava wrote:
>> Yes, I get that. But this doesn't uniquely identify *which* processor
>> it is.
>
> What do you mean, which processor it is? You want to know which
>
| grep doit | wc -l)
echo "$i running, $num_ps outstanding"
fi
done
and the system usually panics within 500 iterations.
This patch effectively reverts commit 955ef483.
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: Lenny Szubowicz
Cc: linux...@vge
: Russell King
Cc: Jesper Nilsson
Cc: Viresh Kumar
Cc: "David S. Miller"
Cc: Ramkumar Ramachandra
Cc: "Rafael J. Wysocki"
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
---
Documentation/cpu-freq/governors.txt|2 +-
Documentation/cpu-freq/int
: Randy Dunlap
Cc: Russell King
Cc: Jesper Nilsson
Cc: Viresh Kumar
Cc: "David S. Miller"
Cc: Ramkumar Ramachandra
Cc: "Rafael J. Wysocki"
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
[v2]: text update
---
Documentation/cpu-freq/governors.txt|2 +
: Randy Dunlap
Cc: Russell King
Cc: Jesper Nilsson
Cc: Viresh Kumar
Cc: "David S. Miller"
Cc: Ramkumar Ramachandra
Cc: "Rafael J. Wysocki"
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
[v2]: text update
[v3]: text update
---
Documentation/cpu-freq/gov
Cc: Josh Boyer
Cc: Rob Landley
Cc: Andrew Morton
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
[v2]: A few people recommended that I add code to allow for a list of
initcalls as there maybe
On 03/31/2014 09:04 AM, Andi Kleen wrote:
>> do_initcall_level(level);
>> +
>> +list_for_each_safe(tmp, next, &blacklisted_initcalls) {
>> +entry = list_entry(tmp, struct blacklist_entry, next);
>> +free_bootmem(entry->buf, strlen(entry->buf));
>> +
Cc: Josh Boyer
Cc: Rob Landley
Cc: Andrew Morton
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
[v2]: A few people recommended that I add code to allow for a list of
initcalls as there maybe
Weinberger
Cc: Andi Kleen
Cc: Josh Boyer
Cc: Rob Landley
Cc: Andrew Morton
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
[v2]: A few people recommended that I add code to allow for a list of
init
m_siblings = $1 = 0x1
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Borislav Petkov
Cc: Paul Gortmaker
Cc: Andrew Morton
Cc: Andi Kleen
Cc: Dave Jones
Cc: Torsten Kaiser
Cc: Jan Beulich
Cc: Jan Kiszka
Cc: Toshi Kani
Cc: Andrew Jones
Signed-o
Cc: Torsten Kaiser
Cc: Jan Beulich
Cc: Jan Kiszka
Cc: Toshi Kani
Cc: Andrew Jones
Signed-off-by: Prarit Bhargava
---
arch/x86/kernel/cpu/amd.c |1 -
arch/x86/kernel/cpu/common.c | 23 +++
arch/x86/kernel/cpu/topology.c |2 +-
arch/x86/kernel/smpboot.c
Cc: Dave Jones
Cc: Torsten Kaiser
Cc: Jan Beulich
Cc: Jan Kiszka
Cc: Toshi Kani
Cc: Andrew Jones
Signed-off-by: Prarit Bhargava
---
arch/x86/kernel/cpu/common.c |2 +-
arch/x86/kernel/smpboot.c|5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/
On 06/01/2014 05:23 AM, Oren Twaig wrote:
> Hi Prarit,
>
> See below,
>
> On 05/30/2014 02:43 PM, Prarit Bhargava wrote:
>> I have a system on which I have disabled threading in the BIOS, and I am
>> booting
>> the kernel with the option "idle=poll&quo
I have a system on which I have disabled threading in the BIOS, and I am booting
the kernel with the option "idle=poll".
The kernel displays
process: WARNING: polling idle and HT enabled, performance may degrade
which is incorrect -- I've already disabled HT.
This warning is issued here:
void
n
Cc: Dave Jones
Cc: Torsten Kaiser
Cc: Jan Beulich
Cc: Jan Kiszka
Cc: Toshi Kani
Cc: Andrew Jones
Signed-off-by: Prarit Bhargava
---
arch/x86/kernel/cpu/amd.c |1 -
arch/x86/kernel/cpu/common.c | 23 +++
arch/x86/kernel/cpu/topology.c |2 +-
arch/x8
On 06/02/2014 12:30 PM, Paul Gortmaker wrote:
> On 14-06-02 07:51 AM, Prarit Bhargava wrote:
>> I have a system on which I have disabled threading in the BIOS, and I am
>> booting
>> the kernel with the option "idle=poll".
>>
>> The kernel displays
On 06/02/2014 12:30 PM, Paul Gortmaker wrote:
> I wonder if this code is in need of an update? I recall reading
> this thread:
>
> http://forum.osdev.org/viewtopic.php?f=1&t=23445
>
> which suggests that we try CPUID with 0xb, and then 0x4 _before_
> relying on the EBX[23:16] of the older C
_disable() allocates two cpumasks on the
stack. Fix this by moving the two cpumasks to a global file context.
Signed-off-by: Prarit Bhargava
Cc: Andi Kleen
Cc: Michel Lespinasse
Cc: Seiji Aguchi
Cc: Yang Zhang
Cc: Paul Gortmaker
Cc: Janet Morgan
Cc: Tony Luck
Cc: Ruiv Wang
Cc: Gong Che
On 01/26/2014 03:50 PM, Yinghai Lu wrote:
> assign_irq_vector will stop before first_system_vector.
> also it will not vector that is set in used_vectors.
>
> used_vectors is used to track non per_cpu irq_vector in vector_irq.
> It include first 32 exception [0,1f) and system vector near 0xfe.
>
On 01/28/2014 04:54 PM, Yinghai Lu wrote:
> used_vectors is a bitmap for vectors that are not tracked in per_cpu
> vector_irq.
> used_vectors contains information on the first 32 exceptions, the system
> vectors.
> the IA32_SYSCALL_VECTOR (0x80), and the IRQ_MOVE_CLEANUP_VECTOR (0x20).
>
> assi
3108.872896] [] ? kthread_create_on_node+0x180/0x180
[ 3108.880176] ---[ end trace 078b214fc68689e7 ]---
This patch adds a range check in the edac_mc_poll_msec code to check for 0.
Signed-off-by: Prarit Bhargava
Cc: Doug Thompson
Cc: linux-kernel@vger.kernel.org
---
drivers/edac/edac_mc_sysfs.c |2 +-
1 file changed,
On 02/04/2014 04:01 PM, Greg Kroah-Hartman wrote:
> 3.10-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Prarit Bhargava
>
> commit da6139e49c7cb0f4251265cb5243b8d220adb48d upstream.
>
> Bugzilla:
On 02/04/2014 04:06 PM, Greg Kroah-Hartman wrote:
> 3.12-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Prarit Bhargava
>
> commit da6139e49c7cb0f4251265cb5243b8d220adb48d upstream.
>
> Bugzilla:
the top-level Makefile and to the ignore
list in scripts/tags.sh.
Signed-off-by: Prarit Bhargava
Cc: Michal Marek
Cc: Andrew Morton
Cc: Kirill Tkhai
Cc: Michael Opdenacker
Cc: Rusty Russell
Cc: linux-kbu...@vger.kernel.org
---
Makefile|3 ++-
scripts/tags.sh |2 +-
2 files cha
On 02/05/2014 10:05 AM, Michal Marek wrote:
> On 2014-02-05 16:01, Prarit Bhargava wrote:
>> Add *.mod.c to the RCS_FIND_IGNORE in the top-level Makefile and to the
>> ignore
>> list in scripts/tags.sh.
>
>
> This breaks make clean, which is supposed to remove
it() seems more appropriate here and then we
can avoid these delays, resulting in very quick load times for the
microcode.
Signed-off-by: Prarit Bhargava
Cc: x...@kernel.org
Cc: herrmann.der.u...@googlemail.com
Cc: ming@canonical.com
Cc: tig...@aivazian.fsnet.co.uk
Prarit Bhargava (2):
dd a
debug dev_dbg() to indicate that the FW has not been found.
Signed-off-by: Prarit Bhargava
Cc: x...@kernel.org
Cc: herrmann.der.u...@googlemail.com
Cc: ming@canonical.com
Cc: tig...@aivazian.fsnet.co.uk
---
drivers/base/firmware_class.c |6 +-
1 file changed, 5 insertions(+),
very quick load times for the
microcode.
Signed-off-by: Prarit Bhargava
Cc: x...@kernel.org
Cc: herrmann.der.u...@googlemail.com
Cc: ming@canonical.com
Cc: tig...@aivazian.fsnet.co.uk
---
arch/x86/include/asm/microcode.h |7
arch/x86/kernel/microcode
On 10/21/2013 08:20 AM, Ming Lei wrote:
> On Mon, Oct 21, 2013 at 5:35 AM, Prarit Bhargava wrote:
>> If no firmware is found on the system that matches the processor, the
>> microcode module can take hours to load. For example on recent kernels
>> when loading the microco
On 10/21/2013 08:32 AM, Ming Lei wrote:
> On Mon, Oct 21, 2013 at 8:26 PM, Prarit Bhargava wrote:
>>>
>>> And why don't you pass FW_ACTION_HOTPLUG? and you are sure
>>> that udev isn't required to handle your microcode update request?
>>>
&g
On 10/21/2013 08:24 AM, Ming Lei wrote:
> On Mon, Oct 21, 2013 at 5:35 AM, Prarit Bhargava wrote:
>> If request_firmware_nowait() is called with uevent == NULL, the firmware
>> completion is never marked complete resulting in a hang in the process.
>>
>> If uevent is
On 10/21/2013 10:35 PM, Ming Lei wrote:
> On Tue, Oct 22, 2013 at 6:24 AM, Prarit Bhargava wrote:
>>
>>
>> On 10/21/2013 08:24 AM, Ming Lei wrote:
>>> On Mon, Oct 21, 2013 at 5:35 AM, Prarit Bhargava wrote:
>>>> If request_firmware_nowait() i
On 10/21/2013 10:43 PM, Ming Lei wrote:
> On Mon, Oct 21, 2013 at 10:25 PM, Prarit Bhargava wrote:
>>
>>
>> On 10/21/2013 08:32 AM, Ming Lei wrote:
>>> On Mon, Oct 21, 2013 at 8:26 PM, Prarit Bhargava wrote:
>>>>>
>>>>> And why don&#x
On 10/23/2013 12:16 AM, Ming Lei wrote:
> On Wed, Oct 23, 2013 at 7:15 AM, Prarit Bhargava wrote:
>> On 10/21/2013 10:35 PM, Ming Lei wrote:
>>>
>>> That is why NOHOTPLUG isn't encouraged to be taken, actually
>>> I don't suggest you to do that
On 10/23/2013 06:36 AM, Prarit Bhargava wrote:
>
>
> On 10/23/2013 12:16 AM, Ming Lei wrote:
>> On Wed, Oct 23, 2013 at 7:15 AM, Prarit Bhargava wrote:
>>> On 10/21/2013 10:35 PM, Ming Lei wrote:
>>>>
>>>> That is why NOHOTPLUG isn't enco
On 10/23/2013 09:21 AM, Ming Lei wrote:
> On Wed, Oct 23, 2013 at 8:02 PM, Prarit Bhargava wrote:
>
>>
>> After all this I completely forgot the problem I'm trying to solve here. The
>> issue is that with HOTPLUG & request_microcode_nowait(), if the microcod
On 10/24/2013 07:17 AM, Henrique de Moraes Holschuh wrote:
> On Wed, 23 Oct 2013, Prarit Bhargava wrote:
>> After all this I completely forgot the problem I'm trying to solve here. The
>> issue is that with HOTPLUG & request_microcode_nowait(), if the microcode
>&g
On 12/03/2013 09:48 PM, rui wang wrote:
> On 11/20/13, Prarit Bhargava wrote:
> Have you considered the case when an IRQ is destined to more than one CPU?
> e.g.:
>
> bash# cat /proc/irq/89/smp_affinity_list
> 30,62
> bash#
>
> In this case offlining CPU30 does n
CPU to go down, an
error is returned and propogated back to userspace.
v2: Do not look at percpu irqs
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Michel Lespinasse
Cc: Andi Kleen
Cc: Seiji Aguchi
Cc: Yang Zhang
On 12/19/2013 02:19 AM, rui wang wrote:
> On 12/19/13, Prarit Bhargava wrote:
>>
>>
>> On 12/03/2013 09:48 PM, rui wang wrote:
>>> On 11/20/13, Prarit Bhargava wrote:
>>> Have you considered the case when an IRQ is destined to more than one CPU?
&
On 12/19/2013 01:05 PM, Tony Luck wrote:
> On Wed, Dec 18, 2013 at 11:50 AM, Tony Luck wrote:
>> Looks good to me.
>
> Though now I've been confused by an offline question about affinity.
Heh :) I'm pursuing it now. Rui has asked a pretty good question that I don't
know the answer to off the
On 12/19/2013 02:19 AM, rui wang wrote:
> On 12/19/13, Prarit Bhargava wrote:
>>
>>
>> On 12/03/2013 09:48 PM, rui wang wrote:
>>> On 11/20/13, Prarit Bhargava wrote:
>>> Have you considered the case when an IRQ is destined to more than one CPU?
&
d failed
because the server doesn't support the MSR_PP1_ENERGY_STATUS
register (0x641). This patch implements a get_msr_nowarn() which suppresses the
above warning and then sets !RAPL_GFX.
Signed-off-by: Prarit Bhargava
Cc: Len Brown
Cc: "Rafael J. Wysocki"
Cc: Josh Triplett
Cc: Kr
On 12/20/2013 04:41 AM, rui wang wrote:
> On 12/20/13, Prarit Bhargava wrote:
>>
>>
>> On 12/19/2013 01:05 PM, Tony Luck wrote:
>>> On Wed, Dec 18, 2013 at 11:50 AM, Tony Luck wrote:
>>>> Looks good to me.
>>>
>>> Though now I'
be used in scripts/tags.sh and
add explicitly ignore *.mod.c files.
Signed-off-by: Prarit Bhargava
Cc: Michal Marek
Cc: Andrew Morton
Cc: Kirill Tkhai
Cc: Michael Opdenacker
Cc: Rusty Russell
Cc: linux-kbu...@vger.kernel.org
---
Makefile|5 +++--
scripts/tags.sh |9 --
t; - vector++) {
> +
> + /*
> + * assign_irq_vector() only scan per_cpu vectors from
> + * FIRST_EXTERNAL_VECTOR to first_system_vector.
> + * It aslo skip vectors that are set in used_vectors bitmask.
"also&qu
hould stop with an error message after the first
failure. Fix the error return in cmd_freq_set() to read errors as less
than zero.
Signed-off-by: Prarit Bhargava
Cc: Dominik Brodowski
Cc: Thomas Renninger
Cc: "Rafael J. Wysocki"
Cc: Alan Cox
Cc: One Thousand Gnomes
---
tools/
On 02/07/2014 01:55 PM, Prarit Bhargava wrote:
> On a system which has only 4.00GHz set as the only available frequency,
>
> [root@amd-pike-05 ~]# cpupower frequency-info
>
> current policy: frequency should be within 4.00 GHz and 4.00 GHz.
> The govern
On 12/30/2013 09:58 PM, rui wang wrote:
> On 12/30/13, Prarit Bhargava wrote:
>>
>>
>> On 12/30/2013 07:56 AM, rui wang wrote:
>>
> ...
>> Okay, so the big issue is that we need to do the calculation without this
>> cpu,
>
>>
>> int c
On 01/01/2014 09:41 PM, Chen, Gong wrote:
> On Tue, Dec 31, 2013 at 04:22:09PM -0500, Prarit Bhargava wrote:
>> Okay, how about,
>> if (irq_has_action(irq) && !irqd_is_per_cpu(data) &&
>>
On 01/02/2014 07:57 AM, Prarit Bhargava wrote:
>
>
> On 01/01/2014 09:41 PM, Chen, Gong wrote:
>> On Tue, Dec 31, 2013 at 04:22:09PM -0500, Prarit Bhargava wrote:
>>> Okay, how about,
>>> if (irq_has_act
CPU to go down, an
error is returned and propogated back to userspace.
Tested on both -tip and current linux.git.
v2: Do not need to look at percpu irqs
v3: Need to check affinity to prevent counting of MSIs in IOAPIC Lowest
Priority Mode
v4: Additional changes suggested by Gong Chen.
Signed-off
On 01/05/2014 11:07 AM, Prarit Bhargava wrote:
> I tested this by doing a continuous loop of booting a system, downing all
> cpus, and then rebooting. Before every reboot I grepped the dmesg log for
> the do_IRQ warning to see if there were any additional do_IRQ warnings and
> I do
patchset resolves this by adding definitions for VECTOR_UNDEFINED(-1) and
VECTOR_RETRIGGERED(-2) and modifying the code to use them.
[v2]: sent with more detailed commit message
[v3]: set vector_irq[irq] back to VECTOR_UNDEFINED after call in do_IRQ()
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixn
patchset resolves this by adding definitions for VECTOR_UNDEFINED(-1) and
VECTOR_RETRIGGERED(-2) and modifying the code to use them.
[v2]: sent with more detailed commit message
[v3]: set vector_irq[irq] back to VECTOR_UNDEFINED after call in do_IRQ()
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixn
uma core_id is now only used for debug output.
Successfully tested on the system above and also verified on an Intel
dual-socket E5-26XX system.
Signed-off-by: Prarit Bhargava
Cc: Len Brown
Cc: Kristen Carlson Accardi
---
tools/power/x86/turbostat/turbostat.c | 20 +---
1 file
ated back to userspace.
v2: Do not need to look at percpu irqs
v3: Need to check affinity to prevent counting of MSIs in IOAPIC Lowest
Priority Mode
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Michel Lespinasse
On 12/23/2013 02:12 AM, Chen, Gong wrote:
> On Fri, Dec 20, 2013 at 10:50:09AM -0500, Prarit Bhargava wrote:
>> +int check_vectors(void)
>> +{
>> +int irq, cpu;
>> +unsigned int vector, this_count, count;
>> +struct irq_desc *desc;
>> +
8<
Gong Chen caught this coding error during inspection of the patch. The
code should be AND not OR.
Signed-off-by: Prarit Bhargava
Cc: Michel Lespinasse
Cc: Seiji Aguchi
Cc: Yang Zhang
Cc: Paul Gortmaker
Cc: Janet Morgan
Cc: Tony Luck
Cc: Ruiv Wang
Cc: Gong Chen
Cc: Andi Klee
On 12/23/2013 04:41 AM, rui wang wrote:
> On 12/2/13, Prarit Bhargava wrote:
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64831
>>
>> When downing a cpu it is possible that there are unhandled irqs left in
>> the APIC IRR register. fixup_irqs() goes thr
On 12/23/2013 11:41 PM, rui wang wrote:
> On 12/23/13, Prarit Bhargava wrote:
> > I think I have root caused this to the IRR being set in the down'd cpu. It
> > is
> > admittedly a rare occurrence in the kernel. I usually have to run about
> > 1000 up
> >
On 12/23/2013 09:51 PM, Chen, Gong wrote:
> On Mon, Dec 23, 2013 at 09:39:12AM -0500, Prarit Bhargava wrote:
>> diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
>> index 7d40698..aed7acc 100644
>> --- a/arch/x86/kernel/irq.c
>> +++ b/arch/x86/kernel/irq.c
On 12/24/2013 09:40 PM, Chen, Gong wrote:
> On Tue, Dec 24, 2013 at 08:19:09AM -0500, Prarit Bhargava wrote:
>> On 12/23/2013 09:51 PM, Chen, Gong wrote:
>>> On Mon, Dec 23, 2013 at 09:39:12AM -0500, Prarit Bhargava wrote:
>>>> diff --git a/arch/x86/kernel
On 12/25/2013 03:22 AM, rui wang wrote:
>
> Yes that comment was what triggered me to think that the issue wasn't
> understood. You now have a clear enough explanation.
>
Rui, you've pointed out that my patch description in insufficient. I'll rewrite
it and resubmit with a much more detailed
On 12/27/2013 08:07 PM, H. Peter Anvin wrote:
> On 12/27/2013 08:13 AM, Prarit Bhargava wrote:
>>>
>>> Back to my question, assume cpu1 will be off-lined and one irq affinity is
>>> set as (1, 2) -- this irq will be bypassed. Looks good. But if one irq
>>&g
On 12/20/2013 04:41 AM, rui wang wrote:
> On 12/20/13, Prarit Bhargava wrote:
>>
>>
>> On 12/19/2013 01:05 PM, Tony Luck wrote:
>>> On Wed, Dec 18, 2013 at 11:50 AM, Tony Luck wrote:
>>>> Looks good to me.
>>>
>>> Though now I'
modifying the code to use them.
[v2]: sent with more detailed commit message
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Michel Lespinasse
Cc: Andi Kleen
Cc: Seiji Aguchi
Cc: Yang Zhang
Cc: Paul Gortmaker
Cc: j
On 12/30/2013 02:44 AM, Chen, Gong wrote:
> On Sat, Dec 28, 2013 at 12:10:38PM -0500, Prarit Bhargava wrote:
>> Gong and Rui,
>>
>> After looking at this in detail I realized I made a mistake in my patch by
>> including the check for the smp_affinity. Simply put, it
401 - 500 of 1067 matches
Mail list logo
