SIGILL on s390x in libpthread when run inside cosmic VM
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.
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-
Program received signal SIGILL, Illegal instruction.
0x000003fffdffe71c in __kernel_getcpu ()
(gdb) where
#0 0x000003fffdffe71c in __kernel_getcpu ()
#1 0x000003fffd8699a4 in sched_getcpu ()
at ../sysdeps/
#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 |