Bug 5522
Summary: | Timer going backward on an AMD64 dual core | ||
---|---|---|---|
Product: | Platform Specific/Hardware | Reporter: | Claudio Scordino (cloud.of.andor) |
Component: | x86-64 | Assignee: | john stultz (john.stultz) |
Status: | REJECTED INSUFFICIENT_DATA | ||
Severity: | normal | CC: | andi-bz, cloud.of.andor, john.stultz |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.14 | Subsystem: | |
Regression: | --- | Bisected commit-id: |
Description
Claudio Scordino
2005-10-28 14:54:49 UTC
Very mysterious. Can you state what was the last mainline (not distro) kernel that didn't have the problem? Also add boot log from both the last working and the broken kernel. Thanks. Does the problem appear if you boot a uniproc kernel? You might also want to check out but #3341 since it also deals with nvidia chipsets. I think the bug #3341 is not related to our problem: in our case the gettimeofday works fine, except for "sometimes" that it goes backward (without rebooting and doing nothing...). The problem does not appear when we boot a uniproc kernel. It does not appear either in the other machines that have the same configuration, the same distro, and quite the same hardware (the difference is that they are single-processor machines). May the problem be with the do_vgettimeofday ?? The gettimeofday seems to work fine (I'm not sure, but I couldn't see any strange behaviour...). Why I can't use the printk in do_vgettimeofday even after the lock has been released? How can I print the values of the variables from inside the function? How are you verifying gettimeofday works fine compared to vgettimeofday? Additionally, could you quantify how large the time inconsistencies (jumps backward in time) are? I just said that putting some printk inside do_gettimeofday() seems that it works fine. I can't test do_vgettimeofday() because if I put a printk it crashes the system during boot (probably I didn't consider some lock). I'm suspicious of your testing method. To verify do_gettimeofday works better then do_vgettimeofday, you might try setting the kernel.vsyscall64 value to zero via sysctl. This should force do_gettimeofday to be used when you call gettimeofday(). Unfortunately, the guy in the lab that said to have disabled NTP, actually didn't. I'm really sorry. After 2 days spent looking at the code and putting printk around it, I discovered that "someone" was updating xtime.tv_sec with a new value less than the current value. Then, I discovered that actually NTP was _not_ disabled. As soon as NTP has been disabled, the problem disappeared (using both the PIT and PM timers). The guy says that he already tested with NTP disabled, and there was still the problem. However, according to my experiments, disabling NTP on a 2.6.14 kernel fixes the problem. Therefore, I'm going to move the bug state to "solved". Well, NTP should be able to slew the clock without it jumping backwards. This is partially a problem with the current time code that I'm working to fix, so hopefully it will be resolved in the near future. I'm stil a little concerned that your clock is skewing quickly enough that NTP need to set the clock rather then slew it. Could you provide the output, after NTP has been running for awhile, from running: /usr/sbin/ntpdc -c kerninfo Alternatively if your application depends on time not going backwards, I'd suggest using the clock_gettime(CLOCK_MONOTONIC,...) call. This interface shuold provide an increasing clock (since boot time) that is not affected by settimeofday. Claudio: Any chance you could reply to the questions in comment #9. Otherwise I'll probably reject this bug as invalid. No info on this one for awhie, rejecting it as insufficient data. Please re-open if there is new info that can be provided. |