From owner-freebsd-hardware Thu Aug 28 10:01:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA09525 for hardware-outgoing; Thu, 28 Aug 1997 10:01:07 -0700 (PDT) Received: from dragon.awen.com (dragon.awen.com [207.33.155.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA09520 for ; Thu, 28 Aug 1997 10:01:00 -0700 (PDT) Received: from cmnsens (cmnsens.awen.com [207.33.155.2]) by dragon.awen.com (8.8.7/8.8.6) with SMTP id KAA16401 for ; Thu, 28 Aug 1997 10:00:40 -0700 (PDT) Message-Id: <199708281700.KAA16401@dragon.awen.com> From: "Mike Burgett" To: "hardware@freebsd.org" Date: Thu, 28 Aug 97 10:00:39 -0700 Reply-To: "Mike Burgett" Priority: Normal X-Mailer: PMMail 1.92 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Fwd: K6 Linux Re-Compile Issue Sender: owner-freebsd-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk FWIW, I just got the following from AMD tech support, regarding the problems I had reported with my initial K6 and running 'make world' ==================BEGIN FORWARDED MESSAGE================== >Date: Thu, 28 Aug 1997 08:47:35 -0700 >From: AMD Tech Support >Organization: AMD Tech Hotline >Subject: K6 Linux Re-Compile Issue Hello, AMD recently received reports from a limited number of users having intermittent problems while running core re-compiles of the Linux shareware operating system. Our systems engineering group has duplicated the observation and determined that it is related to a previously know erratum. Full technical details of this erratum are documented in section 2.6.2 of the AMD-K6 MMX Enhanced Processor Revision Guide posted on our website, www.amd.com. Users that feel they are being affected by this problem, should contact AMD s support line at (408) 749-3060 and ask for Dan Hingle or Glen Garcia. Regards, Technical Support ===================END FORWARDED MESSAGE=================== Here's the section of the errata that they apparently didn't feel like appending: 2.6.2 Re-execution of Instructions Due to Self-Modifying Code Products Affected. B stepping Normal Specified Operation. If the processor detects a potential self-modifying code condition, the processor performs specific internal actions to ensure that instruction execution occurs in the correct manner. Non-conformance. If: - The target of a transfer control instruction is fetched and loaded into the processor s Branch Target Cache (BTC) - This transfer control instruction is speculatively executed and hits in the BTC - An instruction (Instruction A ) is executed that causes the processor to detect a potential self-modifying code condition relative to the transfer control target that resides in the BTC - Instruction A is followed by a register-modifying instruction(s) in the form of: A long-decoded instruction, or; One or two short-decoded instructions - The transfer control instruction that was speculatively executed follows the register-modifying instruction(s) within approximately 1-9 instructions - Certain other relative internal pipeline timing conditions must occur then: the long-decoded instruction, or the short-decoded instruction(s), is executed twice. Potential Effect on System. If software is not affected by the re-execution of the register-modifying instruction(s) for instance, loading immediate data into a general purpose register then this erratum has no effect on the system. However, if any of the instructions that are re-executed change the state of the system from the state that would be achieved by the normal specified operation for instance, incrementing a register by one then this erratum can lead to unpredictable system behavior. Suggested Workaround. None. Resolution Status. This erratum will be corrected in a future stepping of the AMD-K6 processor. --Mike