From owner-freebsd-hackers Thu Nov 13 13:46:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA24106 for hackers-outgoing; Thu, 13 Nov 1997 13:46:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from heron.doc.ic.ac.uk (rAgXTqqLR1NctZao4N5+0hSnL5yRokvn@heron.doc.ic.ac.uk [146.169.43.9]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA24100 for ; Thu, 13 Nov 1997 13:46:35 -0800 (PST) (envelope-from njs3@doc.ic.ac.uk) Received: from ash3.doc.ic.ac.uk [146.169.16.31] ([jU7dkYhn+fc4wXTaAyplmO/h6G42WOwm]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0xW774-0005ZY-00; Thu, 13 Nov 1997 21:47:46 +0000 Received: from njs3 by ash3.doc.ic.ac.uk with local (Exim 1.62 #1) id 0xW75o-00013t-00; Thu, 13 Nov 1997 21:46:28 +0000 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Thu, 13 Nov 1997 21:46:28 +0000 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hackers@freebsd.org Subject: Intel Pentium bugfix for FreeBSD Message-Id: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Someone recently suggested here (I would quote them if I hadn't inadvertantly typed "delete" then "update") that the workaround for intels latest bug may not be integrated into FreeBSD because if you wanted to crash a machine, you can do it regardless. However, most other methods for crashing a machine that I can think of require a pretty concerted effort to exhaust system resources, and are therefore relatively easily traceable. The F00F bug however, is untraceable, and therefore I feel that it should be integrated into the source tree. A kernel configuration option to turn it on/off might be useful if it has a performance impact. Or then again, maybe you should go and get a new CPU from Intel. :) Hmm there's a thought - I wonder if you would have to give the old one back, if not .. SMP here I come! Niall