LTP - gettimeofday02 FAIL
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Paul Larson
This has been noticed, I've posted to lkml about it. The only person who replied to me seems to be suggesting it is a hardware issue, but I can't believe it is impossible to work around.
It is very hard to solve properly and efficiently. When you search the list archives you will find long threads about the problem (search for "TSC" and gettimeofday and perhaps HPET or cyclone). Last one was one or two weeks ago.
The problem has been there always in some way in linux, now it is just exposed in LTP because it tests for it.
-Andi
Quoted 7 lines · Andi Kleen
It is very hard to solve properly and efficiently. When you search the list archives you will find long threads about the problem (search for "TSC" and gettimeofday and perhaps HPET or cyclone). Last one was one or two weeks ago.
The problem has been there always in some way in linux, now it is just exposed in LTP because it tests for it.
Dual ppro boxes normally run with a locked synchronous TSC clock. That suggests the newer code broke stuff. It may also be due to the bug in the 2.5 timer handling code (missing delays on timer reads, incorrect assumption that the timer never reads its limit value during the timer switch back to zero)
Quoted 11 lines · Alan Cox
Quoted 7 lines · Andi Kleen
It is very hard to solve properly and efficiently. When you search the list archives you will find long threads about the problem (search for "TSC" and gettimeofday and perhaps HPET or cyclone). Last one was one or two weeks ago.
The problem has been there always in some way in linux, now it is just exposed in LTP because it tests for it.
Dual ppro boxes normally run with a locked synchronous TSC clock. That suggests the newer code broke stuff. It may also be due to the bug in
It is because of the HZ=1000. See Jim Houston's mail on the same topic, he analyzed the failure.
Basically the current code cannot handle missing ticks properly on SMP and with the new 1ms tick it is much more likely that a timer interrupt gets lost.
-Andi
Quoted 5 lines · Andi Kleen
It is because of the HZ=1000. See Jim Houston's mail on the same topic, he analyzed the failure.
Basically the current code cannot handle missing ticks properly on SMP and with the new 1ms tick it is much more likely that a timer interrupt gets lost.
Ok so add that to the other existing 2.5 timer handling bugs 8(
Quoted 8 lines · Alan Cox
Quoted 5 lines · Andi Kleen
It is because of the HZ=1000. See Jim Houston's mail on the same topic, he analyzed the failure.
Basically the current code cannot handle missing ticks properly on SMP and with the new 1ms tick it is much more likely that a timer interrupt gets lost.
Ok so add that to the other existing 2.5 timer handling bugs 8(
2.4 has the same problem, it is just much less likely to hit because of HZ=100
-Andi