On Monday 22 April 2013, Wolfram Gloger wrote:
> Hi,
>
> >Yeah, I was thinking of asking my old contacts about it but it is simply
> >not worth it. Those CPUs are on their way to the museum if they're not
> >there already.
>
> I have a perfectly running K6 system (the legendary K6-III I believe),
>
Hi,
>Yeah, I was thinking of asking my old contacts about it but it is simply
>not worth it. Those CPUs are on their way to the museum if they're not
>there already.
I have a perfectly running K6 system (the legendary K6-III I believe),
though I am about to have it taken to recycling.
If you want
On Sun, Apr 21, 2013 at 03:35:41PM -0700, H. Peter Anvin wrote:
> Looks like it is just trying to sense the bug... but then it doesn't
> actually do anything about it. At least it should taint the kernel.
Yeah, I was thinking of asking my old contacts about it but it is simply
not worth it. Those
On 04/21/2013 10:44 AM, Borislav Petkov wrote:
>
> But I have hard time understanding what that test with the 10^6 loop
> iterations is supposed to achieve. And what makes sure that the RDTSCs
> don't get reordered? Or maybe K6 wasn't reordering that aggressively...
>
> Erratum says "unpredictabl
On Sun, Apr 21, 2013 at 10:06:58AM -0700, H. Peter Anvin wrote:
> On 04/21/2013 09:49 AM, Andi Kleen wrote:
> > From: Andi Kleen
> >
> > The AMD K6 errata check relies on timing a indirect call.
> > But the way it was written it could be optimized to a direct call.
> > Force gcc to actually do a
> Maybe it would be even better to just code the indirect call instruction
> in assembly?
I only have the simple low risk fix to offer. If you want something
gold plated you have to do/test it yourself.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On 04/21/2013 09:49 AM, Andi Kleen wrote:
> From: Andi Kleen
>
> The AMD K6 errata check relies on timing a indirect call.
> But the way it was written it could be optimized to a direct call.
> Force gcc to actually do a indirect call and not just
> constant resolve the target address.
>
> Found
From: Andi Kleen
The AMD K6 errata check relies on timing a indirect call.
But the way it was written it could be optimized to a direct call.
Force gcc to actually do a indirect call and not just
constant resolve the target address.
Found during code review, no runtime testing due to lack
of har
> Would be useful to read in the changelog about how you found the bug:
>
> - saw miscalculated values and figured out the reason
> - saw a new warning in GCC
> - saw it during review
>
> ?
Saw it during code review when I was fixing the code for LTO.
I don't have a K6 anymore, but I still ha
* Andi Kleen wrote:
> From: Andi Kleen
>
> The AMD K6 errata check relies on timing a indirect call.
> But the way it was written it could be optimized to a direct call.
> Force gcc to actually do a indirect call and not just
> constant resolve the target address.
>
> Signed-off-by: Andi Klee
From: Andi Kleen
The AMD K6 errata check relies on timing a indirect call.
But the way it was written it could be optimized to a direct call.
Force gcc to actually do a indirect call and not just
constant resolve the target address.
Signed-off-by: Andi Kleen
diff --git a/arch/x86/kernel/cpu/am
11 matches
Mail list logo
