Date: Mon, 10 Nov 1997 03:11:40 -0600 (CST) From: Jim Bryant <jbryant@unix.tfs.net> To: tlambert@primenet.com (Terry Lambert) Cc: freebsd-hackers@freebsd.org Subject: Re: Newest Pentium bug (fatal) Message-ID: <199711100911.DAA07810@argus.tfs.net> In-Reply-To: <199711100737.AAA10415@usr06.primenet.com> from Terry Lambert at "Nov 10, 97 07:37:17 am"
next in thread | previous in thread | raw e-mail | index | archive | help
In reply: > > 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". where do you see this? what page? defintely not in the "Instruction Set" chapter [chapter 25]... p 25-72: "Operation if edx:eax = dest zf <- 1 dest <- ecx:ebx else zf <- 0 edx:eax <- dest" p 25-73: "Notes This instruction can be used with the LOCK prefix. In order to simplify interface to the processor's bus, the destination operand receives a write cycle without regard to the result of the comparison. DEST is written back if the comparison fails, and SRC is written into the destination otherwise. (The processor never produces a locked read without also producing a locked write.)" > 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. the 0C8h r/m byte specifies the proper extended regs... > I can verify that using non-extended registers doesn't crash. if the backwards compatable 32-bit instruction CMPXCHG was buggy we would have found out about this a long time ago... intel was obviously betting that things would remain 486 backwards compatable for the market lifetime of the pentium. they had to have tested this very early in the production cycle or late in the tooling process. if i'm right about a coverup, it must have been a good one, so good that they put it into the MMX. > 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. hmmmmmm.... just so we are talking apples <-> apples, i am referencing intel's "Pentium(R) Processor Family Developer's Manual, Volume 3: Archetecture and Programming Manual", ISBN 1-55512-247-7, (c) 1995, order number 241430-004. covering the 1110/133, 1000/120, 815/100, 735/90, and 615/75 cpus. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711100911.DAA07810>