I've got one, although I no longer have a notebook to use it in, and when I
did it ran OS/2.
| So there are at least a few device drivers which are apparently holding
| interrupts off long enough so that we lose a clock interrupt. Not good,
+--->8
That was my conclusion back in April when I sat down and tried to diagnose
it. There was a little bit of evidence that the console driver was
involved, but not much... and I completely failed to find a common thread
between my own system at home and all the various systems in CMU ECE, aside
from the use of Red Hat 5.x.
Whatever it is, it's been consistent across 2.0.33 - 2.0.36 and it *didn't*
happen on my older system (486DX2/66) with 2.0.33 kernel --- but I've only
observed it on Red Hat 5 and to date I haven't had an RH5 install on the
older system (it ran RH4 for over a year without showing any such symptom,
but the same applies to some older ECE systems including some with hardware
identical to the ones that have severe clock drift).
The other thing about it is that it's not just lost interrupts: the systems
are as apt to *gain* time, instead of losing it, again enough to make
Kerberos upset (I've seen them gain 10 minutes over 5 minutes of wall time).
Again, I haven't been able to correlate gain vs. loss (or amount thereof)
to any particular program or device/driver.
-- brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net system administrator [WAY too many hats] allbery@ece.cmu.edu carnegie mellon / electrical and computer engineering KF8NH Kiss my bits, Billy-boy.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/