On 06/01/2015 04:18 PM, Daniel Bristot de Oliveira wrote:
>
>
> Il 29/05/2015 17:24, John Stultz ha scritto:
>> Thus this patch series tries to address this isssue, including
>> extending the leap-a-day test to catch this problem, as well
>> as other relevant fixups I found while working on the c
eturning -EINVAL. Since intel_pstate_sample() has been called, subsequent
timer function calls will then again pick up the correct calculations and the
system will continue functioning properly.
Cc: Kristen Carlson Accardi
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.o
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 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
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 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
attempts to load amd64_edac_mod, which
fails because of unknown symbols from edac_mce_amd.
add_unformed_module() must wait to return for any case other than
MODULE_STATE_LIVE to prevent a race between multiple loads of
dependent modules.
Signed-off-by: Prarit Bhargava
Reported-by: Cathy Avery
Cc
On 4/3/19 3:02 AM, Naoya Horiguchi wrote:
> turbostat could be terminated by general protection fault on some latest
> hardwares which (for example) support 9 levels of C-states and show 18
> "tADDED" lines. That bloats the total output and finally causes buffer
> overrun. So let's extend the b
Jessica? ping?
P.
On 4/2/19 9:39 AM, Prarit Bhargava wrote:
> Microsoft HyperV disables the X86_FEATURE_SMCA bit on AMD systems, and
> linux guests boot with repeated errors:
>
> amd64_edac_mod: Unknown symbol amd_unregister_ecc_decoder (err -2)
> amd64_edac_mod:
t: Warn on bad ACPI LPIT data")
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Prarit Bhargava
P.
> ---
> tools/power/x86/turbostat/turbostat.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tools/power/x86/turbostat/turbostat.c
> b/tools/power/x
Chunyan Zhang wrote:
> From: Prarit Bhargava
>
> printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock
> timestamp to printk messages. The local hardware clock loses time each
> day making it difficult to determine exactly when an issue has occurred in
&
On 8/11/20 9:02 AM, Petr Mladek wrote:
> On Tue 2020-08-11 14:05:12, Thomas Gleixner wrote:
>> Petr Mladek writes:
>>> At least "crash" tool would need an update anyway. AFAIK, it checks
>>> the size of struct printk_log and refuses to read it when it changes.
>>>
>>> It means that the hack wit
On 8/5/20 10:04 AM, Petr Mladek wrote:
> On Wed 2020-07-29 08:22:36, Prarit Bhargava wrote:
>> Chunyan Zhang wrote:
>>> From: Prarit Bhargava
>>>
>>> printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock
>>> timestamp to pri
e actually affinity is broken.
>
> If no node is assigned then only the full affinity mask and if that fails
> the full online mask is tried.
>
> Fixes: d6ffc6ac83b1 ("x86/vector: Respect affinity mask in irq descriptor")
> Reported-by: Shung-Hsi Yu
> Reported-by
ignment of the
irqs is still done later in the cpu disable code path.
At the same time I've created a helper function,
_evaluate_irq_for_cpu_disable()that is only called in from
check_irq_vectors_for_cpu_disable(). This makes
the code alot easier to read.
Signed-off-by: Prarit Bhargav
On 11/03/2013 05:18 AM, Ingo Molnar wrote:
>
> * Josh Boyer wrote:
>
>> The current range for SMP configs is 2 - 512, or a full 4096 in the case
>> of MAXSMP. There are machines that have 1024 CPUs in them today and
>> configuring a kernel for that means you are forced to set MAXSMP. This
On 11/04/2013 09:16 AM, Josh Boyer wrote:
> On Mon, Nov 04, 2013 at 03:10:51PM +0100, Ingo Molnar wrote:
>>
>> * Josh Boyer wrote:
>>
Why touch MAXSMP at all? It's really just a shortcut for 'configure
the kernel silly large', via a single option, nothing else. You are
not force
: janet.mor...@intel.com
Cc: tony.l...@intel.com
Cc: ruiv.w...@gmail.com
Signed-off-by: Prarit Bhargava
---
arch/x86/kernel/apic/io_apic.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 6ad4658..bf97b64
On 03/04/2014 05:37 PM, David Rientjes wrote:
> On Tue, 4 Mar 2014, Prarit Bhargava wrote:
>
>> linux.git commit 9345005f4eed805308193658d12e4e7e9c261e74 added
>> a definition for VECTOR_UNDEFINED = -1. There is a missing replacement in
>> the io_apic.c file. Found dur
mas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Rui Wang
Cc: Liu Ping Fan
Cc: Bjorn Helgaas
Cc: Yoshihiro YUNOMAE
Cc: Lv Zheng
Cc: Seiji Aguchi
Cc: Yang Zhang
Cc: Andi Kleen
Cc: "Steven Rostedt (Red Hat)"
Cc: Li Fei
Cc: gong.c...@linux.intel.co
During another patch review, David Rientjes noted that VECTOR_UNDEFINED
and VECTOR_RETRIGGERED should be defined with ()s so that they are not
erroneously used in an arithmetic operation.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin&qu
On 03/05/2014 04:09 PM, David Rientjes wrote:
> On Wed, 5 Mar 2014, Prarit Bhargava wrote:
>
>> diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
>> index d99f31d..55fab61 100644
>> --- a/arch/x86/kernel/irq.c
>> +++ b/arch/x86/kernel/irq.c
>> @@ -
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 +++--
2 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kernel/apic/io_a
On 03/06/2014 09:10 AM, Igor Mammedov wrote:
> Hang is observed on virtual machines during CPU hotplug, especially
> in big guests with many CPUs. (It happens more often if host is
> over-committed).
>
> Patch is present in RHEL6 since 2012 and it fixes issue there,
> it also fixes issue in upst
all_function_single(.wait=1) for the
> irq_cpu_stop_queue_work() to ensure the queueing is actually done under
> stop_cpus_lock. Without this we could have dropped the lock by the time
> we do the queueing and get the race we tried to fix.
>
> Fixes: 7053ea1a34fa ("stop_machine:
On 03/13/2014 10:25 AM, Igor Mammedov wrote:
> Hang is observed on virtual machines during CPU hotplug,
> especially in big guests with many CPUs. (It happens more
> often if host is over-committed).
>
Hey Igor, I like this better than the previous version. Thanks for taking into
account the p
On 03/18/2014 02:49 PM, Igor Mammedov wrote:
> On Tue, 18 Mar 2014 08:21:19 -0400
> Prarit Bhargava wrote:
>
>>
>>
>> On 03/13/2014 10:25 AM, Igor Mammedov wrote:
>>> Hang is observed on virtual machines during CPU hotplug,
>>> especially i
nregister() is called outside of the dev->device_lock so it
looks like mei_watchdog_register() can as well.
Signed-off-by: Prarit Bhargava
Cc: Tomas Winkler
---
drivers/misc/mei/hbm.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
>>
>> when NR_CPUS=8192
>>
>> We should use zalloc_cpumask_var() instead.
>>
>> -v2: update to GFP_ATOMIC instead and free the allocated cpumask at last.
>>
>> Signed-off-by: Yinghai Lu
>> Cc: Prarit Bhargava
>>
>> ---
>>
On 01/26/2014 08:32 AM, Ingo Molnar wrote:
>
> * Prarit Bhargava wrote:
>
>> On 01/25/2014 03:02 AM, Ingo Molnar wrote:
>>>
>>> * Yinghai Lu wrote:
>>>
>>>> Fix warning:
>>>> arch/x86/kernel/irq.c: In function check_irq_vecto
On 01/26/2014 03:29 PM, H. Peter Anvin wrote:
> I strongly disagree with putting variables in file scope when function scope
> will do, but I do like to see static variables before automatics. Anyway,
> this is bikeshedding.
>
> Ingo Molnar wrote:
>>
>> * H. Peter Anvin wrote:
>>
>>> s/glob
()s so that they are not
erroneously used in an arithmetic operation.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Seiji Aguchi
Cc: Yang Zhang
Cc: Andi Kleen
Cc: David Rientjes
---
arch/x86/include/asm/hw_irq.h |
placement in
the io_apic.c file. Found during debugging of another issue.
Cc: Rui Wang
Cc: Michel Lespinasse
Cc: Seiji Aguchi
Cc: Yang Zhang
Cc: Paul Gortmaker
Cc: janet.mor...@intel.com
Cc: tony.l...@intel.com
Cc: ruiv.w...@gmail.com
Cc: David Rientjes
Acked-by: David Rientjes
Signe
to standard changelog style
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Rui Wang
Cc: Liu Ping Fan
Cc: Bjorn Helgaas
Cc: Yoshihiro YUNOMAE
Cc: Lv Zheng
Cc: Seiji Aguchi
Cc: Yang Zhang
Cc: Andi Kleen
Cc: "Steven Rostedt (Red Hat)"
Cc:
CPU to go down, an
error is returned and propogated 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
v4: Additional changes suggested by Gong Chen.
v5/v6: Updated comment text
Signed-off-by: Prarit Bh
On 01/07/2014 12:54 PM, Luck, Tony wrote:
> + for (vector = FIRST_EXTERNAL_VECTOR; vector < NR_VECTORS; vector++) {
> + irq = __this_cpu_read(vector_irq[vector]);
> + if (irq >= 0) {
> + desc = irq_to_desc(irq);
> + data = irq_de
CPU to go down, an
error is returned and propogated 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
v4: Additional changes suggested by Gong Chen.
v5/v6/v7: Updated comment text
Signed-off-by: Prarit Bh
On 01/09/2014 04:44 PM, Vivek Goyal wrote:
> On Thu, Jan 09, 2014 at 04:34:16PM -0500, KOSAKI Motohiro wrote:
>> On Thu, Jan 9, 2014 at 10:00 AM, Vivek Goyal wrote:
>>> On Thu, Jan 09, 2014 at 12:00:29AM +0100, Rafael J. Wysocki wrote:
>
> Makes sense. Something like "acpi_no_memhotplug" or "a
On 01/09/2014 10:57 PM, Yasuaki Ishimatsu wrote:
> (2014/01/10 6:44), Vivek Goyal wrote:
>> On Thu, Jan 09, 2014 at 04:34:16PM -0500, KOSAKI Motohiro wrote:
>>> On Thu, Jan 9, 2014 at 10:00 AM, Vivek Goyal wrote:
On Thu, Jan 09, 2014 at 12:00:29AM +0100, Rafael J. Wysocki wrote:
[
ACPI memory hotplug.
[v2]: changed to acpi_no_memhotplug
Signed-off-by: Prarit Bhargava
Cc: Vivek Goyal
Cc: Len Brown
Cc: "Rafael J. Wysocki"
Cc: kosaki.motoh...@gmail.com
Cc: dyo...@redhat.com
Cc: linux-a...@vger.kernel.org
Cc: ke...@lists.infradead.org
---
Documentation/kernel-para
ACPI memory hotplug.
[v2]: changed acpi_no_memhotplug to bool
Signed-off-by: Prarit Bhargava
Cc: Vivek Goyal
Cc: Len Brown
Cc: "Rafael J. Wysocki"
Cc: kosaki.motoh...@gmail.com
Cc: dyo...@redhat.com
Cc: linux-a...@vger.kernel.org
Cc: ke...@lists.infradead.org
---
Documentat
On 01/10/2014 09:34 AM, Prarit Bhargava wrote:
> When booting a kexec/kdump kernel on a system that has specific memory hotplug
> regions the boot will fail with warnings like:
>
Oops. Sorry, fat-fingered this.
Ignore please.
P.
--
To unsubscribe from this list: send the line &qu
On 01/10/2014 09:49 AM, Vivek Goyal wrote:
> On Fri, Jan 10, 2014 at 09:36:55AM -0500, Prarit Bhargava wrote:
>
> [..]
>> This can also be reproduced by using the memmap=exactmap and mem=X
>> parameters on the main kernel and booting.
>>
>> This patchset resolv
ACPI memory hotplug.
[v2]: changed to acpi_no_memhotplug
Signed-off-by: Prarit Bhargava
Cc: Vivek Goyal
Cc: Len Brown
Cc: "Rafael J. Wysocki"
Cc: kosaki.motoh...@gmail.com
Cc: dyo...@redhat.com
Cc: linux-a...@vger.kernel.org
Cc: ke...@lists.infradead.org
---
Documentation/kernel-para
mapping ACPI Memory Hotplug should be
disabled in this case.
[v2]: really add mem=
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Len Brown
Cc: "Rafael J. Wysocki"
Cc: Linn Crosetto
Cc: Pekka Enberg
Cc: Yi
ACPI memory hotplug.
[v2]: changed acpi_no_memhotplug to bool
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Len Brown
Cc: "Rafael J. Wysocki"
Cc: Linn Crosetto
Cc: Pekka Enberg
Cc: Yinghai Lu
Cc: Andrew Mo
This patchset adds the ability for the user to disable ACPI Memory Hotplug
by adding "acpi_no_memhotplug" as a kernel paramaeter, and disables
ACPI Memory Hotplug by default when the memmap=exactmap and mem=X parameters
are used.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
On 01/10/2014 01:46 PM, Prarit Bhargava wrote:
> kdump uses memmap=exactmap and mem=X values to configure the memory
> mapping for the kdump kernel. If memory is hotadded during the boot of
> the kdump kernel it is possible that the page tables for the new memory
> cause the kdump k
On 01/11/2014 11:35 AM, 7egg...@gmx.de wrote:
>
>
> On Fri, 10 Jan 2014, Prarit Bhargava wrote:
>
>> kdump uses memmap=exactmap and mem=X values to configure the memory
>> mapping for the kdump kernel. If memory is hotadded during the boot of
>> the kdump kerne
On 01/12/2014 04:56 AM, Ingo Molnar wrote:
>
> * Prarit Bhargava wrote:
>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64791
>>
>> When a cpu is downed on a system, the irqs on the cpu are assigned to
>> other cpus. It is possible, however
CPU to go down, an
error is returned and propogated 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
v4: Additional changes suggested by Gong Chen.
v5/v6/v7/v8: Updated comment text
Signed-off-by: Pra
redefining irq as a signed int. The remaining consumers of the
int are okay.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
Cc: Joerg Roedel
Cc: Fengguang
parameter,
acpi_no_memhotplug, to disable ACPI memory hotplug. ACPI memory hotplug
should also be disabled by default when a user specified a memory mapping with
"memmap=exactmap" or "mem=X".
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin&
On 01/13/2014 03:31 PM, KOSAKI Motohiro wrote:
> On Sun, Jan 12, 2014 at 6:46 PM, Prarit Bhargava wrote:
>>
>>
>> On 01/11/2014 11:35 AM, 7egg...@gmx.de wrote:
>>>
>>>
>>> On Fri, 10 Jan 2014, Prarit Bhargava wrote:
>>>
>>>>
On 01/13/2014 05:17 PM, KOSAKI Motohiro wrote:
> On Mon, Jan 13, 2014 at 4:56 PM, Prarit Bhargava wrote:
>> When booting a kexec/kdump kernel on a system that has specific memory
>> hotplug
>> regions the boot will fail with warnings like:
>>
>> [2.9
On 01/13/2014 09:43 PM, Yasuaki Ishimatsu wrote:
> (2014/01/14 10:41), Toshi Kani wrote:
>> On Tue, 2014-01-14 at 10:11 +0900, Yasuaki Ishimatsu wrote:
>> :
> I think we need a knob manually enable mem-hotplug when specify memmap.
> But
> it is another story.
>
> Acked-by:
On 01/13/2014 07:33 PM, Toshi Kani wrote:
> On Mon, 2014-01-13 at 18:39 -0500, Prarit Bhargava wrote:
>>
>> On 01/13/2014 03:31 PM, KOSAKI Motohiro wrote:
>>> On Sun, Jan 12, 2014 at 6:46 PM, Prarit Bhargava wrote:
>>>>
>>>>
&
On 01/13/2014 08:41 PM, Toshi Kani wrote:
> On Tue, 2014-01-14 at 10:11 +0900, Yasuaki Ishimatsu wrote:
> :
I think we need a knob manually enable mem-hotplug when specify memmap. But
it is another story.
Acked-by: KOSAKI Motohiro
>>>
>>> As mentioned, self-NAK. I have seen
ACPI memory hotplug.
[v2]: changed acpi_no_memhotplug to bool
[v3]: cleaned up Documentation/kernel-parameters.txt
Signed-off-by: Prarit Bhargava
Cc: Vivek Goyal
Cc: Len Brown
Cc: "Rafael J. Wysocki"
Cc: kosaki.motoh...@gmail.com
Cc: dyo...@redhat.com
Cc: toshi.k...@hp.com
Cc: is
On 01/14/2014 07:42 PM, David Rientjes wrote:
> On Tue, 14 Jan 2014, Prarit Bhargava wrote:
>
>> diff --git a/Documentation/kernel-parameters.txt
>> b/Documentation/kernel-parameters.txt
>> index b9e9bd8..ea93f75 100644
>> --- a/Documentation/kernel-parameters.txt
ACPI memory hotplug.
[v2]: changed acpi_no_memhotplug to bool
[v3]: cleaned up Documentation/kernel-parameters.txt
[v4]: add __initdata to acpi_no_memhotplug
Signed-off-by: Prarit Bhargava
Cc: Vivek Goyal
Cc: Len Brown
Cc: "Rafael J. Wysocki"
Cc: kosaki.motoh...@gmail.com
Cc: dyo...@red
CPU to go down, an
error is returned and propogated back to userspace.
Signed-off-by: Prarit Bhargava
Cc: x...@kernel.org
---
arch/x86/include/asm/irq.h |1 +
arch/x86/kernel/irq.c | 33 +
arch/x86/kernel/smpboot.c |6 ++
3 files changed,
s an error immediately if the
>>> f/w can't be loaded directly in kernel.
>>>
>>> Without CONFIG_FW_LOADER_USER_HELPER=y, request_firmware_direct() is
>>> just an alias of request_firmware(), due to obvious reason.
>>>
>>> Tested-by:
and
discovered that that we are getting bogus events. This patchset resolves
this by adding definitions for VECTOR_UNDEFINED(-1) and
VECTOR_RETRIGGERED(-2) and modifying the code to use them.
Signed-off-by: Prarit Bhargava
Cc: x...@kernel.org
---
arch/x86/include/asm/hw_irq.h |2 ++
arch
;t enough vectors for the CPU to go down, an
error is returned and propogated back to userspace.
Signed-off-by: Prarit Bhargava
Cc: x...@kernel.org
---
arch/x86/include/asm/irq.h |1 +
arch/x86/kernel/irq.c | 33 +
arch/x86/kernel/smpboot.c |6 ++
& vector was retriggered and
discovered that that we are getting bogus events. This patchset resolves
this by adding definitions for VECTOR_UNDEFINED(-1) and
VECTOR_RETRIGGERED(-2) and modifying the code to use them.
Signed-off-by: Prarit Bhargava
Cc: x...@kernel.org
---
arch/x86/include
rocode in place and without, as well as on several different OSes.
Signed-off-by: Prarit Bhargava
Cc: tig...@aivazian.fsnet.co.uk
Cc: x...@kernel.org
Cc: h...@hmh.eng.br
Cc: a...@firstfloor.org
v2: Update for Andi's and Henrique's comments.
---
arch/x86/kerne
On 10/28/2013 11:06 AM, Henrique de Moraes Holschuh wrote:
> On Mon, 28 Oct 2013, Borislav Petkov wrote:
>> So Prarit, please split this patch into changes which *directly* address
>> the issue and other cleanups ontop. This will simplify review immensely
>> as having one single bulky patch is no
On 10/28/2013 11:05 AM, Takashi Iwai wrote:
> At Mon, 28 Oct 2013 08:06:08 -0400,
> 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
>> whe
On 10/28/2013 11:05 AM, Takashi Iwai wrote:
> At Mon, 28 Oct 2013 08:06:08 -0400,
> 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
>> whe
On 11/01/2013 07:08 AM, Mel Gorman wrote:
> On Thu, Oct 31, 2013 at 04:31:44PM -0400, Rik van Riel wrote:
>> There is a race between stop_two_cpus, and the global stop_cpus.
>>
>
> What was the trigger for this? I want to see what was missing from my own
> testing. I'm going to go out on a limb
offline.sh
>> from mmtests running in parallel.
>
> AFAIK the trigger was a test that continuously loads and
> unloads kernel modules, while doing other stuff.
>
With this patch in place the module load/unload test ran for ~16 hours without
failure. Without the patch the test u
On 11/01/2013 10:47 AM, Mel Gorman wrote:
> On Fri, Nov 01, 2013 at 10:41:46AM -0400, Rik van Riel wrote:
>> Subject: fix race between stop_two_cpus and stop_cpus
>>
>> There is a race between stop_two_cpus, and the global stop_cpus.
>>
>> It is possible for two CPUs to get their stopper function
ween stop_cpus (a rare operation),
>> and stop_two_cpus.
>>
>> Signed-off-by: Rik van Riel
>> ---
>> v2: use lglock, as suggested by Peter & Mel, thanks to both of you
>> for insisting on nicer code :)
>>
>
> This is a tad more comprehe
ilable on
the system. If there aren't enough vectors for the CPU to go down, an
error is returned and propogated back to userspace.
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
and
discovered that that we are getting bogus events. This patchset resolves
this by adding definitions for VECTOR_UNDEFINED(-1) and
VECTOR_RETRIGGERED(-2) and modifying the code to use them.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x
ministrators to properly report bugs to
hardware vendors.
Signed-off-by: Prarit Bhargava
Cc: Arnd Bergmann
Cc: Andrew Morton
Cc: Greg Kroah-Hartman
Prarit Bhargava (3):
Introduce FW_INFO* functions and messages
Introduce FW_WARN* functions and messages
Introduce FW_BUG* functions and mess
ools and system administrators to properly report bugs to
hardware vendors.
I found an improperly classified FW_INFO in arch/x86/kernel/cpu/amd.c
which that should be a FW_BUG.
Signed-off-by: Prarit Bhargava
Cc: Arnd Bergmann
Cc: Andrew Morton
Cc: Greg Kroah-Hartman
---
arch/x86/pci/mmconfig-
ools and system administrators to properly report bugs to
hardware vendors.
Signed-off-by: Prarit Bhargava
Cc: Arnd Bergmann
Cc: Andrew Morton
Cc: Greg Kroah-Hartman
---
arch/x86/kernel/apic/apic.c |8 ++---
arch/x86/kernel/cpu/amd.c|9 +++--
arch/x86/kernel/c
ools and system administrators to properly report bugs to
hardware vendors.
Also made some usage corrections.
Signed-off-by: Prarit Bhargava
Cc: Arnd Bergmann
Cc: Andrew Morton
Cc: Greg Kroah-Hartman
---
arch/x86/kernel/cpu/amd.c |2 +-
arch/x86/kernel/cpu/mtrr/generic.c |2 +-
dr
On 12/03/2013 04:21 PM, Andrew Morton wrote:
> On Mon, 2 Dec 2013 10:19:37 -0500 Prarit Bhargava wrote:
> A slight simplification:
>
>> +static inline char *dump_hadware_arch_desc(void)
>> +{
>> +return NULL;
>> +}
>
> return "unavailab
On 12/03/2013 06:42 PM, Yu, Fenghua wrote:
>
>
>> -Original Message-----
>> From: Prarit Bhargava [mailto:pra...@redhat.com]
>>
>> Second try at this ...
>>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64791
>>
>> Whe
Sorry everyone, I was out on PTO for the past few weeks.
On 12/06/2013 07:30 AM, Matt Fleming wrote:
> On Thu, 05 Dec, at 07:55:03AM, Joe Perches wrote:
>> On Thu, 2013-12-05 at 11:30 +, Matt Fleming wrote:
>>> On Wed, 04 Dec, at 07:22:57PM, Arnd Bergmann wrote:
The other part I noticed
yes
Cc: Dominik Brodowski
Cc: Thomas Renninger
Signed-off-by: Prarit Bhargava
---
tools/power/cpupower/man/cpupower-frequency-info.1 |3 +
tools/power/cpupower/utils/cpufreq-info.c | 110 +---
2 files changed, 73 insertions(+), 40 deletions(-)
diff --git a/too
kernel I see oopses usually within 500 iterations. In the
patched kernel which fixes the broken locking, I can go several hours
without any issues.
This patch effectively reverts commit 955ef483.
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: Lenny Szubowicz
Cc: linux...@vger.kernel.org
Si
mem84: type=3, attr=0xf,
range=[0x645b5000-0x645fb000) (280kiB)
Signed-off-by: Prarit Bhargava
Cc: lszub...@redhat.com
Cc: Matt Fleming
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: linux-...@vger.kernel.org
---
arch/x86/platform/e
On 07/29/2014 04:29 PM, David Rientjes wrote:
> On Tue, 29 Jul 2014, Prarit Bhargava wrote:
>
>> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
>> index 87fc96b..3875090 100644
>> --- a/arch/x86/platform/efi/efi.c
>> +++ b/arch/x86/pl
On 07/29/2014 06:02 PM, Joe Perches wrote:
> On Tue, 2014-07-29 at 13:29 -0700, David Rientjes wrote:
>> On Tue, 29 Jul 2014, Prarit Bhargava wrote:
>>> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> []
>>> @@ -384,10 +384,10 @@ static voi
On 07/29/2014 06:29 PM, Borislav Petkov wrote:
> On Tue, Jul 29, 2014 at 01:09:21PM -0400, Prarit Bhargava wrote:
>> The current debug print in EFI does
>>
>> [0.00] efi: mem84: type=3, attr=0xf,
>> range=[0x645b5000-0x645fb000) (0MB)
>>
On 07/29/2014 06:36 PM, Borislav Petkov wrote:
> On Tue, Jul 29, 2014 at 06:32:56PM -0400, Prarit Bhargava wrote:
>> and it was best to keep the code simple with a KiB.
>
> You're missing the point - the output doesn't get simple with KiB. Read
> the example I just
On 07/29/2014 07:01 PM, Borislav Petkov wrote:
> On Tue, Jul 29, 2014 at 03:42:55PM -0700, David Rientjes wrote:
>> If Prarit is going to implement this suggested reverse memparse() ...
>
> The only meaningful argument about the formatting here IMO is what
> people staring at this output are goi
On 07/29/2014 08:03 PM, Rafael J. Wysocki wrote:
> On Tuesday, July 29, 2014 07:46:02 AM Prarit Bhargava wrote:
>> [v2]: Fixed wording of commit, and added additional testing information.
>>
>> A while ago we added a test to mimic some of our users' userspace governor
On 07/30/2014 11:05 AM, Colin Ian King wrote:
> On 30/07/14 15:48, Matt Fleming wrote:
>> On Wed, 30 Jul, at 12:29:32AM, Borislav Petkov wrote:
>>> On Tue, Jul 29, 2014 at 01:09:21PM -0400, Prarit Bhargava wrote:
>>>> The current debug print in EFI does
>>>
On 07/30/2014 10:16 PM, Rafael J. Wysocki wrote:
> On Wednesday, July 30, 2014 06:36:00 PM Saravana Kannan wrote:
>> On 07/30/2014 02:40 PM, Rafael J. Wysocki wrote:
>>> On Wednesday, July 30, 2014 10:18:25 AM Prarit Bhargava wrote:
>>>>
>>>> On 07
On 07/31/2014 06:16 AM, Prarit Bhargava wrote:
>
>
> On 07/30/2014 10:16 PM, Rafael J. Wysocki wrote:
>> On Wednesday, July 30, 2014 06:36:00 PM Saravana Kannan wrote:
>>> On 07/30/2014 02:40 PM, Rafael J. Wysocki wrote:
>>>> On Wednesday, July 30, 20
On 07/30/2014 10:16 PM, Rafael J. Wysocki wrote:
> On Wednesday, July 30, 2014 06:36:00 PM Saravana Kannan wrote:
>> On 07/30/2014 02:40 PM, Rafael J. Wysocki wrote:
>>> On Wednesday, July 30, 2014 10:18:25 AM Prarit Bhargava wrote:
>>>>
>>>> On 07
On 07/31/2014 12:36 PM, Rafael J. Wysocki wrote:
> On Thursday, July 31, 2014 06:23:18 AM Prarit Bhargava wrote:
>>
>> On 07/30/2014 10:16 PM, Rafael J. Wysocki wrote:
>>> On Wednesday, July 30, 2014 06:36:00 PM Saravana Kannan wrote:
>>>> On 07/30/20
On 07/31/2014 02:38 PM, Rafael J. Wysocki wrote:
> On Thursday, July 31, 2014 01:57:29 PM Prarit Bhargava wrote:
>>
>> On 07/31/2014 12:36 PM, Rafael J. Wysocki wrote:
>>> On Thursday, July 31, 2014 06:23:18 AM Prarit Bhargava wrote:
>>>>
>>>>
On 07/31/2014 04:24 PM, Saravana Kannan wrote:
> On 07/31/2014 11:26 AM, Prarit Bhargava wrote:
>>
>>
>> On 07/31/2014 02:38 PM, Rafael J. Wysocki wrote:
>>> On Thursday, July 31, 2014 01:57:29 PM Prarit Bhargava wrote:
>>>>
>>>> On 07/31/201
On 07/31/2014 04:38 PM, Saravana Kannan wrote:
> On 07/31/2014 01:30 PM, Prarit Bhargava wrote:
>>
>>
>> On 07/31/2014 04:24 PM, Saravana Kannan wrote:
>>>
>>> Prarit,
>>>
>>> I'm not an expert on sysfs locking, but I would t
301 - 400 of 1067 matches
Mail list logo
