I've never deliberately touched anything in there. Everything
will have come from RedHat (7.2 CDs) or kernel.org, and I'm
pretty sure I didn't install any interim and/or experimental
versions or patches.
> I wish I knew more about this hardware bug. The test
> suggests that the chip is not resetting the latch on
> interrupt, but rather that it just rolls over (or under).
> This would cause the count to, again, reach zero (and,
> hopefully interrupt) in about 50 ms. On the other hand, the
> chip could be switching modes and only the "0X34" mode will
> continue to interrupt with out the chip being reprogrammed.
> In this case, it is hard to understand how the system keeps
> ANY time at all.
Both machines generally seem to keep time just fine, apart
from the bumps. But then, there were only a few of the
hardware bug warning messages in the logs, so it didn't
manifest itself very often.
Anyway, nothing caught over the weekend, unfortunately. The trap
in do_fast_gettimeoffset() reads:
if ( eax > 100000000 ) {
glob_eax = eax;
return delay_at_last_interrupt;
}
Then a check and printk() in do_gettimeofday(). The machine
has lost NTP synch somewhat sporadically, but not as regularly
as before. Sigh. Maybe it's the weather, we've been having a
heatwave since Friday, and everybody and everything in the office
is roasting.
I'm going to try to fiddle around some more, also with the other
machine.
-- Per
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/