Prev: x86 rwsem optimization extreme
Next: [RFC PATCH 0/1] input/touchscreen: Synaptics Touchscreen Driver
From: H. Peter Anvin on 17 Feb 2010 17:40
On 02/17/2010 03:42 AM, Luca Barbieri wrote:
> No known CPU should have this combination, and future ones are very
> unlikely to.
>
> However, should this happen, we would generate working but non-atomic
> code, so panic instead.
> ---
> arch/x86/lib/atomic64_32.c | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/lib/atomic64_32.c b/arch/x86/lib/atomic64_32.c
> index 9ff8589..35dbd12 100644
> --- a/arch/x86/lib/atomic64_32.c
> +++ b/arch/x86/lib/atomic64_32.c
> @@ -47,6 +47,17 @@ EXPORT_SYMBOL(cx8_atomic64_inc_not_zero_cx8call);
> union generic_atomic64_lock generic_atomic64_lock[ATOMIC64_NR_LOCKS] __cacheline_aligned_in_smp;
> pure_initcall(init_generic_atomic64_lock);
>
> +static int __init panic_on_sse_without_cx8(void)
> +{
> + /* no known CPU should do this, and we generate non-atomic code in this case
> + * because we mix the generic spinlock-reliant code and the SSE code
> + */
> + if (!boot_cpu_has(X86_FEATURE_CX8) && boot_cpu_has(X86_FEATURE_XMM))
> + panic("CPUs without CX8 but with SSE are not supported\nBoot with clearcpuid=25 and report your CPU model to linux-kernel(a)vger.kernel.org\n");
> + return 0;
> +}
> +core_initcall(panic_on_sse_without_cx8);
> +
> EXPORT_SYMBOL(generic_atomic64_add);
> EXPORT_SYMBOL(generic_atomic64_add_return);
> EXPORT_SYMBOL(generic_atomic64_sub);

NAK in the extreme.

This is not how we deal with these kinds of stuff. If this really
matters, we explicitly clear the CPU feature in the feature detect code.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Yuhong Bao on 17 Feb 2010 18:10

> NAK in the extreme.
>
> This is not how we deal with these kinds of stuff. If this really
> matters, we explicitly clear the CPU feature in the feature detect code.
Also, don't forget the NT4 CX8 bug with non-Intel/AMD/Cyrix vendors:
http://www.geoffchappell.com/studies/windows/km/cpu/cx8.htm
If a processor support SSE (or PAE or MMX for that matter), you can pretty much assume CX8 exists even if the feature bit is cleared because of this bug.

Yuhong Bao

_________________________________________________________________
Hotmail: Trusted email with Microsoft�s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469226/direct/01/--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 17 Feb 2010 18:50
On 02/17/2010 03:00 PM, Yuhong Bao wrote:
>
>> NAK in the extreme.
>>
>> This is not how we deal with these kinds of stuff. If this really
>> matters, we explicitly clear the CPU feature in the feature detect code.
> Also, don't forget the NT4 CX8 bug with non-Intel/AMD/Cyrix vendors:
> http://www.geoffchappell.com/studies/windows/km/cpu/cx8.htm
> If a processor support SSE (or PAE or MMX for that matter), you can pretty much assume CX8 exists even if the feature bit is cleared because of this bug.
>

Those kinds of things we *also* deal with by adjusting the CPU features
in the detection code.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Luca Barbieri on 17 Feb 2010 19:50
> NAK in the extreme.
>
> This is not how we deal with these kinds of stuff. �If this really
> matters, we explicitly clear the CPU feature in the feature detect code.

The rationale is that a panic will likely be reported as a a bug and
this lets us know that such CPUs exist, which we may otherwise not
hear about.
The user may bypass the panic by altering the command line.

To avoid doing the panic, we could define an artificial "CX8_XMM"
flag, set it if CX8 && XMM and use that in the alternatives code in
the previous patch; this is a bit more intrusive.

We already manually set the CX8 flag on VIA CPUs that mistakenly not
report it, so that shouldn't be a problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Yuhong Bao on 17 Feb 2010 20:20

>> Also, don't forget the NT4 CX8 bug with non-Intel/AMD/Cyrix vendors:
>> http://www.geoffchappell.com/studies/windows/km/cpu/cx8.htm
>> If a processor support SSE (or PAE or MMX for that matter), you can pretty much assume CX8 exists even if the feature bit is cleared because of this bug.
>>
>
> Those kinds of things we *also* deal with by adjusting the CPU features
> in the detection code.

And in fact, the Linux setup code already has code similar to the code used in XP to disable this NT4 workaround.

Yuhong Bao

_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2
Prev: x86 rwsem optimization extreme
Next: [RFC PATCH 0/1] input/touchscreen: Synaptics Touchscreen Driver