This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Support for Intel X1000
- From: Rich Felker <dalias at libc dot org>
- To: "Kinsella, Ray" <ray dot kinsella at intel dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "carlos at redhat dot com" <carlos at redhat dot com>
- Date: Tue, 12 May 2015 10:04:32 -0400
- Subject: Re: Support for Intel X1000
- Authentication-results: sourceware.org; auth=none
- References: <1431426490 dot 3246 dot 29 dot camel at intel dot com>
On Tue, May 12, 2015 at 10:28:11AM +0000, Kinsella, Ray wrote:
> Hi all,
>
> The Intel X1000 (32bit Pentium ISA) has a bug on the LOCK prefix,
> that cannot be fixed with an updated microcode and cannot be worked
> around by trapping elsewhere (in the Linux Kernel). This bug results in
> segfaults anywhere LOCK prefix has been used (lowlevel locks, atomics
> etc)
>
> The only workable solution is the following steps:-
>
> 1. Not using the LOCK prefix on the Intel X1000. This can be achieved
> either by defining UP (uniprocessor) or telling the assembler to omit
> the LOCK prefix "momit-lock-prefix=yes".
>
> 2. OS builders creating a UP version of glibc targeted for the X1000.
> The runtime linker then decides which glibc to load based on a HWCAP,
> in a similar way to how the Xen specific glibc is loaded.
>
> Clearly no changes are needed to glibc for this - as it already provides
> a UP build, however I wanted to socialize the approach to fixing the
> issue
> for comments here. Relevant patches will land with:-
>
> 1. The OS - LKML for the Linux Kernel to indicate a HWCAP for the
> broken LOCK prefix on X1000.
> 2. The OS Builders - Debian and others to build a version of glibc
> specifically to work around this issue and put there library where
> the runtime linker can find it.
>
> Feedback is welcome.
Since you asked for feedback, my feedback is that Intel needs to
recall this CPU model and replace all affected units.
Rich