From: garbanzo AT hooked DOT net (Alex) Subject: Re: Newest Pentium bug (fatal) (fwd) 9 Nov 1997 14:59:11 -0800 Message-ID: Reply-To: Alex Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 To: Robert Eckardt 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 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".