From owner-freebsd-questions Wed May 15 11:04:55 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA10047 for questions-outgoing; Wed, 15 May 1996 11:04:55 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA10039 for ; Wed, 15 May 1996 11:04:50 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA14978; Wed, 15 May 1996 11:01:48 -0700 From: Terry Lambert Message-Id: <199605151801.LAA14978@phaeton.artisoft.com> Subject: Re: CMOS checksum brokedness and turbo being switched off To: vuori@sci.fi (Valtteri Vuorikoski) Date: Wed, 15 May 1996 11:01:47 -0700 (MST) Cc: freebsd-questions@FreeBSD.ORG In-Reply-To: from "Valtteri Vuorikoski" at May 14, 96 06:21:37 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I installed FreeBSD 960501-SNAP on a 386dx/25 Nokia Mikromikko 4 m336 > (doorstop machine) (with AHA-1520, 100mb SCSI disk and some ne2k > ethernet card) a few days ago, and it's having some problems. When > it's booted, it complains that the BIOS base (639k) doesn't match the RTC > base (640k). On subsequent boots there's also a warning about incorrect > CMOS checksum from the BIOS until the CMOS is updated. When FreeBSD is > booted after just pressing F1 to resume and not fixing the CMOS checksum, > it complains about RTC diag error 2 just before running init. > > The worst thing is that the machine has a software-controlled turbo mode > and FreeBSD apparently switches it off, since it runs and benchmarks > (dhrystone) like a 8mhz 286. The BIOS shows that the speed is 'normal', > which means that it should be running at full speed. An interesting > feature is that if I change the speed, caches or such, when I boot > FreeBSD, reboot and go to setup again, things are back to defaults. > > If I boot with -c and reboot the machine while it's sitting around > waiting for configuration, cmos stays in condition. Booting at any later > phase, it breaks. > > wall_cmos_clock doesn't appear to be helpful. 2.1.0-RELEASE had the same > problem and it was being rather unstable. Sounds like your CMOS pretends it has knowledge of DST and that's what is being used for the software turbo mode. Garrett Wollman made it so you could touch a file in /etc and fix it so it would not mess with the CMOS (blowing the time information is probably what kills your checksum and blowing the DST information is probably what kills the turbo mode). FYI: it's a bad design that steals clock bits from the CMOS to use in software modes; your motherboard is violating the specs. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.