From owner-freebsd-hardware Tue Sep 24 01:17:26 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA14053 for hardware-outgoing; Tue, 24 Sep 1996 01:17:26 -0700 (PDT) Received: from vector.jhs.no_domain (slip139-92-42-59.ut.nl.ibm.net [139.92.42.59]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA13936; Tue, 24 Sep 1996 01:16:58 -0700 (PDT) Received: (from jhs@localhost) by vector.jhs.no_domain (8.7.5/8.6.9) id AAA11775; Tue, 24 Sep 1996 00:18:59 +0200 (MET DST) Date: Tue, 24 Sep 1996 00:18:59 +0200 (MET DST) Message-Id: <199609232218.AAA11775@vector.jhs.no_domain> To: hardware@freebsd.org cc: gj@freebsd.org Subject: cache size in cmos From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" Organization: Vector Systems Ltd. Mailer: EXMH 1.6.7, PGP available X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Phone: +49.89.268616 X-Fax: +49.89.2608126 X-Web: http://www.freebsd.org/~jhs/ Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is sent: To: hardware@freebsd.org bcc: doc@freebsd.org I had an experience with an old AMD BIOS that seems worth telling... The lesson I learned: If a machine seems really slow, try reloading cmos defaults, (after taking careful note of current settings :-) Someone might want to put that tip in the currently empty (as of Sep 1) section 10.3.4 of the handbook. Hence I bcc'd this to doc@ , but suggest follow up on just hardware@ Why the CMOS Reset ? Well ... I had a hardware problem on a newish (to me) system built from old motherboard, old discs etc, & with loose cache chips, I took cache chips out & I guess I ran that system without to deduce if it was the chips causing my previous problem, anyway I cured the cache chip loose socket problem, But I think the cmos resized itself as having no cache (it doesnt show cache chip availability on my old AMD BIOS, I just have the M/board DIPS to set), & when I put the cache chips back in, the system worked, but was slow as treacle, (but I didnt notice as I was chasing other problems on the system, (like synch/asynch on old HP drives, & data corruption). It also, (after the last surgery on board, & until today) used to ignore the turbo switch (which actually acts not as a frequency controller, but as a cache enable/disable switch), & the `spinner' at kernel load time didnt spin, it trudged along slowly. I decided to track down the `treacle' today, I finally (at power time) told it (the AMD bios from DEL) to reload power (slow) defaults & then bios (faster) defaults, It used to take 120 secs to do cd usr/src/*/ls ; make it now takes turbo on 19.20 real 16.66 user 1.71 sys turbo off 51.48 real 45.97 user 4.51 sys the above with sh & then time, & 2nd compile, 'cos 1st loads stuff into freebsd kernel cache (ie disc to ram) so 1st is always slower than #2 & #3 make. Oh, BTW I had to disable F000 64K cache else reboot ceased to work. (The reload with BIOS defaults had enabled it) The environment 33MHz Intel 486 Motherboard `Gigabyte' `GA-486US' 256K cache. UM82C481A, USA, 9140KV016 UM82C482A, USA, 9138KV001 UM82C206F, 9142-C9, C82093 Copyright American Megatrends Inc., 40-0500-D91199-00101111-050591-UMCWB-F various CLK/2 & CLK/5 madse no real difference, A half week old current that had just finished make world (took about half a week or so (Really ! that's why I investigated)) & kernel that reports FreeBSD 2.2-CURRENT #0: Fri Sep 13 22:38:55 MSZ 1996 jhs@vector:/usr2/src/cur-960901/sys/compile/GATE & with an /etc/make.conf CFLAGS= -O2 -m486 -pipe & cc --version 2.6.3 System idle other than test running. Well, that system is 6 times faster now :-) If this tale has merely amused you, it's been worth it, the more so if it digs someone out of a similar hole. Julian --- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/