[arch-general] linux 3.1-4 - two i686 lockups after ~ 5 hours of operations. two x86_64 seem OK

[C Anthony Risinger]

On Nov 10, 2011 2:44 PM, "David C. Rankin" <drankinatty at suddenlinkmail.com>
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
different
>> 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??

Yeah I'm really not sure about the jump, ntp should be logging any changes
anyway (though I believe it will not change the time if greater than some
threshold)

... however, some time ago it was announced that localtime is no longer
supported for a variety of well-known and good reasons.  Windows just needs
a small tweak (via registry IIRC) and it will behave.  I would recommended
switching to UTC hardware clock, and making said change.

C Anthony [mobile]