Date: Fri, 21 Aug 1998 07:37:30 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Brian Somers <brian@Awfulhak.org> Cc: Brian Feldman <green@unixhelp.org>, Terry Lambert <tlambert@primenet.com>, bde@zeta.org.au, freebsd-current@FreeBSD.ORG, jwd@unx.sas.com Subject: Re: 13 months of user time? Message-ID: <294.903677850@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 20 Aug 1998 22:37:34 BST." <199808202137.WAA03270@awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>[...] the machine I was having problems with was >running apm, so it used the i8254 timecounter rather than the tsc >counter. Ahh... I bet that is it: APM sucks. Try to disable APM and see if you can reproduce it, I'll bet you my collection of genuine 11 row punched cards that you can't. Our handling of APM is probably not the best either, in sys/i386/apm/apm.c the apm_default_resume() and apm_default_resume() does things which most parents would not want their kids to see or even know about. The basic scoop on APM is: Normal mode: Your TSC may run on variable frequency, with no warning, or with warning by an APM bios event (usually after the fact). Your i8254 mostly seem to run at constant frequency, although some reports I've seen indicates it may not. The APM bios may issue events to report anomalies (post factum). Your RTC runs at nominal speed, and the interrupts will arrive one by one, mostly on time. Suspend mode: Your TSC may or may not run, frequency unknown. Your i8254 may or may not run, frequency unknown. Your RTC runs, but interrupts may be disabled or postponed and arrive in "batch mode" when the machine is resumed. There is no doubt that the right thing to do on resume is to spin-poll the RTC for a shift of second, fixup the boottime and let the system loose again. What to do about the i8254 being slowed is much more tricky. If you could add code to your system which counts the RTC interrupts and tracks the i8254 timecounter delta between irqs, then maybe we can see what is happening on your system and get an idea for handling it... "Unfortunately" both of the two laptops I have access to doesn't have any of these problems, so I can't work on it myself. I said "Unfortunately" because they were chosen partly because of that... Summary: It will take hacking by the people who see the problem on their machines to fix this problem... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?294.903677850>