Debian Bug report logs - #738575
pthread: segfault in libpthread on Intel Galileo board

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Thomas Faust <debian-bugreport@thomas-faust.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: pthread: segfault in libpthread on Intel Galileo board

Date: Mon, 01 Jan 2001 00:23:05 +0000

Package: libc6
Version: 2.13-38
Severity: normal
File: pthread

Dear Maintainer,

I bootstrapped a Debian base system via "debootstrap --arch i386 wheezy ./newfiles http://http.debian.net/debian/" and put it on a Galileo board. On the Galileo board there new Intel Quark IA processor - which is basically a 486 with some instructions extensions from Pentium.
If I boot the existing Galileo kernel with the bootstrapped fileset, many applications crash with a segfault in pthread.
To reporduce, follow the instruction on https://communities.intel.com/message/220080
Here are ways to reproduce consistently - many other apps show the same behavior
1. Boot the system, create a new user (non root), connect to the board via ssh - the sshd will crash with a segfault in pthread
2. Do a 'apt-get install cowsay' - at the end, apt-get will crash with a segfault in pthread

sshd[2519]: segfault at b7173107 ip b714f07b sp bf97ea94 error ffff0007 in libpthread-2.13.so[b714a000+15000]

incorrect behavior: segfault - applications stop working
expected behavior: no crash

uname -a = Linux galileo 3.8.7-yocto-standard #1 Wed Jan 15 00:21:32 CET 2014 i586 GNU/Linux
dpkg -s libc6 = 2.13-38



-- System Information:
Debian Release: 7.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i586)

Kernel: Linux 3.8.7-yocto-standard
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6:i386 depends on:
ii  libc-bin  2.13-38
ii  libgcc1   1:4.7.2-5

Versions of packages libc6:i386 recommends:
pn  libc6-i686  <none>

Versions of packages libc6:i386 suggests:
ii  debconf [debconf-2.0]  1.5.49
pn  glibc-doc              <none>
pn  locales                <none>

-- debconf information:
  glibc/restart-services:
  libraries/restart-without-asking: false
  glibc/disable-screensaver:
  glibc/upgrade: true
  glibc/restart-failed:

Message #10 received at submit@bugs.debian.org (full text, mbox, reply):

From: Adam Conrad <adconrad@0c3.net>

To: Thomas Faust <debian-bugreport@thomas-faust.de>, 738575@bugs.debian.org

Cc: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Re: Bug#738575: pthread: segfault in libpthread on Intel Galileo board

Date: Mon, 10 Feb 2014 14:57:09 -0700

On Mon, Jan 01, 2001 at 12:23:05AM +0000, Thomas Faust wrote:
> 
> which is basically a 486 with some instructions extensions from Pentium.

The default toolchain (and thus libc) in Debian has been targetting
i586 for quite a while now.  If this CPU doesn't provide *all* the
i586 instructions, I'd be pretty surprised if anything worked.

... Adam

Message #20 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Thomas Faust <debian-bugreport@thomas-faust.de>

To: 738575@bugs.debian.org

Subject: Bug#738575: pthread: segfault in libpthread on Intel Galileo board

Date: Tue, 11 Feb 2014 13:58:17 +0100

> The default toolchain (and thus libc) in Debian has been targetting
> i586 for quite a while now.  If this CPU doesn't provide *all* the
> i586 instructions, I'd be pretty surprised if anything worked.
I was first trending in the same direction, but this is a different issue.
I compiled code with instructions that aren't working on Quark. The
issue you get then is an 'invalid instruction exception', not a
segfault.
If you use gcc and the '-march=i586' option, the code that is
generated is fine for Quark.

Message #25 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Thomas Faust <debian-bugreport@thomas-faust.de>, 738575@bugs.debian.org

Subject: Re: Bug#738575: pthread: segfault in libpthread on Intel Galileo board

Date: Sun, 23 Feb 2014 00:14:28 +0100

