From owner-freebsd-hackers  Fri Nov  7 12:41:53 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA21913
          for hackers-outgoing; Fri, 7 Nov 1997 12:41:53 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from kithrup.com (kithrup.com [205.179.156.40])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA21908
          for <hackers@freebsd.org>; Fri, 7 Nov 1997 12:41:50 -0800 (PST)
          (envelope-from sef@Kithrup.COM)
Received: (from sef@localhost) by kithrup.com (8.8.5/8.6.6) id MAA05816; Fri, 7 Nov 1997 12:41:49 -0800 (PST)
Date: Fri, 7 Nov 1997 12:41:49 -0800 (PST)
From: Sean Eric Fagan <sef@Kithrup.COM>
Message-Id: <199711072041.MAA05816@kithrup.com>
To: hackers@freebsd.org
Reply-To: hackers@freebsd.org
Subject: Re: Newest Pentium bug (fatal)
References: <3463605C.41C67EA6@whistle.com>
Organization: Kithrup Enterprises, Ltd.
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Fri, 7 Nov 1997, Julian Elischer wrote:
> On a "genuine Intel" pentium (not pentium pro)
> execution of the following sequence, 0xf0 0x0f 0xc7 0xc8
> 

This disassembled into a "lock cmpxchg8b %eax", according to gdb.

I sent a note to Robert Collins, who is the x86.org guy who pops up in the
news periodically when Intel tries to hassle him.  He says:

	Actually, I've known about it for a few months.  I verified
	it back then.  It's a real bug.  The bug occurs when you
	do two illegal things at once:
	1) use the invalid opcode cmpxchg8b EAX
	2) put a lock prefix on a non-read/modify/write instruction.

	Both conditions are already illegal.  However instead of
	generating an invalid opcode exception, the processor locks
	up.

Based on a later message on the list I just saw, it looks like Intel cleared
this up in newer versions of the processor.