> Searching through the mailing list I could not find a
> reference to this problem, hence this post.
> Having ran various kernel and distribution
> combinations (SGI's 2.4.2-xfs bundled with their Red
> Hat installer, 2.4-xfs-1.0 and 2.4 CVS trees, Linux
> Mandrake with default kernel 2.4.3, and lastly
> 2.4.5-ac9), compiled for generic i386 and/or Transmeta
> Crusoe with APM off or on, one thing sticks out : a
> clock drift of a few minutes per day.
> This problem might not be noticeable for most users
> since notebooks are not normally left running that
> long, but it is rather serious. I can choose not to
> sync the software and hardware clock on shutdown and
> re-read the hardware clock every hour or so but it is
> rather kludgy.
> Any suggestions and/or user experiences more than
Let me guess: vesafb?
If problem goes away when you stop using framebuffer (i.e. go X), then
it is known.
You are lucky. My machine is able to loose 2 minutes from every 3
try time cat /etc/termcap, and check it against stopwatch.
-- I'm firstname.lastname@example.org. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at email@example.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/