From owner-freebsd-hackers Tue Mar 5 15:12:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA05032 for hackers-outgoing; Tue, 5 Mar 1996 15:12:28 -0800 (PST) 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 PAA05016 Tue, 5 Mar 1996 15:12:16 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA09368; Tue, 5 Mar 1996 16:08:28 -0700 From: Terry Lambert Message-Id: <199603052308.QAA09368@phaeton.artisoft.com> Subject: Re: Triton-II support... when? To: mikebo@tellabs.com Date: Tue, 5 Mar 1996 16:08:28 -0700 (MST) Cc: terry@lambert.org, mikebo@eagle.safetynet.net, questions@freebsd.org, hackers@freebsd.org In-Reply-To: <199603052144.PAA02531@sunc210.tellabs.com> from "mikebo@tellabs.com" at Mar 5, 96 03:44:06 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-hackers@freebsd.org Precedence: bulk > > > o Will FreeBSD 2.1-RELEASE boot/run on Triton-II main boards as-is? > > > > Will FreeBSD 2.1-RELEASE boot/run on a P5 without the floating point > > bug? The question is basically a non-sequitur -- there is no function > > difference in the chipsets except the Triton-II happens to work. > > > Are a lot of people running FreeBSD with their Level-2 caches off? Not "off"; with writeback disabled (pick "write through in BIOS CMOS, I believe). > As I understand it, there are much more profound changes than simply > one bug fix. I've been told that Triton-II: > o fixes a write-back cache bug > o nominally speeds all memory accesses ~5% These two ar the same thing. > o adds support for concurrent PCI/ISA bus accesses Who uses ISA cards? > o adds support for multi-processing Assuming it's an MP motherboard, Triton I ought to do the same thing. > o adds support for ECC memory Still no parity, eh? 8-). > Seems like a *lot* more functionality than can be accounted for by a > simple bug fix, no? Perhaps Terry means Triton-II implements a superset > of Triton-I functionality (plus the cache bug fix) so there's no reason > existing kernel code would break? That's great... I thought perhaps > there was more purpose to the chipset sensing code in > /usr/src/sys/pci/pcisupport.c . I don't think bridge chipsets are programmed-to anyway. It's not like it can't run ing SMP spec virtual wire mode or has its own APIC. The sensing code is there for timers for ISA controller emulation, so at most it's a single line change (and that code is mostly to make the console speaker driver happy, AFAICT). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.