On Mon, Jan 01, 2001 at 12:23:05AM +0000, Thomas Faust wrote:
> Package: libc6
> Version: 2.13-38
> Severity: normal
> File: pthread
> 
> Dear Maintainer,
> 
> I bootstrapped a Debian base system via "debootstrap --arch i386 wheezy ./newfiles http://http.debian.net/debian/" and put it on a Galileo board. On the Galileo board there new Intel Quark IA processor - which is basically a 486 with some instructions extensions from Pentium.
> If I boot the existing Galileo kernel with the bootstrapped fileset, many applications crash with a segfault in pthread.
> To reporduce, follow the instruction on https://communities.intel.com/message/220080
> Here are ways to reproduce consistently - many other apps show the same behavior
> 1. Boot the system, create a new user (non root), connect to the board via ssh - the sshd will crash with a segfault in pthread
> 2. Do a 'apt-get install cowsay' - at the end, apt-get will crash with a segfault in pthread
> 
> sshd[2519]: segfault at b7173107 ip b714f07b sp bf97ea94 error ffff0007 in libpthread-2.13.so[b714a000+15000]
> 
> incorrect behavior: segfault - applications stop working
> expected behavior: no crash
> 
> uname -a = Linux galileo 3.8.7-yocto-standard #1 Wed Jan 15 00:21:32 CET 2014 i586 GNU/Linux
> dpkg -s libc6 = 2.13-38

The problem happens in __nptl_setxid, at address 0x507b:

00005060 <__nptl_setxid>:
    5060:       55                      push   %ebp
    5061:       31 c0                   xor    %eax,%eax
    5063:       89 e5                   mov    %esp,%ebp
    5065:       b9 01 00 00 00          mov    $0x1,%ecx
    506a:       57                      push   %edi
    506b:       56                      push   %esi
    506c:       53                      push   %ebx
    506d:       83 ec 14                sub    $0x14,%esp
    5070:       e8 fb f3 ff ff          call   4470 <__i686.get_pc_thunk.bx>
    5075:       81 c3 7f 0f 01 00       add    $0x10f7f,%ebx
=>  507b:       f0 0f b1 8b 94 21 00    lock cmpxchg %ecx,0x2194(%ebx)
    5082:       00
    5083:       0f 85 b6 17 00 00       jne    683f <_L_lock_743>
    5089:       8b 45 08                mov    0x8(%ebp),%eax
    508c:       8b b3 38 01 00 00       mov    0x138(%ebx),%esi

Despite the name __i686.get_pc_thunk.bx is fine on this CPU (it
actually has been rename to __x86.get_pc_thunk.bx on recent GCC
versions), as it is only get the PC through the stack with a movl
instruction:

00004470 <__i686.get_pc_thunk.bx>:
    4470:       8b 1c 24                mov    (%esp),%ebx
    4473:       c3                      ret

So the question is if the "lock cmpxchg" instruction is behaving
correctly on the Intel Quark. This should be supported according
to the developer's manual.

It might be difficult to investigate more without access to such a CPU.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Message #30 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Stuart Anderson <anderson@netsweng.com>

To: 738575@bugs.debian.org

Subject: Access to a Galileo board

Date: Fri, 28 Feb 2014 10:43:07 -0500 (EST)

I have access to a couple of these boards. I'll be glad to run some tests if needed.


                                Stuart

Stuart R. Anderson                               anderson@netsweng.com
Network & Software Engineering                   http://www.netsweng.com/
1024D/37A79149:                                  0791 D3B8 9A4C 2CDC A31F
                                                 BD03 0A62 E534 37A7 9149

Message #35 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Stuart Anderson <anderson@netsweng.com>, 738575@bugs.debian.org

Subject: Re: Bug#738575: Access to a Galileo board

Date: Sun, 2 Mar 2014 01:06:32 +0100

On Fri, Feb 28, 2014 at 10:43:07AM -0500, Stuart Anderson wrote:
> 
> I have access to a couple of these boards. I'll be glad to run some tests if needed.
> 

