From owner-freebsd-questions Tue May 14 08:21:58 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA17346 for questions-outgoing; Tue, 14 May 1996 08:21:58 -0700 (PDT) Received: from r2d2.sci.fi (r2d2.sci.fi [194.215.80.6]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA17322 for ; Tue, 14 May 1996 08:21:49 -0700 (PDT) Received: from sci.fi (vuori@borg [194.215.80.5]) by r2d2.sci.fi (8.6.12/8.6.11) with ESMTP id SAA14277 for ; Tue, 14 May 1996 18:21:39 +0300 Received: (vuori@localhost) by sci.fi (8.6.12/8.6.4) id SAA14319; Tue, 14 May 1996 18:21:38 +0300 Date: Tue, 14 May 1996 18:21:37 +0300 (EET DST) From: Valtteri Vuorikoski X-Sender: vuori@borg To: freebsd-questions@freebsd.org Subject: CMOS checksum brokedness and turbo being switched off Message-ID: Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. -- 'Good-bye and hello, as always'