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)" <sowadski@umr.edu> 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/
This archive was generated by hypermail 2b29 : Sun Feb 23 2003 - 22:00:26 EST