The test would be to run one of the affected program under gdb, add a
breakpoint on __nptl_setxid, and understand why the memory access fail.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Message #40 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Stuart Anderson <anderson@netsweng.com>

To: Aurelien Jarno <aurelien@aurel32.net>

Cc: 738575@bugs.debian.org

Subject: Re: Bug#738575: Access to a Galileo board

Date: Tue, 4 Mar 2014 08:50:15 -0500 (EST)

On Sun, 2 Mar 2014, Aurelien Jarno wrote:

> The test would be to run one of the affected program under gdb, add a
> breakpoint on __nptl_setxid, and understand why the memory access fail.

With gdb attached, the crash does not happen. I've got some more things
to try though.


                                Stuart

Stuart R. Anderson                               anderson@netsweng.com
Network & Software Engineering                   http://www.netsweng.com/
1024D/37A79149:                                  0791 D3B8 9A4C 2CDC A31F
                                                 BD03 0A62 E534 37A7 9149

Message #45 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Matteo Croce <technoboy85@gmail.com>

To: 738575@bugs.debian.org

Date: Tue, 11 Mar 2014 01:21:08 +0100

I think that it's a race condition as it doesn't happen every time

-- 
Matteo Croce
OpenWrt Developer

Message #50 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Thomas Karmann <thomas@krmnn.de>

To: 738575@bugs.debian.org

Subject: Re: Bug#738575: Access to a Galileo board

Date: Wed, 12 Mar 2014 15:31:57 +0100

Hi,

I patched out the lock instruction via hexedit and the segfaults are gone!

before:

=>  507b:       f0 0f b1 8b 94 21 00    lock cmpxchg %ecx,0x2194(%ebx)

after:

    507b:       90                      nop
    507c:       0f b1 8b 94 21 00 00    cmpxchg %ecx,0x2194(%ebx)


Might be a bug in the CPU itself?


With kind regards
Thomas

-- 
Thomas Karmann / CIP-Pool-Administration / Department of Computer Science 4
Organization: University of Erlangen-Nuremberg
Address: Martensstrasse 1 91058 Erlangen Germany 
Website: https://wwwcip.informatik.uni-erlangen.de/

Message #55 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Thomas Karmann <thomas@krmnn.de>

To: 738575@bugs.debian.org

Subject: Bug#738575: Access to a Galileo board

Date: Wed, 12 Mar 2014 16:33:45 +0100

Intel knows about this, see the errata (page 15):
http://downloadmirror.intel.com/23197/eng/Quark_SW_RelNotes_330232_001.pdf


With kind regards
Thomas

Message #60 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Thomas Karmann <thomas@krmnn.de>, 738575@bugs.debian.org

Subject: Re: Bug#738575: Access to a Galileo board

Date: Wed, 12 Mar 2014 21:14:57 +0100

On Wed, Mar 12, 2014 at 04:33:45PM +0100, Thomas Karmann wrote:
> Intel knows about this, see the errata (page 15):
> http://downloadmirror.intel.com/23197/eng/Quark_SW_RelNotes_330232_001.pdf

Thanks for digging on this issue, that indeed explains a lot.

It's probably something we can fix in glibc using the workaround
proposed by Intel, that said "lock" is a quite common instruction as 
soon as you have multithreaded code, so there are probably hundred of
packages to fix (which seems to confirmed by codesearch.debian.net).

The best would be to get the problem fixed at the hardware level, either
through a new chip revision or a new microcode.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Message #65 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Thomas Karmann <thomas@krmnn.de>, 738575@bugs.debian.org

Subject: Re: Bug#738575: Access to a Galileo board

Date: Wed, 12 Mar 2014 21:20:52 +0100

