On Tue, Aug 13, 2013 at 10:53:29AM -0700, Jamie Zawinski wrote: > If you have a *tested* patch, please send it.
I don't know that code, and as you say yourself it is security sensitive. I can give it a try if you wish, though. > I don't have any systems that exhibit the kind of broken behavior you > describe, and can't test it myself. This is very security-sensitive code > so I am hesitant to make any changes at all without them being very > obviously correct. These days, a good deal of arm-based stuff don't ship a RTC chip. Usually because adding a battery is expensive, but since this machine is a laptop that already has a battery, I kind of fail to understand why. After boot-up, the clock is set to 2010-01-01. For obvious reasons, I installed ntp, but network is not always available. If it comes up after I log in (wifi coverage, AP selection, etc), the clock will suddenly advance by multiple years. I guess you can duplicate this by moving aside /etc/init.d/hwclock.sh (I can't check if that's enough right now). Or by setting the clock a few years back in the BIOS. > It's also important that you understand and explain what systems this > affects and how to properly detect that it is available, if the routines > you are calling are not POSIX. man clock_gettime says it's specified in SUSv2 and POSIX.1-2001; there might be other functions that could be used for this purpose. > timers.c:check_for_clock_skew() is what you're looking for. However it is > only called every pointerPollTime seconds (default 5) and even then only > if /proc/interrupts exists. (Which I suppose means that the clock skew > check never happens on BSD?) > > Also note that if the wall clock moves backwards, XtInterval timers > completely fail to fire until the clock catches up. This is an unfixable > failure in the bowels of Xt. I've seen multiple machines with broken RTC, including x86 ones (a broken /depleted battery is enough), fortunately in every case it resetted to a time in the past. > It's great to know that even here in This Modern World, trying to close > the lid on a Linux laptop and have anything work is still slapstick > comedy. This bug is not related to the lid. > What year is this? My clock say 2010. [screen lock]. Oh, 2013. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
