On Thu, Apr 25, 2013 at 09:38:22AM +0800, Li Zefan wrote:
> On 2013/4/25 6:42, Guenter Roeck wrote:
> > On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote:
> >>
> >>
> >> On 04/08/2013 04:19 PM, John Stultz wrote:
> >>> On 04/08/2013 05:47 AM, Prarit Bhargava wrote:
> >>
>
>
On 2013/4/25 6:42, Guenter Roeck wrote:
> On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote:
>>
>>
>> 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
On 04/24/2013 05:35 PM, Guenter Roeck wrote:
On Wed, Apr 24, 2013 at 05:05:03PM -0700, John Stultz wrote:
On 04/24/2013 03:42 PM, Guenter Roeck wrote:
On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote:
On 04/08/2013 04:19 PM, John Stultz wrote:
On 04/08/2013 05:47 AM, Prarit
On Wed, Apr 24, 2013 at 05:05:03PM -0700, John Stultz wrote:
> On 04/24/2013 03:42 PM, Guenter Roeck wrote:
> >On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote:
> >>
> >>On 04/08/2013 04:19 PM, John Stultz wrote:
> >>>On 04/08/2013 05:47 AM, Prarit Bhargava wrote:
> A simple
On 04/24/2013 03:42 PM, Guenter Roeck wrote:
On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote:
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
On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote:
>
>
> 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
On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote:
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
On 04/24/2013 03:42 PM, Guenter Roeck wrote:
On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote:
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
On Wed, Apr 24, 2013 at 05:05:03PM -0700, John Stultz wrote:
On 04/24/2013 03:42 PM, Guenter Roeck wrote:
On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote:
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
On 04/24/2013 05:35 PM, Guenter Roeck wrote:
On Wed, Apr 24, 2013 at 05:05:03PM -0700, John Stultz wrote:
On 04/24/2013 03:42 PM, Guenter Roeck wrote:
On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote:
On 04/08/2013 04:19 PM, John Stultz wrote:
On 04/08/2013 05:47 AM, Prarit
On 2013/4/25 6:42, Guenter Roeck wrote:
On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote:
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
On Thu, Apr 25, 2013 at 09:38:22AM +0800, Li Zefan wrote:
On 2013/4/25 6:42, Guenter Roeck wrote:
On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote:
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
On Mon, Apr 08, 2013 at 01:19:23PM -0700, John Stultz wrote:
> On 04/08/2013 05:47 AM, Prarit Bhargava wrote:
> >2nd submit: I did quite a bit of testing with this patch and I don't see any
> >ill effects. I've tested across several large and small x86 systems, and a
> >ppc system for good
On Mon, Apr 08, 2013 at 01:19:23PM -0700, John Stultz wrote:
On 04/08/2013 05:47 AM, Prarit Bhargava wrote:
2nd submit: I did quite a bit of testing with this patch and I don't see any
ill effects. I've tested across several large and small x86 systems, and a
ppc system for good measure.
On 04/08/2013 01:34 PM, Prarit Bhargava wrote:
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
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
On 04/08/2013 05:47 AM, Prarit Bhargava wrote:
2nd submit: I did quite a bit of testing with this patch and I don't see any
ill effects. I've tested across several large and small x86 systems, and a
ppc system for good measure.
P.
8<---
`
The settimeofday01 test in the LTP testsuite
On 04/08/2013 07:53 AM, Rik van Riel wrote:
On 04/08/2013 08:47 AM, Prarit Bhargava wrote:
When we change the system time to a low value like this, the value of
timekeeper->offs_real will be a negative value.
It seems that the WARN occurs because an hrtimer has been started in
the time
On 04/08/2013 08:47 AM, Prarit Bhargava wrote:
When we change the system time to a low value like this, the value of
timekeeper->offs_real will be a negative value.
It seems that the WARN occurs because an hrtimer has been started in the time
between the releasing of the timekeeper lock and
2nd submit: I did quite a bit of testing with this patch and I don't see any
ill effects. I've tested across several large and small x86 systems, and a
ppc system for good measure.
P.
8<---
`
The settimeofday01 test in the LTP testsuite effectively does
gettimeofday(current time);
2nd submit: I did quite a bit of testing with this patch and I don't see any
ill effects. I've tested across several large and small x86 systems, and a
ppc system for good measure.
P.
8---
`
The settimeofday01 test in the LTP testsuite effectively does
gettimeofday(current time);
On 04/08/2013 08:47 AM, Prarit Bhargava wrote:
When we change the system time to a low value like this, the value of
timekeeper-offs_real will be a negative value.
It seems that the WARN occurs because an hrtimer has been started in the time
between the releasing of the timekeeper lock and the
On 04/08/2013 07:53 AM, Rik van Riel wrote:
On 04/08/2013 08:47 AM, Prarit Bhargava wrote:
When we change the system time to a low value like this, the value of
timekeeper-offs_real will be a negative value.
It seems that the WARN occurs because an hrtimer has been started in
the time
On 04/08/2013 05:47 AM, Prarit Bhargava wrote:
2nd submit: I did quite a bit of testing with this patch and I don't see any
ill effects. I've tested across several large and small x86 systems, and a
ppc system for good measure.
P.
8---
`
The settimeofday01 test in the LTP testsuite
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 that.
On 04/08/2013 01:34 PM, Prarit Bhargava wrote:
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 settimeofday01 test in the LTP testsuite effectively does
gettimeofday(current time);
settimeofday(Jan 1, 1970 + 100 seconds);
settimeofday(current time);
This test causes a stack trace to be displayed on the console during the
setting of timeofday to Jan 1, 1970 +
The settimeofday01 test in the LTP testsuite effectively does
gettimeofday(current time);
settimeofday(Jan 1, 1970 + 100 seconds);
settimeofday(current time);
This test causes a stack trace to be displayed on the console during the
setting of timeofday to Jan 1, 1970 +
28 matches
Mail list logo