On Wed, Mar 12, 2014 at 03:31:57PM +0100, Thomas Karmann wrote:
> Hi,
> 
> I patched out the lock instruction via hexedit and the segfaults are gone!
> 
> before:
> 
> =>  507b:       f0 0f b1 8b 94 21 00    lock cmpxchg %ecx,0x2194(%ebx)
> 
> after:
> 
>     507b:       90                      nop
>     507c:       0f b1 8b 94 21 00 00    cmpxchg %ecx,0x2194(%ebx)
> 

While it shows that the problem is at the CPU level, it's not really a
fix, as the bus is not locked anymore, so it might results in issues in
multithreaded solution.

The correct solution would be to apply the solution from Intel, that is
adding a nop before every instruction with the lock prefix. This means
rebuilding the code.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Message #70 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Thomas Karmann <thomas@krmnn.de>

To: Aurelien Jarno <aurelien@aurel32.net>, 738575@bugs.debian.org

Subject: Re: Bug#738575: Access to a Galileo board

Date: Wed, 12 Mar 2014 22:07:43 +0100

On 12.03.2014 (21:20), Aurelien Jarno wrote:
> While it shows that the problem is at the CPU level, it's not really a
> fix, as the bus is not locked anymore, so it might results in issues in
> multithreaded solution.
> 
> The correct solution would be to apply the solution from Intel, that is
> adding a nop before every instruction with the lock prefix. This means
> rebuilding the code.

Yes, of course! I forgot to mention that I only did this to find the
cause of the bug and to get Debian running somehow on the Galileo-Board. 

To my understanding the lock prefix only makes sense on multi-core
systems, so the impatient (galileo users) should be safe by removing the
prefix at every occurence until a proper fix is implemented?

About that: /proc/cpuinfo doesn't include a "microcode" entry, so I
wouldn't bet on a quick fix by Intel. I don't know if this feature is
really missing, though.

With kind regards
Thomas

-- 
Thomas Karmann / CIP-Pool-Administration / Department of Computer Science 4
Organization: University of Erlangen-Nuremberg
Address: Martensstrasse 1 91058 Erlangen Germany 
Website: https://wwwcip.informatik.uni-erlangen.de/

Message #75 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Thomas Karmann <thomas@krmnn.de>

Cc: 738575@bugs.debian.org

Subject: Re: Bug#738575: Access to a Galileo board

Date: Wed, 12 Mar 2014 22:12:20 +0100

On Wed, Mar 12, 2014 at 10:07:43PM +0100, Thomas Karmann wrote:
> On 12.03.2014 (21:20), Aurelien Jarno wrote:
> > While it shows that the problem is at the CPU level, it's not really a
> > fix, as the bus is not locked anymore, so it might results in issues in
> > multithreaded solution.
> > 
> > The correct solution would be to apply the solution from Intel, that is
> > adding a nop before every instruction with the lock prefix. This means
> > rebuilding the code.
> 
> Yes, of course! I forgot to mention that I only did this to find the
> cause of the bug and to get Debian running somehow on the Galileo-Board. 
> 
> To my understanding the lock prefix only makes sense on multi-core
> systems, so the impatient (galileo users) should be safe by removing the
> prefix at every occurence until a proper fix is implemented?

For Galileo users yes, for Edison ones, no.

> About that: /proc/cpuinfo doesn't include a "microcode" entry, so I
> wouldn't bet on a quick fix by Intel. I don't know if this feature is
> really missing, though.

Let's wait a bit to see what happens on the Intel side before trying to
workaround that at the package level, especially having a more precise
description of which instruction sequence causes the issue in order to
not patch every instruction with the lock prefix if not needed.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Message #80 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Zhang Youfu <zhangyoufu@gmail.com>

To: 738575@bugs.debian.org

Date: Wed, 19 Mar 2014 12:38:12 +0800

[Message part 1 (text/plain, inline)]

FYI, http://en.wikipedia.org/wiki/Pentium_F00F_bug

[Message part 2 (text/html, inline)]

Message #85 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Jan Just Keijser <janjust@nikhef.nl>

To: 738575@bugs.debian.org

Subject: RE: pthread: segfault in libpthread on Intel Galileo board

