Subject: Re: Newest Pentium bug (fatal) (fwd)
From: [email-masked] (Alex)

9 Nov 1997 14:59:11 -0800
Message-ID: <[email-masked]>
Reply-To: Alex <[email-masked]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
To: [email-masked]

Here's the two best descriptions of the problems, that should probably
answer nearly all of your questions.

---------- Forwarded message ----------
Date: Sat, 08 Nov 1997 12:56:21 -0800
From: Julian Elischer <[email-masked]>
To: Robert Eckardt <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Newest Pentium bug (fatal)

Robert Eckardt wrote:
> 
>
> 
> Let denote "C" compilation with TC,
>            "1" a full crash (i.e. no reaction at all),
>            "0" Numlock and Ctrl-Alt-Del work,
>            "c" cold boot,
>            "w" warm boot.
> Then I found the wollowing pattern:   C 1 c 0 w 0 w... C 1 c 0 w 0 w
> 
> It seems that it depends on what is in memory.
> It crashed completely when I had used TC first.
> 
That makes sense, as the bug involes the bus-lock operation
The bus lock operation is invoked when a cache line of page TLB
operation is enacted. If a page is laready lleaded, or already in 
the instruction-cache, then it may not need to do a lock operation..
 (or maybe it's the other way around/....
if the page is NOT alreay loaded it's OK :?
anyway..
you may find that if you add "0xc3" to the end, the '0' entries go away.
---------- Forwarded message ----------

On a side note

From [email-masked] Sun Nov  9 14:37:01 1997
Date: Fri, 7 Nov 1997 12:41:49 -0800 (PST)
From: Sean Eric Fagan <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: Newest Pentium bug (fatal)
[...]
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.
---------------------------
(Alex typing now): As far as I personally have seen, this isn't the case,
and just about every P5 (not P5 OverDrive, or P6, or K6, or 6x86) is
vunerable.  Way to go Intel.

- alex

-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".