diff options
Diffstat (limited to 'results/classifier/105/instruction/1689367')
| -rw-r--r-- | results/classifier/105/instruction/1689367 | 120 |
1 files changed, 120 insertions, 0 deletions
diff --git a/results/classifier/105/instruction/1689367 b/results/classifier/105/instruction/1689367 new file mode 100644 index 000000000..9aa2212fd --- /dev/null +++ b/results/classifier/105/instruction/1689367 @@ -0,0 +1,120 @@ +instruction: 0.828 +graphic: 0.818 +device: 0.811 +semantic: 0.804 +vnc: 0.792 +KVM: 0.789 +network: 0.747 +assembly: 0.741 +other: 0.735 +socket: 0.710 +mistranslation: 0.709 +boot: 0.572 + +In qemu chroot, repeating "qemu: Unsupported syscall: 384" messages. sys_getrandom ? + +On exec of an armv7 qemu chroot on my local x86_64 desktop, launched via + + /usr/sbin/qemu-binfmt-conf.sh + +from + + qemu-linux-user-2.9.0-374.1.x86_64 + +on the host, inside the chroot any compile activity is laced with repetitions of + + qemu: Unsupported syscall: 384 + +messages. + +This wasn't always the case -- but, TBH, it's been ~ 6 months since I used this env, and there have been scads of usual pkg updates in the interim. These messages appear to be non-fatal, with no particular effect at all; at least not so far ... + +From a chat in #IRC, + + [10:05] davidgiluk clever/pgnd: I see it as getrandom + [10:05] davidgiluk pgnd: https://fedora.juszkiewicz.com.pl/syscalls.html sort it on the ARM table and you can easily see it + [10:05] clever arch/arm/tools/syscall.tbl:384 common getrandom sys_getrandom + [10:06] davidgiluk pgnd: my *guess* is that something is calling getrandom, getting told it's not implemented and then falling back to using /dev/urandom + [10:10] pgnd davidgiluk: If that *is* the case, is it to be considered a problem, or just informational? + [10:12] davidgiluk pgnd: As long as it's falling back probably informational; but someone should probably go and wire up sys_getrandom at some point + +arm32 syscall 384 is indeed getrandom, but QEMU implemented this in commit f894efd19917321 as of Feb 2016, which should be in 2.6 or later. I've just checked and the LTP test cases for getrandom all pass with qemu-arm-user and do invoke the getrandom syscall and don't provoke the warning from QEMU. + +Can you check that the qemu-arm-static binary inside the chroot is really 2.9 and not an older version? + + +The statically linked qemu files in chroot are cp'd from the host env + + file $(which qemu-arm) $(which qemu-arm-binfmt) + /usr/bin/qemu-arm: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.0.0, BuildID[sha1]=a6c50ab9b8f1845daab2f41d85936712aabafd89, not stripped + /usr/bin/qemu-arm-binfmt: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.0.0, BuildID[sha1]=ff78e29b45699433557fab5396b79f07211fd3d5, not stripped + +where + + rpm -q --whatprovides $(which qemu-arm) $(which qemu-arm-binfmt) + qemu-linux-user-2.10.1-412.1.x86_64 + qemu-linux-user-2.10.1-412.1.x86_64 + +pkg + + qemu-linux-user-2.10.1-412.1.x86_64 + +is sourced/installed from the openSUSE 'Virtualization' repo, + + https://build.opensuse.org/package/show/Virtualization/qemu-linux-user + +and, + + rpm -q --changelog qemu-linux-user-2.10.1-412.1.x86_64 | head -n 20 + * Thu Oct 19 2017 <email address hidden> + - Patch queue updated from git://github.com/openSUSE/qemu.git opensuse-2.10 + * Patches added: + 0040-io-monitor-encoutput-buffer-size-fr.patch + 0041-cirrus-fix-oob-access-in-mode4and5-.patch + 0042-9pfs-use-g_malloc0-to-allocate-spac.patch + + * Tue Oct 03 2017 <email address hidden> + - Update to v2.10.1 a stable, bug-fix-only release + * Patches dropped (upstream): + 0034-slirp-fix-clearing-ifq_so-from-pend.patch + 0035-s390-ccw-Fix-alignment-for-CCW1.patch + 0038-s390x-ais-for-2.10-stable-disable-a.patch + 0039-s390x-cpumodel-remove-ais-from-z14-.patch + * Patches renamed: + 0036-target-i386-cpu-Add-new-EPYC-CPU-mo.patch + - > 0034-target-i386-cpu-Add-new-EPYC-CPU-mo.patch + 0037-chardev-baum-fix-baum-that-releases.patch + - > 0035-chardev-baum-fix-baum-that-releases.patch + 0040-io-fix-temp-directory-used-by-test-.patch + + +Can you just run /usr/bin/qemu-arm-static --version in the chroot, please ? (or whatever suse calls its statically linked binary). + + +The other interesting question is what version of the (host) kernel headers the QEMU binary was built against -- if that's earlier than 3.17 then the headers won't define __NR_getrandom for the host system and we won't implement the syscall. + + +> Can you just run /usr/bin/qemu-arm-static --version in the chroot, +please ? (or whatever suse calls its statically linked binary). + +Yep, as soon as I'm sitting back in front of the machine with the chroot on it. Bit later ... + +> The other interesting question is what version of the (host) kernel headers the QEMU binary was built against -- if that's earlier than 3.17 then the headers won't define __NR_getrandom for the host system and we won't implement the syscall. + +The qemu build uses headers from a repo which tracks Kernel/Stable's regular releases. It _currently_ holds kernel 4.13.10. + + +> run /usr/bin/qemu-arm-static --version in the chroot + +:/# /usr/bin/qemu-arm --version + qemu-arm version 2.10.1 + Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + + +In that case I'm confused about what is happening here -- the emulation of getrandom() for arm guests on x86-64 targets works for me. The only other thing I can suggest is that you try building an upstream QEMU -- perhaps there's something odd going on with the SUSE patches or build environment. + + +[Expired for QEMU because there has been no activity for 60 days.] + +I am able to reproduce using docker and qemu-arm version 1.5.93 + |