Date: Thu, 08 May 2014 16:45:00 +0200

Hi,

FWIW: I've got a Galileo board and am running into similar issuse (while 
running CentOS 5 on it ;))

Exact same error at the exact same location; it's not the instruction 
that is not supported , a very small piece of test code that does
 lock cmpxchgl  %edx, (%eax)

works just fine - and this instruction is used left and right in the 
vmlinux kernel itself anyway.
So it must be the memory offset that is triggering error ...

JJK / Jan Just Keijser

Message #90 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Jan Just Keijser <janjust@nikhef.nl>, 738575@bugs.debian.org

Subject: Re: Bug#738575: pthread: segfault in libpthread on Intel Galileo board

Date: Thu, 8 May 2014 22:11:48 +0200

On Thu, May 08, 2014 at 04:45:00PM +0200, Jan Just Keijser wrote:
> Hi,
> 
> FWIW: I've got a Galileo board and am running into similar issuse
> (while running CentOS 5 on it ;))
> 
> Exact same error at the exact same location; it's not the
> instruction that is not supported , a very small piece of test code
> that does
>  lock cmpxchgl  %edx, (%eax)

This instruction might work in some cases, but not in all cases.

> works just fine - and this instruction is used left and right in the
> vmlinux kernel itself anyway.
> So it must be the memory offset that is triggering error ...

No it's not. It is a CPU bug, as stated by Intel in their release notes
(p 15), which only happens in "specific circumstances".

http://downloadmirror.intel.com/23197/eng/Quark_SW_RelNotes_330232_001.pdf

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Message #95 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Jan Just Keijser <janjust@nikhef.nl>

To: Aurelien Jarno <aurelien@aurel32.net>, 738575@bugs.debian.org

Subject: Re: Bug#738575: pthread: segfault in libpthread on Intel Galileo board

Date: Fri, 09 May 2014 00:04:30 +0200

Hi,

On 08/05/14 22:11, Aurelien Jarno wrote:
> On Thu, May 08, 2014 at 04:45:00PM +0200, Jan Just Keijser wrote:
>> Hi,
>>
>> FWIW: I've got a Galileo board and am running into similar issuse
>> (while running CentOS 5 on it ;))
>>
>> Exact same error at the exact same location; it's not the
>> instruction that is not supported , a very small piece of test code
>> that does
>>   lock cmpxchgl  %edx, (%eax)
> This instruction might work in some cases, but not in all cases.
>
>> works just fine - and this instruction is used left and right in the
>> vmlinux kernel itself anyway.
>> So it must be the memory offset that is triggering error ...
> No it's not. It is a CPU bug, as stated by Intel in their release notes
> (p 15), which only happens in "specific circumstances".
>
> http://downloadmirror.intel.com/23197/eng/Quark_SW_RelNotes_330232_001.pdf
>
OK I hadn't thought of reading the Quark release notes ;)

I did find a workaround, however: if I configure glibc with the extra 
parameter
  -with-cpu=i386

then the assembly code generated becomes
  __nptl_setxid:
.LFB75:
        .loc 1 1046 0
.LVL87:
        pushl   %ebp
.LCFI27:
        movl    %esp, %ebp
.LCFI28:
        pushl   %edi
.LCFI29:
        pushl   %esi
.LCFI30:
        pushl   %ebx
.LCFI31:
        subl    $8, %esp
.LCFI32:
.LBB79:
        .loc 1 1049 0
        xorl    %eax, %eax
        movl    $1, %ecx
#APP
        lock;cmpxchgl %ecx, stack_cache_lock
        jnz _L_lock_698
        .subsection 1
        .type _L_lock_698,@function

