SIGILL on s390x in libpthread when run inside cosmic VM

Bug #1784583 reported by Colin Ian King
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
eglibc (Ubuntu)
New
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.