diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1245 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1245543 | 45 | ||||
| -rw-r--r-- | results/classifier/108/other/1245703 | 93 | ||||
| -rw-r--r-- | results/classifier/108/other/1245724 | 86 |
4 files changed, 240 insertions, 0 deletions
diff --git a/results/classifier/108/other/1245 b/results/classifier/108/other/1245 new file mode 100644 index 000000000..3dd8f0a44 --- /dev/null +++ b/results/classifier/108/other/1245 @@ -0,0 +1,16 @@ +performance: 0.649 +device: 0.530 +graphic: 0.341 +permissions: 0.297 +files: 0.196 +semantic: 0.186 +debug: 0.185 +network: 0.182 +vnc: 0.179 +PID: 0.109 +other: 0.109 +KVM: 0.069 +boot: 0.047 +socket: 0.028 + +arm: cp15 support diff --git a/results/classifier/108/other/1245543 b/results/classifier/108/other/1245543 new file mode 100644 index 000000000..55ffdcfce --- /dev/null +++ b/results/classifier/108/other/1245543 @@ -0,0 +1,45 @@ +performance: 0.804 +other: 0.798 +device: 0.770 +semantic: 0.629 +socket: 0.619 +network: 0.548 +vnc: 0.529 +PID: 0.521 +permissions: 0.498 +graphic: 0.455 +boot: 0.437 +debug: 0.381 +files: 0.344 +KVM: 0.262 + +Wrong implementation of SSE4.1 pmovzxbw and similar instructions + +QEMU 1.5.0 (and git version, as far as I can tell from the source code) has incorrect implementation of pmovzxbw and similar SSE4.1 instructions. The instruction zero-extends the first 8 8-bit elements of a vector to 16bit vector and puts them to another vector. The current implementation applies this operation only to the first element and zeros out the rest. + +To verify, compile the attached program for SSE4.1 (g++ -msse4.1 cvtint.cc). On real hardware, it produces the following output: + +$ ./a.out +1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 + +On QEMU, the output is as follows: + +$ ./a.out +1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 + +QEMU is invoked as: + +qemu-system-x86_64 \ + -M pc -cpu Haswell,+sse4.1,+avx,+avx2,+fma,enforce -m 512 \ + -serial stdio -no-reboot \ + -kernel vmlinuz -initrd initrd.img \ + -netdev user,id=user.0 -device rtl8139,netdev=user.0 -redir tcp:2222::22 \ + -hda ubuntu-amd64.ext3 \ + --append "rw console=tty root=/dev/sda" + + + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1245703 b/results/classifier/108/other/1245703 new file mode 100644 index 000000000..c862b09f5 --- /dev/null +++ b/results/classifier/108/other/1245703 @@ -0,0 +1,93 @@ +other: 0.822 +graphic: 0.799 +performance: 0.771 +permissions: 0.769 +device: 0.766 +files: 0.748 +PID: 0.739 +vnc: 0.738 +network: 0.730 +semantic: 0.729 +debug: 0.726 +socket: 0.725 +KVM: 0.704 +boot: 0.668 + +LD_PREFIX option reads directories recursively in an endless loop + +If I run qemu user emulation with -L /path/to/my/sysroot/ in which also the proc and dev filesystem is mounted QEMU eats my memory until it gets killed by the kernel. + +According to the strace output it follows the symbolic links in the proc filesystem running forever in a recursive loop. + +The easiest solution would be to add in the function "add_dir_maybe" in the file util/path.c an additional check for symbolic links that it don't follow them. + +Also I don't really understand the need of doing this. A lot of ressources are wasted everytime QEMU-user is started just by having the directory structure in memory. In my case this are more than 20000 entries which QEMU is loading every time. + +On 28 October 2013 23:15, Sebastian Macke <email address hidden> wrote: +> If I run qemu user emulation with -L /path/to/my/sysroot/ in which also +> the proc and dev filesystem is mounted QEMU eats my memory until it gets +> killed by the kernel. +> +> According to the strace output it follows the symbolic links in the proc +> filesystem running forever in a recursive loop. +> +> The easiest solution would be to add in the function "add_dir_maybe" in +> the file util/path.c an additional check for symbolic links that it +> don't follow them. + +Yeah, this -L code is just busted. It's really only intended to work +with extremely simple sysroot directories which don't have weird +stuff like proc mounts or symlinks and aren't very big. + +If the thing you're looking at isn't like that then you might be better +off using the "static qemu and chroot into the directory" approach +instead. + +-- PMM + + +Ok, thanks for the info. +For me it looks like removing the whole path code and putting a one-liner combining two string is the best solution. But maybe I am missing something. + +qemu-arm *and* qemu-arm-static 1.5.0+dfsg-3ubuntu5.1 (AMD64 13.10 host) are affected by this. + +Steps to reproduce: +0. mkdir /mnt/mychroot +1. qemu-debootstrap --arch=armhf wheezy /mnt/mychroot http://ftp.debian.org/debian +2. qemu-arm-static -L /mnt/mychroot /mnt/mychroot/usr/sbin/chroot /mnt/mychroot /bin/sh + +In this case, the loop starts when it meets /mnt/mychroot/dev/fd (which links to /proc/self/fd). + +One ugly workaround is, in case anyone needs it: + +cp -a /usr/bin/qemu-arm-static /mnt/mychroot/ +chroot /mnt/mychroot /qemu-arm-static /bin/sh + +We're (Yocto Project) hit this often. We're building a root file system and then using userspace qemu to run binaries inside it (such as fc-cache). If a cyclic symlink appears in the rootfs, it blows up. + + + +On 26 March 2015 at 21:37, Ross Burton <email address hidden> wrote: +> We're (Yocto Project) hit this often. We're building a root file system +> and then using userspace qemu to run binaries inside it (such as fc- +> cache). If a cyclic symlink appears in the rootfs, it blows up. + +If you're actually building a rootfs then you're probably +better off using binfmt-misc and chrooting into it rather +than using -L. -L really isn't intended to point at a +full rootfs. + +-- PMM + + +We need to be able to run qemu as not root. Has anyone tried using qemu with fakechroot? + +I posted a patch a while back that would fix this: + +https://patchwork.kernel.org/patch/9512083/ + +Fixed by in 4.1.0 by: + +f3a8bdc1d5b2 ("util/path: Do not cache all filenames at startup") + + diff --git a/results/classifier/108/other/1245724 b/results/classifier/108/other/1245724 new file mode 100644 index 000000000..68cf0f518 --- /dev/null +++ b/results/classifier/108/other/1245724 @@ -0,0 +1,86 @@ +semantic: 0.864 +other: 0.856 +performance: 0.829 +KVM: 0.826 +debug: 0.811 +PID: 0.784 +files: 0.779 +device: 0.750 +permissions: 0.739 +graphic: 0.725 +network: 0.690 +vnc: 0.660 +socket: 0.609 +boot: 0.507 + +libfdt.a git compilation fail + +I don't know the commit tags but I checked out dtc on the 28 of october at 20:27 in the tree of qemu (also git checkout out tonight). The compilation fail at line 234 in qemu/dtc/Makefile so I inserted that line: + +@$ /usr/bin/strace -o /usr/src/qemu_build/error.log.txt /usr/bin/ar $@ + +into the makefile at position 234 to see what is the exact problem but the strace log is inconclusive. + +for the error: /usr/bin/ar: deux operations différentes spécifiées + +liberal translation is: two different operation specified. + +the distribution is arch linux with binutils 2.23.2, gcc 4.8.2 and kernel kvm-3.12.0-rc5 from git. + + + +Which version of make are you using? Recently, a bug with make 4.0 has been discovered, please see this thread for a description and a work-around: + +http://<email address hidden>/msg198719.html + + +I am indeed using make v4.0. Thanks you very much for the email thread, I will try to compile qemu again. + +Alain + +-----Message d'origine----- +De : <email address hidden> [mailto:<email address hidden>] De la part de thh +Envoyé : 29 octobre 2013 04:32 +À : <email address hidden> +Objet : [Bug 1245724] Re: libfdt.a git compilation fail + +Which version of make are you using? Recently, a bug with make 4.0 has been discovered, please see this thread for a description and a work- +around: + +http://<email address hidden>/msg198719.html + +-- +You received this bug notification because you are subscribed to the bug report. +https://bugs.launchpad.net/bugs/1245724 + +Title: + libfdt.a git compilation fail + +Status in QEMU: + New + +Bug description: + I don't know the commit tags but I checked out dtc on the 28 of + october at 20:27 in the tree of qemu (also git checkout out tonight). + The compilation fail at line 234 in qemu/dtc/Makefile so I inserted + that line: + + @$ /usr/bin/strace -o /usr/src/qemu_build/error.log.txt /usr/bin/ar $@ + + into the makefile at position 234 to see what is the exact problem but + the strace log is inconclusive. + + for the error: /usr/bin/ar: deux operations différentes spécifiées + + liberal translation is: two different operation specified. + + the distribution is arch linux with binutils 2.23.2, gcc 4.8.2 and + kernel kvm-3.12.0-rc5 from git. + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1245724/+subscriptions + + + +This should be working fine again with recent versions of QEMU, so I'm closing the bug. If you still have problems, feel free to open it again. + |