[Bug 1784583] [NEW] SIGILL on s390x in libpthread when run inside cosmic VM
Colin Ian King
1784583 at bugs.launchpad.net
Tue Jul 31 08:50:26 UTC 2018
Public bug reported:
I installed the Cosmic s390x server on an x86-64 Cosmic host using virt
manager and get a SIGILL when using libptread.
For example: I built stress-ng from the upstream git repo using:
sudo apt-get build-dep stress-ng
git clone git://kernel.ubuntu.com/cking/stress-ng
cd stress-ng
make
./stress-ng --help
[66597.487332] User process fault: interruption code 0002 ilc:2
Illegal instruction
Debugging this with gdb one can see the SIGILL occurs in libpthread:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
Program received signal SIGILL, Illegal instruction.
0x000003fffdffe71c in __kernel_getcpu ()
(gdb) where
#0 0x000003fffdffe71c in __kernel_getcpu ()
#1 0x000003fffd8699a4 in sched_getcpu ()
at ../sysdeps/unix/sysv/linux/sched_getcpu.c:32
#2 0x000002aa000ea96e in stress_get_cpu () at helper.c:1064
#3 0x000002aa000edef6 in mwc_reseed () at mwc.c:70
#4 0x000002aa000f7d5a in main (argc=1, argv=0x3fffffffb98) at stress-ng.c:3477
cat /proc/cpuinfo
vendor_id : IBM/S390
# processors : 4
bogomips per cpu: 13370.00
max thread id : 0
features : esan3 zarch stfle msa ldisp eimm etf3eh highgprs
facilities : 0 1 2 3 4 7 9 16 17 18 19 21 22 24 25 27 30 31 32 33 34 35 40 41 45 49 51 52 71 72 76 77 138
processor 0: version = 00, identification = 000000, machine = 2827
processor 1: version = 00, identification = 400000, machine = 2827
processor 2: version = 00, identification = 800000, machine = 2827
processor 3: version = 00, identification = C00000, machine = 2827
However, the same code runs perfectly OK on a s390 cosmic VM on a s390 host, cpu info of this is:
vendor_id : IBM/S390
# processors : 2
bogomips per cpu: 3033.00
max thread id : 0
features : esan3 zarch stfle msa ldisp eimm dfp edat etf3eh highgprs te vx
facilities : 0 1 2 3 4 6 7 8 9 10 13 14 16 17 18 19 20 21 22 23 24 25 26 27 28 30 31 32 33 34 35 36 37 40 41 42 43 44 45 46 47 48 49 50 51 52 53 55 57 73 75 76 77 78 80 81 82 129
cache0 : level=1 type=Data scope=Private size=128K line_size=256 associativity=8
cache1 : level=1 type=Instruction scope=Private size=96K line_size=256 associativity=6
cache2 : level=2 type=Data scope=Private size=2048K line_size=256 associativity=8
cache3 : level=2 type=Instruction scope=Private size=2048K line_size=256 associativity=8
cache4 : level=3 type=Unified scope=Shared size=65536K line_size=256 associativity=16
cache5 : level=4 type=Unified scope=Shared size=491520K line_size=256 associativity=30
processor 0: version = FF, identification = 258F67, machine = 2964
processor 1: version = FF, identification = 258F67, machine = 2964
cpu number : 0
cpu MHz dynamic : 5000
cpu MHz static : 5000
cpu number : 1
cpu MHz dynamic : 5000
cpu MHz static : 5000
So I think this must be to do with the s390x VM on a x86-64 host.
** Affects: eglibc (Ubuntu)
Importance: Medium
Status: New
** Changed in: eglibc (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to eglibc in Ubuntu.
https://bugs.launchpad.net/bugs/1784583
Title:
SIGILL on s390x in libpthread when run inside cosmic VM
Status in eglibc package in Ubuntu:
New
Bug description:
I installed the Cosmic s390x server on an x86-64 Cosmic host using
virt manager and get a SIGILL when using libptread.
For example: I built stress-ng from the upstream git repo using:
sudo apt-get build-dep stress-ng
git clone git://kernel.ubuntu.com/cking/stress-ng
cd stress-ng
make
./stress-ng --help
[66597.487332] User process fault: interruption code 0002 ilc:2
Illegal instruction
Debugging this with gdb one can see the SIGILL occurs in libpthread:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
Program received signal SIGILL, Illegal instruction.
0x000003fffdffe71c in __kernel_getcpu ()
(gdb) where
#0 0x000003fffdffe71c in __kernel_getcpu ()
#1 0x000003fffd8699a4 in sched_getcpu ()
at ../sysdeps/unix/sysv/linux/sched_getcpu.c:32
#2 0x000002aa000ea96e in stress_get_cpu () at helper.c:1064
#3 0x000002aa000edef6 in mwc_reseed () at mwc.c:70
#4 0x000002aa000f7d5a in main (argc=1, argv=0x3fffffffb98) at stress-ng.c:3477
cat /proc/cpuinfo
vendor_id : IBM/S390
# processors : 4
bogomips per cpu: 13370.00
max thread id : 0
features : esan3 zarch stfle msa ldisp eimm etf3eh highgprs
facilities : 0 1 2 3 4 7 9 16 17 18 19 21 22 24 25 27 30 31 32 33 34 35 40 41 45 49 51 52 71 72 76 77 138
processor 0: version = 00, identification = 000000, machine = 2827
processor 1: version = 00, identification = 400000, machine = 2827
processor 2: version = 00, identification = 800000, machine = 2827
processor 3: version = 00, identification = C00000, machine = 2827
However, the same code runs perfectly OK on a s390 cosmic VM on a s390 host, cpu info of this is:
vendor_id : IBM/S390
# processors : 2
bogomips per cpu: 3033.00
max thread id : 0
features : esan3 zarch stfle msa ldisp eimm dfp edat etf3eh highgprs te vx
facilities : 0 1 2 3 4 6 7 8 9 10 13 14 16 17 18 19 20 21 22 23 24 25 26 27 28 30 31 32 33 34 35 36 37 40 41 42 43 44 45 46 47 48 49 50 51 52 53 55 57 73 75 76 77 78 80 81 82 129
cache0 : level=1 type=Data scope=Private size=128K line_size=256 associativity=8
cache1 : level=1 type=Instruction scope=Private size=96K line_size=256 associativity=6
cache2 : level=2 type=Data scope=Private size=2048K line_size=256 associativity=8
cache3 : level=2 type=Instruction scope=Private size=2048K line_size=256 associativity=8
cache4 : level=3 type=Unified scope=Shared size=65536K line_size=256 associativity=16
cache5 : level=4 type=Unified scope=Shared size=491520K line_size=256 associativity=30
processor 0: version = FF, identification = 258F67, machine = 2964
processor 1: version = FF, identification = 258F67, machine = 2964
cpu number : 0
cpu MHz dynamic : 5000
cpu MHz static : 5000
cpu number : 1
cpu MHz dynamic : 5000
cpu MHz static : 5000
So I think this must be to do with the s390x VM on a x86-64 host.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1784583/+subscriptions
More information about the foundations-bugs
mailing list