[PATCH]: Fix bogus softlockup warning with sysrq-t

2007-03-15 Thread Prarit Bhargava
PROTECTED] Signed-off-by: Prarit Bhargava [EMAIL PROTECTED] diff --git a/arch/ia64/kernel/uncached.c b/arch/ia64/kernel/uncached.c index c58e933..db514bb 100644 --- a/arch/ia64/kernel/uncached.c +++ b/arch/ia64/kernel/uncached.c @@ -254,7 +254,7 @@ static int __init uncached_build_memmap(unsigned long

[PATCH]: Add gate.lds to Documentation/dontdiff

2007-03-15 Thread Prarit Bhargava
Add gate.lds to dontdiff for ia64. Signed-off-by: Prarit Bhargava [EMAIL PROTECTED] diff --git a/Documentation/dontdiff b/Documentation/dontdiff index 63c2d0c..0bf10c7 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff @@ -86,6 +86,7 @@ filelist fixdep fore200e_mkfirm

[PATCH]: Fix __devinit __devexit declarations in de2104x driver

2007-02-14 Thread Prarit Bhargava
: reference to .exit.text:de_remove_one from .data.rel.local after 'de_driver' (at offset 0x28) Signed-off-by: Prarit Bhargava [EMAIL PROTECTED] --- linux-2.6.18.ia64.orig/drivers/net/tulip/de2104x.c 2006-09-19 23:42:06.0 -0400 +++ linux-2.6.18.ia64/drivers/net/tulip/de2104x.c 2007-02-14

[PATCH]: Change sysenter_setup to __cpuinit improve __INIT, __INITDATA

2007-02-19 Thread Prarit Bhargava
0xc041a27a) and 'enable_sep_cpu' Signed-off-by: Prarit Bhargava [EMAIL PROTECTED] diff --git a/arch/i386/kernel/sysenter.c b/arch/i386/kernel/sysenter.c index 13ca54a..168f814 100644 --- a/arch/i386/kernel/sysenter.c +++ b/arch/i386/kernel/sysenter.c @@ -72,7 +72,7 @@ extern const char

[PATCH]: Add __init to probe_bigsmp

2007-02-19 Thread Prarit Bhargava
Add __init to probe_bigsmp. All callers are __init and data being examined is __initdata. Resolves MODPOST warning similar to: WARNING: vmlinux - Section mismatch: reference to .init.data: from .text between 'probe_bigsmp' (at offset 0xc0401e56) and 'init_apic_ldr' Signed-off-by: Prarit

[PATCH]: Resubmitting: Add __init to probe_bigsmp

2007-03-21 Thread Prarit Bhargava
Originally submitted Feb 13, 2007. Add __init to probe_bigsmp. All callers are __init and data being examined is __initdata. Resolves BZ 228543. Successfully tested by me. --- linux-2.6.18.i386.orig/arch/i386/mach-generic/bigsmp.c 2007-02-05 13:29:12.0 -0500 +++

[PATCH]: Resubmitting: __init to __cpuinit in mtrr code

2007-03-21 Thread Prarit Bhargava
Originally submitted 2007-02-28. Adding Bhavana from AMD... __init to __cpuinit in mtrr code. Resolves warnings similar to: WARNING: vmlinux - Section mismatch: reference to .init.text:mtrr_bp_init from .text between 'identify_cpu' (at offset 0xc040b38e) and 'detect_ht' Signed-off-by: Prarit

[PATCH]: Fix warning message in PCIE port driver

2007-03-23 Thread Prarit Bhargava
PCIE error output should conform to vendor_id:device_id. Signed-off-by: Prarit Bhargava [EMAIL PROTECTED] diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c index 0be5a0b..df38364 100644 --- a/drivers/pci/pcie/portdrv_pci.c +++ b/drivers/pci/pcie/portdrv_pci.c @@ -93,7

[PATCH]: Fix overloaded use of acpi= on bootline

2007-03-26 Thread Prarit Bhargava
. This patch changes the genapic situation to use genapic=. Signed-off-by: Prarit Bhargava [EMAIL PROTECTED] diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index ef2ffde..8cbd90c 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel

Re: [PATCH]: Fix bogus softlockup warning with sysrq-t

2007-03-27 Thread Prarit Bhargava
I have another pair of softlockup patches in which I try to address: * ignoring time stolen by hypervisors * threads going to sleep tickless for long periods of time I'm looking at the code now. Your solution is definately better :) I could easy add a global disable function,

Re: [patch 1/2] Ignore stolen time in the softlockup watchdog

2007-03-27 Thread Prarit Bhargava
Jeremy Fitzhardinge wrote: --- kernel/softlockup.c | 28 +++- 1 file changed, 19 insertions(+), 9 deletions(-) === --- a/kernel/softlockup.c +++ b/kernel/softlockup.c @@ -17,8 +17,8 @@ static

Re: [patch 2/2] percpu enable flag for softlockup watchdog

2007-03-27 Thread Prarit Bhargava
Jeremy Fitzhardinge wrote: +static DEFINE_PER_CPU(int, enabled); Minor nit: let's call this softlockup_enabled. Makes it easier for the reader ;) P. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo

[PATCH]: Resubmit Fix overloaded use of acpi= on bootline

