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

[Leonid Isaev]

On (11/10/11 13:16), David C. Rankin wrote:
-~>   Hmm.. Absolutely no help from the logs on the box that locked:
-~> 
-~> Nov 10 03:20:04 phoenix -- MARK --
-~> Nov 10 03:25:34 phoenix dhcpd: DHCPREQUEST for 192.168.7.124 from
-~> 00:11:43:22:50:08 via eth0
-~> Nov 10 03:25:34 phoenix dhcpd: DHCPACK on 192.168.7.124 to
-~> 00:11:43:22:50:08 via eth0
-~> Nov 10 12:44:33 phoenix kernel: [    0.000000] Initializing cgroup subsys cpuset
-~> Nov 10 12:44:33 phoenix kernel: [    0.000000] Initializing cgroup subsys cpu
-~> 
-~>   Obviously something occurred after 03:25:34, but no indication
-~> of what. The second box I lost and thought was locked, wasn't
-~> locked, I just had the uncanny coincidence of trying it during one
-~> of its spontaneous reboots due to hwclock drift (I'll create a
-~> cron job to update this).  The boxes are on the same LAN subnet.
-~> The only SWAG I have is that once the box with the drifting clock
-~> got far enough out of time any net communications with the box
-~> that locked may have caused it to panic over the time sync issue.
-~> 
-~> (but that is wrong because once running, the sysclock is the only
-~> clock that matters - right? But that can't be all wrong, otherwise
-~> there is no explanation for the spontaneous reboot due to clock
-~> drift. A digital paradox so to speak :)
-~> 
-~>   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.
-~> 
-~> -- 
-~> David C. Rankin, J.D.,P.E.

Regarding logs, I would look into dmesg.log and probably append loglevel=7 (or
debug) to the kernel command line.

If your machine crashes because of rtc, your motherboard is junk -- get rid of
it.

-- 
Leonid Isaev
GnuPG key ID: 164B5A6D
Key fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20111110/f355eeea/attachment.asc>