SIGILL on s390x in libpthread when run inside cosmic VM

Bug #1784583 reported by Colin Ian King on 2018-07-31
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
eglibc (Ubuntu)
Medium
Unassigned

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.

Changed in eglibc (Ubuntu):
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers