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
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
24 matches
Mail list logo
