[arch-general] linux 3.1-4 - two i686 lockups after ~ 5 hours of operations. two x86_64 seem OK
registo.mailling at gmail.com
Thu Nov 10 15:58:50 EST 2011
On 10-11-2011 20:44, David C. Rankin wrote:
> On 11/10/2011 01:55 PM, Mauro Santos wrote:
>> On 10-11-2011 19:16, David C. Rankin wrote:
>>> Richard, David - check your hardware clock "# hwclock -r" and compare
>>> that to the time returned by "# date". If they are hours apart, then
>>> make sure your sysclock is correct and set the hardware clock to your
>>> sysclock with "# hwclock -w". Worth checking regardless. I know this
>>> used to be done on boot or shutdown and I don't know why it isn't
>>> anymore. I'll do some more digging.
>> You should take into account that 'hwclock -r' and 'date' might return
>> times and things will still be ok, it all depends on if you have the
>> clock set
>> to UTC or localtime and your timezone. The man page says there is some
>> autodetection logic but as with all things it can fail.
> True, hwclock always returns time in 'localtime' as does 'date'. Both
> also provide the '-u' option to return UTC. This box has the hwclock set
> to localtime because it dual-boots with M$. Come to think about it, it
> is one of my only boxes that is dual-boot. I wonder if the rtc set to
> localtime may be uncovering a regression that is causing this strange
> behavior, because honestly I can't explain jumping backwards in time
> over 13.75 hours with ntp running??
I thought hwclock would return the time set in the CMOS clock, which
should be set to UTC (if you set HARDWARECLOCK="UTC" in /etc/rc.conf)
and date would return localtime due to taking the timezone setting into
account. That is why I said they could be different but maybe I'm
looking at it in the wrong way. If everything is set to localtime then
both hwclock and date should return the same time.
More information about the arch-general