e the HPET MMAP exposed.
[v2]: Clemens suggested modifying the Kconfig help text and making the
default setting configurable.
Signed-off-by: Prarit Bhargava
Cc: Clemens Ladisch
---
Documentation/kernel-parameters.txt |3 +++
drivers/char/Kconfig| 10 --
drivers
[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
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
e 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
Cc: Clemens Ladisch
---
Documentation/kernel-parameters.txt |
the hardware clock in the ntp code. This patch adds sys_time_offset which
indicates that an offset has been applied in warp_clock().
Signed-off-by: Prarit Bhargava
Cc: John Stultz
Cc: Thomas Gleixner
---
include/linux/time.h |1 +
kernel/time.c|8
kernel/time/ntp
On 02/07/2013 12:24 PM, John Stultz wrote:
> On Thu, Feb 7, 2013 at 5:29 AM, Prarit Bhargava 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). Ot
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 wrote:
>>>
>> I'm not sure I understand the purpose behin
clock.
x86 does not have 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
Cc: Joh
clock.
x86 does not have 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
S
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 c
On 02/23/2013 06:11 PM, Alessandro Zummo wrote:
> On 22/feb/2013, at 22:05, John Stultz 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 wrot
atch ...
-8<
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
Cc: John Stultz
Cc: Thomas Gleixner
Cc: x...@kernel.org
---
kernel/time/clocksource.c |1 +
1 file changed
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 localti
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 clock
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. :)
On 02/25/2013 09:58 AM, Alessandro Zummo wrote:
> On Sun, 24 Feb 2013 12:03:01 -0500
> Prarit Bhargava 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
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
Cc: John Stultz
Cc: Thomas Gleixner
Cc: x...@kernel.org
---
kernel/time/clocksource.c |1 +
1 file changed, 1 insertion
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.
>>
>&
duced a kernel parameter, hpet_mmap_enable, that
is required in order to actually have the HPET MMAP exposed.
Signed-off-by: Prarit Bhargava
Cc: Clemens Ladisch
---
Documentation/kernel-parameters.txt |3 +++
drivers/char/hpet.c | 20 ++--
2 files change
increasing, causing timers to not expire.
>
> The fix is to make sure we don't directly 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
Add debugfs entries for ntp time_status and time_state. These are useful
for debugging ntp issues.
Signed-off-by: Prarit Bhargava
Cc: John Stultz
Cc: Thomas Gleixner
---
kernel/time/ntp.c | 40
1 file changed, 40 insertions(+)
diff --git a/kernel
On 10/24/2012 05:49 AM, Ingo Molnar wrote:
>
> * 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 determ
x86_hyper. We can use this to output additional debug
information during a panic/oops/stack trace.
Signed-off-by: Prarit Bhargava
Cc: Avi Kivity
Cc: Gleb Natapov
Cc: Alex Williamson
Cc: Marcelo Tostatti
Cc: Ingo Molnar
Cc: k...@vger.kernel.org
Cc: x...@kernel.org
[v2]: Modifications suggested by
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 an
time 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
Acked-by: Don Zickus
Cc: gre...@linuxfoundation.org
Cc: John Stultz
C
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 ..
x86_hyper. We can use this to output additional debug
information during a panic/oops/stack trace.
Signed-off-by: Prarit Bhargava
Cc: Avi Kivity
Cc: Gleb Natapov
Cc: Alex Williamson
Cc: Marcelo Tostatti
Cc: Ingo Molnar
Cc: k...@vger.kernel.org
Cc: x...@kernel.org
[v2]: Modifications suggested by
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,
> t
x86_hyper. We can use this to output additional debug
information during a panic/oops/stack trace.
Signed-off-by: Prarit Bhargava
Cc: Avi Kivity
Cc: Gleb Natapov
Cc: Alex Williamson
Cc: Marcelo Tostatti
Cc: Ingo Molnar
Cc: k...@vger.kernel.org
Cc: x...@kernel.org
[v2]: Modifications suggested by
On 07/01/2013 09:30 AM, Thomas Gleixner wrote:
> On Mon, 1 Jul 2013, Prarit Bhargava wrote:
>> On 06/28/2013 06:52 AM, Thomas Gleixner wrote:
>>> Huch. Did the warning in the broadcast code trigger before that?
>>
>> tglx,
>>
>> AFAICT it does not. Lo
physical core_id, which is
what we really want. The numa 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/x8
hardware
random number generator while allowing individual users to enable or
disable generator.
Signed-off-by: Prarit Bhargava
Cc: Theodore Ts'o
---
Documentation/kernel-parameters.txt |5 +
drivers/char/Kconfig|8
drivers/char/random.c |
On 09/05/2013 10:48 AM, Theodore Ts'o wrote:
> On Thu, Sep 05, 2013 at 08:18:44AM -0400, Prarit Bhargava wrote:
>> The current code has two exported functions, get_bytes_random() and
>> get_bytes_random_arch(). The first function only calls the entropy
>> store t
On 09/05/2013 03:49 PM, Theodore Ts'o wrote:
> BTW, note the following article, published today:
>
> http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html?pagewanted=all
>
> "By this year, the Sigint Enabling Project had found ways inside some
> of the encryption chips th
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
On 08/29/2013 02:01 AM, Matt Wilson wrote:
> On Fri, Mar 22, 2013 at 09:32:54AM -0400, 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
found an improperly classified FW_INFO in
arch/x86/kernel/cpu/amd.c which that should be a FW_WARN. For now, I am
leaving it as a FW_INFO and will fix it when I implement the FW_BUG for
the "full" patchset.
Comments are appreciated and welcomed. Thanks in advance for reviewing.
Signed-of
On 09/27/2013 11:40 AM, Joe Perches wrote:
> On Fri, 2013-09-27 at 09:22 -0400, Prarit Bhargava wrote:
>> I'm proposing with this patch to do something similar to the WARN()
>> mechanism that is currently implemented in the kernel. This
>> patchset introduces FW_INFO
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 de
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
Cc: Avi Kivity
Cc: Gleb Natapov
Cc: Alex Williamson
Cc: Marcelo Tostatti
Cc: Ingo Molnar
Cc: k...@vger.kernel.org
Cc: x...@kernel.org
---
arch/x86
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
Similar panics reported during bringup here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/166205.html
http://lkml.org/lkml/2013/5/8/342
I've seen this a few times on 3.10 based kernels.
[ 175.842027] Disabling non-boot CPUs ...
[ 475.827017] BUG: unable to handle kernel NULL
Len,
>The "Power Limit Notification" (X86_FEATURE_PLN) was added in Sandy Bridge
>to give the OS the option of knowing when the package has reached
>a configured power threshold.
>printk(KERN_CRIT "CPU%d: %s power limit notification (total events = %lu)
>printk(KERN_INFO "CPU%d: %s power limit no
On 06/24/2013 03:01 PM, Chegu Vinod wrote:
>
> Hello,
>
> Lots (~700+) of the following messages are showing up in the dmesg of a
> 3.10-rc1
> based kernel (Host OS is running on a large socket count box with HT-on).
>
> [ 82.270682] PERCPU: allocation failed, size=42 align=16, alloc from
On 06/24/2013 09:57 AM, Thomas Gleixner wrote:
> On Tue, 18 Jun 2013, Prarit Bhargava wrote:
>
>> Similar panics reported during bringup here:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/166205.html
>> http://lkml.org/lkml/2013/5/8/342
&g
cpu_idle+0x74/0xc8)
> [ 27.844451] [] (cpu_idle+0x74/0xc8) from []
> (start_kernel+0x248/0x288)
> [ 27.852722] ---[ end trace 9d8ad385bde80fd3 ]---
> [ 27.857330] hrtimer: interrupt took 0 ns
^^^ see below ...
>
> This is triggered with our v3.4-based custom ARM kernel, bu
On 06/26/2013 07:05 AM, Thomas Gleixner wrote:
> On Tue, 25 Jun 2013, Prarit Bhargava wrote:
>> On 06/24/2013 09:57 AM, Thomas Gleixner wrote:
>>> Does the patch below fix it?
>>>
>>
>> Thomas,
>>
>> Thanks for the patch.
>>
>>
e 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:
any issues.
Also, remove the unused cycles_2_ns() function.
Signed-off-by: Prarit Bhargava
Cc: John Stultz
Cc: Dave Hansen
Cc: x...@kernel.org
---
arch/x86/include/asm/timer.h | 15 +++
arch/x86/kernel/tsc.c| 13 +
2 files changed, 16 insertions(+), 12 deletion
hat their systems are vulnurable to this problem.
>
> Signed-off-by: Neil Horman
> CC: Prarit Bhargava
> CC: Don Zickus
> CC: Don Dutile
> CC: Bjorn Helgaas
> CC: Asit Mallick
> CC: linux-...@vger.kernel.org
> ---
> drivers/iommu/intel_irq_remapping.c
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
Cc: John Stultz
Cc: Thomas Gleixner
Cc: x...@kernel.org
---
include
On 05/12/2013 06:27 AM, tip-bot for Thomas Gleixner wrote:
> Commit-ID: 4b0c0f294f60abcdd20994a8341a95c8ac5eeb96
> Gitweb: http://git.kernel.org/tip/4b0c0f294f60abcdd20994a8341a95c8ac5eeb96
> Author: Thomas Gleixner
> AuthorDate: Fri, 3 May 2013 15:02:50 +0200
> Committer: Thomas Gleix
On 05/13/2013 03:10 PM, Thomas Gleixner wrote:
> On Mon, 13 May 2013, Prarit Bhargava wrote:
>> Thomas, while this does fix up the NULL pointer issue, I think you've
>> introduced
>> a new bug in the schedule timer code.
>
> I don't think that I introduced
function being run,
and the reprogramming of the timer after that.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: John Stultz
---
kernel/hrtimer.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index cc47812..17eafd7 100644
--- a/ke
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 repro
ch resolves the problem on
linux.git top of tree.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: John Stultz
---
kernel/time/tick-sched.c | 12
1 file changed, 12 insertions(+)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index a19a399..5027187 10
On 05/03/2013 04:10 AM, Thomas Gleixner wrote:
> On Fri, 3 May 2013, Thomas Gleixner wrote:
>
>> On Tue, 30 Apr 2013, Prarit Bhargava wrote:
>>
>>> 2nd try at this ... going with a more global cc.
>>>
>>> I think the linux.git "system ha
On 05/03/2013 09:02 AM, Thomas Gleixner wrote:
> On Fri, 3 May 2013, Prarit Bhargava wrote:
>> Down a cpu and then bring it back up.
>
> A. So the issue is, that we do not clear the per cpu ts->inidle
> and friends when we bring the cpu down.
>
:) I'll giv
line an interrupt happens before the per cpu tick
> device is registered the irq_enter() check potentially sees stale data
> and dereferences a NULL pointer.
>
> Cleanup the data after the cpu is dead.
>
> Reported-by: Prarit Bhargava
> Cc: sta...@vger.kernel.org
> Link:
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
Cc: Thomas Gleixner
---
kernel/time/tick-sched.c | 12
1 file changed, 12 insertions(+)
diff --git
On 05/27/2013 06:00 AM, Thomas Gleixner wrote:
> On Fri, 22 Feb 2013, Prarit Bhargava wrote:
>
>> If I explicitly disable the clocksource watchdog in the x86 Kconfig,
>
> And why do you want to do that?
Hey Thomas, I was debugging something and stumbled across this.
IIRC
ove 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 Bhargava
P.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
e 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 that.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: John Stultz
---
kernel/hrtimer.c |2 ++
1 file changed, 2 insertions(+)
diff
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
>>> remappin
have system for which their BIOS 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.
>>>>
>>>>
On 07/23/2012 04:22 PM, John Stultz wrote:
> Fix missing casts that can cause boot problems on 32bit systems,
> most easily observed with Xen systems. This issue was introduced
> w/ 1e75fa8be9fb61e1af46b5b3b176347a4c958ca1.
>
> Cc: Ingo Molnar
> Cc: Thomas Gleixner
> Cc:
On 07/10/2012 06:43 PM, John Stultz wrote:
> clock_was_set() cannot be called from hard interrupt context because
> it calls on_each_cpu(). For fixing the widely reported leap seconds
> issue it's necessary to call it from the timer interrupt context.
>
> Provide a new function which denotes it
gt;
> Once merged, I'll be working to get the backports finished as quickly
> as I can and sent to -stable.
>
> thanks
> -john
>
Add an Acked-by: Prarit Bhargava
John -- I'll do some testing of this patchset today and tomorrow and let you
know the results.
P.
-
>> I wish there was a nicer way to do this ... but looking at the code I can't
>> figure out a better way. (no offense John, it's just the way the code is ;)
>> )
>
> Yeah, I had the same discussion with Peter earlier today. There is
> only a rather limited set of options.
>
> 1) Retrigger the
IW.
>
Ditto - and it's not just FWIW.
John (and everyone else), I think we're over-thinking this. Would it be nice to
get an extremely elegant solution to this? Yeah ... it would. But the reality
is that we're not going to get there and IMO we're making things too complex for
On 07/11/2012 07:17 AM, Ingo Molnar wrote:
>
> * John Stultz wrote:
>
>> Over the weekend, Thomas got a chance to review the leap
>> second fix in more detail and had a few additional changes he
>> wanted to make to improve performance as well as style.
John,
FYI -- Using a mix of AMD and
it
Fedora 18 on an UEFI system and confirmed that the system time and hwclock
were now correct at boot.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: John Stultz
Cc: x...@kernel.org
Cc: Matt Fleming
Cc: David Vrabel
Cc: Andrew Morton
Cc: Andi Kleen
Cc: linux-...@vger.kernel.org
et as they do all the
required bounds checking.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: John Stultz
Cc: x...@kernel.org
Cc: Matt Fleming
Cc: David Vrabel
Cc: Andrew Morton
Cc: Andi Kleen
Cc: linux-...@vger.kernel.org
---
arch/x86/kernel/rtc.c
/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 Bharga
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
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
> 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
> CPU
data field which is populated in i7core_create_sysfs_devices().
Signed-off-by: Prarit Bhargava
Cc: Mauro Chehab
---
drivers/edac/i7core_edac.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
index 3672101..10c8c00 1
data field which is populated in i7core_create_sysfs_devices().
Signed-off-by: Prarit Bhargava
Cc: Mauro Chehab
Cc: linux-e...@vger.kernel.org
---
drivers/edac/i7core_edac.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/edac/i7core_edac.c b/drivers
On 01/10/2013 10:48 PM, Rusty Russell wrote:
> Prarit Bhargava writes:
>> [ 15.478160] kvm: Could not allocate 304 bytes percpu data
>> [ 15.478174] PERCPU: allocation failed, size=304 align=32, alloc
>> from reserved chunk failed
> ...
>> What is happening is
On 01/11/2013 08:06 PM, Rusty Russell wrote:
> Prarit Bhargava writes:
>> On 01/10/2013 10:48 PM, Rusty Russell wrote:
>> The timing were similar. I didn't see any huge delays, etc. Can the
>> relocations really cause a long delay? I thought we were pretty much w
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
&g
module
which results in the failure of other drivers to load.
This patch moves the module percpu allocation after the check for an
existing instance of the module.
Signed-off-by: Prarit Bhargava
Cc: Rusty Russell
Cc: Mike Galbraith
---
kernel/module.c | 124 +
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 Tig
(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]&
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
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
=
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. B
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 =
--
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, too.
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/
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/d
drivers/built-in.o
`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
G: drivers/net/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.000
waiting 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: Pr
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 a
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
(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 Bharga
#x27;
Signed-off-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_
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.
inte
1 - 100 of 1067 matches
Mail list logo
