delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1997/11/09/14:59:11

From: garbanzo AT hooked DOT net (Alex)
Subject: Re: Newest Pentium bug (fatal) (fwd)
9 Nov 1997 14:59:11 -0800 :
Message-ID: <Pine.BSF.3.96.971109143538.3963H-100000.cygnus.gnu-win32@zippy.dyn.ml.org>
Reply-To: Alex <garbanzo AT hooked DOT net>
Mime-Version: 1.0
To: gnu-win32 AT cygnus DOT com

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 <julian AT whistle DOT com>
To: Robert Eckardt <roberte AT MEP DOT Ruhr-Uni-Bochum DOT de>
Cc: dec AT phoenix DOT its DOT rpi DOT edu, hackers AT FreeBSD DOT ORG
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 sef AT Kithrup DOT COM Sun Nov  9 14:37:01 1997
Date: Fri, 7 Nov 1997 12:41:49 -0800 (PST)
From: Sean Eric Fagan <sef AT Kithrup DOT COM>
Reply-To: hackers AT FreeBSD DOT ORG
To: hackers AT FreeBSD DOT ORG
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
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019