On Tue, 2007-04-17 at 10:09 -0700, Andrew Morton wrote:
I guess this counts as a regression.
Begin forwarded message:
Date: Tue, 17 Apr 2007 14:16:25 +0200 (MEST)
From: Mikael Pettersson
To: linux-kernel@vger.kernel.org
Subject: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on
On 4/19/07, guilherme [EMAIL PROTECTED] wrote:
Hi,
If i enable High Resolution Timer Support, my machine stops here at boot:
Clocksource tsc unstable (delta = -297340790165 ns)
Time: hpet clocksource has been installed.
If i disable HPET, it boots fine.
Hmmm.. What happens if you boot w/
On Sat, 2007-04-21 at 20:07 -0300, Guilherme M. Schroeder wrote:
john stultz wrote:
On 4/19/07, guilherme [EMAIL PROTECTED] wrote:
Hi,
If i enable High Resolution Timer Support, my machine stops here at
boot:
Clocksource tsc unstable (delta = -297340790165 ns)
Time: hpet
On Mon, 2007-04-23 at 15:30 -0700, john stultz wrote:
On Sat, 2007-04-21 at 20:07 -0300, Guilherme M. Schroeder wrote:
john stultz wrote:
On 4/19/07, guilherme [EMAIL PROTECTED] wrote:
Hi,
If i enable High Resolution Timer Support, my machine stops here at
boot
On Tue, 2007-03-13 at 09:31 -0700, Jeremy Fitzhardinge wrote:
The current Linux scheduler makes one big assumption: that 1ms of CPU
time is the same as any other 1ms of CPU time, and that therefore a
process makes the same amount of progress regardless of which particular
ms of time it gets.
Gleixner [EMAIL PROTECTED]
Ek! Thanks Thomas!
Acked-by: John Stultz [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
[EMAIL PROTECTED]
Acked-by: John Stultz [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, 2007-02-14 at 11:18 +1100, Paul Mackerras wrote:
Andi Kleen writes:
Just to avoid spreading misinformation: modulo some new broken hardware
(which we always try to work around when found) i386/x86-64 gettimeofday
is monotonic. AFAIK on the currently known hardware it should be
, or at least the minimum for machines with small cache lines.
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
Sounds fine to me. Can you actually observe a difference?
Acked-by: John Stultz [EMAIL PROTECTED]
--- linux-2.6.21-rc4-mm1/include/linux/clocksource.h
+++ linux-2.6.21-rc4-mm1-ed/include
On Tue, 2007-03-20 at 11:04 -0700, Daniel Walker wrote:
On Tue, 2007-03-20 at 10:58 -0700, john stultz wrote:
/* timekeeping specific data, ignore */
- cycle_t cycle_last, cycle_interval;
- u64 xtime_nsec, xtime_interval;
+ cycle_t cycle_interval;
+ u64 xtime_interval
On Wed, 2007-03-21 at 21:18 +0100, Bartlomiej Zolnierkiewicz wrote:
Thanks for narrowing it down, I'm adding John to cc:.
On Wednesday 21 March 2007, Bob Tracy wrote:
I originally wrote:
Platform is a Dell CPxJ 650GT notebook. Attempts to boot 2.6.21-rc3
and -rc4 produce the following
On Wed, 2007-03-21 at 16:00 -0600, Bob Tracy wrote:
john stultz wrote:
Hmmm. Are you able to capture a full dmesg?
For the it hangs case, short of either trying to boot with the
console I/O redirected to a serial port or hooking up a printer to
the console and scanning in the resulting
On Wed, 2007-03-21 at 21:45 -0600, Bob Tracy wrote:
john stultz wrote:
Also, does booting w/ clocksource=jiffies change the behavior?
Works fine with 2.6.21-rc4. I'm running on that kernel as I type this.
Also trying booting w/ notsc would be a useful data point.
Boot hangs
On Thu, 2007-03-22 at 13:14 -0600, Bob Tracy wrote:
john stultz wrote:
Try this patch and let me know if it does the right thing.
Will do. I'll report back in a few hours.
Although I do
still need to dig a bit on the PIT hang issue.
Any chance this might be related to the APIC
On Thu, 2007-03-22 at 13:39 -0600, Bob Tracy wrote:
john stultz wrote:
On Thu, 2007-03-22 at 13:14 -0600, Bob Tracy wrote:
john stultz wrote:
Try this patch and let me know if it does the right thing.
Will do. I'll report back in a few hours.
Although I do
still need
Tested by Bob Tracy.
On Wed, 2007-03-21 at 21:45 -0600, Bob Tracy wrote:
john stultz wrote:
Also, does booting w/ clocksource=jiffies change the behavior?
Works fine with 2.6.21-rc4. I'm running on that kernel as I type this.
Also trying booting w/ notsc would be a useful data point
: Bob Tracy [EMAIL PROTECTED]
Caused-By : John Stultz [EMAIL PROTECTED]
commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd
Handled-By : John Stultz [EMAIL PROTECTED]
Status : problem is being debugged
The incorrect clocksource selection is resolved w/ this patch:
http://lkml.org
-john
Signed-off-by: John Stultz [EMAIL PROTECTED]
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index eb12509..eaa3d24 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -32,7 +32,7 @@ #define MAX_TICKADJ_SCALED(((u64)(MAX_T
/* TIME_ERROR prevents overwriting the CMOS clock
On Fri, 2007-03-23 at 14:54 -0700, Linus Torvalds wrote:
On Fri, 23 Mar 2007, john stultz wrote:
The incorrect clocksource selection is resolved w/ this patch:
http://lkml.org/lkml/2007/3/22/287
There is still an issue of why the PIT clocksource hangs, but for the
moment the issue
On Thu, 2007-04-05 at 14:03 -0700, Daniel Walker wrote:
Before this change the timekeeping code would poll the clocksource
list every interrupt. This changes that so the clocksource list is
only checked when there has been and update, and no longer checks
in interrupt context.
This also has
On Thu, 2007-04-05 at 14:29 -0700, Daniel Walker wrote:
On Thu, 2007-04-05 at 14:25 -0700, john stultz wrote:
On Thu, 2007-04-05 at 14:03 -0700, Daniel Walker wrote:
Before this change the timekeeping code would poll the clocksource
list every interrupt. This changes that so
On Thu, 2007-04-05 at 14:36 -0700, Andrew Morton wrote:
On Thu, 05 Apr 2007 14:25:19 -0700
john stultz [EMAIL PROTECTED] wrote:
On Thu, 2007-04-05 at 14:03 -0700, Daniel Walker wrote:
Before this change the timekeeping code would poll the clocksource
list every interrupt. This changes
Signed-off-by: John Stultz [EMAIL PROTECTED]
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 1734d96..86f6ca3 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -53,6 +53,10 @@ config GENERIC_CALIBRATE_DELAY
bool
default y
+config GENERIC_TIME
+ bool
not tested this at all, but it seems pretty straight forward
I'd appreciate any comments or feedback!
thanks
-john
Signed-off-by: John Stultz [EMAIL PROTECTED]
diff --git a/arch/v850/Kconfig b/arch/v850/Kconfig
index 50ccc7f..5f54c12 100644
--- a/arch/v850/Kconfig
+++ b/arch/v850/Kconfig
@@ -37,6
to test this on a few of my own
boxes.
thanks
-john
Signed-off-by: John Stultz [EMAIL PROTECTED]
arch/i386/kernel/hpet.c | 80 ---
arch/i386/kernel/i8253.c |2
arch/i386/kernel/setup.c |1
arch/i386/kernel/time.c |1
arch/i386/kernel
This patch changes mark_tsc_unstable() so it takes a string argument,
which holds the reason the TSC was marked unstable.
This is then displayed the first time mark_tsc_unstable is called.
This should help us better debug why the TSC was marked unstable on
certain systems and allow us to make
/timekeeping code.
Signed-off-by: Peter Keilty [EMAIL PROTECTED]
Signed-off-by: John Stultz [EMAIL PROTECTED]
Kconfig |2 +-
defconfig |2 +-
kernel/time.c | 34 +++---
3 files changed, 25 insertions(+), 13 deletions(-)
linux-2.6.21-rc1_timeofday-arch
Crud, my poor gmail skills dropped lkml on the CC list for this one.
On 2/23/07, john stultz [EMAIL PROTECTED] wrote:
On 2/23/07, David Miller [EMAIL PROTECTED] wrote:
While probeing PLL information via radeon_get_pllinfo(), it does a
gettimeofday(); do_something(); gettimeofday(); type
On Fri, 2007-02-23 at 16:34 -0800, David Miller wrote:
From: john stultz [EMAIL PROTECTED]
Date: Fri, 23 Feb 2007 11:51:18 -0800
Yea. I actually have some in-progress patches from Peter Keilty that
convert ia64 and sparc64 time_interpolators to clocksources, then
removes
On Sun, 2007-02-25 at 19:00 -0500, David Woodhouse wrote:
On Mon, 2006-12-11 at 20:59 +, Linux Kernel Mailing List wrote:
Make sure we populate the initroot filesystem late enough
This seems to be what's triggering the apparent memory corruption we've
been seeing recently -- in
-by: John Stultz [EMAIL PROTECTED]
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 1734d96..86f6ca3 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -53,6 +53,10 @@ config GENERIC_CALIBRATE_DELAY
bool
default y
+config GENERIC_TIME
+ bool
+ default y
to convert, but I
figured I'd get the maintainer's input and submit the patch for comment.
And again, I do not have hardware, so this is completely untested.
thanks
-john
Signed-off-by: John Stultz [EMAIL PROTECTED]
diff --git a/arch/v850/Kconfig b/arch/v850/Kconfig
index 50ccc7f..5f54c12 100644
On Tue, 2007-02-27 at 14:04 -0500, Mathieu Desnoyers wrote:
__get_nsec_offset : reads clock-cycle_last. Should be called with
xtime_lock held. (ok so far, but see below)
change_clocksource
clock-cycle_last = now; (non atomic 64 bits update. Not protected by
any lock ?) - this would race
On Fri, 2007-03-02 at 02:18 -0800, Andrew Morton wrote:
On Thu, 22 Feb 2007 16:13:02 -0800 john stultz [EMAIL PROTECTED] wrote:
Thus the solution here is to register clocksources earlier (ideally when
the hardware is being initialized), and then we enable clocksource
selection
On Fri, 2007-03-02 at 12:32 -0800, David Miller wrote:
From: john stultz [EMAIL PROTECTED]
Date: Fri, 02 Mar 2007 11:58:11 -0800
Oh! Sorry! Yea, looking at it more the ioremap isn't actually necessary,
as we can use hpet_readl() instead of re-calculating the hpet base
address pointer
added an explicit update_vsyscall() during the settimeofday(), that way
the vsyscall state doesn't get stale.
Any thought John?
Oh! Yes, very good catch, Daniel!
Thanks so much!
-john
Signed-Off-By: Daniel Walker [EMAIL PROTECTED]
Acked-by: John Stultz [EMAIL PROTECTED]
---
kernel
with a hopeful inclusion date of 2.6.22.
Simply, it moves the timekeeping code out of kernel/timer.c and into
kernel/time/timekeeping.c. I made no cleanups or other changes in
transit.
Any thoughts or objections?
thanks
-john
Signed-off-by: John Stultz [EMAIL PROTECTED]
include/linux/time.h
On Wed, 2007-03-28 at 13:02 -0700, Andrew Morton wrote:
On Wed, 28 Mar 2007 18:44:57 +0200
Mariusz Koz__owski [EMAIL PROTECTED] wrote:
2) This was found a couple minutes later when the system was
really busy and close to oom condition.
INFO: lockdep is turned off.
BUG: soft
path as
i386).
Any thoughts or comments?
thanks
-john
Signed-off-by: John Stultz [EMAIL PROTECTED]
time.c | 43 +--
1 file changed, 1 insertion(+), 42 deletions(-)
diff --git a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
index 75d73a9
clocksource
earlier so a bad TSC won't get selected just because nothing else is yet
registered.
thanks
-john
Signed-off-by: John Stultz [EMAIL PROTECTED]
diff --git a/kernel/time/jiffies.c b/kernel/time/jiffies.c
index 3be8da8..4c256fd 100644
--- a/kernel/time/jiffies.c
+++ b/kernel/time
On Wed, 2007-04-04 at 13:43 -0700, Andrew Morton wrote:
On Wed, 04 Apr 2007 12:50:15 -0700
john stultz [EMAIL PROTECTED] wrote:
In debugging a problem w/ the -rt tree, I noticed that on systems that
mark the tsc as unstable before it is registered, the TSC would still be
selected
On Wed, 2007-04-04 at 14:30 -0700, Andrew Morton wrote:
On Wed, 04 Apr 2007 23:13:11 +0200
Thomas Bittermann [EMAIL PROTECTED] wrote:
Andrew Morton schrieb:
On Wed, 04 Apr 2007 22:20:54 +0200
Thomas Bittermann [EMAIL PROTECTED] wrote:
This patch adds 2 missing symbol exports:
On Wed, 2008-01-09 at 18:29 -0500, Steven Rostedt wrote:
plain text document attachment (rt-time-starvation-fix.patch)
Handle accurate time even if there's a long delay between
accumulated clock cycles.
Signed-off-by: John Stultz [EMAIL PROTECTED]
Signed-off-by: Steven Rostedt [EMAIL
On Wed, 2008-01-09 at 18:29 -0500, Steven Rostedt wrote:
plain text document attachment (rt-time-starvation-fix.patch)
Handle accurate time even if there's a long delay between
accumulated clock cycles.
Signed-off-by: John Stultz [EMAIL PROTECTED]
Signed-off-by: Steven Rostedt [EMAIL
On Thu, 2008-01-10 at 11:54 -0800, Tony Luck wrote:
Tony: ia64 also needs something like this, but I found the fsyscall asm
bits a little difficult to grasp. So I'll need some assistance on how to
include the accumulated cycles into the final calculation.
I'm trying to figure out all
On Thu, 2008-01-10 at 15:15 -0500, Steven Rostedt wrote:
I'm trying to figure out all the ramifications of the new
cycle_accumulated field. Does it really need to be
John,
Before we hardcode these names, can we change them? Later in the series I
use something called 'cycle_raw' which
On Thu, 2008-01-10 at 15:42 -0500, Mathieu Desnoyers wrote:
I think it's about time I introduce the approach I have taken for LTTng
timestamping. Basically, one of the main issues with the clock sources
is the xtime lock : having a read seqlock nested over a write seqlock is
a really, really
On Thu, 2008-01-10 at 17:00 -0500, Mathieu Desnoyers wrote:
* john stultz ([EMAIL PROTECTED]) wrote:
On Thu, 2008-01-10 at 15:42 -0500, Mathieu Desnoyers wrote:
I think it's about time I introduce the approach I have taken for LTTng
timestamping. Basically, one of the main issues
On Thu, 2008-01-03 at 15:52 -0800, Dan Hecht wrote:
Looking at pit_read() in arch/x86/kernel/i8253.c, it seems that the PIT
clocksource code assumes that the PIT CH0 is in periodic mode. With
clockevents, this assumption is no longer valid. There are at least two
places that make this
On 10/16/07, Joshua Roys [EMAIL PROTECTED] wrote:
I am running a vanilla 2.6.23 kernel and am experiencing (seemingly)
random hangs. Below is a piece of dmesg and my kernel config, along
with a few snippets from /var/log/messages showing a 5 minute hang
(and another hang, but I wasn't at the
On Mon, 2007-10-29 at 23:17 +0100, Thomas Gleixner wrote:
On Mon, 29 Oct 2007, Glauber de Oliveira Costa wrote:
CC'ed John and removed [EMAIL PROTECTED] :)
From: Glauber de Oliveira Costa [EMAIL PROTECTED]
tsc is very good time source (when it does not have drifts, does not
change
On Fri, 2008-02-08 at 18:33 +0100, Roman Zippel wrote:
Hi,
On Fri, 1 Feb 2008, John Stultz wrote:
CLOCK_TICK_ADJUST is based on LATCH and HZ, if the update frequency isn't
based on HZ, there is no point in using it!
Hey Roman,
Again, I'm sorry I don't seem to be following
On Sun, 2008-02-10 at 19:45 +0100, Roman Zippel wrote:
Hi,
On Fri, 8 Feb 2008, john stultz wrote:
-ENOPATCH
We're taking weeks to critique fairly small bug fix. I'm sure we both
have better things to do then continue to misunderstand each other. I'll
do the testing
On Tue, 2008-02-12 at 15:36 +0100, Roman Zippel wrote:
On Mon, 11 Feb 2008, john stultz wrote:
This fine grained error accounting is where the bug I'm trying to
address is cropping up from. In order to have the comparison we need to
have two values:
A: The clocksource's notion of how
:38:09 -0400)
John Stultz (11):
alarmtimer: Use hrtimer per-alarm instead of per-base
alarmtimer: Remove unused helpers defines
alarmtimer: Rename alarmtimer_remove to alarmtimer_dequeue
jiffies: Kill unused
On 09/24/2012 09:48 AM, John Stultz wrote:
Hey Thomas, Ingo,
[snip]
PS: Just a reminder that there is still a pending change in
tip/timers/urgent that I'd hope to get into 3.6.
Oh, ignore that. Just updated my tree and it looks like it landed over
the weekend.
Sorry for the noise.
-john
On 09/27/2012 01:39 PM, Greg KH wrote:
On Tue, Sep 11, 2012 at 06:35:23PM -0400, John Stultz wrote:
Just wanted to send out a few timekeeping fixes that were merged
in 3.6 which are appropriate for -stable.
This queue backports the following fixes
On 10/03/2012 09:01 AM, Willy Tarreau wrote:
Hi Ben,
On Wed, Oct 03, 2012 at 03:50:14PM +0100, Ben Hutchings wrote:
On Tue, 2012-10-02 at 00:52 +0200, Willy Tarreau wrote:
2.6.32-longterm review patch. If anyone has any objections, please let me know.
[...]
No objection, but please remove
On 09/30/2012 04:59 AM, Fengguang Wu wrote:
On Sun, Sep 30, 2012 at 01:32:46PM +0200, Avi Kivity wrote:
On 09/30/2012 01:23 PM, Fengguang Wu wrote:
On Sun, Sep 30, 2012 at 01:10:55PM +0200, Avi Kivity wrote:
On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
On Thu, Sep 27, 2012 at 12:40:44PM
On 10/07/2012 11:25 PM, Minchan Kim wrote:
Hi John,
On Fri, Sep 28, 2012 at 11:16:30PM -0400, John Stultz wrote:
After Kernel Summit and Plumbers, I wanted to consider all the various
side-discussions and try to summarize my current thoughts here along
with sending out my current
resembles volatile mmap ranges
(i.e. the work that John Stultz is leading in parallel).
Agreed. I haven't been paying close attention to those patches but it
seems to me that one possiblity is that a listener for a vmevent would
set volatile ranges in response.
I don't have too much to comment
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?
thanks
-john
--
To unsubscribe from this list: send the line
idle for more then 4
seconds.
Thanks for the audit, and sending this in!
Thomas: Mind queuing this? Probably should be marked for stable too.
Acked-by: John Stultz johns...@us.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On 10/09/2012 01:07 AM, Mike Hommey wrote:
Note it doesn't have to be a vs. situation. madvise could be an
additional way to interface with volatile ranges on a given fd.
That is, madvise doesn't have to mean anonymous memory. As a matter of
fact, MADV_WILLNEED/MADV_DONTNEED are usually used on
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 might be
wrong. Note the bug happens on *BOTH* upstream and the current RHEL6 tree.
The data in this email is from
On 11/08/2012 01:01 PM, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
Currently, whenever CONFIG_ARCH_USES_GETTIMEOFFSET is enabled, each
arch core provides a single implementation of arch_gettimeoffset(). In
many cases, different sub-architectures, different machines, or
On 10/16/2012 10:23 AM, Peter Zijlstra wrote:
On Tue, 2012-10-16 at 12:13 +0200, Stephane Eranian wrote:
Hi,
There are many situations where we want to correlate events happening at
the user level with samples recorded in the perf_event kernel sampling buffer.
For instance, we might want to
-by: Doug Anderson diand...@chromium.org
Cc: Anton Vorontsov cbouatmai...@gmail.com
Cc: John Stultz johns...@us.ibm.com
Signed-off-by: Kees Cook keesc...@chromium.org
---
v2:
- export needed for timekeeping_suspended (thanks to Fengguang Wu).
---
fs/pstore/ram.c |8 +++-
kernel
On 11/11/2012 12:32 PM, Stephane Eranian wrote:
On Sat, Nov 10, 2012 at 3:04 AM, John Stultz john.stu...@linaro.org wrote:
On 10/16/2012 10:23 AM, Peter Zijlstra wrote:
On Tue, 2012-10-16 at 12:13 +0200, Stephane Eranian wrote:
Hi,
There are many situations where we want to correlate events
the final implementation in later
patches, because they already have function pointers in place for this
purpose.
Cc: Russell King li...@arm.linux.org.uk
Cc: Mike Frysinger vap...@gentoo.org
Cc: Mikael Starvik star...@axis.com
Cc: Hirokazu Takata tak...@linux-m32r.org
Cc: John Stultz johns
On 11/12/2012 12:54 PM, Stephane Eranian wrote:
On Mon, Nov 12, 2012 at 7:53 PM, John Stultz john.stu...@linaro.org wrote:
On 11/11/2012 12:32 PM, Stephane Eranian wrote:
On Sat, Nov 10, 2012 at 3:04 AM, John Stultz john.stu...@linaro.org
wrote:
Also I worry that it will be abused in the same
On 10/12/2012 08:40 AM, Prarit Bhargava wrote:
One possibility is that if the cpu we're doing our timekeeping
accumulation on is different then the one running the test, we might
go into deeper idle for longer periods of time. Then when we
accumulate time, we have more then a single tick to
On 11/05/2012 12:51 AM, David Henningsson wrote:
Hi LKML,
I'm trying to make audio more useful in everyday low-latency scenarios
such as gaming or VOIP.
While doing so, I ran the wakeup_rt tracer, to track the time from
PulseAudio requesting wakeup (through hrtimers), to the thread
On 11/12/2012 03:53 PM, John Stultz wrote:
On 11/05/2012 12:51 AM, David Henningsson wrote:
Hi LKML,
I'm trying to make audio more useful in everyday low-latency
scenarios such as gaming or VOIP.
While doing so, I ran the wakeup_rt tracer, to track the time from
PulseAudio requesting
On 11/12/2012 05:53 PM, Shan Wei wrote:
From: Shan Wei davids...@tencent.com
Signed-off-by: Shan Wei davids...@tencent.com
Reviewed-by: Christoph Lameter c...@linux.com
Please provide a changelog (even for trivial changes) in the future.
Applied to my tree.
thanks
-john
--
To unsubscribe
On 10/18/2012 02:34 AM, Lars-Peter Clausen wrote:
Commit f1b8274 (clocksource: Cleanup clocksource selection) removed all
external references to clocksource_jiffies so there is no need to have the
symbol globally visible.
Fixes the following sparse warning:
CHECK kernel/time/jiffies.c
On 10/19/2012 09:46 PM, Dan Carpenter wrote:
I changed the strict_strtoul() to kstrtouint(). That has the check
for UINT_MAX built in to it so the ifdefs can be removed. Also
I changed a printk() to pr_info().
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Applied. Thanks!
-john
--
PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Cc: Tony Luck [EMAIL PROTECTED]
Cc: John Stultz [EMAIL PROTECTED]
---
Only compile tested for IA64
Testcase at: http://bakeyournoodle.com/~tony/settimeofday-0.0/
I guess this is aimed at 2.6.24
arch/ia64/kernel/time.c |5 +
arch
Hey Andi,
I've not been able to review the new vdso code very carefully yet, but
I noticed one thing right off: the offset calculation is not masked, so
its possible w/ counters less then 64bits wide to have wrapping issues.
It seems something like the following would be needed.
diff
On Mon, 2007-07-23 at 10:59 -0700, john stultz wrote:
Hey Andi,
I've not been able to review the new vdso code very carefully yet, but
I noticed one thing right off: the offset calculation is not masked, so
its possible w/ counters less then 64bits wide to have wrapping issues.
Here's
how you box is
slipping through.
Can you run the following test to verify that the TSCs are skewed?
thanks
-john
/* TSC sync test
* by: john stultz ([EMAIL PROTECTED])
* (C) Copyright IBM 2003, 2005
* Licensed under the GPL
*/
#include stdio.h
#include sys/time.h
#define CALLS_PER_LOOP
/hpet.c
both register a clocksource named hpet. Probably a result of bringing
back to life a long lost patch, and having someone else (John Stultz,
according
to git blame) make a similar change to a different file in the intervening
time.
Presumably the thing to do would be merge the x86_64
On Thu, 2007-08-23 at 14:05 -0700, john stultz wrote:
On Thu, 2007-08-23 at 13:41 -0700, Luck, Tony wrote:
I have a double hpet entry in available_clocksource:
$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet hpet acpi_pm jiffies
Oops. If seems
On Fri, 2007-08-24 at 08:46 -0400, Bob Picco wrote:
john stultz wrote:[Thu Aug 23 2007, 05:41:45PM EDT]
On Thu, 2007-08-23 at 14:05 -0700, john stultz wrote:
On Thu, 2007-08-23 at 13:41 -0700, Luck, Tony wrote:
I have a double hpet entry in available_clocksource:
$ cat
On Thu, 2007-08-23 at 14:05 -0700, john stultz wrote:
On Thu, 2007-08-23 at 13:41 -0700, Luck, Tony wrote:
I have a double hpet entry in available_clocksource:
$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet hpet acpi_pm jiffies
Oops. If seems
cycle_raw + cycle_delta;
}
unsigned long notrace cycles_to_usecs(cycle_t cycles)
Otherwise:
Acked-by: John Stultz [EMAIL PROTECTED]
thanks
-john
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
On Fri, 2007-08-24 at 17:07 -0700, Andrew Morton wrote:
On Sat, 25 Aug 2007 01:27:25 +0200
Tilman Schmidt [EMAIL PROTECTED] wrote:
Am 22.08.2007 11:06 schrieb Andrew Morton:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
After applying
On Mon, 2007-08-27 at 17:34 -0300, Luiz Fernando N. Capitulino wrote:
Em Fri, 24 Aug 2007 11:17:34 -0700
john stultz [EMAIL PROTECTED] escreveu:
| On Fri, 2007-08-24 at 08:46 -0400, Bob Picco wrote:
| john stultz wrote:[Thu Aug 23 2007, 05:41:45PM EDT]
| On Thu, 2007-08-23 at 14
depending on your kernel config. This patch converts to using
num_possible_cpus() so we spread it as evenly as possible on every
machine.
Briefly tested w/ NR_CPUS=255 and verified reduced contention.
Signed-off-by: John Stultz [EMAIL PROTECTED]
Index: 2.6-rt/kernel/time/tick-sched.c
Hey Ingo, Thomas,
I was playing with the latency tracer on 2.6.23-rc2-rt2 while a make
-j8 was going on in the background and the box hung with this on the
console:
[ BUG: circular locking deadlock detected! ]
Whoops, forgot to CC lkml.
-- Forwarded message --
From: john stultz [EMAIL PROTECTED]
Date: Jul 30, 2007 11:13 AM
Subject: Re: [2.6.22] negative time jump
To: Vasily Averin [EMAIL PROTECTED]
On 7/29/07, Vasily Averin [EMAIL PROTECTED] wrote:
I've investigated why my testnode
On Wed, 2007-05-30 at 17:49 -0700, john stultz wrote:
All,
So we've been seeing PI mutex deadlocks with a few of our applications
using the -rt kernel. After narrowing things down, we were finding that
the applications were indirectly calling futex_unlock_pi(), which on
occasion would
Stultz [EMAIL PROTECTED]
Status : problem is being debugged
Subject: acpi_pm clocksource loses time on x86-64
References : http://lkml.org/lkml/2007/4/17/143
Submitter : Mikael Pettersson [EMAIL PROTECTED]
Handled-By : John Stultz [EMAIL PROTECTED]
Status : problem
On Wed, 2007-04-25 at 20:33 -0400, Len Brown wrote:
On Wednesday 25 April 2007 14:08, john stultz wrote:
On Wed, 2007-04-25 at 04:06 -0700, Andrew Morton wrote:
On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk [EMAIL PROTECTED] wrote:
Subject: acpi_pm clocksource loses time on x86-64
-by: John Stultz [EMAIL PROTECTED]
The Signed-off-by: should reflect the order in which a path is processed
with the last submitter at the bottom of the list.
So if this patch came from John then he should be first in the list
and since the patch passes you and you submit it you should
On Thu, 2007-04-26 at 16:27 -0400, Peter Keilty wrote:
From: Peter Keilty [EMAIL PROTECTED]
Remove time_interpolator code.
Signed-off-by: Peter Keilty [EMAIL PROTECTED]
Signed-off-by: John Stultz [EMAIL PROTECTED]
---
include/linux/timex.h | 60 ---
kernel/time.c
On Thu, 2007-04-26 at 16:26 -0400, Peter Keilty wrote:
From: Peter Keilty [EMAIL PROTECTED]
Initial ia64 conversion to the generic timekeeping/clocksource code.
Signed-off-by: Peter Keilty [EMAIL PROTECTED]
Signed-off-by: John Stultz [EMAIL PROTECTED]
Peter,
Thanks so much
All,
Currently the x86-64 HPET code assumes the entire HPET implementation
from the spec is present. This breaks on boxes that do not implement the
optional legacy timer replacement functionality portion of the spec.
This is my first swing at resolving this issue, allowing x86-64 systems
that all HPET capable
systems I had also had Legacy Support.
Using HPET interrupts via the IOAPIC would be a possibility, but seems
more invasive then what I'm proposing.
Some comments on the patch inlined below..
On Tue, Apr 12, 2005 at 07:43:16PM -0700, john stultz wrote:
Its likely
Andrew, All,
Currently the x86-64 HPET code assumes the entire HPET implementation
from the spec is present. This breaks on boxes that do not implement the
optional legacy timer replacement functionality portion of the spec.
This patch fixes this issue, allowing x86-64 systems that cannot
1 - 100 of 7113 matches
Mail list logo
