From owner-freebsd-hardware Wed Jan 26 3:25:50 2000 Delivered-To: freebsd-hardware@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 124D8151FC for ; Wed, 26 Jan 2000 03:25:47 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (qmail 27717 invoked from network); 26 Jan 2000 11:25:43 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 26 Jan 2000 11:25:43 -0000 Date: Wed, 26 Jan 2000 22:25:40 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: "Jose M. Alcaide" Cc: freebsd-hardware@FreeBSD.ORG Subject: Re: RTC (stat clock) does not generate interrupts ?!?! In-Reply-To: <388EC68B.7CEC90AC@we.lc.ehu.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 26 Jan 2000, Jose M. Alcaide wrote: > Definitely, the Dell Inspiron 3700 C433GT is one of those machines > that have a broken statclock. I would like to know what does this mean, > but, anyway, these are the facts. Rats. It meant that statclock interrupts woke up the system, so the system couldn't stay suspended if the statclock were used. Nohing to do with your problem. > Then, for "solving" the suspend problems, the apm device must be > compiled with flags 0x20, as stated in LINT. > > I don't know what are the consequences of the missing statclock for > the system. I suppose that profiling won't work, but... any more effects? Decomposition of time into user/nice/system/interrupt/idle components will be less accurate. Unfair processes will have an easier time implementing unfair scheduling. Resource usage statistics will be less accurate. Profiling will work but will be less accurate. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message