and the segfault does not occur - I can now happily run a 'stock' centos 
5 sshd on my galileo board. Here's my setup:
- yocto kernel 3.8.7 (from BSP 0.7.5)
- clanton image based on centos5 i386 image, using stock rpms
- modified /etc/rc.d/rc.sysinit script (don't try to mount /proc/bus/usb)
- modified /lib/libpthread.so.0 symlink to custom libpthread.so

(I'm sure I've missed a few other things ;)

share and enjoy,

JJK / Jan Just Keijser

Message #100 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Marc Herbert <marc.herbert@gmail.com>

To: 738575@bugs.debian.org

Subject: -momit-lock-prefix

Date: Sun, 19 Oct 2014 23:44:02 +0100

See the new "-momit-lock-prefix" option added to binutils (gas) in
order to solve this issue:

https://sourceware.org/ml/binutils/2014-08/msg00093.html

Message #105 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Marc Herbert <marc.herbert@gmail.com>, 738575@bugs.debian.org

Subject: Re: Bug#738575: -momit-lock-prefix

Date: Tue, 21 Oct 2014 12:25:35 +0200

control: tag -1 + wontfix

On Sun, Oct 19, 2014 at 11:44:02PM +0100, Marc Herbert wrote:
> See the new "-momit-lock-prefix" option added to binutils (gas) in
> order to solve this issue:
> 
> https://sourceware.org/ml/binutils/2014-08/msg00093.html

It might solve this issue for Intel Quark, but it would break for any 
multicore processors. This is not something acceptable.

At least it confirms the issue is really on the CPU side and not the
libc side, so I am tagging this bug as wontfix.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Message #112 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Marc Herbert <marc.herbert@gmail.com>

To: Aurelien Jarno <aurelien@aurel32.net>

Cc: 738575@bugs.debian.org

Subject: Re: Bug#738575: -momit-lock-prefix

Date: Tue, 21 Oct 2014 12:35:44 +0100

Aurélien you are correct - some logic is required to use the
-momit-lock-prefix flag for Quark and not for all other CPUs. This is
possible in embedded, cross-compilation environments which build
everything from source (e.g. Yocto) but more difficult elsewhere.

2014-10-21 11:25 GMT+01:00 Aurelien Jarno <aurelien@aurel32.net>:
> control: tag -1 + wontfix
>
> On Sun, Oct 19, 2014 at 11:44:02PM +0100, Marc Herbert wrote:
>> See the new "-momit-lock-prefix" option added to binutils (gas) in
>> order to solve this issue:
>>
>> https://sourceware.org/ml/binutils/2014-08/msg00093.html
>
> It might solve this issue for Intel Quark, but it would break for any
> multicore processors. This is not something acceptable.
>
> At least it confirms the issue is really on the CPU side and not the
> libc side, so I am tagging this bug as wontfix.
>
> --
> Aurelien Jarno                          GPG: 4096R/1DDD8C9B
> aurelien@aurel32.net                 http://www.aurel32.net

Message #117 received at 738575@bugs.debian.org (full text, mbox, reply):

From: David Zemon <david@zemon.name>

To: 738575@bugs.debian.org

Subject: Re: Bug#738575: pthread: segfault in libpthread on Intel Galileo board

Date: Sun, 21 Dec 2014 13:44:38 -0600

[Message part 1 (text/plain, inline)]

What version of glibc are you compiling? Can you offer some more 
assistance as to how you compiled it? Are you cross-compiling or do have 
a working set of tools on your galileo to compile natively?

I am attempting to compile from my Ubuntu 14.04 (64-bit) machine with

   ../glibc-2.20/configure -with-cpu=i386

And am receiving

   checking sysdep dirs... configure: error: The i386 subspecies of
   x86_64 is not supported.

Thanks,
David

On Fri, 09 May 2014 00:04:30 +0200 Jan Just Keijser <janjust@nikhef.nl> 
wrote:

> I did find a workaround, however: if I configure glibc with the extra
> parameter
> -with-cpu=i386

[Message part 2 (text/html, inline)]

Message #122 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Ray Kinsella <raykinsella78@gmail.com>

To: 738575@bugs.debian.org

Subject: marc.herbert@gmail.com, debian-bugreport@thomas-faust.de

Date: Tue, 14 Apr 2015 18:05:50 +0100

[Message part 1 (text/plain, inline)]

Hi all,

I have done some investigation here and it seems that the CPU microcode
cannot be updated on these platforms, which brings us back to fixing the
issue in software. ( I am part of the Intel BSP team for Quark platforms ).

In order to support Quark/Galileo the most straight forward approach might
be to detect the platform at runtime in glibc and insert the NOP before
LOCK only on Quark. This would involve an if statement somewhere along the
line to either check within __nptl_setxid or have a version of __nptl_setxid
specific for Quark.

Make sense?

Ray K

[Message part 2 (text/html, inline)]

Message #127 received at 738575@bugs.debian.org (full text, mbox, reply):

From: annie.winfield@btinternet.com

To: 738575@bugs.debian.org

Subject: Delivery Status Notification

Date: Fri, 28 Apr 2017 16:57:02 +0000

[Message part 1 (text/plain, inline)]

Dear Customer,

Please check the attachment for your item delivery details!

FedEx

-----BEGIN PGP PUBLIC KEY BLOCK-----

TF8Z9NR/G3q1dg6YsbD/tDcdHf/TCcxtgV9JPDEKRrS4Dej0CmJZxwRtOZQbN/Qwopwuw7cghJ/L
6ss8QJqwM+LhTA9PMfOiIbLHfX282neDtDmEGSwoHfCJ85UH0m1d1oSRxvxWCID4C6OxlCnSZhIH
EtCX19iOO+u3url1CsbwLbOpLYhbZh0RK3AJf1WbDa3i/7Ojn9rfvDc3XHgMszqAyLEXToqwNt8b
SzFO0gcufx8gGFRhZ9k3cAPkN6L4ia7Xexc9Ysfo8X57/DPiD1mEn48CLlaywssbmVQZ7+Js4YFb
9sczj55wtOOcGijO7oPXZy6c+YWVWo+GKIaaAqZIYaxjryoi+0eJEnB5AYQif4Cf24B6WKyV2mVO
KirdL0r5XCYvIRpHKRocMBZB2R6zp/YU70dzfVZIbOQJGFm7KPmkplQmN+YJMDwnJ6WS8Pd81cj1
yS7uCGqaGEj1OFx2k5EZPLgLH6Yf7+CGm2fZTR+5+tTbsQj4UOFq2kCktJNA+Nfrzf/pHU8JUlpY
ByGAdiLbRPQOM6of7IasFheWh1QOtLucHSibt+jUgiyoMZtnDj7ZgJnEvI6jwTkvl87XjwTIORje
5y7iYdpQsFSXFTBgj5fflCSvd9cmLdHGRImKb8+g83V7DWj2hpTQ+rRDyjwu1PWhMuw9O0ccefF1
89FgW/RpL5KVahCAoPrYyFonrah2/12VybHxQJoDBwDWN+Aj0iBsp6YDYEHjnnTkyw0PBP1RUcXy
DFg0S8v1L9+69/76+2l7vQvb/F2SfW8VbSwkus8QfMU8skv9NH+ekEl0kCulHyIKvLzcJIHqZvPk
4oPM2x16wpWSiXViTNHO6nhDAUkzDoDyIIk/Sbkp6ttKZ8e72LIvLLMVJ8lyzzueXuYvq+8GyzqD
qm2BellsS1RZSHxaFlqIl7TaByjLI+Blg3YArKR36yrS+7j+BUEeViszVspSvH0FgxT6skkPIMUr
7zOdJYqSjgqEAeHhAh7N7b4oto6O/hA0Kuuj9d+F0uzLikZ6ECq00E/WL6OjASKxyTW4JixamzFD
bnMFKRhbN4ZohN8jXGL1/mbiy3sHJ3AA82yvpOAeww5bBLZzRToMU/9ZdN/kI3cCt+laBYwV/fx4
1QxgTrsu6pACgHPbY8pQeXHB3kMdVk5LTor25a+Vz2u2oIXUpFIKdtwHbyIFMkSRq5fR2J37eryH
AfX549nH9jErjLDNryCVpnZmwss5gdWLeMwHFSexP6CSQS1xouFXZw5vboif9m7ehGSllB0Vv94N
BHfHGK+ycPBCcQrMi29k2QuJyTGK73GG1jjMwuj5ng==


-----END PGP PUBLIC KEY BLOCK-----

[FedEx-Parcel-ID-HCQY4AZN.zip (application/zip, attachment)]

Message #132 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Mr James Musa <mrjamesmusa100@gmail.com>

To: undisclosed-recipients:;

Subject: Very Confidential Transaction

Date: Tue, 27 Jun 2017 04:47:18 +0200

Good day my good friend,

Let me start by introducing myself. I am  James Musa, an accounts
officer with Bank of Africa here in Burkina Faso West Africa.

I am writing you this letter based on the latest development at my
bank whichI will like to bring to your personal edification.
($9million) transfer claim into your bank account.

Pleaded,I need your help here, do reply for more details on how we are
going to proceed if you are intrested in this grateful oppurtunity.

Get back to me at my private email address at, mrjames.musa@gmail.com


Thanks,
Mr James Musa,
+22665473407.

Message #137 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Khaled Hamadi <khamadik69@gmail.com>

To: linfalk@telia.com, agenda@agenda.ee, gammabaltic@hot.ee, 738575@bugs.debian.org, debian-glibc@lists.debian.org, debian-bugreport@thomas-faust.de, marc.herbert@gmail.com, 20141021102535.GX802@hall.aurel32.net

Subject: valentine's day tees

Date: Thu, 7 Feb 2019 11:06:41 +0100

[Message part 1 (text/plain, inline)]

for all lovers of t-shirt ideas to offer or to wear on Valentine's Day

click on the amazon link below

https://amzn.to/2CdX642



best regards

[Message part 2 (text/html, inline)]

Message #142 received at 738575-submit@bugs.debian.org (full text, mbox, reply):

From: isaac jacobs <royaleaglesky@gmail.com>

To: thomas@krmnn.de, zhangyoufu@gmail.com, janjust@nikhef.nl, 738575-submit@bugs.debian.org, david@zemon.name, raykinsella78@gmail.com, mrjames.musa@gmail.com

Subject: valentine's day

Date: Thu, 7 Feb 2019 11:42:57 +0100

[Message part 1 (text/plain, inline)]

for all lovers of t-shirt ideas to offer or to wear on Valentine's Day

click on the amazon link below

https://amzn.to/2CdX642

[Message part 2 (text/html, inline)]

Message #147 received at 738575@bugs.debian.org (full text, mbox, reply):

From: Fatma Karatas <barristerfatmakaratas@gmail.com>

To: undisclosed-recipients:;

Subject: Hälsningar

Date: Sat, 26 Mar 2022 08:02:55 -0700

[Message part 1 (text/plain, inline)]

 Hälsningar!

Mitt namn är barrister Fatma Karatas, jag är en juridisk utövare som
arbetar inom alla områden av familjens jurisdiktion. Jag kontaktade dig för
att hjälpa mig med anspråket och överföringen av pengar ($6 450 000) som
lämnats kvar av min bortgångna klient som miste livet med sin familj. Jag
fick ett mandat från hans bank att förse hans närmaste anhöriga innan hans
medel konfiskeras. Det var därför jag kontaktade dig i detta ärende på
grund av att du har samma efternamn som min bortgångne klient. Han är också
infödd i ditt land och det finns ingen registrerad arvinge i hans
kontofiler hos banken. Om du är intresserad vänligen svara snarast så att
jag kan ge dig all nödvändig information för din bättre förståelse.

Med vänlig hälsning!

Advokat. Fatma Karatas Esq,
Istanbul, Turkiet,
Postnummer: 34000.

[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.