From owner-freebsd-hackers  Sun Nov  9 23:37:31 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA10572
          for hackers-outgoing; Sun, 9 Nov 1997 23:37:31 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA10566
          for <freebsd-hackers@FreeBSD.ORG>; Sun, 9 Nov 1997 23:37:28 -0800 (PST)
          (envelope-from tlambert@usr06.primenet.com)
Received: (from daemon@localhost)
	by smtp04.primenet.com (8.8.7/8.8.7) id AAA18769;
	Mon, 10 Nov 1997 00:37:27 -0700 (MST)
Received: from usr06.primenet.com(206.165.6.206)
 via SMTP by smtp04.primenet.com, id smtpd018762; Mon Nov 10 00:37:20 1997
Received: (from tlambert@localhost)
	by usr06.primenet.com (8.8.5/8.8.5) id AAA10415;
	Mon, 10 Nov 1997 00:37:17 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199711100737.AAA10415@usr06.primenet.com>
Subject: Re: Newest Pentium bug (fatal)
To: jbryant@tfs.net
Date: Mon, 10 Nov 1997 07:37:17 +0000 (GMT)
Cc: plm@xs4all.nl, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <199711100650.AAA07487@argus.tfs.net> from "Jim Bryant" at Nov 10, 97 00:50:40 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> LOCK	CMPXCHG8B	EDX:EAX, ECX:EBX  ; crash...  pp 25-72 to
>                                           ; 25-73 of intel's arch & prog
>                                           ; manual for the pentium

The same manual states that the CMPXCHG8B asserts a "#LOCK" signal, as
does the "#LOCK" command.  Also some paging situations, and "XCHG".

It looks to me like they took the 486 macrocell, and extended it (easiest
way to get binary compatability), and "forgot" the new registers when
implementing the "#LOCK" assert test.

I can verify that using non-extended registers doesn't crash.

As someone else noticed, ther emay also be a cache fetch interaction
(page fault was another thing referenced by #LOCK).

Clearly, it's self-deadlocking trying to assert #LOCK.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.