summary refs log tree commit diff stats
path: root/results/classifier/108/none/1054
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/none/105445
-rw-r--r--results/classifier/108/none/105481226
-rw-r--r--results/classifier/108/none/105483169
3 files changed, 140 insertions, 0 deletions
diff --git a/results/classifier/108/none/1054 b/results/classifier/108/none/1054
new file mode 100644
index 00000000..c9d5243e
--- /dev/null
+++ b/results/classifier/108/none/1054
@@ -0,0 +1,45 @@
+graphic: 0.450
+device: 0.368
+debug: 0.305
+performance: 0.281
+semantic: 0.253
+permissions: 0.253
+boot: 0.240
+vnc: 0.212
+PID: 0.197
+socket: 0.171
+other: 0.142
+network: 0.120
+files: 0.092
+KVM: 0.040
+
+Unable to start CirrOS 0.5.1 on QEMU 7.0 with -M virt and -cpu max
+Description of problem:
+
+Steps to reproduce:
+1. Fetch CirrOS image: ```wget https://github.com/cirros-dev/cirros/releases/download/0.5.1/cirros-0.5.1-aarch64-disk.img```
+2. Run QEMU:
+   ```
+   qemu-system-aarch64 -drive file=cirros-0.5.1-aarch64-disk.img -M virt -m 2048 \
+      -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd -cpu max -nographic
+   ```
+Additional information:
+When image boots, GRUB window appears for a second and then kernel/initramfs are loaded and booted:
+```
+EFI stub: Booting Linux Kernel...
+EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
+EFI stub: Using DTB from configuration table
+EFI stub: Exiting boot services and installing virtual address map...
+```
+
+When everything is fine we can see kernel output:
+```
+[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd070]
+[    0.000000] Linux version 5.3.0-26-generic (buildd@bos02-arm64-028) (gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)) #28~18.04.1-Ubuntu SMP Wed Dec 18 16:41:01 UTC 2019 (Ubuntu 5.3.0-26.28~18.04.1-generic 5.3.13)
+[    0.000000] efi: Getting EFI parameters from FDT:
+[    0.000000] efi: EFI v2.70 by EDK II
+```
+
+But on QEMU 7.0 with ```-M virt -cpu max``` we never get kernel output.
+
+#
diff --git a/results/classifier/108/none/1054812 b/results/classifier/108/none/1054812
new file mode 100644
index 00000000..95467bfe
--- /dev/null
+++ b/results/classifier/108/none/1054812
@@ -0,0 +1,26 @@
+device: 0.530
+other: 0.324
+semantic: 0.220
+graphic: 0.174
+vnc: 0.104
+socket: 0.100
+boot: 0.091
+PID: 0.076
+network: 0.075
+debug: 0.072
+files: 0.061
+performance: 0.047
+permissions: 0.042
+KVM: 0.012
+
+Configure uses wrong libtool on Darwin
+
+On Darwin/OS X, there are two versions of libtool: the GNU libtool, and Apple's libtool. Both are installed, but Apple's libtool (libtool) won't build libcacard that Qemu uses, but Gnu's libtool (glibtool) does. I get around using Apple's libtool by passing LIBTOOL=glibtool when configuring; unfortunately this variable isn't preserved so when Qemu's configure changes it's not passed. A simple switch in the configure script could check for Darwin, then if present, use glibtool. Or configure could check the features of libtool, see if they can build libcacard, then look for alternatives like glibtool. 
+
+This bug was probably introduced when libcacard was added to Qemu, and is present in commit 93b6599734f81328ee3d608f57667742cafeea72.
+
+Since libcacard is not longer part of QEMU, I assume this is not an issue anymore today. So can we close this bug nowadays?
+
+Yes, libtool handling was removed entirely in commit e999ee443496b, so this bug is no longer present.
+
+
diff --git a/results/classifier/108/none/1054831 b/results/classifier/108/none/1054831
new file mode 100644
index 00000000..33ee9e4d
--- /dev/null
+++ b/results/classifier/108/none/1054831
@@ -0,0 +1,69 @@
+PID: 0.179
+network: 0.173
+device: 0.169
+other: 0.150
+permissions: 0.129
+semantic: 0.116
+vnc: 0.106
+performance: 0.104
+socket: 0.104
+debug: 0.093
+files: 0.074
+graphic: 0.058
+KVM: 0.054
+boot: 0.046
+
+qemu-user-static for sparc32plus : bash: fork: Invalid argument
+
+On Debian x86-64 host system I setup a sparc chroot using:
+
+host $ mkdir sparc 
+host $ sudo debootstrap --arch=sparc --foreign wheezy sparc http://ftp.au.debian.org/debian
+host $ sudo cp ~/Git/qemu/sparc32plus-linux-user/qemu-sparc32plus sparc/usr/bin/qemu-sparc32plus-static
+host $ LANG=C sudo chroot sparc/ /usr/bin/qemu-sparc32plus-static /bin/bash
+
+When I then run the second stage of debootstrap I get:
+
+target $ /debootstrap/debootstrap --second-stage
+bash: fork: Invalid argument
+
+The above procedures works perfectly for armhf.
+
+This is with current git HEAD (commit 93b6599734f81328ee3d608f57667742cafeea72).
+
+This is due to QEMU sparc32plus-linux-user not being compiled with NPTL support.
+
+Dillon Amburgey wrote:
+
+> This is due to QEMU sparc32plus-linux-user not being compiled with NPTL
+> support.
+
+I just check, and NPTL is enabled. I also did this on the binary I
+compiled:
+
+    $ strings  /usr/bin/qemu-sparc32plus-static | grep nptl
+    ../nptl/sysdeps/pthread/createthread.c
+    ../nptl/pthread_mutex_lock.c
+    nptl-init.c
+    ../nptl/sysdeps/unix/sysv/linux/x86_64/../fork.c
+
+which suggests that it has been compiled with NPTL.
+
+
+What I mean is that QEMU isn't compiled with guest support for NPTL on every architecture.
+
+If you look in the configure script around line 3900, you'll see some architectures have target_nptl="yes" while others (including sparc) do not.
+
+Unfortunately it looks like the code isn't complete for sparc support, so it isn't a simple matter of enabling it in the configure script.
+
+The reason you get "bash: fork: Invalid argument" is because glibc makes a call to clone() with NPTL arguments that aren't supported.
+
+This bug should be fixed by a combination of:
+ * the enable-NPTL-everywhere patchset: http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg02614.html
+ * a fix for pipe() on sparc: http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg01072.html
+which I hope will make it into QEMU 1.6.
+
+
+This was fixed years ago...
+
+