Quote:
Originally Posted by Suwat
I spent several hours doing some experimentation on the clock. As it turned out, "clock=pit" had nothing to do with the inaccuracy of the clock. I did some reading and found out that "clock=pit" was i386 systems specific. For q7, it will run correctly after bootstrap or clock-server-sync (probably after clock-setting too) as long as the device is not suspended. After suspend, it will start running faster and faster. I still could not find the causes.
The above event that the clock reversed back to the correct time occured only that once. I tried several ways to duplicate it without success. It's probably a fluke. Maybe it's like you said, there's a hardware rtc-clock and the software clock applet that displays time. Maybe there's intervals that the software clock goes back and update the rtc-clock. Hence, the reversal of hardware time because I did the reboot too early.
I will keep investigate anyway. Wish me luck.
|
Luck!
I am certain that the Linux kernel has its own methods of keeping time and synchronization -- at least 3 or 4. That "clock=pit" is 386-specific also does not surprise me.
The issue is ARM, and the kernel options when it was compiled. When my Q7 comes back (if it ever does) I will try to mimic the current desktop on Jaunty by installing Mer, then adding LXDE and removing Hildon. This should give me a clock to compare to the original. If the newer kernel has proper compilation, I expect that the clock has been taken care of. Jaunty is the first Ubuntu release that has official support for ARM, and I expect that at least minimal bug-checking has been done.
m a r