From owner-freebsd-mobile Thu Apr 6 10:10:32 2000 Delivered-To: freebsd-mobile@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.79.126]) by hub.freebsd.org (Postfix) with ESMTP id 3B3AE37BF9A for ; Thu, 6 Apr 2000 10:10:29 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.79.115]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA22651; Thu, 6 Apr 2000 11:10:27 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id LAA22387; Thu, 6 Apr 2000 11:10:26 -0600 (MDT) (envelope-from nate) Date: Thu, 6 Apr 2000 11:10:26 -0600 (MDT) Message-Id: <200004061710.LAA22387@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Jose M. Alcaide" Cc: freebsd-mobile@FreeBSD.ORG Subject: Re: proposal of a better solution for "statclock broken" laptops In-Reply-To: <38ECA91E.F98AE48@we.lc.ehu.es> References: <38ECA91E.F98AE48@we.lc.ehu.es> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ Moved to -mobile only ] > Some laptops suffer of the "statclock broken" problem: APM suspend > does not work while the RTC is generating periodic interrupts (which > are used for the statistical clock). Currently, the "solution" consists > of setting the 0x20 flag for the apm(4) driver. If this flag is set, > the cpu_initclocks() routine in sys/i386/isa/clock.c does not > initialize the statclok at all. As a consequence, the functionality > of the statclock is lost. > > I tried another solution which seems to work for my laptop (a Dell I3.7k). This is good stuff Jose. Unfortunately, as the author and bug-finder of the original 'broken statclock' code, I don't have time to delve into if your new solution works. Partly because the machine in question is no longer in my service, and partly because I don't have time to do '-current' development anymore. Note also that someone (you?) sent a patch a few days ago that caused the statclock to start working again due to a missing read call to the interrupt, which also might fix it. I don't have the reference handy, but it may be that the statclock has worked the entire time, it just that something forgot to read a critical register. Ahh, it was *you* that proposed the fix, and later assigned it to Bruce. Can you tell me what is different about the fix you posted in your PR vs. this one? Finally, not having the statclock is *really* not that big of a deal. It makes for better heuristics in the scheduler, but in fact makes very little difference in most machines as far as performance goes. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message