2007-04-09 Thread Prarit Bhargava
. This patch changes the genapic situation to use genapic=. Signed-off-by: Prarit Bhargava [EMAIL PROTECTED] diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index ef2ffde..8cbd90c 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel

Re: [PATCH]: Change sysenter_setup to __cpuinit improve __INIT, __INITDATA

2007-02-20 Thread Prarit Bhargava
to .init.data:vsyscall_sysenter_end from .text between 'sysenter_setup' (at offset 0xc041a275) and 'enable_sep_cpu' WARNING: vmlinux - Section mismatch: reference to .init.data:vsyscall_sysenter_start from .text between 'sysenter_setup' (at offset 0xc041a27a) and 'enable_sep_cpu' Signed-off-by: Prarit Bhargava [EMAIL PROTECTED

[PATCH]: change rivafb_remove to __devexit

2007-02-20 Thread Prarit Bhargava
Resubmitting with wider audience (akpm lkml). Change rivafb_remove to __deviexit to fix MODPOST warnings: WARNING: drivers/video/riva/rivafb.o - Section mismatch: reference to .exit.text:rivafb_remove from .data.rel.local after 'rivafb_driver' (at offset 0x28) Signed-off-by: Prarit Bhargava

[PATCH]: remove __initdata from initkmem_list3

2007-02-20 Thread Prarit Bhargava
Remove __initdata from initkmem_list3 Resolves MODPOST warning similar to: WARNING: vmlinux - Section mismatch: reference to .init.data:initkmem_list3 from .text between 'set_up_list3s' (at offset 0xc046a3ed) and 's_start' Signed-off-by: Prarit Bhargava [EMAIL PROTECTED] diff --git a/mm

[PATCH]: __init to __cpuinit fixes in mtrr code

2007-02-20 Thread Prarit Bhargava
__init to __cpuinit in mtrr code. Resolves warnings similar to: WARNING: vmlinux - Section mismatch: reference to .init.text:mtrr_bp_init from .text between 'identify_cpu' (at offset 0xc040b38e) and 'detect_ht' Signed-off-by: Prarit Bhargava [EMAIL PROTECTED] diff --git a/arch/i386/kernel/cpu

[PATCH]: Remove __exit from mon_bin_exit mon_text_exit.

2007-02-21 Thread Prarit Bhargava
`mon_text_exit' referenced in section `.init.text' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o make: *** [.tmp_vmlinux1] Error 1 Signed-off-by: Prarit Bhargava [EMAIL PROTECTED] diff --git a/drivers/usb/mon/mon_bin.c b/drivers/usb/mon/mon_bin.c index c01dfe6

[PATCH]: Fix __devinit __devexit declarations in de2104x driver

2007-02-26 Thread Prarit Bhargava
/tulip/de2104x.o - Section mismatch: reference to .exit.text:de_remove_one from .data.rel.local after 'de_driver' (at offset 0x28) Signed-off-by: Prarit Bhargava [EMAIL PROTECTED] --- linux-2.6.18.ia64.orig/drivers/net/tulip/de2104x.c 2006-09-19 23:42:06.0 -0400 +++ linux-2.6.18.ia64

[PATCH]: Use stop_machine_run in the Intel RNG driver

2007-02-27 Thread Prarit Bhargava
with interrupts disabled and does not see the IPI. CPU C is stuck waiting for CPU B to respond to the IPI. Deadlock. The solution is to use stop_machine_run instead of call_smp_function (call_smp_function should not be called in situations where the CPUs may be suspended). Signed-off-by: Prarit Bhargava [EMAIL

Re: [PATCH]: Fix __devinit __devexit declarations in de2104x driver

2007-02-27 Thread Prarit Bhargava
Jeff Garzik wrote: Prarit Bhargava wrote: Resending (originally sent 2007-02-14). __devinit __devexit cleanups for de2104x driver. Fixes MODPOST warnings similar to: WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to .init.text:de_init_one from .data.rel.local after

Re: [PATCH]: Use stop_machine_run in the Intel RNG driver

2007-02-27 Thread Prarit Bhargava
Prarit Bhargava wrote: Replace call_smp_function with stop_machine_run in the Intel RNG driver. CPU A has done read_lock(lock) CPU B has done write_lock_irq(lock) and is waiting for A to release the lock. A third CPU calls call_smp_function and issues the IPI. CPU A takes CPU C's IPI. CPU

[PATCH]: __init to __cpuinit in mtrr code

2007-02-28 Thread Prarit Bhargava
(Resending to wider audience) __init to __cpuinit in mtrr code. Resolves warnings similar to: WARNING: vmlinux - Section mismatch: reference to .init.text:mtrr_bp_init from .text between 'identify_cpu' (at offset 0xc040b38e) and 'detect_ht' Signed-off-by: Prarit Bhargava [EMAIL PROTECTED

[PATCH]: Fix __init declarations in Compaq SMART2 Controller driver

2007-02-28 Thread Prarit Bhargava
-by: Prarit Bhargava [EMAIL PROTECTED] --- linux-2.6.18.ia64.orig/drivers/block/cpqarray.c 2007-02-14 11:36:20.0 -0500 +++ linux-2.6.18.ia64/drivers/block/cpqarray.c 2007-02-14 13:08:57.0 -0500 @@ -212,7 +212,7 @@ static struct proc_dir_entry *proc_array * Get us a file

Re: [PATCH]: Use stop_machine_run in the Intel RNG driver

2007-03-01 Thread Prarit Bhargava
I think what you're describing here is just the standard old smp_call_function() deadlock, rather than anything which is specific to intel-rng, yes? It is well known that you can't call smp_call_function() with local interrupts disabled. In fact i386 will spit a warning if you try it.

Re: [PATCH]: Fix bogus softlockup warning with sysrq-t

2007-03-27 Thread Prarit Bhargava
Jeremy Fitzhardinge wrote: Prarit Bhargava wrote: I think that's a good idea -- I'll propose an add on patch to fix the sysrq-t case ... I'm working on this patch at the moment. I'm just wondering what happens if you do a global re-enable while a CPU is locally disabled. I think

Re: [PATCH]: Fix bogus softlockup warning with sysrq-t

2007-03-27 Thread Prarit Bhargava
Jeremy Fitzhardinge wrote: diff -r 4c81d8cafb67 drivers/char/sysrq.c --- a/drivers/char/sysrq.c Tue Mar 27 01:16:07 2007 -0700 +++ b/drivers/char/sysrq.c Tue Mar 27 01:18:05 2007 -0700 @@ -408,6 +408,8 @@ void __handle_sysrq(int key, struct tty_ int i; unsigned long

Re: [patch 1/2] Ignore stolen time in the softlockup watchdog

2007-03-27 Thread Prarit Bhargava
Jeremy Fitzhardinge wrote: Prarit Bhargava wrote: I'd like to see this patch implement/fix touch_cpu_softlockup_watchdog and touch_softlockup_watchdog to mimic touch_nmi_watchdog's behaviour. Why? Is that more correct? It seems to me that you're interested in whether a specific

Re: [patch 1/2] Ignore stolen time in the softlockup watchdog

2007-03-27 Thread Prarit Bhargava
Jeremy Fitzhardinge wrote: Prarit Bhargava wrote: Jeremy Fitzhardinge wrote: Prarit Bhargava wrote: I'd like to see this patch implement/fix touch_cpu_softlockup_watchdog and touch_softlockup_watchdog to mimic touch_nmi_watchdog's behaviour

Re: [patch 3/4] Locally disable the softlockup watchdog rather than touching it

2007-03-28 Thread Prarit Bhargava
Jeremy Fitzhardinge wrote: I haven't really worked out how this should interact with the nmi watchdog; touch_nmi_watchdog() still ends up calling touch_softlockup_watchdog(), so there's still some redundancy here. touch_nmi_watchdog is attempting to tickle _all_ CPUs softlockup

[PATCH]: Resubmit Fix bogus softlockup warning with sysrq-t

2007-03-28 Thread Prarit Bhargava
-off-by: Prarit Bhargava [EMAIL PROTECTED] diff --git a/arch/i386/kernel/nmi.c b/arch/i386/kernel/nmi.c index 1470242..864399e 100644 --- a/arch/i386/kernel/nmi.c +++ b/arch/i386/kernel/nmi.c @@ -928,7 +928,7 @@ void touch_nmi_watchdog (void) /* * Tickle the softlockup detector too

Re: [patch 3/4] Locally disable the softlockup watchdog rather than touching it

2007-03-28 Thread Prarit Bhargava
Jeremy Fitzhardinge wrote: Prarit Bhargava wrote: I don't like the idea of having touch_softlockup_watchdog exported with your new code -- we still have two methods of effecting the softlockup watchdog and that's confusing and its going to cause serious problems down the road. It's

Re: [patch 3/4] Locally disable the softlockup watchdog rather than touching it

2007-03-28 Thread Prarit Bhargava
Jeremy Fitzhardinge wrote: Prarit Bhargava wrote: You don't have to do them all -- you could do one with (as in my previous patch -- which I'm not married to BTW ;) ) touch_cpu_softlockup_watchdog() and all with touch_softlockup_watchdog() Well, I think changing the meaning

Re: [patch 3/4] Locally disable the softlockup watchdog rather than touching it

2007-03-28 Thread Prarit Bhargava
touch_nmi_watchdog is attempting to tickle _all_ CPUs softlockup watchdogs. It is supposed to only touch the current CPU, just like it only touches the NMI watchdog on the current CPU. Andi, (sorry for the cut-and-paste). touch_nmi_watchdogs sets EACH CPUs alert_counter to 0.

Re: [patch 3/4] Locally disable the softlockup watchdog rather than touching it

2007-03-28 Thread Prarit Bhargava
Andi Kleen wrote: On Wednesday 28 March 2007 16:00, Prarit Bhargava wrote: touch_nmi_watchdog is attempting to tickle _all_ CPUs softlockup watchdogs. It is supposed to only touch the current CPU, just like it only touches the NMI watchdog on the current CPU

PATCH: Remove endflag in NMI smp_call_function call

2007-12-03 Thread Prarit Bhargava
(Wim, I'm not sure if you're the right person to get this or not. Nothing else came close in the MAINTAINERS file ) 'endflag' is globally defined -- Passing endflag into smp_call_function is no longer necessary. Signed-off-by: Prarit Bhargava [EMAIL PROTECTED] diff --git a/arch/x86/kernel

[PATCH] x86, add hypervisor name to dump_stack() [v3]

2012-10-30 Thread Prarit Bhargava
x86_hyper. We can use this to output additional debug information during a panic/oops/stack trace. Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: Avi Kivity a...@redhat.com Cc: Gleb Natapov g...@redhat.com Cc: Alex Williamson alex.william...@redhat.com Cc: Marcelo Tostatti mtosa...@redhat.com Cc

Re: [PATCH] x86, add hypervisor name to dump_stack() [v3]

2012-10-30 Thread Prarit Bhargava
On 10/30/2012 03:14 PM, Prarit Bhargava wrote: Debugging crash, panics, stack trace WARN_ONs, etc., from both virtual and bare-metal boots can get difficult very quickly. While there are ways to decipher the output and determine if the output is from a virtual guest, the in-kernel

[PATCH] x86, add hypervisor name to dump_stack() [v4]

2012-10-30 Thread Prarit Bhargava
x86_hyper. We can use this to output additional debug information during a panic/oops/stack trace. Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: Avi Kivity a...@redhat.com Cc: Gleb Natapov g...@redhat.com Cc: Alex Williamson alex.william...@redhat.com Cc: Marcelo Tostatti mtosa...@redhat.com Cc

[PATCH] ntp, add debugfs entries for time_status and time_state

2012-10-04 Thread Prarit Bhargava
Add debugfs entries for ntp time_status and time_state. These are useful for debugging ntp issues. Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: John Stultz johns...@us.ibm.com Cc: Thomas Gleixner t...@linutronix.de --- kernel/time/ntp.c | 40 1

Re: [PATCH] x86, add hypervisor name to dump_stack()

2012-10-24 Thread Prarit Bhargava
On 10/24/2012 05:49 AM, Ingo Molnar wrote: * Prarit Bhargava pra...@redhat.com wrote: Debugging crash, panics, stack trace WARN_ONs, etc., from both virtual and bare-metal boots can get difficult very quickly. While there are ways to decipher the output and determine if the output

Re: [PATCH] ntp, add debugfs entries for time_status and time_state

2012-10-09 Thread Prarit Bhargava
On 10/08/2012 09:47 PM, John Stultz wrote: On 10/04/2012 06:48 AM, Prarit Bhargava wrote: Add debugfs entries for ntp time_status and time_state. These are useful for debugging ntp issues. Aren't these easily fetched from adjtimex()? How does having them in debugfs help

[PATCH] x86, add hypervisor name to dump_stack()

2012-10-10 Thread Prarit Bhargava
x86_hyper. We can use this to output a single extra line on virtual machines that indicates the hypervisor type. Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: Avi Kivity a...@redhat.com Cc: Gleb Natapov g...@redhat.com Cc: Alex Williamson alex.william...@redhat.com Cc: Marcelo Tostatti mtosa

RCU NOHZ, tsc, and clock_gettime

2012-10-11 Thread Prarit Bhargava
I've been tracking an odd bug that may involve the RCU NOHZ code and just want to know if you have any ideas on debugging and/or what might be wrong. Note the bug happens on *BOTH* upstream and the current RHEL6 tree. The data in this email is from running on RHEL6 because that's what I happen to

Re: RCU NOHZ, tsc, and clock_gettime

2012-10-12 Thread Prarit Bhargava
On 10/11/2012 04:21 PM, Paul E. McKenney wrote: On Thu, Oct 11, 2012 at 12:51:44PM -0700, John Stultz wrote: On 10/11/2012 11:52 AM, Prarit Bhargava wrote: I've been tracking an odd bug that may involve the RCU NOHZ code and just want to know if you have any ideas on debugging and/or what

Re: RCU NOHZ, tsc, and clock_gettime

2012-10-12 Thread Prarit Bhargava
The effect of removing the two functions you noted (on 3.6 and earlier) is to prevent RCU from checking for dyntick-idle CPUs, likely incurring a cache miss for each CPU with interrupts disabled. If you have a lot of CPUs (or even if NR_CPUS is large and you have a smaller number of CPUs),

[PATCH] x86, add hypervisor name to dump_stack() [v2]

2012-10-26 Thread Prarit Bhargava
x86_hyper. We can use this to output additional debug information during a panic/oops/stack trace. Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: Avi Kivity a...@redhat.com Cc: Gleb Natapov g...@redhat.com Cc: Alex Williamson alex.william...@redhat.com Cc: Marcelo Tostatti mtosa...@redhat.com Cc

Re: RCU NOHZ, tsc, and clock_gettime

2012-11-13 Thread Prarit Bhargava
On 11/12/2012 06:27 PM, John Stultz wrote: Hey Prarit, Just back from being on leave, and wanted to check in on this. Did you ever get to run with an increase sample size to see how that affected things? Its exactly your point that the non-NOHZ case could align the execution of a

[PATCH] i7core_edac, Fix panic when accessing sysfs files

2012-10-16 Thread Prarit Bhargava
field which is populated in i7core_create_sysfs_devices(). Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: Mauro Chehab mche...@redhat.com --- drivers/edac/i7core_edac.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/edac/i7core_edac.c b/drivers/edac

[PATCH RESEND] i7core_edac, Fix panic when accessing sysfs files

2012-10-16 Thread Prarit Bhargava
field which is populated in i7core_create_sysfs_devices(). Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: Mauro Chehab mche...@redhat.com Cc: linux-e...@vger.kernel.org --- drivers/edac/i7core_edac.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/edac

[PATCH]: Stop bogus softlockup warnings in debug_show_all_locks (2nd try)

2007-09-05 Thread Prarit Bhargava
Trying this again with a wider audience. 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

[PATCH]: Stop bogus softlockup warnings in debug_show_all_locks

2007-08-22 Thread Prarit Bhargava
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 @@ retry

[PATCH]: i386 Stop bogus nmi softlockup warnings in show_mem

2007-08-23 Thread Prarit Bhargava
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/i386/mm

Re: [PATCH 1/2] Fix the memory leak Intel RNG driver for 2.6.21-rc7-mm1

2007-04-30 Thread Prarit Bhargava
. Could you please re-review and ideally re-test this, let me know the result? I verified that the error code paths are correct. So both of those changes are okay. P. Thanks. From: Prarit Bhargava [EMAIL PROTECTED] Replace call_smp_function with stop_machine_run in the Intel RNG driver

Re: [PATCH][RFC]: Clean up resource allocation in i8042 driver

2005-02-14 Thread Prarit Bhargava
I didn't see a final ACK on this patch -- just checking for one :) P. Prarit Bhargava wrote: I've taken into account Dmitry's comments (thanks Dmitry!) and generated a new patch. Thanks, P. Jesse Barnes wrote: On Friday, January 21, 2005 8:35 am, Vojtech Pavlik wrote: No. But vacant ports

Re: [5/6 PATCH] Kprobes : Prevent possible race conditions ia64 changes

2005-07-08 Thread Prarit Bhargava
Keshavamurthy Anil S wrote: On Fri, Jul 08, 2005 at 04:40:45PM +0530, Prasanna S Panchamukhi wrote: Hi Anil, I have updated the patch as per your comments to move routines from jprobes.S to .kprobes.text section. Please let me know if you any issues. Looks fine and tested it too on IA64

[PATCH RFC]: DEBUG for PCI IO MEM allocation

2005-03-14 Thread Prarit Bhargava
Colleagues, Over the past few years I've been heavily involved in two projects that deal with PCI HotPlug. While doing this work, one area of code always seems to require printk's to debug through -- the allocation freeing of IO MEM resources. I've discovered many bugs surrounding Hotplug

Re: [PATCH RFC]: DEBUG for PCI IO MEM allocation

2005-03-21 Thread Prarit Bhargava
Thanks Andrew. Shouldn't this also be printing the -name of the new resource? A lot of the statements which you're adding will look screwy in an 80-col xterm. Please wrap 'em. -- new patch with Andrew's comments fixed. P. Index: io_debug/kernel/resource.c

[PATCH][RFC]: Clean up resource allocation in i8042 driver

2005-01-21 Thread Prarit Bhargava
Hi, The following patch cleans up resource allocations in the i8042 driver when initialization fails. Please consider for tree application. Patch is generated against current bk pull. Thanks, P. Signed-off-by: Prarit Bhargava [EMAIL PROTECTED] = i8042.c 1.71 vs edited = --- 1.71

Re: [PATCH][RFC]: Clean up resource allocation in i8042 driver

2005-01-21 Thread Prarit Bhargava
I've taken into account Dmitry's comments (thanks Dmitry!) and generated a new patch. Thanks, P. Jesse Barnes wrote: On Friday, January 21, 2005 8:35 am, Vojtech Pavlik wrote: No. But vacant ports usually return 0xff. The problem here is that 0xff is a valid value for the status register,

Re: [PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug

2012-07-16 Thread Prarit Bhargava
I can do some _OST CPU and Memory hotplug. These systems are newer Intel systems in which ACPI events can be triggered via switches to add CPUs. I tested this patchset with CPU _add_ and haven't seen any issues. So... Tested-by: Prarit Bhargava pra...@redhat.com P. -- To unsubscribe from

Re: [PATCH 2/2] time: Cleanup offs_real/wall_to_mono and offs_boot/total_sleep_time updates

2012-07-19 Thread Prarit Bhargava
. This also provides WARN_ONs to detect if future changes break the invariants. Cc: Ingo Molnar mi...@kernel.org Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Richard Cochran richardcoch...@gmail.com Cc: Prarit Bhargava pra...@redhat.com Cc: Thomas Gleixner t...@linutronix.de Signed-off

[PATCH] NOHZ, check to see if tick device is initialized in IRQ handling path

2013-04-15 Thread Prarit Bhargava
this occur on one system. I've tested with and without the patch and as far as I can tell this patch resolves the problem on linux.git top of tree. Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: Thomas Gleixner t...@linutronix.de --- kernel/time/tick-sched.c | 12 1 file

[PATCH] hrtimer, add expiry time overflow check in hrtimer_interrupt

2013-04-08 Thread Prarit Bhargava
-by: Prarit Bhargava pra...@redhat.com Cc: Thomas Gleixner t...@linutronix.de Cc: John Stultz john.stu...@linaro.org --- kernel/hrtimer.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index cc47812..17eafd7 100644 --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c

Re: [PATCH] hrtimer, add expiry time overflow check in hrtimer_interrupt

2013-04-08 Thread Prarit Bhargava
On 04/08/2013 04:19 PM, John Stultz wrote: On 04/08/2013 05:47 AM, Prarit Bhargava wrote: A simple check for an overflow can resolve this problem. Using KTIME_MAX instead of the overflow value will result in the hrtimer function being run, and the reprogramming of the timer after

[RFE PATCH] hrtimer, add expiry time overflow check in hrtimer_interrupt

2013-03-28 Thread Prarit Bhargava
will result in the hrtimer function being run, and the reprogramming of the timer after that. Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: Thomas Gleixner t...@linutronix.de Cc: John Stultz john.stu...@linaro.org --- kernel/hrtimer.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel

[PATCH] hpet, allow user controlled mmap for user processes

2013-03-15 Thread Prarit Bhargava
a kernel parameter, hpet_mmap_enable, that is required in order to actually have the HPET MMAP exposed. Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: Clemens Ladisch clem...@ladisch.de --- Documentation/kernel-parameters.txt |3 +++ drivers/char/hpet.c | 20

Re: [PATCH] hpet, allow user controlled mmap for user processes

2013-03-18 Thread Prarit Bhargava
the HPET MMAP exposed. [v2]: Clemens suggested modifying the Kconfig help text and making the default setting configurable. Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: Clemens Ladisch clem...@ladisch.de --- Documentation/kernel-parameters.txt |3 +++ drivers/char/Kconfig

clockevents: WARNING when settimeofday() is called

2013-03-19 Thread Prarit Bhargava
[Note: I can also reproduce this on latest top-of-tree but I didn't keep my debug output :(. I'll checkout a new tree and do the same debug if necessary.] settimeofday causes a backtrace WARNING in clockevents code on large CPU count systems . Debugging points to lapic timer (which is used as a

Re: [PATCH] hpet, allow user controlled mmap for user processes

2013-03-19 Thread Prarit Bhargava
On 03/19/2013 03:43 AM, Clemens Ladisch wrote: Prarit Bhargava wrote: The CONFIG_HPET_MMAP Kconfig option exposes the memory map of the HPET registers to userspace. The Kconfig help points out that in some cases this can be a security risk as some systems may erroneously configure the map

Re: [PATCH] hpet, allow user controlled mmap for user processes

2013-03-19 Thread Prarit Bhargava
the HPET MMAP exposed. [v2]: Clemens suggested modifying the Kconfig help text and making the default setting configurable. [v3]: Fixed up Documentation and Kconfig entries, default now Y Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: Clemens Ladisch clem...@ladisch.de --- Documentation/kernel

[PATCH] hpet, allow user controlled mmap for user processes

2013-03-22 Thread Prarit Bhargava
the HPET MMAP exposed. [v2]: Clemens suggested modifying the Kconfig help text and making the default setting configurable. [v3]: Fixed up Documentation and Kconfig entries, default now Y [v4]: After testing, found that I need to modify CONFIG_HPET_MMAP_DEFAULT usage Signed-off-by: Prarit Bhargava pra

Re: [PATCH 0/8] Move ntp state to be protected by timekeeping lock

2013-03-28 Thread Prarit Bhargava
-shadowtime or http://git.linaro.org/gitweb?p=people/jstultz/linux.git;a=shortlog;h=refs/heads/dev/tglx-shadowtime Beyond the above comment, a quick test shows that ntp does work AFAICT (at least on F18 + your git tree. I'll try and do a heavier test next week. So for now ... Acked-by: Prarit

Re: [PATCH] irq: add quirk for broken interrupt remapping on 55XX chipsets

2013-03-09 Thread Prarit Bhargava
On 03/04/2013 08:24 AM, Don Dutile wrote: On 03/02/2013 10:59 AM, Andreas Mohr wrote: Hi, if ((revision == 0x13) irq_remapping_enabled) { +pr_warn(WARNING WARNING WARNING WARNING WARNING WARNING\n +This system BIOS has enabled interrupt remapping\n +on a

Re: [PATCH v2] irq: add quirk for broken interrupt remapping on 55XX chipsets

2013-03-11 Thread Prarit Bhargava
level is such that this feature was not properly turned off. As such, it would be good to give them a reminder that their systems are vulnurable to this problem. Signed-off-by: Neil Horman nhor...@tuxdriver.com CC: Prarit Bhargava pra...@redhat.com CC: Don Zickus dzic...@redhat.com CC

Re: [PATCH] irq: add quirk for broken interrupt remapping on 55XX chipsets

2013-03-02 Thread Prarit Bhargava
...@tuxdriver.com CC: Prarit Bhargava pra...@redhat.com CC: Don Zickus dzic...@redhat.com CC: Don Dutile ddut...@redhat.com CC: Bjorn Helgaas bhelg...@google.com CC: Asit Mallick asit.k.mall...@intel.com CC: linux-...@vger.kernel.org --- drivers/iommu/intel_irq_remapping.c | 20

[PATCH] x86, clocksource, fix !CONFIG_CLOCKSOURCE_WATCHDOG compile [v2]

2013-03-03 Thread Prarit Bhargava
If I explicitly disable the clocksource watchdog in the x86 Kconfig, the x86 kernel will not compile unless this is properly defined. v2: Oops ... move this to clocksource.h where it belongs Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: John Stultz john.stu...@linaro.org Cc: Thomas

Re: [RFE PATCH] time, Fix setting of hardware clock in NTP code

2013-02-07 Thread Prarit Bhargava
On 02/07/2013 12:24 PM, John Stultz wrote: On Thu, Feb 7, 2013 at 5:29 AM, Prarit Bhargava pra...@redhat.com wrote: We do not see this manifest on some architectures because they limit changes to the rtc to +/-15 minutes of the current value of the rtc (x86, alpha, mn10300). Other arches do

Re: [RFE PATCH] time, Fix setting of hardware clock in NTP code

2013-02-07 Thread Prarit Bhargava
On 02/07/2013 02:52 PM, John Stultz wrote: On 02/07/2013 10:20 AM, Prarit Bhargava wrote: On 02/07/2013 12:24 PM, John Stultz wrote: On Thu, Feb 7, 2013 at 5:29 AM, Prarit Bhargava pra...@redhat.com wrote: I'm not sure I understand the purpose behind the +/-15 minute window? Is it just

[PATCH] time, Fix setting of hardware clock in NTP code

2013-02-08 Thread Prarit Bhargava
this problem as rtc writes are software limited to a +/-15 minute window relative to the current rtc time. Other arches, such as powerpc, however do a full synchronization of the system time to the rtc and will see this problem. Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: John Stultz johns

Re: [PATCH] time, Fix setting of hardware clock in NTP code

2013-02-08 Thread Prarit Bhargava
this problem as rtc writes are software limited to a +/-15 minute window relative to the current rtc time. Other arches, such as powerpc, however do a full synchronization of the system time to the rtc and will see this problem. [v2]: generated against tip/timers/core Signed-off-by: Prarit Bhargava

Re: [PATCH] time, Fix setting of hardware clock in NTP code

2013-02-08 Thread Prarit Bhargava
On 02/08/2013 06:12 PM, John Stultz wrote: On 02/08/2013 02:59 PM, Prarit Bhargava wrote: Ok, I've got this queued in my tree. What sort of testing did you do with it? I want to make sure we don't run into any bad interactions with the existing 15min cap on x86. John, I did

[RFE PATCH] time, Fix setting of hardware clock in NTP code

2013-02-07 Thread Prarit Bhargava
sys_time_offset which indicates that an offset has been applied in warp_clock(). Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: John Stultz johns...@us.ibm.com Cc: Thomas Gleixner t...@linutronix.de --- include/linux/time.h |1 + kernel/time.c|8 kernel/time/ntp.c

Re: [RFE PATCH 2/2] rtc, add write functionality to sysfs

2013-02-28 Thread Prarit Bhargava
On 02/25/2013 09:58 AM, Alessandro Zummo wrote: On Sun, 24 Feb 2013 12:03:01 -0500 Prarit Bhargava pra...@redhat.com wrote: AFAICT there is no way for me to test or use the write from userspace. hwclock uses the SET_TIME ioctl, which is a different code path AFAICT. I'd like

[RFE PATCH 0/2] x86, rtc, ntp, Enable full rtc synchronization

2013-02-14 Thread Prarit Bhargava
system and confirmed that the system time and hwclock were now correct at boot. Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: Thomas Gleixner t...@linutronix.de Cc: John Stultz john.stu...@linaro.org Cc: x...@kernel.org Cc: Matt Fleming matt.flem...@intel.com Cc: David Vrabel david.vra

[RFE PATCH 1/2] x86, rtc, ntp, Do full rtc synchronization with ntp

2013-02-14 Thread Prarit Bhargava
as they do all the required bounds checking. Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: Thomas Gleixner t...@linutronix.de Cc: John Stultz john.stu...@linaro.org Cc: x...@kernel.org Cc: Matt Fleming matt.flem...@intel.com Cc: David Vrabel david.vra...@citrix.com Cc: Andrew Morton a...@linux

[RFE PATCH 2/2] rtc, add write functionality to sysfs

2013-02-14 Thread Prarit Bhargava
/sys/class/rtc/rtcX/date and /sys/class/rtc/rtcX/time currently have read-only access. This patch introduces write functionality which will set the rtc time. Usage: echo -MM-DD /sys/class/rtc/rtcX/date echo HH:MM:SS /sys/class/rtc/rtcX/time Signed-off-by: Prarit Bhargava pra

[PATCH] x86, clocksource, fix !CONFIG_CLOCKSOURCE_WATCHDOG compile

2013-02-22 Thread Prarit Bhargava
If I explicitly disable the clocksource watchdog in the x86 Kconfig, the x86 kernel will not compile unless this is properly defined. Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: John Stultz john.stu...@linaro.org Cc: Thomas Gleixner t...@linutronix.de Cc: x...@kernel.org --- kernel/time

Re: [RFE PATCH 2/2] rtc, add write functionality to sysfs

2013-02-22 Thread Prarit Bhargava
On 02/22/2013 03:43 PM, John Stultz wrote: On 02/14/2013 09:02 AM, Prarit Bhargava wrote: /sys/class/rtc/rtcX/date and /sys/class/rtc/rtcX/time currently have read-only access. This patch introduces write functionality which will set the rtc time. Usage: echo -MM-DD /sys/class/rtc

Re: [RFE PATCH 2/2] rtc, add write functionality to sysfs

2013-02-24 Thread Prarit Bhargava
On 02/23/2013 06:11 PM, Alessandro Zummo wrote: On 22/feb/2013, at 22:05, John Stultz john.stu...@linaro.org wrote: On 02/22/2013 12:55 PM, Prarit Bhargava wrote: On 02/22/2013 03:43 PM, John Stultz wrote: On 02/14/2013 09:02 AM, Prarit Bhargava wrote: /sys/class/rtc/rtcX/date and /sys

Re: [PATCH] x86, clocksource, fix !CONFIG_CLOCKSOURCE_WATCHDOG compile

2013-02-24 Thread Prarit Bhargava
the clocksource watchdog in the x86 Kconfig, the x86 kernel will not compile unless this is properly defined. Signed-off-by: Prarit Bhargava pra...@redhat.com Cc: John Stultz john.stu...@linaro.org Cc: Thomas Gleixner t...@linutronix.de Cc: x...@kernel.org --- kernel/time/clocksource.c |1 + 1

Re: [RFE PATCH 1/2] x86, rtc, ntp, Do full rtc synchronization with ntp

2013-02-24 Thread Prarit Bhargava
On 02/22/2013 03:42 PM, John Stultz wrote: This looks reasonable to me. Though I want to make sure we get this thoroughly tested by the various distros so we don't surprise anyone, since it has to potential to cause problems where folks are dualbooting windows (using a localtime RTC)

Re: [PATCH] x86, clocksource, fix !CONFIG_CLOCKSOURCE_WATCHDOG compile

2013-02-25 Thread Prarit Bhargava
On 02/24/2013 12:04 PM, Prarit Bhargava wrote: On 02/22/2013 03:14 PM, Thomas Gleixner wrote: +void clocksource_mark_unstable(struct clocksource *cs) { } Unless this is defined as +static inline void clocksource_mark_unstable(struct clocksource *cs) { } Right? Whups. Of course

Re: [PATCH] x86, clocksource, fix !CONFIG_CLOCKSOURCE_WATCHDOG compile

2013-02-25 Thread Prarit Bhargava
On 02/22/2013 03:14 PM, Thomas Gleixner wrote: On Fri, 22 Feb 2013, Prarit Bhargava wrote: If I explicitly disable the clocksource watchdog in the x86 Kconfig, the x86 kernel will not compile unless this is properly defined. You shouldn't do that. :) Signed-off-by: Prarit Bhargava

[PATCH] Fix race in efi variable delete code.

2007-01-22 Thread Prarit Bhargava
Fix race when deleting an EFI variable and issuing another EFI command on the same variable. The removal of the variable from the efivars_list should be done in efivar_delete and not delayed until the kprobes release. Signed-off-by: Prarit Bhargava [EMAIL PROTECTED] diff --git a/drivers

Re: [PATCH] time: Fix timeekeping_get_ns overflow on 32bit systems

2012-09-12 Thread Prarit Bhargava
store the result of timekeeping_get_ns() into a tv_nsec field, instead using a 64bit nsec value which can then be added into the timespec via timespec_add_ns(). Cc: Ingo Molnar mi...@kernel.org Cc: Richard Cochran richardcoch...@gmail.com Cc: Prarit Bhargava pra...@redhat.com Cc: Thomas

[PATCH] tty, add kref to sysrq handlers

2012-07-27 Thread Prarit Bhargava
3rd try on this one ... 8- On a large system with a large number of tasks, the output of echo t /proc/sysrq-trigger can take a long period of time. If this period is greater than the period of the current clocksource, the clocksource watchdog will mark the clocksource as unstable and

[PATCH] tty, add kref to sysrq handlers

2012-07-27 Thread Prarit Bhargava
that the sysrq_key_table_lock is acquired and results in a functional sysrq-t. I've tested both options and I no longer see the clocksource watchdog marking the TSC clocksource as unstable. Signed-off-by: Prarit Bhargava pra...@redhat.com Acked-by: Don Zickus dzic...@redhat.com Cc: gre...@linuxfoundation.org Cc

Re: [PATCH 0/2][RFC] Better handling of insane CMOS values

2012-07-31 Thread Prarit Bhargava
On 07/31/2012 02:35 AM, John Stultz wrote: So CAI Qian noticed recent boot trouble on a machine that had its CMOS clock configured for the year 8200. See: http://lkml.org/lkml/2012/7/29/188 In case anyone was wondering, the system's date was very much screwed up: │ System Time

Re: [PATCH 1/2] kvm, Add x86_hyper_kvm to complete detect_hypervisor_platform check [v2]

2012-07-06 Thread Prarit Bhargava
On 07/06/2012 07:27 AM, Marcelo Tosatti wrote: On Thu, Jul 05, 2012 at 09:37:00AM -0400, Prarit Bhargava wrote: On 07/05/2012 09:26 AM, Avi Kivity wrote: Please copy at least k...@vger.kernel.org, and preferably Marcelo as well (the other kvm co-maintainer). While debugging I noticed

  1   2   3   4   5   6   7   8   9   10   >