Bug 100
| Summary: | LTP - gettimeofday02 fails (time is going backwards) | ||
|---|---|---|---|
| Product: | Timers | Reporter: | Paul Larson (pl) |
| Component: | gettimeofday | Assignee: | john stultz (john.stultz) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Hardware: | IA-32 | ||
| OS: | Linux | ||
| Kernel Version: | Subsystem: | ||
| Regression: | --- | Bisected commit-id: | |
I've reproduced the bug here. Will continue researching it. any update on this? It's still failing. xtime_lock starvation and lost-interrupts are two known causes of this problem. Once those are shot down, hopefully this can be closed or researched further. lost-ticks and seqence locks (accepted into 2.5.60) should have fixed this and so far it hasn't reoccured in testing, so I'm marking this fixed. Fix has been incorporated into mainline tree. Therefore this bug is closed. |
(Please check that the problem happens on Linus' tree if not then file under the Alternate Trees category.) Exact Kernel version: 2.5.47 (and many other 2.5 kernels, not specific to this version) Distribution: SuSE 8.0 Hardware Environment: 2-way PIII-550 Software Environment: Problem Description: I've been getting a somewhat random error in a few of the recent 2.5 kernels with SMP machines. I noticed this on a 2.5.47 bk pull, but I was also able to reproduce it on 2.5.46. I haven't tried any earlier kernels yet. The LTP gettimeofday02 test sometimes fails with this message: gettimeofday02 0 INFO : checking if gettimeofday is monotonous, takes 30s gettimeofday02 1 FAIL : Time is going backwards (old 1037138184.846333 vs new 1037138184.843346! I have not been able to reproduce this on a single processor machine though. Basically, all the test does is: gettimeofday(&tv1, NULL); while(!done) { gettimeofday(&tv2, NULL); FAIL if tv2 < tv1 tv1 = tv2; } Steps to reproduce: Run gettimeofday02 from LTP on a SMP machine. It happens at random and may take several tries.