diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1779 | 45 | ||||
| -rw-r--r-- | results/classifier/108/other/1779017 | 110 | ||||
| -rw-r--r-- | results/classifier/108/other/1779120 | 117 | ||||
| -rw-r--r-- | results/classifier/108/other/1779447 | 39 | ||||
| -rw-r--r-- | results/classifier/108/other/1779634 | 93 | ||||
| -rw-r--r-- | results/classifier/108/other/1779649 | 28 |
6 files changed, 432 insertions, 0 deletions
diff --git a/results/classifier/108/other/1779 b/results/classifier/108/other/1779 new file mode 100644 index 000000000..79764be7c --- /dev/null +++ b/results/classifier/108/other/1779 @@ -0,0 +1,45 @@ +graphic: 0.844 +device: 0.803 +performance: 0.747 +semantic: 0.647 +vnc: 0.578 +PID: 0.575 +permissions: 0.423 +boot: 0.365 +debug: 0.348 +other: 0.235 +network: 0.172 +socket: 0.138 +files: 0.101 +KVM: 0.019 + +PowerPC AltiVec source vector subnormal values are not flushed to zero +Description of problem: +AltiVec specifies that source and result vectors are flushed to zero (in NJ mode). Only result vectors are flushed to zero. +Steps to reproduce: +1. Compile the attached Rust program (e.g. `cargo +nightly build --target powerpc-unknown-linux-gnu`) +2. Run the program and expect assertions to pass. +3. See assertions fail. +Additional information: +See the offending Rust program: + +``` +#![feature(stdsimd, powerpc_target_feature)] + +use std::arch::powerpc::*; + +#[target_feature(enable = "altivec")] +unsafe fn add(x: f32, y: f32) -> f32 { + let array: [f32; 4] = unsafe { std::mem::transmute(vec_add(vec_splats(x), vec_splats(y))) }; + array[0] +} + +pub fn main() { + let result = unsafe { add(-1.0857398e-38, 0.) }; + assert_eq!(result, 0.); + + // if the input is flushed, the result will be +0 + // if only the output is flushed, the result is -0 + assert!(result.is_sign_positive()); +} +``` diff --git a/results/classifier/108/other/1779017 b/results/classifier/108/other/1779017 new file mode 100644 index 000000000..5002eee17 --- /dev/null +++ b/results/classifier/108/other/1779017 @@ -0,0 +1,110 @@ +other: 0.948 +permissions: 0.940 +performance: 0.917 +device: 0.905 +semantic: 0.900 +graphic: 0.895 +debug: 0.892 +socket: 0.874 +boot: 0.859 +PID: 0.836 +network: 0.834 +vnc: 0.833 +KVM: 0.823 +files: 0.812 + +qemu-system-arm: crashes raspian kernels with divide-by-zero + +While trying to boot a arm kernel for a raspi2 machine (kernel7-4.9.41-stretch.img in my case, but applies to other versions, too) the kernel crash with a division by zero. The output on the sreial console is: +[ 10.022377] [<8011d344>] (__warn) from [<8011d42c>] (warn_slowpath_null+0x30/0x38) +[ 10.024726] [<8011d42c>] (warn_slowpath_null) from [<804da378>] (uart_get_baud_rate+0xf8/0x160) + +... + +[ 10.094933] Hardware name: BCM2835 +[ 10.101507] [<8010fb3c>] (unwind_backtrace) from [<8010c058>] (show_stack+0x20/0x24) +[ 10.105413] [<8010c058>] (show_stack) from [<80455f84>] (dump_stack+0xd4/0x118) +[ 10.140268] [<80455f84>] (dump_stack) from [<8010bed4>] (__div0+0x24/0x28) +[ 10.143065] [<8010bed4>] (__div0) from [<8045498c>] (Ldiv0+0x8/0x14) +[ 10.145553] [<8045498c>] (Ldiv0) from [<804e5538>] (pl011_set_termios+0x9c/0x37c) +[ 10.148017] [<804e5538>] (pl011_set_termios) from [<804da954>] (uart_change_speed+0x40/0xfc) +[ 10.185887] [<804da954>] (uart_change_speed) from [<804ddedc>] (uart_startup.part.3+0xa4/0x13c) +[ 10.222187] [<804ddedc>] (uart_startup.part.3) from [<804ddfcc>] (uart_port_activate+0x58/0x64) +[ 10.226014] [<804ddfcc>] (uart_port_activate) from [<804c93b8>] (tty_port_open+0xa0/0xe0) +[ 10.228398] [<804c93b8>] (tty_port_open) from [<804dce64>] (uart_open+0x40/0x48) +[ 10.264254] [<804dce64>] (uart_open) from [<804c1d70>] (tty_open+0xc0/0x678) +[ 10.266697] [<804c1d70>] (tty_open) from [<802753f0>] (chrdev_open+0xe0/0x1a0) +[ 10.269049] [<802753f0>] (chrdev_open) from [<8026d964>] (do_dentry_open+0x1f4/0x314) +[ 10.271620] [<8026d964>] (do_dentry_open) from [<8026ec00>] (vfs_open+0x60/0x8c) +[ 10.275245] [<8026ec00>] (vfs_open) from [<8027f39c>] (path_openat+0x2bc/0x1040) +[ 10.312827] [<8027f39c>] (path_openat) from [<80281040>] (do_filp_open+0x70/0xd4) +[ 10.317860] [<80281040>] (do_filp_open) from [<8026efd8>] (do_sys_open+0x120/0x1d0) +[ 10.320370] [<8026efd8>] (do_sys_open) from [<8026f0b4>] (SyS_open+0x2c/0x30) +[ 10.357033] [<8026f0b4>] (SyS_open) from [<801080c0>] (ret_fast_syscall+0x0/0x1c) + +Tracking that down in the linux kernel source, it looks like somehow uart_get_baud_rate() returns 0. + +The same kernel could be booted without problem with qemu version 2.11. +Trying to bisecting the issue revealed commit @d9f8bbd8eb4e95db97cf02bd03af86a3d606f4f1 as the culprit. + +Commandline to run was: +qemu-system-arm -M raspi2 \ + -kernel "$KERNEL" \ + -m 1024 \ + -d guest_errors,unimp \ + -dtb bcm2709-rpi-2-b.dtb \ + -drive file="$IMG,if=sd,format=raw" + +Distribution is SuSE tumbleweed (x86_64, kernel 4.17.2), but same problem also happens with a freshly compiled qemu from git repository. + +This isn't a kernel crash, it's just a warning (which I think is safely ignorable). The problem is that QEMU doesn't implement the 'cprman' clock control hardware, which means Linux thinks the UART is running at a zero baud rate. Unfortunately the cprman hardware is as far as I can determine undocumented, so it's not really possible to write an emulation of it. + +I'm not sure your bisection has landed on the right thing, as d9f8bbd8eb4e95 should be a no-behaviour-change commit. + + +On Donnerstag, 28. Juni 2018 11:32:08 CEST Peter Maydell wrote: + +Thanks for your quick answer. + +> I'm not sure your bisection has landed on the right thing, as +> d9f8bbd8eb4e95 should be a no-behaviour-change commit. + +Yes, i saw that already. But strangely, the commit before worked (tested +manually after the bisect), and with that commit i get the division by zero. + +The problem is that the kernel stops booting at this point (maybe not because +of the exception, but that is the last message printed) + +>Unfortunately the cprman hardware is as far as I can +>determine undocumented + +Would there be some way to fake it at least, so that linux does not get a zero +baudrate? + + + + + +This does not appear to be DIRECTLY a bug in QEMU, but 'something' has changed in the RPi Kernel to cause this issue. + +The actual cause of the panic is (in my situation) because the kernel is unable to mount root, and this is caused by it being unable to access the SD interface, as it can't get timing. + +This is a random working kernel (using QEMU 3.0) - https://pastebin.com/wvkneNNF + +This is the latest 4.14 kernel (using the identical QEMU) - https://pastebin.com/QTwgCkV2 + +The actual error is on line 160: + +[ 1.706622] sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe + +This never actually activates the mmc controller, and the root volume is not available. + + + +Thanks for the followup. Yes, that sounds like the problem is indeed that we don't currently emulate enough of the clock-control in the raspi's SoC. There were a couple of patches on list a while back that were trying to provide at least a basic dummy emulation of that device; I'm not sure what happened to them. + +This should be fixed for the 5.2 release, as we now have a model of the cprman clock control module. + + +Released with QEMU v5.2.0. + diff --git a/results/classifier/108/other/1779120 b/results/classifier/108/other/1779120 new file mode 100644 index 000000000..40fe07332 --- /dev/null +++ b/results/classifier/108/other/1779120 @@ -0,0 +1,117 @@ +other: 0.782 +device: 0.733 +permissions: 0.732 +KVM: 0.726 +debug: 0.716 +performance: 0.712 +socket: 0.712 +boot: 0.711 +vnc: 0.708 +network: 0.707 +PID: 0.693 +files: 0.679 +semantic: 0.677 +graphic: 0.673 + +disk missing in the guest contingently when hotplug several virtio scsi disks consecutively + +Hi, I found a bug that disk missing (not all disks missing ) in the guest contingently when hotplug several virtio scsi disks consecutively. After rebooting the guest,the missing disks appear again. + +The guest is centos7.3 running on a centos7.3 host and the scsi controllers are configed with iothread. The scsi controller xml is below: + + <controller type='scsi' index='0' model='virtio-scsi'> + <driver iothread='26'/> + <alias name='scsi0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </controller> + + +If the scsi controllers are configed without iothread, disks are all can be seen in the guest when hotplug several virtio scsi disks consecutively. + +I think the biggest difference between them is that scsi controllers with iothread call virtio_notify_irqfd to notify guest and scsi controllers without + +iothread call virtio_notify instead. What make it difference? Will interrupts are lost when call virtio_notify_irqfd due to race condition for some unknow reasons? Maybe guys more familiar with scsi dataplane can help. Thanks for your reply! + +Please post the following information: +(host)# rpm -qa | grep qemu-kvm +(guest)# uname -r + +What are the exact steps to reproduce this issue (virsh command-lines and XML)? + +I also met this bug + +Hi, Stefan. +(host)# rpm -qa | grep qemu-kvm +qemu-kvm-2.8.1-25.142.x86_64 +(guest)# uname -r +3.10.0-514.el7.x86_64 + +I also tried the newest version of qemu-kvm, but it also met this issue. +The steps to reproduce this issue are below: + +1)attach four virtio-scsi controller with dataplane to vm. + <controller type='scsi' index='0' model='virtio-scsi'> + <driver iothread='1'/> + <alias name='scsi0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' +function='0x0'/> + </controller> + <controller type='scsi' index='1' model='virtio-scsi'> + <driver iothread='2'/> + <alias name='scsi1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' +function='0x0'/> + </controller> + <controller type='scsi' index='2' model='virtio-scsi'> + <driver iothread='3'/> + <alias name='scsi2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' +function='0x0'/> + </controller> + <controller type='scsi' index='3' model='virtio-scsi'> + <driver iothread='4'/> + <alias name='scsi3'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' +function='0x0'/> + </controller> + +2)attach 35 virtio-scsi disks(sda - sdai) to vm consecutively. One +controller has 15 scsi disks. +A example of disk xml is below: + <disk type='block' device='lun' rawio='yes'> + <driver name='qemu' type='raw' cache='none' io='native'/> + <source dev='/dev/mapper/360022a11000c1e0a0787bb2500000139'/> + <backingStore/> + <target dev='sda' bus='scsi'/> + <shareable/> + <alias name='scsi0-0-0-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + + You can write a shell script like this: + for((i=1;i++;i<=35)) + do + virsh attach-device centos7.3_64_server scsi_disk_$i.xml +--config --live + done + +This issue is a probabilistic event. If it does not appear, repeat the +above steps several more times. +Thank you! + +On 2018/6/28 21:01, Stefan Hajnoczi wrote: +> Please post the following information: +> (host)# rpm -qa | grep qemu-kvm +> (guest)# uname -r +> +> What are the exact steps to reproduce this issue (virsh command-lines +> and XML)? +> + + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1779447 b/results/classifier/108/other/1779447 new file mode 100644 index 000000000..8b3e70b50 --- /dev/null +++ b/results/classifier/108/other/1779447 @@ -0,0 +1,39 @@ +debug: 0.750 +network: 0.709 +device: 0.640 +socket: 0.615 +files: 0.555 +semantic: 0.544 +vnc: 0.531 +other: 0.501 +permissions: 0.472 +PID: 0.425 +performance: 0.422 +graphic: 0.387 +boot: 0.353 +KVM: 0.142 + +SLIRP SMB silently fails with MacOS smbd + +When using the -net user,id=net0,ipv6=off,smb=/path/to/share/option,hostfwd=tcp::19500-:22 I can successfully mount_smbfs the shared directory on the guest when QEMU is running on a Linux or FreeBSD host. However, on a MacOS host the mount_smbfs command just fails with +`mount_smbfs: unable to open connection: syserr = Connection reset by peer`. +After some debugging it turns out this is because the smbd shipped by macos is incompatible and doesn't use the same config file/command line arguments. + +I have since got it working by compiling the sources form samba.org and using the --smbd= configure option pointing to that binary. + +Would it be possible to print a warning message or even better abort the launch saying smbd is incompatible with QEMU if the -smb= flag is passed? It appears that smbd should die with an error code on invalid arguments so QEMU should be able to report that. + + +This was happening with QEMU built from git sources at c1c2a435905ae76b159c573b0c0d6f095b45ebc6. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/153 + + diff --git a/results/classifier/108/other/1779634 b/results/classifier/108/other/1779634 new file mode 100644 index 000000000..4957731fb --- /dev/null +++ b/results/classifier/108/other/1779634 @@ -0,0 +1,93 @@ +debug: 0.908 +semantic: 0.901 +other: 0.893 +permissions: 0.889 +network: 0.887 +graphic: 0.885 +device: 0.863 +socket: 0.817 +PID: 0.814 +files: 0.807 +performance: 0.796 +vnc: 0.704 +KVM: 0.698 +boot: 0.612 + +qemu-x86_64 on aarch64 reports "Synchronous External Abort" + +Purpose: to run x86_64 utilities on aarch64 platform (Intel/Dell network adapters' firmware upgrade tools) +System: aarch64 server platform, with ubuntu 16.04 (xenial) Linux 4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May 30 11:14:25 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux + +Reproduce: +1) build linux-user qemu-x86_64 static from source (tried both version 1.12.0 & 1.11.02) + ./configure --target-list=x86_64-linux-user --disable-system --static --enable-linux-user + +2) install the interpreter into binfmt_misc filesystem + $ cat /proc/sys/fs/binfmt_misc/qemu-x86_64 + enabled + interpreter /usr/local/bin/qemu-x86_64 + flags: + offset 0 + magic 7f454c4602010100000000000000000002003e00 + mask fffffffffffefefcfffffffffffffffffeffffff + +3) packaging Intel/Dell upgrade utilities into docker images, I've published two on docker hub: + REPOSITORY TAG IMAGE ID CREATED SIZE + heyi/dellupdate latest 8e013f5511cd 6 hours ago 210MB + heyi/nvmupdate64e latest 9d2de9d0edaa 3 days ago 451MB + +4) run the docker container on aarch64 server platform: + docker run -it --privileged --network host --volume /usr/local/bin/qemu-x86_64:/usr/local/bin/qemu-x86_64 heyi/dellupdate:latest + +5) finally, within docker container run the upgrade tool: + # ./Network_Firmware_T6VN9_LN_18.5.17_A00.BIN + +Errors: in dmesg it reports excessive 'Synchronous External Abort': + +kernel: [242850.159893] Synchronous External Abort: synchronous external abort (0x92000610) at 0x0000000000429958 +kernel: [242850.169199] Unhandled fault: synchronous external abort (0x92000610) at 0x0000000000429958 + +thanks and best regards, Yi + +qemu-x86_64 is just a userspace program. If the kernel is getting Synchronous External Aborts then this is not a QEMU problem. Either there's a bug in the host kernel, or the guest binary is attempting to mmap /dev/mem and do wrong things to it because it's expecting it to be an x86 system. I suspect the latter (it's probably trying to do userspace writes directly to the network controller handware). This sort of binary is never going to be runnable via QEMU. + + +You could confirm this hypothesis by using strace and looking for whether it's doing mmap() of /dev/mem or /dev/kmem. If it's true, then the program would not work even if you had the source and recompiled it for aarch64 -- it would require bugfixes (code changes) to achieve whatever it's trying to do. + + +Thanks very much @Peter Maydell, when invoking these tools through docker/qemu-user I really saw syscall disorders, even strace fails. You are right these tools have x86_64 syscall numbers & perhaps mmaps of /dev/mem to allocate contiguous memory region for DMA transactions. + +Then the goal cannot be achieved by docker/qemu-user method (although it is quite convenient :) + +strace ./Network_Firmware_T6VN9_LN_18.5.17_A00.BIN +qemu: Unsupported syscall: 101 +qemu: Unsupported syscall: 101 +/usr/bin/strace: ptrace(PTRACE_TRACEME, ...): Function not implemented ++++ exited with 1 +++ + +I'll downgrade this bug to a question, and try full qemu-system emulation with PCI device passthrough assignment to achieve the goal of running Intel/Dell firmware upgrading tools on aarch64 servers. + + +> /usr/bin/strace: ptrace(PTRACE_TRACEME, ...): Function not implemented + +This indicates that you're trying to run an x86 strace under QEMU. That won't work. You want to either (a) run QEMU + guest binary under the host strace or (b) run QEMU + guest binary with the QEMU -strace option. + + +thanks Peter, yes I tried to run an x86 strace under QEMU. + +I'll stop this experiment since you are right this won't work for utilities with device-level I/O and memory operations, I will raise this requirement to Intel support website firstly. + +Best Regards, Yi + +Hi, + +if of interest to anyone... +we were able to successfully upgrade firmware of Intel XL710 on aarch64 platform. + +Two major items were required: +- small qemu change: https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg00553.html +- hack in Linux kernel /dev/mem driver in mmap function to catch wrong addresses nvmupdate64e asked for thru qemu. For some reason only lower 32-bit portion of actual physical address came to linux kernel. /dev/mem driver in kernel was changed to add missing upper 32 bits of address + +best regards, +Matevz + diff --git a/results/classifier/108/other/1779649 b/results/classifier/108/other/1779649 new file mode 100644 index 000000000..d58aa5ad9 --- /dev/null +++ b/results/classifier/108/other/1779649 @@ -0,0 +1,28 @@ +graphic: 0.833 +device: 0.772 +other: 0.585 +socket: 0.561 +network: 0.546 +vnc: 0.542 +semantic: 0.514 +performance: 0.478 +PID: 0.472 +boot: 0.420 +permissions: 0.403 +files: 0.302 +debug: 0.217 +KVM: 0.074 + +Suspending a domain works with a 3.16 gues kernel but not with a 4.16 one + +Suspending a domain with `systemctl suspend` works with a guest 3.16 kernel (jessie), the domain goes into `pmsuspend` in libvirt but doesn't work anymore with a 4.16 one (sid) where: + - With a QXL card: the spice display just goes black and the domain stays `running` in libvirt but is "dead" + - With a VGA card: the screen goes black and comes back immediately, the domain stays fine + +Qemu: Master, 281bd281222776229d5dbf84d1a5c6d8d9d2a34b + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + |