From owner-freebsd-mobile Thu Apr 6 16: 1:15 2000 Delivered-To: freebsd-mobile@freebsd.org Received: from polaris.we.lc.ehu.es (polaris.we.lc.ehu.es [158.227.6.43]) by hub.freebsd.org (Postfix) with ESMTP id 945CB37C1DE for ; Thu, 6 Apr 2000 16:01:09 -0700 (PDT) (envelope-from jose@we.lc.ehu.es) Received: from we.lc.ehu.es (lxpx73.lx.ehu.es [158.227.99.73]) by polaris.we.lc.ehu.es (8.9.1/8.9.1) with ESMTP id BAA21323; Fri, 7 Apr 2000 01:00:50 +0200 (MET DST) Message-ID: <38ED1721.BF297B57@we.lc.ehu.es> Date: Fri, 07 Apr 2000 01:00:49 +0200 From: "Jose M. Alcaide" Organization: Universidad del Pais Vasco - Dpto. de Electricidad y Electronica X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 3.4-RELEASE i386) X-Accept-Language: es-ES, es, en-US, en MIME-Version: 1.0 To: Nate Williams Cc: freebsd-mobile@FreeBSD.ORG Subject: Re: proposal of a better solution for "statclock broken" laptops References: <38ECA91E.F98AE48@we.lc.ehu.es> <200004061710.LAA22387@nomad.yogotech.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nate Williams wrote: > > 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. Unfortunately I have only one laptop which presents the "broken statclock" problem, and it works fine now :-) I could commit the changes to -CURRENT, but I am not the maintainer of clock.c and I don't want to start a conflict. > 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? They deal with different problems. The statclock did not start on my Dell I3.7k because of a pending interrupt being not cleared at startup. The patch included in PR 17800 fixes this problem. The "broken statclock" is a different problem, related to APM: some machines cannot be put in suspended state while the statclock is generating interrupts. Unfortunately, my Dell I3.7k is one of those machines, so once I got the statclock working thanks to my own fix included in PR 17800, I needed to set apm(4)'s 0x20 flag for being able to suspend my laptop; but then the statclock was lost again! I suggest a different solution which keeps both the statclock and APM suspend working. > 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. True, we can live without the statclock, but if there is some way to keep it working... (actually, the statclock problem is one of my obsessions since I got my I3.7k in January) :-) :-) Saludos, -- JMA ----------------------------------------------------------------------- José Mª Alcaide | mailto:jose@we.lc.ehu.es Universidad del País Vasco | mailto:jmas@FreeBSD.org Dpto. de Electricidad y Electrónica | http://www.we.lc.ehu.es/~jose Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-946013071 ----------------------------------------------------------------------- "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message