Eli Carter wrote:
>
> Eli Carter wrote:
> >
> > Russell King wrote:
> > >
> > > Eli Carter writes:
> > > > What are you seeing that I'm missing?
> > >
> > > Ok, after sitting down and thinking again about this problem, its not
> > > the 9.ms case, but the 10.1 case:
> > [snip]
> > >
Eli Carter wrote:
>
> Russell King wrote:
> >
> > Eli Carter writes:
> > > What are you seeing that I'm missing?
> >
> > Ok, after sitting down and thinking again about this problem, its not
> > the 9.ms case, but the 10.1 case:
> [snip]
> > Like I say, this requires good timing to
Russell King wrote:
>
> Eli Carter writes:
> > What are you seeing that I'm missing?
>
> Ok, after sitting down and thinking again about this problem, its not
> the 9.ms case, but the 10.1 case:
[snip]
> Like I say, this requires good timing to create, so may not be too much of
> a
Eli Carter wrote:
Eli Carter wrote:
Russell King wrote:
Eli Carter writes:
What are you seeing that I'm missing?
Ok, after sitting down and thinking again about this problem, its not
the 9.ms case, but the 10.1 case:
[snip]
Like I say, this requires good
Russell King wrote:
> This problem has a non-trivial solution, and I think whoever originally
> wrote the x86 do_gettimeofday code decided that it wasn't worth finding
> a solution to it.
So are you going to use the x86 solution and not worry about the >10ms
problem for now? The x86 is an
Russell King wrote:
This problem has a non-trivial solution, and I think whoever originally
wrote the x86 do_gettimeofday code decided that it wasn't worth finding
a solution to it.
So are you going to use the x86 solution and not worry about the 10ms
problem for now? The x86 is an
Eli Carter writes:
> And you described (in much better detail) the same problem I was talking
> about in the first email I sent today.
Ok, at least we've got the same picture that we're working from now.
> Yes, but it digs another to get the dirt to fill the first one. :/ for
> instance:
>
>
Russell King wrote:
>
> Eli Carter writes:
> > What are you seeing that I'm missing?
>
> Ok, after sitting down and thinking again about this problem, its not
> the 9.ms case, but the 10.1 case:
And you described (in much better detail) the same problem I was talking
about in the
Eli Carter writes:
> What are you seeing that I'm missing?
Ok, after sitting down and thinking again about this problem, its not
the 9.ms case, but the 10.1 case:
First time:
- interrupts disabled
- read jiffies
- read counter
- jiffies_p != jiffies_t
Russell King wrote:
>
> Eli Carter writes:
> > Russell, I know that at least the EBSA285's timer1_gettimeoffset() needs
> > some attention to fix a time going backward problem.
>
> I know about this, which is what started me looking at what x86 does,
> and I am firmly of the conclusion that x86
Eli Carter writes:
> Russell, I know that at least the EBSA285's timer1_gettimeoffset() needs
> some attention to fix a time going backward problem.
I know about this, which is what started me looking at what x86 does,
and I am firmly of the conclusion that x86 is buggy as it stands.
I believe
Jamie Lokier wrote:
>
> Russell King wrote:
> > > I've noticed that one of my machines here suffers from the "time going
> > > backwards problem" and so started thinking about the x86 solution.
> > >
> > > I've come to the conclusion that it has a hole which could cause it
> > > to return the
Russell King wrote:
> > I've noticed that one of my machines here suffers from the "time going
> > backwards problem" and so started thinking about the x86 solution.
> >
> > I've come to the conclusion that it has a hole which could cause it
> > to return the wrong time in one specific case:
> >
Russell King wrote:
I've noticed that one of my machines here suffers from the "time going
backwards problem" and so started thinking about the x86 solution.
I've come to the conclusion that it has a hole which could cause it
to return the wrong time in one specific case:
- in
Jamie Lokier wrote:
Russell King wrote:
I've noticed that one of my machines here suffers from the "time going
backwards problem" and so started thinking about the x86 solution.
I've come to the conclusion that it has a hole which could cause it
to return the wrong time in one
Eli Carter writes:
Russell, I know that at least the EBSA285's timer1_gettimeoffset() needs
some attention to fix a time going backward problem.
I know about this, which is what started me looking at what x86 does,
and I am firmly of the conclusion that x86 is buggy as it stands.
I believe
Russell King wrote:
Eli Carter writes:
Russell, I know that at least the EBSA285's timer1_gettimeoffset() needs
some attention to fix a time going backward problem.
I know about this, which is what started me looking at what x86 does,
and I am firmly of the conclusion that x86 is buggy
Eli Carter writes:
What are you seeing that I'm missing?
Ok, after sitting down and thinking again about this problem, its not
the 9.ms case, but the 10.1 case:
First time:
- interrupts disabled
- read jiffies
- read counter
- jiffies_p != jiffies_t
Russell King wrote:
Eli Carter writes:
What are you seeing that I'm missing?
Ok, after sitting down and thinking again about this problem, its not
the 9.ms case, but the 10.1 case:
And you described (in much better detail) the same problem I was talking
about in the first
Eli Carter writes:
And you described (in much better detail) the same problem I was talking
about in the first email I sent today.
Ok, at least we've got the same picture that we're working from now.
Yes, but it digs another to get the dirt to fill the first one. :/ for
instance:
On Sat, Mar 03, 2001 at 12:49:04PM +, Russell King wrote:
> Hi,
>
> I've noticed that one of my machines here suffers from the "time going
> backwards problem" and so started thinking about the x86 solution.
>
> I've come to the conclusion that it has a hole which could cause it
> to return
On Sat, Mar 03, 2001 at 12:49:04PM +, Russell King wrote:
Hi,
I've noticed that one of my machines here suffers from the "time going
backwards problem" and so started thinking about the x86 solution.
I've come to the conclusion that it has a hole which could cause it
to return the
On Sat, Mar 03, 2001 at 12:49:04PM +, Russell King wrote:
> Further more, while do_gettimeofday() is still within the
> read_lock_irqsave, we spin_unlock(_lock) in do_slow_gettimeoffset()
> and _re-enable_ interrupts! This means when we later read xtime, we're
> doing it with interrupts
Hi,
I've noticed that one of my machines here suffers from the "time going
backwards problem" and so started thinking about the x86 solution.
I've come to the conclusion that it has a hole which could cause it
to return the wrong time in one specific case:
- in do_gettimeofday(), we disable
Hi,
I've noticed that one of my machines here suffers from the "time going
backwards problem" and so started thinking about the x86 solution.
I've come to the conclusion that it has a hole which could cause it
to return the wrong time in one specific case:
- in do_gettimeofday(), we disable
On Sat, Mar 03, 2001 at 12:49:04PM +, Russell King wrote:
Further more, while do_gettimeofday() is still within the
read_lock_irqsave, we spin_unlock(i8253_lock) in do_slow_gettimeoffset()
and _re-enable_ interrupts! This means when we later read xtime, we're
doing it with interrupts
26 matches
Mail list logo
