Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 19 Feb 2003 14:03:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 19 Feb 2003 14:03:28 -0500 Received: from mrelay1.cc.umr.edu ([131.151.1.120]:47544 "EHLO smtp.umr.edu") by vger.kernel.org with ESMTP id convert rfc822-to-8bit; Wed, 19 Feb 2003 14:03:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: 2.4.20 amd speculative caching Date: Wed, 19 Feb 2003 13:13:28 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 2.4.20 amd speculative caching Thread-Index: AcLYP9MjR2ILod7bQuSArDT3cTtloQACUc0w From: "Sowadski, Craig Harold (UMR-Student)" To: "Andi Kleen" Cc: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1992 Lines: 61 Sorry, I didn't mean to state that the bug was in the processor. The systems consistently hard locks in any accelerated application. The mem=nopentium does not seem to help at all. Are there any dependencies that must be taken care of to implement the new fix? Also, should I be seeing any dmesg output from this new implementation? Are there any debugging techniques I could use to track the cause? (I have no log outputs due to hard lock) If it helps, here is my hardware config: AMD Duron 1300MHZ MSI K7T Turbo-2 ATI Radeon 7500 w/64mb Redhat 8.0 Thanks again for any information, Craig Sowadski (sowadski@umr.edu) -----Original Message----- From: Andi Kleen [mailto:ak@suse.de] Sent: Wednesday, February 19, 2003 11:54 AM To: Sowadski, Craig Harold (UMR-Student) Cc: linux-kernel@vger.kernel.org Subject: Re: 2.4.20 amd speculative caching "Sowadski, Craig Harold (UMR-Student)" writes: > I have recently upgraded to an AMD processor that is exhibiting the > problems with the AMD speculative caching bug. Kernel 2.4.19 seems to It's actually not an AMD bug, but an Linux bug that assumed undefined x86 behaviour to behave well. > fix the problem with the temporary work-around (adv-spec-cache patch). I > have noticed that the patch has been removed from 2.4.20 and I am > wondering if there is some other mechanism that is supposed to address > this issue. Currently I have a 2.4.20 kernel with same configuration as Yes, there is a new mechanism to address the problem the adv-spec-cache patch solved. It enforces that there are not conflicting cache attributes for memory mappings. > my 2.4.19 and the problem seems to have reappeared. What problem exactly? And does mem=nopentium help ? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/