diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/130 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1300021 | 24 | ||||
| -rw-r--r-- | results/classifier/108/other/1300863 | 25 | ||||
| -rw-r--r-- | results/classifier/108/other/1302 | 32 | ||||
| -rw-r--r-- | results/classifier/108/other/1303 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1303926 | 314 | ||||
| -rw-r--r-- | results/classifier/108/other/1304 | 24 | ||||
| -rw-r--r-- | results/classifier/108/other/1305402 | 114 | ||||
| -rw-r--r-- | results/classifier/108/other/1306818 | 63 | ||||
| -rw-r--r-- | results/classifier/108/other/1307225 | 487 | ||||
| -rw-r--r-- | results/classifier/108/other/1307281 | 30 | ||||
| -rw-r--r-- | results/classifier/108/other/1308341 | 186 | ||||
| -rw-r--r-- | results/classifier/108/other/1308381 | 101 | ||||
| -rw-r--r-- | results/classifier/108/other/1309 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1309034 | 50 |
15 files changed, 1498 insertions, 0 deletions
diff --git a/results/classifier/108/other/130 b/results/classifier/108/other/130 new file mode 100644 index 00000000..5bdeb789 --- /dev/null +++ b/results/classifier/108/other/130 @@ -0,0 +1,16 @@ +device: 0.753 +other: 0.670 +performance: 0.522 +network: 0.510 +graphic: 0.437 +semantic: 0.431 +files: 0.361 +permissions: 0.345 +debug: 0.340 +boot: 0.236 +vnc: 0.147 +socket: 0.143 +PID: 0.039 +KVM: 0.026 + +QEmu translation is incorrect when using REX in combination with LAHF/SAHF diff --git a/results/classifier/108/other/1300021 b/results/classifier/108/other/1300021 new file mode 100644 index 00000000..b39ae868 --- /dev/null +++ b/results/classifier/108/other/1300021 @@ -0,0 +1,24 @@ +device: 0.759 +graphic: 0.731 +performance: 0.714 +other: 0.512 +semantic: 0.504 +network: 0.442 +debug: 0.415 +vnc: 0.288 +PID: 0.281 +socket: 0.233 +KVM: 0.188 +boot: 0.122 +files: 0.061 +permissions: 0.053 + +after loadvm the system clock isn't current time + +hi, +when i load a snapshot of month ago using "loadvm name"command, the vm system time is past time,not recover current time. + +Triaging old bug tickets ... Which version of QEMU did you use here? Can you still reproduce the problem with the latest version of QEMU? How did you start QEMU? Did you specify the -rtc parameter? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1300863 b/results/classifier/108/other/1300863 new file mode 100644 index 00000000..56f5143e --- /dev/null +++ b/results/classifier/108/other/1300863 @@ -0,0 +1,25 @@ +files: 0.918 +device: 0.895 +boot: 0.877 +graphic: 0.782 +semantic: 0.724 +network: 0.672 +permissions: 0.666 +performance: 0.664 +vnc: 0.563 +socket: 0.538 +other: 0.479 +PID: 0.476 +debug: 0.441 +KVM: 0.028 + +Qemu does not show all files on floppy or hard drive (MS DOS 6.22 guest) + +My host system is a raspberry pi model B 512MB. To start qemu I typed into lxterminal: + +qemu-system-i386 -hda qemu.img -Fda Dos622-1.img -boot a + +Qemu version 1.7.0+dfsg-3 installed as package. The DOS disks were downloaded from winworldpc.com and if I mount them under Linux I see all the files, but on qemu I see the first 3 files only. The hard drive image I am using is a 30MB flat image created using bximage. + +Seems like you are using the QEMU from your Linux distribution. If you want to have support for that version, you should use the bug tracker from your distro instead. Otherwise, can you please try again with the latest version from http://wiki.qemu-project.org/Download to see whether the bug is already fixed there? Thanks! + diff --git a/results/classifier/108/other/1302 b/results/classifier/108/other/1302 new file mode 100644 index 00000000..cbb84fca --- /dev/null +++ b/results/classifier/108/other/1302 @@ -0,0 +1,32 @@ +device: 0.832 +graphic: 0.750 +socket: 0.719 +performance: 0.705 +semantic: 0.584 +PID: 0.556 +network: 0.536 +vnc: 0.498 +debug: 0.440 +files: 0.418 +boot: 0.417 +permissions: 0.327 +KVM: 0.304 +other: 0.181 + +Per-thread logging flag must be made immutable +Description of problem: +The problem is that the code assumes it isn't possible to switch from global logging to per-thread logging and vice-versa per design, but it lags appropriate checks to enforce it. Enabling or disabling per-thread logging at runtime from the monitor causes unexpected results. +Steps to reproduce: +Enabling per-thread logging at runtime: + +1. Start QEMU : `./qemu-system-x86_64 -S -monitor stdio -D qemu.log.%d` +2. Enable per-thread logging from the HMP monitor : `(qemu) log tid` +3. Fails with `Filename template with '%d' required for 'tid'` even though such a template was passed with `-D`. + +Disabling per-thread logging at runtime: + +1. Start QEMU : `./qemu-system-x86_64 -S -monitor stdio -D qemu.log.%d -d tid,cpu_reset` +2. Disable per-thread logging from the HMP monitor: `(qemu) log cpu_reset` +3. QEMU creates a log file with a bogus `qemu.log.%d` name. +Additional information: +[Series](https://patchew.org/QEMU/20221104120059.678470-1-groug@kaod.org/) posted and already reviewed by @rth7680 . diff --git a/results/classifier/108/other/1303 b/results/classifier/108/other/1303 new file mode 100644 index 00000000..7eebaa36 --- /dev/null +++ b/results/classifier/108/other/1303 @@ -0,0 +1,16 @@ +device: 0.848 +network: 0.739 +performance: 0.545 +graphic: 0.528 +semantic: 0.431 +debug: 0.422 +files: 0.229 +boot: 0.186 +permissions: 0.177 +KVM: 0.143 +vnc: 0.122 +socket: 0.115 +other: 0.056 +PID: 0.045 + +tcg/cputlb: code path is reachable in load_memop/store_memop() diff --git a/results/classifier/108/other/1303926 b/results/classifier/108/other/1303926 new file mode 100644 index 00000000..831721a4 --- /dev/null +++ b/results/classifier/108/other/1303926 @@ -0,0 +1,314 @@ +other: 0.809 +debug: 0.805 +permissions: 0.744 +device: 0.725 +graphic: 0.717 +performance: 0.714 +vnc: 0.712 +KVM: 0.702 +semantic: 0.683 +PID: 0.627 +boot: 0.624 +socket: 0.613 +files: 0.558 +network: 0.540 + +qemu-system-x86_64 crashed with SIGABRT + +I've been getting this periodically since my upgrade to qemu 2.0 in trusty this morning. + +ProblemType: Crash +DistroRelease: Ubuntu 14.04 +Package: qemu-system-x86 2.0.0~rc1+dfsg-0ubuntu1 +ProcVersionSignature: Ubuntu 3.13.0-23.45-generic 3.13.8 +Uname: Linux 3.13.0-23-generic x86_64 +ApportVersion: 2.14.1-0ubuntu1 +Architecture: amd64 +Date: Mon Apr 7 13:31:53 2014 +ExecutablePath: /usr/bin/qemu-system-x86_64 +InstallationDate: Installed on 2013-11-26 (131 days ago) +InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1) +ProcEnviron: PATH=(custom, no user) +Registers: No symbol table is loaded. Use the "file" command. +Signal: 6 +SourcePackage: qemu +StacktraceTop: + +Title: qemu-system-x86_64 crashed with SIGABRT +UpgradeStatus: Upgraded to trusty on 2014-01-17 (79 days ago) +UserGroups: + + + +It seems to happen when my quantal i386 guest is using the VMVGA driver. Switching to Cirrus fixes it. +Also happens to trusty amd64 guest with VMVGA driver. + +Stacktrace: + #0 0x00007f4eb7fa1f79 in ?? () + No symbol table info available. + Cannot access memory at address 0x7fffa1617188 +StacktraceSource: #0 0x00007f4eb7fa1f79 in ?? () +StacktraceTop: ?? () + + + + +And it is not just with vnc either. + +2f487a3d40faff1772e14da6b921900915501f9a was ok, so bisecting right now. + +Hm, bisect is pointing at 6ff45f01c734e1ad051f19913449e2577c9f4b7d which is very unlikely. I'll have to keep playing. + +Pretty sure that commit b533f658a98325d0e47b36113bd9f5bcc046fdae is the first bad commit. + +This is interesting. The commit is correct in that kvm_vm_ioctl() returns -errno, not -1, on error. However, the caller, kvm_physical_sync_dirty_bitmap, on seeing the error, shortcuts some extra errors to return -1 itself, but its caller then ignores its error. + +An extra debug statement shows that the ioctl is getting + +ioctl failed: No such file or directory + + +At the point when the ioctl fails, this is the backtrace: + +(gdb) where +#0 kvm_physical_sync_dirty_bitmap (section=0x7fffffffd820) at /home/serge/src/qemu/kvm-all.c:446 +#1 0x000055555580e30c in kvm_log_sync (listener=<optimized out>, section=<optimized out>) at /home/serge/src/qemu/kvm-all.c:803 +#2 0x000055555581390e in memory_region_sync_dirty_bitmap (mr=mr@entry=0x555556257ca8) at /home/serge/src/qemu/memory.c:1210 +#3 0x00005555557d943f in vga_sync_dirty_bitmap (s=0x555556257c98) at /home/serge/src/qemu/hw/display/vga.c:1618 +#4 vga_draw_graphic (full_update=0, s=0x555556257c98) at /home/serge/src/qemu/hw/display/vga.c:1653 +#5 vga_update_display (opaque=0x555556257c98) at /home/serge/src/qemu/hw/display/vga.c:1913 +#6 0x0000555555780d92 in dpy_refresh (s=0x555556203690) at ui/console.c:1416 +#7 gui_update (opaque=0x555556203690) at ui/console.c:194 +#8 0x0000555555764bd9 in timerlist_run_timers (timer_list=0x5555561d2460) at qemu-timer.c:488 +#9 0x0000555555764e44 in qemu_clock_run_timers (type=<optimized out>) at qemu-timer.c:499 +#10 qemu_clock_run_all_timers () at qemu-timer.c:605 +#11 0x0000555555729dbc in main_loop_wait (nonblocking=<optimized out>) at main-loop.c:490 +#12 0x00005555555e6196 in main_loop () at vl.c:2051 +#13 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4506 + + +(which means my comment #8 is off track - the caller in this case is checking the return value, then aborting - and this is the exact same backtrace as we get anyway) + +Looking at arch/x86/kvm/x86.c, ENOENT (only) happens when memslot->dirty_bitmap is NULL in kvm_vm_ioctl_get_dirty_log(). + + + +It seems reasonable that if we are requesting writing a dirty bitmap, and kernel says it's not dirty, we ignore that failure? I.e. ignore ENOENT? + +ENOENT (iiuc) means the kernel has an empty dirty bitmap for this +slot. Don't abort in that case. This appears to solve the bug +reported at + +https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1303926 + +which first showed up with commit b533f658a98325d: fix return check for +KVM_GET_DIRTY_LOG ioctl + +Signed-off-by: Serge Hallyn <email address hidden> +--- + kvm-all.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/kvm-all.c b/kvm-all.c +index 82a9119..7b7ea8d 100644 +--- a/kvm-all.c ++++ b/kvm-all.c +@@ -441,10 +441,13 @@ static int kvm_physical_sync_dirty_bitmap(MemoryRegionSection *section) + + d.slot = mem->slot; + +- if (kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d) == -1) { ++ ret = kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d); ++ if (ret < 0 && ret != -ENOENT) { + DPRINTF("ioctl failed %d\n", errno); + ret = -1; + break; ++ } else if (ret < 0) { ++ ret = 0; + } + + kvm_get_dirty_pages_log_range(section, d.dirty_bitmap); +-- +1.9.1 + + + +This bug was fixed in the package qemu - 2.0.0~rc1+dfsg-0ubuntu3 + +--------------- +qemu (2.0.0~rc1+dfsg-0ubuntu3) trusty; urgency=medium + + * d/p/ubuntu/kvm_physical_sync_dirty_bitmap-ignore-ENOENT-from-kv.patch + don't abort() just because the kernel has no dirty bitmap. + (LP: #1303926) + -- Serge Hallyn <email address hidden> Tue, 08 Apr 2014 22:32:00 -0500 + +Quoting Michael Tokarev (<email address hidden>): +> 09.04.2014 07:21, Serge Hallyn wrote: +> > ENOENT (iiuc) means the kernel has an empty dirty bitmap for this +> > slot. Don't abort in that case. This appears to solve the bug +> > reported at +> > +> > https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1303926 +> > +> > which first showed up with commit b533f658a98325d: fix return check for +> > KVM_GET_DIRTY_LOG ioctl +> > +> > Signed-off-by: Serge Hallyn <email address hidden> +> > --- +> > kvm-all.c | 5 ++++- +> > 1 file changed, 4 insertions(+), 1 deletion(-) +> > +> > diff --git a/kvm-all.c b/kvm-all.c +> > index 82a9119..7b7ea8d 100644 +> > --- a/kvm-all.c +> > +++ b/kvm-all.c +> > @@ -441,10 +441,13 @@ static int kvm_physical_sync_dirty_bitmap(MemoryRegionSection *section) +> > +> > d.slot = mem->slot; +> > +> > - if (kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d) == -1) { +> > + ret = kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d); +> > + if (ret < 0 && ret != -ENOENT) { +> > DPRINTF("ioctl failed %d\n", errno); +> > ret = -1; +> > break; +> > + } else if (ret < 0) { +> > + ret = 0; +> > } +> > +> > kvm_get_dirty_pages_log_range(section, d.dirty_bitmap); +> +> Should we omit calling kvm_get_dirty_pages_log_range() if there's +> no bitmap from kernel? + +If that's something we can know then certainly that'll be better. +It'll save an ioctl and copy_from_user of the whole of &d. + +> In particular, do we trust kernel to not +> touch d.dirty_bitmap when it returns ENOENT? + +Seems ok, kvm_vm_ioctl_get_dirty_log() doesn't change anything +in *log before returning when it finds no dirty_mapslot. + +-serge + + +Hi Serge, + +I keep getting the crash notification due to kvm crashes with the same bug title as this one. I see that the status is Fix Released, I'm on precise and fully up-to-date. + + +My package is: + +ii qemu-kvm 1.0+noroms-0ubuntu14.14 Full virtualization on i386 and amd64 hardware + +which seems the correct one. + + +However, from the changelog I cannot see anything that seems related to this bug fix: + +qemu-kvm (1.0+noroms-0ubuntu14.14) precise-security; urgency=medium + + * SECURITY UPDATE: arbitrary code execution via MAC address table update + - debian/patches/CVE-2014-0150.patch: fix overflow in hw/virtio-net.c. + - CVE-2014-0150 + * SECURITY UPDATE: denial of service and possible code execution via + smart self test counter + - debian/patches/CVE-2014-2894.patch: correct self-test count in + hw/ide/core.c. + - CVE-2014-2894 + + -- Marc Deslauriers <email address hidden> Fri, 25 Apr 2014 17:37:13 -0400 + +qemu-kvm (1.0+noroms-0ubuntu14.13) precise-security; urgency=medium + + * SECURITY UPDATE: privilege escalation via REPORT LUNS + - debian/patches/CVE-2013-4344.patch: support more than 256 LUNS in + hw/scsi-bus.c, hw/scsi.h. + - CVE-2013-4344 + + -- Marc Deslauriers <email address hidden> Tue, 28 Jan 2014 09:08:09 -0500 + + +(the other entries are older than these ones) + + +Has this fix really been released to precise? + + + +Thank you! + +Hi, + +the cause of this particular bug was introduced during 2014, so could not have been present in precise. We definately will want to figure out the cause of your bug, so please open a new bug report using 'ubuntu-bug qemu-kvm' immediately after a crash has happened. + +Thanks! + +Hi Serge, + + +I think I have already reported the required information a number of times with the Ubuntu built-in bug reporting facility (apport?), which asked me to report the crash information to developers. + +Are you able to find it out or do I need to manually open a new bug? + + +Thanks you. + +Unfortunately the only bug launchpad shows me when I search for bugs reported +by you is https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1180777 + +If you can give me a bug# that would be great, otherwise please do file a +new bug. + + +Hi Serge, + +I have opened this new bug: + +https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1320144 + +I have the similar issue, the KVM 2.0 keeps crashing, here is the stack I captured with GDB + +(gdb) c +Continuing. + +Program received signal SIGABRT, Aborted. +[Switching to Thread 0x7ffede1f9700 (LWP 5555)] +0x00007ffeee4d4f79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. +(gdb) bt +#0 0x00007ffeee4d4f79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +#1 0x00007ffeee4d8388 in __GI_abort () at abort.c:89 +#2 0x00007ffeee4cde36 in __assert_fail_base (fmt=0x7ffeee61f718 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", + assertion=assertion@entry=0x7ffef45f1c1e "s->current", + file=file@entry=0x7ffef45f17e0 "/build/buildd/qemu-2.0.0~rc1+dfsg/hw/scsi/lsi53c895a.c", line=line@entry=541, + function=function@entry=0x7ffef45f275b "lsi_do_dma") at assert.c:92 +#3 0x00007ffeee4cdee2 in __GI___assert_fail (assertion=0x7ffef45f1c1e "s->current", + file=0x7ffef45f17e0 "/build/buildd/qemu-2.0.0~rc1+dfsg/hw/scsi/lsi53c895a.c", line=541, + function=0x7ffef45f275b "lsi_do_dma") at assert.c:101 +#4 0x00007ffef43de87d in ?? () +#5 0x00007ffef43dca97 in ?? () +#6 0x00007ffef4507631 in ?? () +#7 0x00007ffef450c776 in ?? () +#8 0x00007ffef44b1933 in ?? () +#9 0x00007ffef4506615 in ?? () +#10 0x00007ffef44a6f42 in ?? () +#11 0x00007ffeee86c182 in start_thread (arg=0x7ffede1f9700) at pthread_create.c:312 +#12 0x00007ffeee59930d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 +(gdb) + +My KVM command line +================== + +qemu-system-x86_64 -enable-kvm -name 015-win2k3-32bit-dev-target -S -machine pc-i440fx-trusty,accel=kvm,usb=off -m 4096 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 2af25570-37cd-a3af-e157-0d85cf31d47d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/015-win2k3-32bit-dev-target.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device lsi,id=scsi0,bus=pci.0,addr=0x4 -drive file=/home/vm/015-win2k3-32bit-dev-target/disk.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,cache=writeback -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/home/vm/015-win2k3-32bit-dev-target/zhe_test.qcow2,if=none,id=drive-scsi0-0-0,format=qcow2,cache=writeback -device scsi-hd,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -netdev tap,fd=25,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=e0:db:55:04:dd:0f,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:115 -device VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 + + + +Anyone works on the crash now? The above back trace shows it crashed at assert(s->current) ? + +Do you still have this problem with the latest released version of QEMU (see http://wiki.qemu-project.org/Download)? + +OK, since there hasn't been a reply within 6 months, I assume this is now fixed. So closing this ticket now. + diff --git a/results/classifier/108/other/1304 b/results/classifier/108/other/1304 new file mode 100644 index 00000000..9dad33d7 --- /dev/null +++ b/results/classifier/108/other/1304 @@ -0,0 +1,24 @@ +performance: 0.904 +graphic: 0.891 +device: 0.887 +network: 0.747 +semantic: 0.608 +debug: 0.559 +permissions: 0.512 +socket: 0.479 +other: 0.338 +vnc: 0.217 +KVM: 0.210 +files: 0.197 +PID: 0.171 +boot: 0.165 + +loadvm for arm vexpress-a9 +Description of problem: + +Steps to reproduce: +1. savevm test +2. loadvm test +3. After I execute savevm and loadvm,the guest is not responding +Additional information: +I have read this issue(https://github.com/panda-re/panda/issues/643). If secure is set to off,the guest works well. But I need to use security extensions,so secure cannot be set to off.What do I need to do to solve this problem？ diff --git a/results/classifier/108/other/1305402 b/results/classifier/108/other/1305402 new file mode 100644 index 00000000..32715cfa --- /dev/null +++ b/results/classifier/108/other/1305402 @@ -0,0 +1,114 @@ +KVM: 0.865 +other: 0.861 +network: 0.852 +graphic: 0.840 +debug: 0.833 +permissions: 0.826 +vnc: 0.821 +semantic: 0.813 +files: 0.813 +performance: 0.801 +socket: 0.794 +device: 0.789 +PID: 0.777 +boot: 0.744 + +libvirt fails to start VirtualMachines + +I've created several kvm based machines with the 'trusty' designation using virtual machine manager. They have operated well over the last 4 days without issue. I did an apt-get upgrade, and qemu was in the list of updates. + +After upgrading, I am unable to start any of the provisioned virtual machines with the following error output + +virsh # start node2 +error: Failed to start domain node2 +error: internal error: process exited while connecting to monitor: qemu-system-x86_64: -machine trusty,accel=kvm,usb=off: Unsupported machine type +Use -machine help to list supported machines! + + +virsh # start node3 +error: Failed to start domain node3 +error: internal error: process exited while connecting to monitor: qemu-system-x86_64: -machine trusty,accel=kvm,usb=off: Unsupported machine type +Use -machine help to list supported machines! + + + +$ dpkg -l | grep kvm +ii qemu-kvm 2.0.0~rc1+dfsg-0ubuntu3 amd64 QEMU Full virtualization on x86 hardware (transitional package) + +Log snippet from vm 'media' that was verified working, and fails to start after the upgrade. + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm-spice -name media -S -machine trusty,accel=kvm,usb=off -m 1548 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 60b20f7b-6d20-bcb3-f4fc-808a9b2fe0d0 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/media.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/media.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/home/charles/iso/ubuntu-desktop-12.04.4-amd64.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a0:69:d9,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:1 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 +char device redirected to /dev/pts/13 (label charserial0) +qemu: terminating on signal 15 from pid 31688 +2014-04-10 03:36:54.593+0000: shutting down +2014-04-10 03:59:25.487+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm-spice -name media -S -machine trusty,accel=kvm,usb=off -m 1548 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 60b20f7b-6d20-bcb3-f4fc-808a9b2fe0d0 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/media.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/media.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/home/charles/iso/ubuntu-desktop-12.04.4-amd64.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a0:69:d9,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 +qemu-system-x86_64: -machine trusty,accel=kvm,usb=off: Unsupported machine type +Use -machine help to list supported machines! +2014-04-10 03:59:25.696+0000: shutting down + +After some additional investigating it looks like the XML format for the trusty machine has changed. I created a new VM and got it to boot off my MAAS cluster, The immediate change I see is: + +new: + <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type> + +old: + <type arch='x86_64' machine='trusty'>hvm</type> + +None of the old XML machines were updated with this new machine flag. + +Thanks for reporting this bug. We briefly had a 'trusty' machine type, with a corresponding libvirt patch to handle it. When we renamed the trusty machine type we dropped the libvirt patch to handle it. + +We should either re-introduce the libvirt patch to handle the trusty machine type for those who have stale VM definitions, or mention this in the release notes. In either case we should keep this bug open to guide others who run into this problem. + +This has just happened to me. For some reason, all my machines had machine='pc-i440fx-wily'. +After an update in yakkety, they stopped working. + +$ qemu-system-x86_64 -enable-kvm -machine help | grep wily + +So I updated the machine xml to a supported machine as Charles suggested, and they work again. + +Here's the note for my future self about how to do the update: + +$ virsh dumpxml $machine-name > /tmp/machine.xml +Edit the xml. +$ virsh define /tmp/machine.xml + +Machine type changes may be related to: + +https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1626070 + +There's a PPA in the bug with a fix for at least the wily machine type. + +On Thu, Sep 22, 2016 at 6:05 PM, Leo Arias <email address hidden> wrote: + +> This has just happened to me. For some reason, all my machines had +> machine='pc-i440fx-wily'. +> After an update in yakkety, they stopped working. +> +> $ qemu-system-x86_64 -enable-kvm -machine help | grep wily +> +> So I updated the machine xml to a supported machine as Charles +> suggested, and they work again. +> +> Here's the note for my future self about how to do the update: +> +> $ virsh dumpxml $machine-name > /tmp/machine.xml +> Edit the xml. +> $ virsh define /tmp/machine.xml +> +> -- +> You received this bug notification because you are subscribed to qemu in +> Ubuntu. +> https://bugs.launchpad.net/bugs/1305402 +> +> Title: +> libvirt fails to start VirtualMachines +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1305402/+subscriptions +> + + +Yeah I'm pretty sure this is a dupe of bug 1626070. + diff --git a/results/classifier/108/other/1306818 b/results/classifier/108/other/1306818 new file mode 100644 index 00000000..dd02d196 --- /dev/null +++ b/results/classifier/108/other/1306818 @@ -0,0 +1,63 @@ +semantic: 0.640 +network: 0.611 +device: 0.610 +performance: 0.585 +other: 0.503 +files: 0.475 +socket: 0.432 +permissions: 0.404 +PID: 0.361 +graphic: 0.354 +debug: 0.289 +boot: 0.257 +vnc: 0.250 +KVM: 0.064 + +resetting moder register in opencores_eth.c code (ethernet IP core specification code) + +Hi, I would like to report a possible error in the code qemu/hw/net/opencores_eth.c + +The corresponding data sheet : http://www.cprover.org/firmware/doc/ethoc/eth_speci.pdf + + +In the code, there is a function open_eth_moder_host_write. + +static void open_eth_moder_host_write(OpenEthState *s, uint32_t val) +{ + uint32_t set = val & ~s->regs[MODER]; + + if (set & MODER_RST) { + open_eth_reset(s); + } + + s->regs[MODER] = val; + + if (set & MODER_RXEN) { + s->rx_desc = s->regs[TX_BD_NUM]; + open_eth_notify_can_receive(s); + } + if (set & MODER_TXEN) { + s->tx_desc = 0; + open_eth_check_start_xmit(s); + } +} + +This piece of code is executed when MODER (Mode Register) resister is command to updated to ‘val’. + +In case of reset, as you can see, if the MODER_RST bit (0x800) bit is set && the old MODER_RST bit (0x800) of MODER register is clear, the code falls into the if(set & MODER_RST) branch. Then, it calls open_eth_reset(s), which does “s->regs[MODER] = 0xa000;”. Now, the MODER register is reset to 0xa000. Page 9 of the data sheet (http://www.cprover.org/firmware/doc/ethoc/eth_speci.pdf) specifies the reset value of the moder is 0000A000h. So far, the code works fine. +Then, the open_eth_moder_host_write function does not end but executes but executes “s->regs[MODER] = val;” line. Now, the MODER register is not 0xa000 any more. +In fact, since the MODER_RST bit of ‘val’ is 1, now the MODER_RST bit of the MODER register becomes 1 as well. Suppose one somehow calls this open_eth_moder_host_write again with val = MODER_RST with purpose of resetting again. Since the MODER_RST bit is 1, (set = val & ~s->regs[MODER]) & MODER_RST is zero. So after this, resetting again is not possible. + +Hence, I doubt the function’s correctness here. I think it could be better if the function changes to : + + if (set & MODER_RST) { + open_eth_reset(s); + return; + } + +Please let me know if I am correct. + +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/1307225 b/results/classifier/108/other/1307225 new file mode 100644 index 00000000..ab3f74e7 --- /dev/null +++ b/results/classifier/108/other/1307225 @@ -0,0 +1,487 @@ +semantic: 0.873 +other: 0.844 +debug: 0.807 +performance: 0.794 +graphic: 0.784 +permissions: 0.780 +PID: 0.777 +device: 0.772 +KVM: 0.750 +vnc: 0.707 +files: 0.687 +boot: 0.671 +network: 0.643 +socket: 0.527 + +Running a virtual machine on a Haswell system produces machine check events + +I'm running a virtual Windows SBS 2003 installation on a Xeon E3 Haswell system running Gentoo Linux. First, I used Qemu 1.5.3 (the latest stable version on Gentoo). I got a lot of machine check events ("mce: [Hardware Error]: Machine check events logged") in dmesg that always looked like (using mcelog): + +Hardware event. This is not a software error. +MCE 7 +CPU 2 BANK 0 +TIME 1390267908 Tue Jan 21 02:31:48 2014 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 6 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 + +I found this discussion on the vmware community: https://communities.vmware.com/thread/452344 + +It seems that this is (at least partly) caused by the Qemu machine. I switched to Qemu 1.7.0, the first version to use "pc-i440fx-1.7". With this version, the errors almost disappeared, but from time to time, I still get machine check events. Anyways, they so not seem to affect neither the vm, nor the host. + +I created the virtual machine on an older Core 2 Duo machine and ran it for several weeks without a single error message, so I think this is actually some problem with the Haswell architecture. The errors didn't show up until I copied the virtual machine to my new machine. + +Still happens with qemu 2.0.0 and the same environment (Windows SBS 2003 32 bit guest on a Gentoo Linux amd64 Haswell host). + +Running the VM with "-cpu Haswell" set still causes those "Internal Parity Errors", but not so many … + +Used QEMU this morning, noticed mce error in log, searched, found this. + +* model name: Intel(R) Core(TM) i3-4130 CPU @ 3.40GHz (it's a Haswell) +* kernel 3.14.4-gentoo +* app-emulation/qemu-1.6.1 +* qemu-system-i386 -enable-kvm andsoon +* [73468.545378] mce: [Hardware Error]: Machine check events logged + +# mcelog +Hardware event. This is not a software error. +MCE 0 +CPU 0 BANK 0 +TIME 1400824994 Fri May 23 08:03:14 2014 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c07 APICID 0 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 + +I don't have anything to contribute other than that Tobias is not the only one who gets this hardware error message when using QEMU on a Haswell. + +I can confirm this. + +Using qemu-kvm for three virtual machines on Ubuntu 14.04 LTS using a Intel i7-4770 Haswell based server. + +dmesg: +[63429.847437] mce: [Hardware Error]: Machine check events logged +[65996.795630] mce: [Hardware Error]: Machine check events logged + +mcelog: +Hardware event. This is not a software error. +MCE 0 +CPU 2 BANK 0 +TIME 1406265172 Fri Jul 25 07:12:52 2014 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 + +It's the same error everytime, only APICID and CPU numbers are different. +The mce errors did not happen until i migrated the virtual machines from another system, the haswell-server was up for three days without any incidents, now, while running qemu-kvm there is a mce error every 6-12 hours. +After the first errors, i called the support of my server provider, they first exchanged RAM, upgraded BIOS... +Then, they replaced the whole server, only swapping my harddisks to the new one. But even that didn't help, i still got MCE errors. The harddisks where replaced too, one at a time (to resync raid). Now, i have a completely swapped hardware, but the MCE errors are still popping up. + +system information attached + +attachment +logfiles, dmidecode, system information + +I got a new Haswell based system a few days ago. It has been running fine without warnings but today I started a VirtualBox VM and got a MCE soon afterwards. "MCA: Internal parity error" like everyone else. From reading this bug and the vmware link in the first post it seems like this problem occurs on all virtualization solutions using hardware acceleration on Haswell based systems. It happens on Qemu, Virtualbox and Vmware and it happens on both Linux and Windows. + +Do anyone have connections within Intel and can pull some strings to have them look at this? It looks like the MCE is always non fatal but perhaps there are other unknown side effects. A microcode update might solve it. + +Try adding this to the Linux commandline, in your bootloader: + +mce=nobootlog + +From Documentation/x86/x86_64/boot-options.txt: + + mce=bootlog + Enable logging of machine checks left over from booting. + Disabled by default on AMD because some BIOS leave bogus ones. + If your BIOS doesn't do that it's a good idea to enable though + to make sure you log even machine check events that result + in a reboot. On Intel systems it is enabled by default. + mce=nobootlog + Disable boot machine check logging. + +How will this help to solve the problem? + +I think this is related to the Haswell erratum 131 of the 'Intel® Xeon® Processor E3-1200 v3 Product Family Specification Update' at: +http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e3-1200v3-spec-update.pdf + + HSW131. Spurious Corrected Errors May be Reported + Problem: Due this erratum, spurious corrected errors may be logged in the IA32_MC0_STATUS + register with the valid field (bit 63) set, the uncorrected error field (bit 61) not set, a + Model Specific Error Code (bits [31:16]) of 0x000F, and an MCA Error Code (bits + [15:0]) of 0x0005. If CMCI is enabled, these spurious corrected errors also signal interrupts. + Implication: When this erratum occurs, software may see corrected errors that are benign. These + corrected errors may be safely ignored. + Workaround: None identified. + Status: For the steppings affected, see the Summary Table of Changes + + +I propose to work around this by mce=ignore_ce, as this is a spurious 'corrected error': +From Documentation/x86/x86_64/boot-options.txt: + mce=ignore_ce + Disable features for corrected errors, e.g. polling timer + and CMCI. All events reported as corrected are not cleared + by OS and remained in its error banks. + Usually this disablement is not recommended, however if + there is an agent checking/clearing corrected errors + (e.g. BIOS or hardware monitoring applications), conflicting + with OS's error handling, and you cannot deactivate the agent, + then this option will be a help. + +But I have not tried this yet. + + +So, at least, this does not seem to be something to worry about. But anyways, why does it only happen if a virtual machine is executed? + +Just my 2 cents. I have two Haswell boxes with Ubuntu Server 14.04 each running bunch of VMs. The first one is Intel Core i7-4770K and it runs only Linux VMs. There is no single MCE here for at least one year. The second box is Intel Core i7-4790K and it runs mix of Linux and Windows 2003 VMs. MCEs regularly appear in logs here. + +mce=ignore_ce indeed "fixes" the messages. However, it will mask real (important) errors as well. + +Since Intel can't or won't correct the bug with a microcode update, how about filtering it in the kernel? + +http://svnweb.freebsd.org/base/head/sys/x86/x86/mca.c?r1=269052&r2=269051&pathrev=269052 + +I'm seeing these MCE messages too. + +My hardware is i7 4790K on a Gigabyte Z97X Gaming GT motherboard. + +I run a mixture of Linux and Windows (client and server editions) guests. Hipervisor is kvm. I'm seeing these MCE messages since I virtualized a Windows Server 2008 R2 SP1. Neither Windows XP nor Windows 8.1 guests showed any messages. + +For a few minutes I was worried my hardware was faulty, but this bug reports somewhat gives me hope the hardware is OK. + +Pasted below is my /var/log/mcelog + + + +mcelog: failed to prefill DIMM database from DMI data +Hardware event. This is not a software error. +MCE 0 +CPU 0 BANK 0 +TIME 1440943174 Sun Aug 30 10:59:34 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 0 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 1 +CPU 0 BANK 0 +TIME 1441015741 Mon Aug 31 07:09:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 0 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 0 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 1 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 2 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 3 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 4 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 5 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 6 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 7 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 8 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 9 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 10 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 11 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 12 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 13 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 0 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 0 +CPU 2 BANK 0 +TIME 1441064371 Mon Aug 31 20:39:31 2015 +MCG status: +MCi status: +Error overflow +Corrected error +Error enabled +MCA: Internal parity error +STATUS d0000200000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 + + +Minor Update: Bug occurs under Intel Skylake, too. + +System-information: Intel Core i7-6700 with 4x8 GB Samsung M378A1G43DB0-CPB DDR4-2133 RAM, Motherboard: Fujitsu D3401-H1 + + +Dec 15 06:53:30 srv01 kernel: [224214.850599] mce: [Hardware Error]: Machine check events logged +Dec 15 06:55:08 srv01 kernel: [224312.001142] mce: [Hardware Error]: Machine check events logged +Dec 15 06:57:12 srv01 kernel: [224435.836130] mce: [Hardware Error]: Machine check events logged +Dec 15 07:03:35 srv01 kernel: [224818.079136] mce: [Hardware Error]: Machine check events logged +Dec 15 07:07:55 srv01 kernel: [225077.697589] mce_notify_irq: 1 callbacks suppressed +Dec 15 07:07:55 srv01 kernel: [225077.697592] mce: [Hardware Error]: Machine check events logged +Dec 15 07:08:51 srv01 kernel: [225134.136571] mce: [Hardware Error]: Machine check events logged +Dec 15 07:12:25 srv01 kernel: [225347.598995] mce_notify_irq: 1 callbacks suppressed +Dec 15 07:12:25 srv01 kernel: [225347.598998] mce: [Hardware Error]: Machine check events logged +Dec 15 07:15:03 srv01 kernel: [225504.880462] mce: [Hardware Error]: Machine check events logged +Dec 15 07:17:49 srv01 kernel: [225670.907609] mce: [Hardware Error]: Machine check events logged +Dec 15 07:21:49 srv01 kernel: [225911.163547] mce: [Hardware Error]: Machine check events logged +Dec 15 07:22:57 srv01 kernel: [225978.227807] mce: [Hardware Error]: Machine check events logged +Dec 15 07:24:32 srv01 kernel: [226073.681985] mce: [Hardware Error]: Machine check events logged +Dec 15 07:28:31 srv01 kernel: [226312.111733] mce: [Hardware Error]: Machine check events logged +Dec 15 07:34:04 srv01 kernel: [226644.639095] mce: [Hardware Error]: Machine check events logged +Dec 15 07:35:58 srv01 kernel: [226757.904937] mce_notify_irq: 2 callbacks suppressed +Dec 15 07:35:58 srv01 kernel: [226757.904940] mce: [Hardware Error]: Machine check events logged +Dec 15 07:36:10 srv01 kernel: [226770.139237] mce: [Hardware Error]: Machine check events logged +Dec 15 07:41:14 srv01 kernel: [227073.719040] mce: [Hardware Error]: Machine check events logged +Dec 15 07:41:16 srv01 kernel: [227075.399257] mce: [Hardware Error]: Machine check events logged +Dec 15 07:44:14 srv01 kernel: [227253.699541] mce: [Hardware Error]: Machine check events logged +Dec 15 07:44:57 srv01 kernel: [227296.490305] mce: [Hardware Error]: Machine check events logged +Dec 15 07:52:44 srv01 kernel: [227762.621344] mce: [Hardware Error]: Machine check events logged +Dec 15 07:52:49 srv01 kernel: [227767.372259] mce: [Hardware Error]: Machine check events logged +Dec 15 07:54:39 srv01 kernel: [227877.219677] mce_notify_irq: 1 callbacks suppressed +Dec 15 07:54:39 srv01 kernel: [227877.219680] mce: [Hardware Error]: Machine check events logged +... + +mcelog: Family 6 Model 5e CPU: only decoding architectural errors +Hardware event. This is not a software error. +MCE 29 +CPU 0 BANK 0 +TIME 1450162369 Tue Dec 15 07:52:49 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 9000004000010005 MCGSTATUS 0 +MCGCAP c0a APICID 0 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 94 +mcelog: Family 6 Model 5e CPU: only decoding architectural errors +Hardware event. This is not a software error. +MCE 30 +CPU 2 BANK 0 +TIME 1450162422 Tue Dec 15 07:53:42 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 9000004000010005 MCGSTATUS 0 +MCGCAP c0a APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 94 +mcelog: Family 6 Model 5e CPU: only decoding architectural errors +Hardware event. This is not a software error. +MCE 31 +CPU 1 BANK 0 +TIME 1450162479 Tue Dec 15 07:54:39 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 9000004000010005 MCGSTATUS 0 +MCGCAP c0a APICID 2 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 94 + + + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I'm not sure if this can still be reproduces but I've found a workaround quite a while ago. The problem disappeared once I migrated the virtual machines using 32 bit OS images to 64 bit. The mix of 32 and 64 bit VMs was the causing these problems at least on my server. + +Last time I saw this error in my mcelog was in August. Probably, some update fixed it. I'll check the next days/weeks if I still see it. This is a quite long time, at the time of my original bug report, I got the errors multiple times a day and later multiple times a week. + +About the workaround moving to 64 bit OS images: Well, if you're (like in my case) stuck with dinosaur OS (Windows SBS 2003), there's no way to simply move to a 64 bit image ;-) + +But as said: I think it simply disappeared by some update. I'm using 2.10.0 at the moment. + +The errors still keep appearing. The mcelog still shows the exact errors posted in the very fist comment. + + +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/101 + + diff --git a/results/classifier/108/other/1307281 b/results/classifier/108/other/1307281 new file mode 100644 index 00000000..4f8c18e1 --- /dev/null +++ b/results/classifier/108/other/1307281 @@ -0,0 +1,30 @@ +KVM: 0.722 +vnc: 0.580 +performance: 0.566 +other: 0.561 +permissions: 0.539 +device: 0.513 +network: 0.509 +graphic: 0.503 +socket: 0.497 +boot: 0.488 +semantic: 0.484 +files: 0.480 +PID: 0.449 +debug: 0.421 + +qemu crash with assertion in usb_packet_complete_one + +qemu release verison: 1.7.1 +guest os : win7 32bits +qemu cmdline: +/usr/bin/qemu-system-x86_64 -name hch_test -S -machine pc-i440fx-1.7,accel=kvm,usb=off -cpu SandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=12,threads=2 -uuid 5ad433c9-e490-42f3-b365-c30d756fbd70 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/hch_test.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=0 -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/opt/cvm/hch_test/hch_test.inst,if=none,id=drive-virtio-disk0,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/opt/data/hugedisk/hch_test/hch_test_share.add,if=none,id=drive-virtio-disk1,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:f2:05:b7,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/hch_test.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -spice port=5903,addr=0.0.0.0,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -readconfig /etc/qemu/ich9-ehci-uhci.cfg -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0 -chardev spicevmc,name=usbredir,id=usbredirchardev2 -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0 -chardev spicevmc,name=usbredir,id=usbredirchardev3 -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0 + +i use spice to connect to vm and utilize usb redirection. i plug a u-disk into a remote computer and start copy a big file (3G+) to u-disk and qemu was crashed in the middle of the transmission. + +i check the qemu log and found this log: "qemu-system-x86_64: hw/usb/core.c:438: usb_packet_complete_one: Assertion `p->stream || ((&ep->queue)->tqh_first) == p' failed". this crash can be reproduced every time. + +Triaging old bug tickets ... Can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1308341 b/results/classifier/108/other/1308341 new file mode 100644 index 00000000..6fd0342e --- /dev/null +++ b/results/classifier/108/other/1308341 @@ -0,0 +1,186 @@ +other: 0.901 +permissions: 0.898 +vnc: 0.892 +KVM: 0.890 +socket: 0.885 +boot: 0.884 +network: 0.882 +device: 0.882 +debug: 0.882 +semantic: 0.879 +performance: 0.879 +files: 0.875 +graphic: 0.875 +PID: 0.864 + +Multiple CPUs causes blue screen on Windows guest (14.04 regression) + +Configuring a Windows 7 guest using more than one CPU cases the guest to fail. This happens after a few hours after guest boot. This is the error on the blue screen: +"A clock interrupt was not received on a secondary processor within the allocated time interval" + +After resetting, the guest will never boot and a new bluescreen with the error "STOP: 0x0000005c" appears. Shutting down the guest completely and restarting it will allow it to boot and run for a few hours again. + +The guest was created using virt-manager. The error happens with or without virtio devices. + + + + + +The command line used to start the guest (from log file): +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm-spice -name win7-test -S -machine pc-i440fx-trusty,accel=kvm,usb=off -m 4096 -realtime mlock=off -smp 4,sockets=1,cores=4,threads=1 -uuid bc6a3c93-2221-4b61-ed29-07edda0a2043 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7-test.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/mnt/sw-test-nas/win7-test.img,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=34 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:d6:60:55,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:2 -device VGA,id=video0,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 + + +Status changed to 'Confirmed' because the bug affects multiple users. + +I have Windows 7 32bit, and Windows 2008 R2 both expirence this problem, info from Windows 7 BSOD +Host system for this VM is Dell R510, qemu-kvm_2.0.0~rc1+dfsg-0ubuntu3_amd64.deb + +VM command line: + +qemu-system-x86_64 -enable-kvm -name win7_kc -S -machine pc-1.0,accel=kvm,usb=off -cpu kvm64,+rdtscp,+pdpe1gb,+dca,+xtpr,+tm2,+est,+vmx,+ds_cpl,+monitor,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 2048 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 6358fe75-bef9-3b4a-da4e-d0842e880d4f -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7_kc.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -drive file=/home/VM/win7_kc.img,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/mnt/a/virtio-win-0.1-74.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=31,id=hostnet0,vhost=on,vhostfd=34 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:09:18:1c,bus=pci.0,addr=0x3 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5901,addr=10.50.0.11,disable-ticketing,plaintext-channel=main,image-compression=auto_glz,seamless-migration=on -k pl -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x6 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 + + +libvirt xml + +BTW, my installation was an upgrade from Ubuntu 10.04 to 12.04. Motherboard is a dual socket Xeon fra ASUS with two E5-2630 v2 CPUs. + +Sorry, I meant from 12.04 to 14.04. 12.04 was a fresh installation. Hyper-threading is enabled. + +My instalation was upgraded from 12.04 to 14.04, as well. My machine have 2 CPU, so I set Windows 7 VM to be the only guest using CPU2 (1,3,5,7,9,11,13,15) , the error still persists. + +It look like adding "hyperv" in "features" section to guest definition helps, my Win7 VM now is running for ~12h, when without "hyperv" it was like 3-4 hour. I will test it for few days and will post here again. + + <features> + <acpi/> + <apic/> + <pae/> + <hyperv> + <relaxed state='on'/> + </hyperv> + </features> + + +Adding "hyperv" seemed to work for me too. + +Thanks, it sounds like at least we should have that enabled by default when, in virt-manager, a windows guest is selected. + +Status changed to 'Confirmed' because the bug affects multiple users. + +After adding "hyperv" feature, the guest freezes regularly. This happens on both and Windows 7 64-bit and Windows 2012 R2 guests. When removing the "hyperv" feature the guest acts normally, but fails with a blue screen as before. This may be a completely different issue, but this renders the workaround unusable for me at least. + +Hallo to all, this is my first post here. + +I have exactly the same problem occurred after Distribution Update Ubuntu Server x64 from 12.04.4 to 14.04. + +1. I have Windows 7 32/64-Bit and Windows 2008 Server 64-Bit VMs, all show the same error with two dedicated cores (no pinning). In combination with the other statements I would say it is a general Windows problem - not specific. + +2. I have an AMD Opteron 6272 (fam: 15, model: 01, stepping: 02, 16 cores) system. Therefore, this problem does not seem to be Intel/AMD architecture-specific. + +3. I configured a couple of VMs ONE core and let it run over the weekend. They didn't crashing, but they reacted only very slowly an choppy. It seems that there is a fundamental error, which is responsible for the multi-core errors. After restarting the VM, the error is initially gone, even though the VM is still slow due to only one core. + +4. I have the latest virtio drivers are installed in the Windows guest systems and use the devices Red Hat VirtIO SCSI and Ethernet (vers. 61.65.104.7400) drivers. Are these drivers installed in your VMs or do you use the IDE/SATA and RTL/Intel-NIC standard driver? + +5. The VM images (qcow2) are located on a mdadm Raid1 volume of two SSDs. Since Linux kernel 3.7 ATA TRIM is possible with Linux software RAID, so I use the mount option 'discard'. I do not want to completely exclude the possibility that the error has to do with it. + +Is there now an indication of the cause of the failure and possibly even a workaround? + +I have done clean install of the server and yes, Windows VM freezes with hyperv before as well as after reinstall. I'm have reverted my servers to 12.04.4 until this is solved. +Krzysiek + +Tried to reproduce this overnight with a windows 8 instance run by hand with 4 cores, but no hang. I'll keep trying with some more options added from your command line. + +-smp 4 -realtime mlock=off -rtc base=localtime does not seem to help me reproduce this. + +Does the system have to be under stress? + +Can you reproduce this without virtio? + +I was able to work around this by downgrading the kernel on a Ubuntu 14 box to 3.12.20-031220-generic #201405160935 (and of course wasn't seeing this with Ubuntu 12). + +I've periodically tried booting back to the standard Ubuntu 14 3.13 kernel to see if it's been fixed (and also tried 3.13-lowlatency) but I get a W2k8R2 server hang with KVM within the first ~24 hours of boot each time. + +This is a dual-processor machine. Also, with 3.13, I was getting these messages on a semi-periodic basis (may be related): + +May 30 20:23:53 kernel: [ 0.000000] Linux version 3.13.0-27-lowlatency (buildd@akateko) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #50-Ubuntu SMP PREEMPT Thu May 15 18:36:04 UTC 2014 (Ubuntu 3.13.0-27.50-lowlatency 3.13.11 + +May 31 14:15:40 kernel: [64348.760175] INFO: task qemu-system-x86:4151 blocked for more than 120 seconds. +May 31 14:15:40 kernel: [64348.767491] Not tainted 3.13.0-27-lowlatency #50-Ubuntu +May 31 14:15:40 kernel: [64348.773291] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. +May 31 14:15:40 kernel: [64348.781205] qemu-system-x86 D ffff881fffc34600 0 4151 1 0x00000000 +May 31 14:15:40 kernel: [64348.781210] ffff881fcf5e3de8 0000000000000002 ffff881fbf140000 ffff881fcf5e3fd8 +May 31 14:15:40 kernel: [64348.781215] 0000000000014600 0000000000014600 ffff881fbf140000 ffff881fbf140000 +May 31 14:15:40 kernel: [64348.781218] ffff883fcfac7060 ffff883fcfac7068 00007f3809e00000 ffff881fbf140000 +May 31 14:15:40 kernel: [64348.781221] Call Trace: +May 31 14:15:40 kernel: [64348.781230] [<ffffffff81722b89>] schedule+0x29/0x70 +May 31 14:15:40 kernel: [64348.781237] [<ffffffff8172552d>] rwsem_down_read_failed+0xcd/0x130 +May 31 14:15:40 kernel: [64348.781243] [<ffffffff81374b04>] call_rwsem_down_read_failed+0x14/0x30 +May 31 14:15:40 kernel: [64348.781247] [<ffffffff81725007>] ? down_read+0x17/0x20 +May 31 14:15:40 kernel: [64348.781252] [<ffffffff810a0db2>] task_numa_work+0xd2/0x300 +May 31 14:15:40 kernel: [64348.781254] [<ffffffff8109f87b>] ? account_user_time+0x8b/0xa0 +May 31 14:15:40 kernel: [64348.781259] [<ffffffff81089e87>] task_work_run+0xa7/0xe0 +May 31 14:15:40 kernel: [64348.781264] [<ffffffff81014e57>] do_notify_resume+0x97/0xb0 +May 31 14:15:40 kernel: [64348.781268] [<ffffffff8172e52a>] int_signal+0x12/0x17 + +I'm not seeing any kernel errors with the 3.12 kernel. + + +Thanks, given that info it seems clear to be a kernel and not a qemu bug. + +(Removed the task against virt-manager since hyperv is apparently *not* a safe workaround in all cases) + +This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run: + +apport-collect 1308341 + +and then change the status of the bug to 'Confirmed'. + +If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'. + +This change has been made by an automated script, maintained by the Ubuntu Kernel Team. + +marking as confirmed, see bug 1332409 with the apport-collect information. + +Re-installing 14.04 fixed my problem. Running with the same virtual machine configurations on the same hardware without any problems. No hyperv feature needed. + +Could it be DUP of https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1307473 ? + +I agree. This seems to me like a duplicate of bug 1307473. + +Just wanted to add that upgrading my kernel to a newer version fixed the problem for me, too. + +Host: 2x E5-2620V2, Ubuntu 14.04 LTS +Guest: 24 virtual cores, Windows Server 2008 R2 + +Before fix: +sudo uname -a +Linux x.contabo.net 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:22:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux +Bluescreen stop 0x0000005c every few hours + +After fix: +sudo uname -a +Linux x.contabo.net 3.16.0-23-generic #31-Ubuntu SMP Tue Oct 21 17:56:17 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux +No Bluescreens or other crashes since 7 days under full load + +Upgraded with this tutorial http://askubuntu.com/questions/541775/how-can-i-install-ubuntu-14-10s-kernel-in-ubuntu-14-04-lts + +Same bluescreen again on day 9 after the kernel upgrade. + +So upgrading Kernel from 3.13 to 3.16 did not help. + +Still looking for a fix. + +I have same problem after crash not help restarting virtual pc on next boot bsod with c5 code persist. I must force off machine and pover on. + + +Same issue there. 2 VMs with 2008 sp2 x86, and 2008 R2 sp1 x64 hanging simultaneously with BSOD stop 0x0000005c (0x0000010b 0x00000003 0x00000000) +Issue arrised after upgrading kernel from 3.12 to 3.13. +Nothing helps to workaround this issue so far. + +Same problem +I using kernel 3.16.0-55-generic, Ubuntu 14.04 + +Hi, + +could you please file a new bug with debugging information as per https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1346917/comments/11 ? + + diff --git a/results/classifier/108/other/1308381 b/results/classifier/108/other/1308381 new file mode 100644 index 00000000..e8e2e129 --- /dev/null +++ b/results/classifier/108/other/1308381 @@ -0,0 +1,101 @@ +performance: 0.825 +graphic: 0.807 +device: 0.793 +debug: 0.789 +PID: 0.786 +other: 0.778 +files: 0.768 +vnc: 0.762 +permissions: 0.749 +boot: 0.749 +socket: 0.709 +network: 0.693 +KVM: 0.628 +semantic: 0.520 + +illegal instructions for AArch64 ARMv8 + +The test case is in the attachment. To reproduce as following (I tried both GCC and Clang): +$aarch64-linux-gnu-gcc qemu.c -o test +$./test +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) + +There are 3 intrinsics are tested in the test case: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: +SQXTUN Bd, Hn +SQXTUN Hd, Sn +SQXTUN Sd, Dn. + +It seems that these instructions are not supported in QEMU. Is this a bug? + + + +Can you attach a statically linked test case binary, please? + + + +Peter Maydell <email address hidden> writes: + +> Can you attach a statically linked test case binary, please? + +I can reproduce with the source file. It looks like: + +@@ -7553,12 +7555,9 @@ static void disas_simd_scalar_two_reg_misc(DisasContext *s, uint32_t insn) + } + break; + case 0x12: /* SQXTUN */ +- if (u) { +- unallocated_encoding(s); +- return; +- } + /* fall through */ + +Fixes it. Let me check why this slipped through the risu tests and +re-validate. I'll submit a patch once I've double checked. + +-- +Alex Bennée + + + +On 16 April 2014 11:55, Alex Bennée <email address hidden> wrote: +> +> Peter Maydell <email address hidden> writes: +> +>> Can you attach a statically linked test case binary, please? +> +> I can reproduce with the source file. It looks like: +> +> @@ -7553,12 +7555,9 @@ static void disas_simd_scalar_two_reg_misc(DisasContext *s, uint32_t insn) +> } +> break; +> case 0x12: /* SQXTUN */ +> - if (u) { +> - unallocated_encoding(s); +> - return; +> - } +> /* fall through */ +> +> Fixes it. + +However the ARM ARM, unless I'm misreading it, requires scalar-2-misc +SQXTUN to have U==1, so the correct fix should be to turn that "if (u)" +into "if (!u)" I think. (Opcode 0x12 u==0 isn't in the table so should undef.) + +Better check we didn't make the same mistake in the vector-2-misc +decode as well. + +thanks +-- PMM + + +Fix identified + +I've sent this patch to the mailing list but it fixes the attached test case and has been tested with risu patterns. + +@pmaydell: yeah vector is unaffected as U is used to select another opcode. + +Patch had been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e44a90c59697cf98 +==> Fix released + diff --git a/results/classifier/108/other/1309 b/results/classifier/108/other/1309 new file mode 100644 index 00000000..f829538c --- /dev/null +++ b/results/classifier/108/other/1309 @@ -0,0 +1,16 @@ +network: 0.893 +graphic: 0.813 +device: 0.748 +performance: 0.730 +debug: 0.249 +vnc: 0.199 +boot: 0.102 +PID: 0.060 +KVM: 0.040 +socket: 0.037 +semantic: 0.029 +other: 0.021 +permissions: 0.011 +files: 0.003 + +Heap-overflow in virtio_net_queue_enable diff --git a/results/classifier/108/other/1309034 b/results/classifier/108/other/1309034 new file mode 100644 index 00000000..eabb2838 --- /dev/null +++ b/results/classifier/108/other/1309034 @@ -0,0 +1,50 @@ +KVM: 0.812 +graphic: 0.788 +device: 0.757 +semantic: 0.722 +boot: 0.677 +other: 0.660 +PID: 0.651 +permissions: 0.631 +socket: 0.617 +files: 0.569 +debug: 0.557 +network: 0.548 +performance: 0.499 +vnc: 0.487 + +A way not to grab keyboards or mice + +I set up the window manager to move windows with Alt-Btn1, and to +iconify windows with Shift-Btn1. But since qemu grabs keyboards and +mice, I can't move or iconify the qemu window. + +I tried not to grab anything, by inserting return, just beginnig of +ui/sdl.c:sdl_grab_start() as follows: + +static void sdl_grab_start(void) +{ + return; + /* + +It is comfortable. I'm glad if you make a way not to grab. +Environment variables, options, etc are welcome. + +Current command line is: +QEMU_AUDIO_DRV=pa /usr/local/bin/qemu-system-x86_64 -enable-kvm -hda /dosc/win8_x64.img -soundhw hda -boot c -m 2G -cpu Nehalem,+sep -usb -usbdevice tablet -display sdl -rtc base=localtime + +qemu version is: +luna:linux % qemu-system-x86_64 --version +QEMU emulator version 1.7.93, Copyright (c) 2003-2008 Fabrice Bellard +luna:linux % + +Host: slackware64 14.1 +Host Environment: xfce4 / sawfish +Guest: Windows 8.1 x64 + +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.] + |