diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/103 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1030 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1030104 | 47 | ||||
| -rw-r--r-- | results/classifier/108/other/1030807 | 73 | ||||
| -rw-r--r-- | results/classifier/108/other/1031920 | 82 | ||||
| -rw-r--r-- | results/classifier/108/other/1031955 | 63 | ||||
| -rw-r--r-- | results/classifier/108/other/1033494 | 30 | ||||
| -rw-r--r-- | results/classifier/108/other/1034 | 32 | ||||
| -rw-r--r-- | results/classifier/108/other/1034423 | 369 | ||||
| -rw-r--r-- | results/classifier/108/other/1035042 | 32 | ||||
| -rw-r--r-- | results/classifier/108/other/1036363 | 118 | ||||
| -rw-r--r-- | results/classifier/108/other/1037606 | 146 | ||||
| -rw-r--r-- | results/classifier/108/other/1037675 | 202 | ||||
| -rw-r--r-- | results/classifier/108/other/1038070 | 134 | ||||
| -rw-r--r-- | results/classifier/108/other/1039 | 16 |
15 files changed, 1376 insertions, 0 deletions
diff --git a/results/classifier/108/other/103 b/results/classifier/108/other/103 new file mode 100644 index 00000000..88d8999c --- /dev/null +++ b/results/classifier/108/other/103 @@ -0,0 +1,16 @@ +files: 0.860 +device: 0.736 +network: 0.730 +performance: 0.640 +other: 0.434 +permissions: 0.368 +boot: 0.361 +PID: 0.348 +semantic: 0.328 +socket: 0.299 +debug: 0.268 +vnc: 0.205 +graphic: 0.129 +KVM: 0.009 + +9pfs does not honor open file handles on unlinked files diff --git a/results/classifier/108/other/1030 b/results/classifier/108/other/1030 new file mode 100644 index 00000000..487fe024 --- /dev/null +++ b/results/classifier/108/other/1030 @@ -0,0 +1,16 @@ +performance: 0.784 +semantic: 0.490 +other: 0.378 +debug: 0.324 +graphic: 0.299 +device: 0.285 +KVM: 0.210 +permissions: 0.198 +vnc: 0.159 +boot: 0.147 +network: 0.104 +socket: 0.058 +PID: 0.045 +files: 0.020 + +Property 'rv32-riscv-cpu.x-v' not found diff --git a/results/classifier/108/other/1030104 b/results/classifier/108/other/1030104 new file mode 100644 index 00000000..b799b614 --- /dev/null +++ b/results/classifier/108/other/1030104 @@ -0,0 +1,47 @@ +performance: 0.640 +device: 0.622 +debug: 0.577 +network: 0.558 +files: 0.549 +other: 0.526 +socket: 0.524 +permissions: 0.506 +semantic: 0.473 +PID: 0.440 +graphic: 0.427 +vnc: 0.314 +boot: 0.287 +KVM: 0.060 + +Parallel build doesn't work after "make clean" + +After running "make clean" qemu won't build with -j option. +When I run "./configure && make clean" and then make -j5, following errors occur: + GEN config-host.h + GEN trace.h + GEN qemu-options.def + GEN qmp-commands.h + GEN qapi-types.h + GEN qapi-visit.h + GEN tests/test-qapi-types.h + GEN tests/test-qapi-visit.h + GEN tests/test-qmp-commands.h + GEN qapi-generated/qga-qapi-types.h + GEN qapi-generated/qga-qapi-visit.h + GEN qapi-generated/qga-qmp-commands.h + CC osdep.o + CC qemu-thread-posix.o +cc1: error: qapi-generated: No such file or directory [-Werror] +cc1: all warnings being treated as errors + +make: *** [qemu-thread-posix.o] Error 1 +make: *** Waiting for unfinished jobs.... +cc1: error: qapi-generated: No such file or directory [-Werror] +cc1: all warnings being treated as errors + +make: *** [osdep.o] Error 1 + +If you run "make -j5" once again after this, build continues succesfully because "qapi-generated" directory already exists. + +I think this should have been fixed at one point in time - at least it seems to work for me, so I'm closing this ticket now. If you still have problems, feel free to open this ticket again, but then please specify the exact version of QEMU which causes the trouble for you. + diff --git a/results/classifier/108/other/1030807 b/results/classifier/108/other/1030807 new file mode 100644 index 00000000..d08cb109 --- /dev/null +++ b/results/classifier/108/other/1030807 @@ -0,0 +1,73 @@ +graphic: 0.894 +other: 0.818 +socket: 0.766 +files: 0.758 +device: 0.757 +permissions: 0.754 +network: 0.753 +performance: 0.721 +semantic: 0.719 +boot: 0.715 +PID: 0.690 +debug: 0.685 +vnc: 0.627 +KVM: 0.571 + +PCI host bridge should ignore 1- and 2-byte I/O accesses + +In PCI there are two IO modes. Deprecated Mode2 that uses single byte IO and Mode1 that uses 4byte IO. +According to the spec a host bridge that supports Mode1 should ignore all IO that is not 4bytes. + +> Anytime a host bridge sees a full DWORD I/O write from the host to +> CONFIG_ADDRESS, the bridge must latch the data into its CONFIG_ADDRESS +> register. On full DWORD I/O reads to CONFIG_ADDRESS, the bridge must return the +> data in CONFIG_ADDRESS. Any other types of accesses to this address (non-DWORD) +> have no effect on CONFIG_ADDRESS and are executed as normal I/O transactions on +> the PCI bus. Therefore, the only I/O Space consumed by this register is a DWORD at the +> given address. I/O devices that share the same address but use BYTE or WORD registers +> are not affected because their transactions will pass through the host bridge unchanged. + +In qemu the host bridge will accept 1-, 2-, and 4-byte reads/writes. That breakes plan9 guests that do not use the bios to access the PCI config space. + +have a look at: +http://code.google.com/p/plan9front/source/browse/sys/src/9/pc/pci.c + +In Lines 960-967 the check for PCI Mode1 is done. This check assumes that the 4-byte write at line 961 succeeds and the single byte write at 962 is ignored. +On qemu line 962 will not be ignored and the test in line 963 will fail. +The plan9 kernel will fall back to Mode2 which does not work. +The result is that the guest will not see any PCI devices. + +I do not really have an image that you guys could quickly check this with, but i could prepare one if need be. +An easy way to reproduce this in linux would be to stick an outb between those two lines from pci_check_type1(void). + +> outl(0x80000000, 0xCF8); ++ outb0x01, 0xcfb); +> if (inl(0xCF8) == 0x80000000 && pci_sanity_check(&pci_direct_conf1)) { + +I did not try this but i guess on real hardware the linux kernel would still work while it would not work anymore on qemu. + +I tried to come up with a patch but did not find a quick solution. I found that in hw/piic_pci.c sysbus_add_io is used which will register read/write functions for 1, 2, and 4 bytes. This is done in ioport.c ioport_register. I guess if i provided a patch you guys might not like it :). So i figured i should report the bug, let me know if you need any additional information. + +I tried the following quick fix but the BIOS does not seem to like that. + + + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +Cc'ing Julia (can't find her on Launchpad) because this looks +similar to a bug she has been tracking. + +On 8/7/20 10:08 AM, Thomas Huth wrote: +> Looking through old bug tickets... is this still an issue with the +> latest version of QEMU? Or could we close this ticket nowadays? +> +> +> ** Changed in: qemu +> Status: New => Incomplete +> + + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1031920 b/results/classifier/108/other/1031920 new file mode 100644 index 00000000..c16ae444 --- /dev/null +++ b/results/classifier/108/other/1031920 @@ -0,0 +1,82 @@ +other: 0.849 +files: 0.769 +debug: 0.759 +performance: 0.728 +device: 0.672 +semantic: 0.657 +graphic: 0.603 +PID: 0.594 +network: 0.558 +permissions: 0.471 +socket: 0.461 +vnc: 0.412 +boot: 0.392 +KVM: 0.358 + +Linux user gdbserver does not respond to remote `Ctrl-C' interrupts + +The bug was reproduce in a recent mainline build for ARM Linux by starting emulation with a gdbserver: + +$ qemu-arm -g 1234 a.out + +and then connecting from gdb: + +(gdb) target remote :1234 +Remote debugging using :1234 +[New Remote target] +[Switching to Remote target] +0x00008ba8 in _start () +(gdb) b main +Breakpoint 1 at 0x8cb0: file hello.c, line 5. +(gdb) cont +Continuing. + +Breakpoint 1, main (argc=1, argv=0xf6fff24c) at hello.c:5 +5 int n = 0; +(gdb) l +1 #include <stdio.h> +2 +3 int main (int argc, char **argv) +4 { +5 int n = 0; +6 +7 for (;;) { +8 printf ("Hello, World!\n"); +9 sleep (5); +10 } +(gdb) cont +Continuing. +^C^CInterrupted while waiting for the program. +Give up (and stop debugging it)? (y or n) y + +Notice that the `Ctrl-C' interrupts are ignored. + +I have encountered that issue recently, and started some analysis. + +The issue is due to the fact that in qemu, gdbstub no longer reads the communication channel once +the debugged process is resumed with "cont". +Another way to say that, is that communication with gdb is only possible once the process thread execution +is re-routed in the gdb handler. + +I am working on a fix. + +The fix will consist in having an additional thread, launched that the internal gdbserver startup, +that will be wakeup when the debugged process is resumed. +That thread will be waiting on the communication channel for the eventually incoming CTRL-C request (0x3) +I start to have promising results but it still needs some testing. + +Meanwhile, (this should likely be a separate discussion thread, but is somehow related with the named issue above) , +I also noticed that with multithreaded +processes, a breakpoint does not suspend all the threads when it is hit. +This is a little bit annoying, and does not match the expected behaviour that is typically seen on a pure native gdb debugging +session. + +Once it is ready I will post a patch to qemu mailing list + +Best regards +Thierry + +Has the fix mentioned in comment #1 been included in the QEMU repository? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1031955 b/results/classifier/108/other/1031955 new file mode 100644 index 00000000..b5a15362 --- /dev/null +++ b/results/classifier/108/other/1031955 @@ -0,0 +1,63 @@ +graphic: 0.635 +device: 0.521 +socket: 0.481 +performance: 0.434 +semantic: 0.363 +permissions: 0.328 +PID: 0.325 +network: 0.265 +other: 0.228 +files: 0.221 +vnc: 0.202 +boot: 0.200 +debug: 0.199 +KVM: 0.105 + +qemu-system-arm -M lm3s811evb fails + +I am trying out examples from StellarisWare. + +When I try the uart_echo example, that initially tries to talk to the +display, I get this: + + $ .../qemu-1.1.1/bin/qemu-system-arm -M lm3s811evb -kernel uart_echo/gcc/uart_echo.bin + qemu: hardware error: strllaris_i2c_read: Bad offset 0xfc0 + + CPU #0: + R00=00000001 R01=005b8d80 R02=00061a80 R03=007a11ff + R04=40020000 R05=005b8d80 R06=00000002 R07=00000000 + R08=00000000 R09=00000000 R10=00000000 R11=00000000 + R12=00000000 R13=200000d4 R14=00000995 R15=000009cc + PSR=20000173 --C- T svc32 + Aborted + +The example is located in boards/ek-lm3s811/uart_echo in the +StellarisWare distribution. + +With the latest from git: + + $ .../qemu-git/qemu/bin/qemu-system-arm -M lm3s811evb -kernel uart_echo/gcc/uart_echo.bin + qemu-system-arm: hw/qdev.c:310: qdev_get_gpio_in: Assertion `n >= 0 && n < dev->num_gpio_in' failed. + +This however seems to be reported already (Bug #1028260). + +Both versions compiled from sources: + + ./configure --target-list=arm-linux-user,arm-softmmu,armeb-linux-user --enable-sdl --prefix=/path/to/... + +Running Ubunti 10.04 with Linux 2.6.32-40-generic-pae. + +/Lars + +I applied the patch from "Bug #1028260". Now I get the same behaviour with the git version as I get from 1.1.1., i.e. + + qemu: hardware error: strllaris_i2c_read: Bad offset 0xfc0 + ... + +/Lars + +Triaging old bug tickets ... can you still reproduce this issue with the +latest version of QEMU (version 2.9)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1033494 b/results/classifier/108/other/1033494 new file mode 100644 index 00000000..427d014f --- /dev/null +++ b/results/classifier/108/other/1033494 @@ -0,0 +1,30 @@ +graphic: 0.738 +device: 0.668 +KVM: 0.557 +network: 0.466 +performance: 0.422 +socket: 0.395 +other: 0.379 +boot: 0.341 +semantic: 0.330 +debug: 0.297 +vnc: 0.292 +files: 0.245 +PID: 0.236 +permissions: 0.230 + +qemu-system-x86_64 segfaults with kernel 3.5.0 + +qemu-kvm 1.1.1 stable is running fine for me with RHEL 6 2.6.32 based kernel. + +But with 3.5.0 kernel qemu-system-x86_64 segfaults while i'm trying to install ubuntu 12.04 server reproducable. + +You find three backtraces here: +http://pastebin.com/raw.php?i=xCy2pEcP + +Stefan + +this thread and this fix http://thread.gmane.org/gmane.comp.emulators.kvm.devel/95314/focus=1338226 are about the same issue, apparently. Please try it and see if it fixes you issue too. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1034 b/results/classifier/108/other/1034 new file mode 100644 index 00000000..2379f9da --- /dev/null +++ b/results/classifier/108/other/1034 @@ -0,0 +1,32 @@ +semantic: 0.805 +performance: 0.737 +graphic: 0.658 +device: 0.564 +other: 0.491 +permissions: 0.479 +PID: 0.357 +network: 0.323 +boot: 0.322 +socket: 0.317 +debug: 0.295 +vnc: 0.235 +files: 0.205 +KVM: 0.157 + +Erlang/OTP 25 JIT on AArch64 fails in user mode emulation +Description of problem: +Compiling Erlang/OTP 25 fails with segfault when using user mode (but works in system mode), the Erlang devs have tracked it down in [ErlangForums](https://erlangforums.com/t/otp-25-0-rc3-release-candidate-3-is-released/1317/24) and give this explanation: + +> Thanks, I’ve found a bug in QEMU that explains this. The gist of it is: +> +> Instead of interpreting guest code, QEMU dynamically translates it to the host architecture. When the guest overwrites code for one reason or another, the translation is invalidated and redone if needed. +> +> Our JIT:ed code is mapped in two regions to work in the face of W^X restrictions: one executable but not writable, and one writable but not executable. Both of these regions point to the same physical memory and writes to the writable region are “magically” reflected in the executable one. +> +> I would’ve expected QEMU to honor the IC IVAU / ISB instructions we use to tell the processor that we’ve altered code at a particular address, but for some reason QEMU just ignores them 3 and relies entirely on trapping writes to previously translated code. +> +> In system mode QEMU emulates the MMU and sees that these two regions point at the same memory, and has no problem invalidating the executable region after writing to the writable region. +> +> In user mode it instead calls mprotect(..., PROT_READ) on all code regions it has translated, and invalidates translations in the signal handler. The problem is that we never write to the executable region – just the writable one – so the code doesn’t get invalidated. + +There doesn't seem to a open or closed QEMU bug that actually describes this problem. diff --git a/results/classifier/108/other/1034423 b/results/classifier/108/other/1034423 new file mode 100644 index 00000000..1c1d83de --- /dev/null +++ b/results/classifier/108/other/1034423 @@ -0,0 +1,369 @@ +permissions: 0.908 +semantic: 0.905 +graphic: 0.902 +other: 0.893 +network: 0.885 +device: 0.873 +KVM: 0.845 +PID: 0.832 +vnc: 0.825 +socket: 0.822 +boot: 0.816 +debug: 0.809 +performance: 0.788 +files: 0.754 + +Guests running OpenIndiana (and relatives) fail to boot on AMD hardware + +First observed with OpenSolaris 2009.06, and also applies to the latest OpenIndiana release. + +Version: qemu-kvm 1.1.1 + +Hardware: + +2 x AMD Opteron 6128 8-core processors, 64GB RAM. + +These guests boot on equivalent Intel hardware. + +To reproduce: + +qemu-kvm -nodefaults -m 512 -cpu host -vga cirrus -usbdevice tablet -vnc :99 -monitor stdio -hda drive.img -cdrom oi-dev-151a5-live-x86.iso -boot order=dc + +I've tested with "-vga std" and various different emulated CPU types, to no effect. + +What happens: + +GRUB loads, and offers multiple boot options, but none work. Some kind of kernel panic flies by very fast before restarting the VM, and careful use of the screenshot button reveals that it reads as follows: + +panic[cpu0]/thread=fec22de0: BAD TRAP: type=8 (#df Double fault) rp=fec2b48c add r=0 + +#df Double fault +pid=0, pc=0xault +pid=0, pc=0xfe800377, sp=0xfec40090, eflags=0x202 +cr0: 80050011<pg,wp,et,pe> cr4:b8<pge,pae,pse,de> +cr2: 0cr3: ae2f000 + gs: 1b0 fs: 0 es: 160 ds: 160 + edi: 0 esi: 0 ebp: 0 esp: fec2b4c4 + ebx: c0010015 edx: 0 ecx: 0 eax: fec40400 + trp: 8 err: 0 eip: fe800377 cs: 158 + efl: 202 usp: fec40090 ss: 160 +tss.tss_link: 0x0 +tss.tss_esp0: 0x0 +tss.tss_ss0: 0x160 +tss.tss_esp1: 0x0 +tss.tss_ss1: 0x0 +tss.tss esp2: 0x0 +tss.tss_ss2: 0x0 +tss.tss_cr3: 0xae2f000 +tss.tss_eip: 0xfec40400 +tss.tss_eflags: 0x202 +tss.tss_eax: 0xfec40400 +tss.tss_ebx: 0xc0010015 +tss.tss_ecx: 0xc0010000 +tss.tss_edx: 0x0 +tss.tss_esp: 0xfec40090 + +Warning - stack not written to the dumpbuf +fec2b3c8 unix:due+e4 (8, fec2b48c, 0, 0) +fec2b478 unix:trap+12fa (fec2b48c, 0, 0) +fec2b48c unix:_cmntrap+7c (1b0, 0, 160, 160, 0) + +If there's any more, I haven't managed to catch it. + +Solaris 11 does not seem to suffer from the same issue, although the first message that appears at boot (after the version info) is "trap: Unkown trap type 8 in user mode". Could be related? + +As always, thanks in advance and please let me know if I can help to test, or provide any more information. + +Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU (currently v2.9)? + +This is an old ticket! I had completely forgotten about it, but will test +when I get a chance and let you know. + +Cheers, + +Owen + +On Fri, May 19, 2017 at 11:25 AM, Thomas Huth <email address hidden> +wrote: + +> Triaging old bug tickets ... can you still reproduce this issue with the +> latest version of QEMU (currently v2.9)? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1034423 +> +> Title: +> Guests running OpenIndiana (and relatives) fail to boot on AMD +> hardware +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> First observed with OpenSolaris 2009.06, and also applies to the +> latest OpenIndiana release. +> +> Version: qemu-kvm 1.1.1 +> +> Hardware: +> +> 2 x AMD Opteron 6128 8-core processors, 64GB RAM. +> +> These guests boot on equivalent Intel hardware. +> +> To reproduce: +> +> qemu-kvm -nodefaults -m 512 -cpu host -vga cirrus -usbdevice tablet +> -vnc :99 -monitor stdio -hda drive.img -cdrom oi-dev- +> 151a5-live-x86.iso -boot order=dc +> +> I've tested with "-vga std" and various different emulated CPU types, +> to no effect. +> +> What happens: +> +> GRUB loads, and offers multiple boot options, but none work. Some kind +> of kernel panic flies by very fast before restarting the VM, and +> careful use of the screenshot button reveals that it reads as follows: +> +> panic[cpu0]/thread=fec22de0: BAD TRAP: type=8 (#df Double fault) +> rp=fec2b48c add r=0 +> +> #df Double fault +> pid=0, pc=0xault +> pid=0, pc=0xfe800377, sp=0xfec40090, eflags=0x202 +> cr0: 80050011<pg,wp,et,pe> cr4:b8<pge,pae,pse,de> +> cr2: 0cr3: ae2f000 +> gs: 1b0 fs: 0 es: +> 160 ds: 160 +> edi: 0 esi: 0 ebp: +> 0 esp: fec2b4c4 +> ebx: c0010015 edx: 0 ecx: 0 eax: +> fec40400 +> trp: 8 err: 0 eip: fe800377 +> cs: 158 +> efl: 202 usp: fec40090 ss: 160 +> tss.tss_link: 0x0 +> tss.tss_esp0: 0x0 +> tss.tss_ss0: 0x160 +> tss.tss_esp1: 0x0 +> tss.tss_ss1: 0x0 +> tss.tss esp2: 0x0 +> tss.tss_ss2: 0x0 +> tss.tss_cr3: 0xae2f000 +> tss.tss_eip: 0xfec40400 +> tss.tss_eflags: 0x202 +> tss.tss_eax: 0xfec40400 +> tss.tss_ebx: 0xc0010015 +> tss.tss_ecx: 0xc0010000 +> tss.tss_edx: 0x0 +> tss.tss_esp: 0xfec40090 +> +> Warning - stack not written to the dumpbuf +> fec2b3c8 unix:due+e4 (8, fec2b48c, 0, 0) +> fec2b478 unix:trap+12fa (fec2b48c, 0, 0) +> fec2b48c unix:_cmntrap+7c (1b0, 0, 160, 160, 0) +> +> If there's any more, I haven't managed to catch it. +> +> Solaris 11 does not seem to suffer from the same issue, although the +> first message that appears at boot (after the version info) is "trap: +> Unkown trap type 8 in user mode". Could be related? +> +> As always, thanks in advance and please let me know if I can help to +> test, or provide any more information. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1034423/+subscriptions +> + + +[Expired for QEMU because there has been no activity for 60 days.] + +Despite the age of the report, I am also reproducing the issue. + +I am using Qemu 6.2.0 with KVM on Linux kernel 6.0.5 under Linux Mint 21. + +The guest is OpenIndiana Hipster 2021.10. + +A guest console capture is attached. + +The guest is managed using libvirt 8.0.0 + +The dump of the libvirt domain configuration is as follows: + +<domain type='kvm' id='62'> + <name>openindiana</name> + <uuid>7a7adcc0-889c-4daf-a73b-21a3fac3d8e7</uuid> + <metadata> + <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> + <libosinfo:os id="http://libosinfo.org/linux/2020"/> + </libosinfo:libosinfo> + </metadata> + <memory unit='KiB'>2097152</memory> + <currentMemory unit='KiB'>2097152</currentMemory> + <vcpu placement='static'>4</vcpu> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-i440fx-jammy'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE_4M.fd</loader> + <nvram template='/usr/share/OVMF/OVMF_VARS_4M.fd'>/var/lib/libvirt/qemu/nvram/openindiana_VARS.fd</nvram> + </os> + <features> + <acpi/> + <apic/> + <vmport state='off'/> + </features> + <cpu mode='host-passthrough' check='none' migratable='on'/> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/srv/vhd/openindiana.qcow2' index='2'/> + <backingStore/> + <target dev='sda' bus='sata'/> + <alias name='sata0-0-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/srv/img/OI-hipster-minimal-20211031.iso' index='1'/> + <backingStore/> + <target dev='sdb' bus='sata'/> + <readonly/> + <boot order='1'/> + <alias name='sata0-0-1'/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <alias name='usb'/> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <alias name='usb'/> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <alias name='usb'/> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='ide' index='0'> + <alias name='ide'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </controller> + <controller type='sata' index='0'> + <alias name='sata0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </controller> + <interface type='network'> + <mac address='52:54:00:20:40:9c'/> + <source network='default' portid='77a38fbb-c35e-4f78-b377-e823963eb30e' bridge='virbr0'/> + <target dev='vnet61'/> + <model type='e1000'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/3'/> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/3'> + <source path='/dev/pts/3'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <channel type='spicevmc'> + <target type='virtio' name='com.redhat.spice.0' state='disconnected'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='tablet' bus='usb'> + <alias name='input0'/> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'> + <alias name='input1'/> + </input> + <input type='keyboard' bus='ps2'> + <alias name='input2'/> + </input> + <graphics type='spice'> + <listen type='none'/> + <image compression='off'/> + </graphics> + <sound model='ac97'> + <alias name='sound0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <audio id='1' type='spice'/> + <video> + <model type='vga' vram='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <redirdev bus='usb' type='spicevmc'> + <alias name='redir0'/> + <address type='usb' bus='0' port='2'/> + </redirdev> + <redirdev bus='usb' type='spicevmc'> + <alias name='redir1'/> + <address type='usb' bus='0' port='3'/> + </redirdev> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </memballoon> + </devices> + <seclabel type='dynamic' model='apparmor' relabel='yes'> + <label>libvirt-7a7adcc0-889c-4daf-a73b-21a3fac3d8e7</label> + <imagelabel>libvirt-7a7adcc0-889c-4daf-a73b-21a3fac3d8e7</imagelabel> + </seclabel> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+64055:+130</label> + <imagelabel>+64055:+130</imagelabel> + </seclabel> +</domain> + + +This bug tracker here is not used anymore. Could you please open a new ticket here: + +https://gitlab.com/qemu-project/qemu/-/issues + +Thanks! + diff --git a/results/classifier/108/other/1035042 b/results/classifier/108/other/1035042 new file mode 100644 index 00000000..68948f73 --- /dev/null +++ b/results/classifier/108/other/1035042 @@ -0,0 +1,32 @@ +graphic: 0.683 +semantic: 0.548 +device: 0.488 +files: 0.430 +socket: 0.394 +network: 0.362 +vnc: 0.227 +performance: 0.208 +boot: 0.167 +other: 0.147 +PID: 0.090 +permissions: 0.085 +debug: 0.063 +KVM: 0.061 + +Inconsistency in x509-dh-key-file parameter + +Hello, + +At source it is x509-dh-file, at config[2] it is x509-dh-key-file, at man[3] it is also x509-dh-key-file. + +I guess that [1] is not correct? + +Thanks! + +[1] http://git.qemu.org/?p=qemu.git;a=blob;f=ui/spice-core.c;h=4fc48f89026944fa91c4be349436041e97fc8654;hb=HEAD#l615 +[2] http://git.qemu.org/?p=qemu.git;a=blob;f=qemu-config.c;h=5c3296b8c6f0ec85201579f9a5f4e085adc33314;hb=HEAD#l498 +[3] http://git.qemu.org/?p=qemu.git;a=blob;f=qemu-options.hx;h=5e7d0dc035978945e692efe3ef063b6a69e73b29;hb=HEAD#l888 + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=9995c0b706a2270a49c + diff --git a/results/classifier/108/other/1036363 b/results/classifier/108/other/1036363 new file mode 100644 index 00000000..bc55ffe1 --- /dev/null +++ b/results/classifier/108/other/1036363 @@ -0,0 +1,118 @@ +other: 0.809 +performance: 0.785 +permissions: 0.782 +semantic: 0.736 +graphic: 0.722 +device: 0.711 +network: 0.708 +PID: 0.699 +KVM: 0.668 +debug: 0.633 +files: 0.600 +vnc: 0.496 +boot: 0.477 +socket: 0.379 + +Major network performance problems on AMD hardware + +Hi, + +I am experiencing some major performance problems with all of our beefy AMD Opteron 6274 servers running Fedora 17 (kernel 3.4.4-5.fc17.x86_64, qemu 1.0-17). The network performance between host and the virtual machine is terrible: + +# iperf -c 10.10.11.22 -r +------------------------------------------------------------ +Server listening on TCP port 5001 +TCP window size: 85.3 KByte (default) +------------------------------------------------------------ +------------------------------------------------------------ +Client connecting to 10.10.11.22, TCP port 5001 +TCP window size: 197 KByte (default) +------------------------------------------------------------ +[ 5] local 10.10.11.199 port 44192 connected with 10.10.11.22 port 5001 +[ ID] Interval Transfer Bandwidth +[ 5] 0.0-10.0 sec 2.45 GBytes 2.11 Gbits/sec +[ 4] local 10.10.11.199 port 5001 connected with 10.10.11.22 port 42601 +[ 4] 0.0-10.0 sec 8.97 GBytes 7.71 Gbits/sec + +So the VM's receive is super slow. I would be happy with 7.71 Gbps because it's closer to matching the speed of the 10G ethernet adapters but the iSCSI drive's write performance is few times faster than read. Now running a similar test on the slowest machine I have, Intel core i3 I see this: + +# iperf -c 192.168.7.60 -r +------------------------------------------------------------ +Server listening on TCP port 5001 +TCP window size: 85.3 KByte (default) +------------------------------------------------------------ +------------------------------------------------------------ +Client connecting to 192.168.7.60, TCP port 5001 +TCP window size: 306 KByte (default) +------------------------------------------------------------ +[ 5] local 192.168.7.98 port 53992 connected with 192.168.7.60 port 5001 +[ ID] Interval Transfer Bandwidth +[ 5] 0.0-10.0 sec 22.5 GBytes 19.3 Gbits/sec +[ 4] local 192.168.7.98 port 5001 connected with 192.168.7.60 port 53339 +[ 4] 0.0-10.0 sec 25.1 GBytes 21.5 Gbits/sec + +As you can image this is a huge difference in network IO. Most setups are identical down to the same versions. Vhost-net is enabled and it appears to use MSI-X on the VM. I've tried all kinds of settings and while they improve performance a little I feel it's just masking a bigger problem. All 12 of my AMD servers have this issue and it appears I'm not the only one complaining. Any help would be appreciated. Thanks. + +I would also like to add that a VM running Windows 2008 R2 is having the same identical problem too. + +Well this is embarrasing. Other Intel KVMs are having the same problem. The test where I got 20 gbps was actually on a Fedora 16 VM running on Fedora 16 KVM. I reinstalled both KVM and VM with Fedora 17 and best I got was 4 gbps. + +I ran another test and here is a recap: + +F16 KVM <-- 20gbps --> F16 VM +F17 KVM <-- 4 gbps --> 16 VM +F17 KVM <-- 4 gbps --> 17 VM + +I'll check F16 KVM with both F16 and F17 VMs. This is all done on my Intel core i3. + +Executed another test: + +F16 KVM <-- 15 gbps --> F17 VM + +So why is F16 much faster? + +On Sun, Aug 26, 2012 at 1:08 AM, Ziemowit Pierzycki +<email address hidden> wrote: +> Executed another test: +> +> F16 KVM <-- 15 gbps --> F17 VM +> +> So why is F16 much faster? + +You could try "bisecting" to find the change that slowed down networking: + +$ git clone git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git +$ cd qemu-kvm + +# Test qemu-kvm 0.15.0, which F16 qemu-kvm is based on +$ git checkout qemu-kvm-0.15.0 +$ ./configure && make +$ ...run test... + +# Test qemu-kvm 1.0, which F17 qemu-kvm is based on +$ git checkout qemu-kvm-1.0 +$ ./configure && make +$ ...run test... + +If the 0.15.0 vs 1.0 results show the same change as F16 vs F17, then +you can use git-bisect(1): + +$ git bisect start qemu-kvm-1.0 qemu-kvm-0.15.0 + +http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html +http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search + +The bisect will leave you at a commit where the performance regression +was introduced. + +Stefan + + +Thank Stefan, + +I compiled both 0.15 and 1.0 and they do not have that problem... but Fedora package does. Perhaps the way Fedora package was compiled? I'm going to grab a source package and attempt to compile from that. + +Okay, looks like the performance issue started with introduction of pc-0.15 machine profile in version 1.0.1. I'll narrow the problem down further. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + diff --git a/results/classifier/108/other/1037606 b/results/classifier/108/other/1037606 new file mode 100644 index 00000000..85ae942a --- /dev/null +++ b/results/classifier/108/other/1037606 @@ -0,0 +1,146 @@ +other: 0.919 +permissions: 0.890 +debug: 0.858 +device: 0.857 +KVM: 0.843 +vnc: 0.820 +graphic: 0.812 +semantic: 0.805 +PID: 0.793 +network: 0.756 +performance: 0.755 +boot: 0.754 +socket: 0.720 +files: 0.684 + +vmwgfx does not work with kvm vmware vga + +vmwgfx driver fails to initialize inside kvm. + +tried: kvm -m 2048 -vga vmware -cdrom RebeccaBlackLinux.iso (Ubuntu based, any Ubuntu live CD would do) + + + +This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run: + +apport-collect 1037606 + +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. + +There is screenshot of the error message. + +The message reads + +*ERROR* Hardware has no pichlock + + +This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run: + +apport-collect 1037606 + +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. + +Since the error prevents graphical environment from starting and apport-collect requires a graphical browser to post the data it collects it is not useful to run. + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.6 kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages. + +Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. Please only remove that one tag and leave the other tags. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. + +If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'. + +If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'. + +If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'. +Once testing of the upstream kernel is complete, please mark this bug as "Confirmed". + + +Thanks in advance. + +[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc3-quantal/ + +This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug. + +If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report. + +[0] https://wiki.ubuntu.com/Bugs/Upstream/kernel + +i am also having this problem on amd64 debian sid, using: + + qemu 1.7.0+dfsg-5 + +on the guest system, i'm also running sid: + + linux-image-amd64 3.13+56 + xserver-xorg-video-vmware 1:13.0.1-3+b1 + +i added vmwgfx to /etc/modules, trying to follow the directions here (aside from using VMware Play, etc.): + + http://www.x.org/wiki/vmware/vmware3D/ + +however, that only gives me the bug sooner than Michael. + +[ 1.590515] [drm] Initialized drm 1.1.0 20060810 +[ 1.598096] [drm] DMA map mode: Using physical TTM page addresses. +[ 1.598131] [drm] Capabilities: +[ 1.598132] [drm] Rect copy. +[ 1.598133] [drm] Cursor. +[ 1.598133] [drm] Cursor bypass. +[ 1.598134] [drm] Cursor bypass 2. +[ 1.598135] [drm] VRAM at 0xfd000000 size is 16384 kiB +[ 1.598136] [drm] MMIO at 0xfe000000 size is 64 kiB +[ 1.598138] [drm] global init. +[ 1.601643] [TTM] Zone kernel: Available graphics memory: 512610 kiB +[ 1.601646] [TTM] Initializing pool allocator +[ 1.601649] [TTM] Initializing DMA pool allocator +[ 1.601657] [drm] No GMR memory available. Graphics memory resources are very limited. +[ 1.601718] [drm:vmw_driver_load] *ERROR* Hardware has no pitchlock +[ 1.601971] [TTM] Finalizing pool allocator +[ 1.601975] [TTM] Finalizing DMA pool allocator +[ 1.602006] [TTM] Zone kernel: Used memory at exit: 0 kiB +[ 1.602724] vmwgfx: probe of 0000:00:02.0 failed with error -38 + + +the bug on the kernel bug tracker is marked as "resolved obsolete", not "confirmed". + +https://bugzilla.kernel.org/show_bug.cgi?id=46711 is marked as WILLNOTFIX, so I'm closing the QEMU bug here, too. + +The kernel bugzilla response is: + +The vmwgfx kernel module does not support devices without the pitchlock capability. Sorry. In that case you need to use the xf86-video-vmware driver standalone without kernel modesetting. + +So presumably this is some capability to be added to the qemu device + +Also http://airlied.livejournal.com/69291.html + +OK, got your point ... but AFAIK the vmware display device in QEMU is pretty much unmaintened anyway, so unless someone steps up and takes care of this device, I think the WONT-FIX status is appropriate for this bug. + diff --git a/results/classifier/108/other/1037675 b/results/classifier/108/other/1037675 new file mode 100644 index 00000000..fa1b68a4 --- /dev/null +++ b/results/classifier/108/other/1037675 @@ -0,0 +1,202 @@ +other: 0.700 +device: 0.649 +permissions: 0.588 +network: 0.584 +PID: 0.577 +vnc: 0.568 +boot: 0.563 +debug: 0.562 +KVM: 0.536 +performance: 0.528 +socket: 0.500 +semantic: 0.487 +graphic: 0.464 +files: 0.388 + +Guest Kernel Panic if using "-cpu host" in qemu-kvm 1.1.1 + +After Upgrading to qemu-kvm-1.1.1-r1 from version 1.0.1-r1 my virtual machines (running gentoo linux) panic at intel_pmu_init. (detailed information including stacktrace are in the uploaded screenshot). When i remove the "-cpu host" option, the system starts normally. + +the command line from whicht the system is bootet: + +qemu-kvm -vnc :7 -usbdevice tablet -daemonize -m 256 -drive file=/data/virtual_machines/wgs-l08.img,if=virtio -boot c -k de -net nic,model=virtio,macaddr=12:12:00:12:34:63,vlan=0 -net tap,ifname=qtap6,script=no,downscript=no,vlan=0 -smp 2 -enable-kvm -cpu host -monitor unix:/var/run/qemu-kvm/wgs-l08.monitor,server,nowait + +also reported on gentoo bug tracker (with some more details of the host): https://bugs.gentoo.org/show_bug.cgi?id=431640 + + + +First of all, your kernel panic screenshot is incomplete: it lacks the most important information which were scrolled off the (virtual) screen. Please enable serial console and capture whole OOPs in a text form. + +Second, it isn't clear whenever this is HOST kernel panic or GUEST kernel panic. I assume it is guest. + +Third, you nevrer said which guest (kernel) it is. + +And forth, gentoo is very well known for breaking qemu-kvm by their "hardened" patches. Disable the hardening and retry. + +/mjt + +sorry for the not very usefull information i provides above. + +i will try to reproduce the the failure with a vailla kernel (host) in a few days. currently the server is in use and cannot be restarted. + +the kernel panic was in the guest (thought this is clear by "my vm panic"). If it is reproducable with a vannilla kernel (host) i will provide more detailed information here. the vm is using a 3.3.8 gentoo kernel (not hardened). + +I have the same issue, but not on hardened. +Tried for 1-2 hours to send the output to serial console but failed. +The text below is what I posted at https://bugs.gentoo.org/show_bug.cgi?id=431640#c8: +############### + +Same issue here (same screenshot with qemu-kvm-1.1.1-r1), but not on hardened. +Happens with 1.1.1-r3 with a different panic message (not the one +mentioned in bug #431444) + +I fail miserably at "sending output to serial console or file", if anyone +would help me there I could provide the entire output of the kernel panic. + +Below is what I've found out to far: +(Tests with qemu-kvm-1.1.1-r1) + +Analysis: +========= +Happens with the following LiveCDs: +- Fedora-17-x86_64-netinst.iso: uname -r = 3.3.4-5.fc17.x86_64; image: /LiveOS/squashfs.img +- pentoo-x86_64-2012.0_beta1.7.iso: uname -r = 3.4.2-pentoo; image: image.squashfs + +Does not happen with: +- pentoo-x86_64-2009.0.iso: uname -r = 2.6.31-pentoo-r3; image: image.squashfs +- (Gentoo) install-amd64-minimal-20120621.iso: uname -r = 3.2.12-gentoo; image.squashfs +- systemrescuecd-x86-2.8.1.iso (64bit kernel): uname -r = 3.2.23-std281-amd64: sysrcd.dat + +Tried installing qemu-kvm-1.1.1-r1 without the 2 patches, no difference. + +Guess: +====== +This seems to happen only with newer guest-kernels (on newer CPUs). + +Hardware-Info: +============== +see attachments + +Correcting myself (comment #2): + +> And forth, gentoo is very well known for breaking qemu-kvm by their "hardened" patches. Disable the hardening and retry. + +I mean the (host) KERNEL hardering, not qemu-kvm userspace hardering there. Sorry for any potential confusion. + +thx for the patience, i am currently very busy, therefore this took a bit longer than it was planed: + +- using a non hardened kernel (gentoo-sources-3.3.8) does not resolve the issue + +therefore i need to use the serial console, which is somewhat new to me. i will do this as soon as i find some time. i am still on it ;) + +ok getting the serial console to work was not that hard. here is the relevant serial output of the failing guest (full output is attached as file): + +[ 0.010706] mce: CPU supports 10 MCE banks +[ 0.011279] ACPI: Core revision 20110623 +[ 0.014769] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.025876] CPU0: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz stepping 07 +[ 0.027998] Performance Events: +[ 0.027998] general protection fault: 0000 [#1] SMP +[ 0.027998] CPU 0 +[ 0.027998] Modules linked in: +[ 0.027998] +[ 0.027998] Pid: 1, comm: swapper/0 Not tainted 3.2.12-gentoo #1 Bochs Bochs +[ 0.027998] RIP: 0010:[<ffffffff81aa553f>] [<ffffffff81aa553f>] intel_pmu_init+0x283/0x85e +[ 0.027998] RSP: 0018:ffff88000f8b9ea0 EFLAGS: 00000202 +[ 0.027998] RAX: 0000000000000003 RBX: 0000000000000000 RCX: 0000000000000345 +[ 0.027998] RDX: 0000000000000003 RSI: 0000000007280202 RDI: ffffffff81a7efa8 +[ 0.027998] RBP: ffff88000f8b9eb0 R08: 0000000000000000 R09: ffffffff81a7ee70 +[ 0.027998] R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff81aa4955 +[ 0.027998] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 +[ 0.027998] FS: 0000000000000000(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000 +[ 0.027998] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b +[ 0.027998] CR2: 0000000000000000 CR3: 0000000001a05000 CR4: 00000000000006f0 +[ 0.027998] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 0.027998] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +[ 0.027998] Process swapper/0 (pid: 1, threadinfo ffff88000f8b8000, task ffff88000f8b0000) +[ 0.027998] Stack: +[ 0.027998] 0000000000000000 ffffffff81b1b550 ffff88000f8b9ef0 ffffffff81aa4989 +[ 0.027998] 0000000000000040 ffffffff81a800d8 ffff88000f8b9f20 ffffffff81b1b550 +[ 0.027998] ffffffff81aa4955 0000000000000000 ffff88000f8b9f20 ffffffff810002ea +[ 0.027998] Call Trace: +[ 0.027998] [<ffffffff81aa4989>] init_hw_perf_events+0x34/0x3ef +[ 0.027998] [<ffffffff81aa4955>] ? check_bugs+0x2d/0x2d +[ 0.027998] [<ffffffff810002ea>] do_one_initcall+0x7a/0x12c +[ 0.027998] [<ffffffff81a9eb45>] kernel_init+0x7a/0x141 +[ 0.027998] [<ffffffff814963b4>] kernel_thread_helper+0x4/0x10 +[ 0.027998] [<ffffffff81a9eacb>] ? start_kernel+0x339/0x339 +[ 0.027998] [<ffffffff814963b0>] ? gs_change+0xb/0xb +[ 0.027998] Code: 48 d3 e0 48 ff c8 41 ff ca 48 89 05 b4 99 fd ff 7e 2b 83 e2 1f b8 03 00 00 00 83 fa 02 b9 45 03 00 00 0f 4f c2 89 05 91 99 fd ff <0f> 32 48 c1 e2 20 89 c0 48 09 c2 48 89 15 ef 99 fd ff e8 cf be +[ 0.027998] RIP [<ffffffff81aa553f>] intel_pmu_init+0x283/0x85e +[ 0.027998] RSP <ffff88000f8b9ea0> +[ 0.029015] ---[ end trace 4eaa2a86a8e2da22 ]--- +[ 0.030006] swapper/0 used greatest stack depth: 5576 bytes left +[ 0.031005] Kernel panic - not syncing: Attempted to kill init! +[ 0.032006] Pid: 1, comm: swapper/0 Tainted: G D 3.2.12-gentoo #1 +[ 0.033000] Call Trace: +[ 0.034003] [<ffffffff8148d64e>] panic+0x8c/0x198 +[ 0.035005] [<ffffffff8103e1f0>] do_exit+0x98/0x7d8 +[ 0.036005] [<ffffffff8103c564>] ? kmsg_dump+0x46/0xd2 +[ 0.037007] [<ffffffff81490078>] oops_end+0xb1/0xb9 +[ 0.038001] [<ffffffff81004bd9>] die+0x55/0x60 +[ 0.039005] [<ffffffff8148fd30>] do_general_protection+0x12e/0x136 +[ 0.040001] [<ffffffff81aa4955>] ? check_bugs+0x2d/0x2d +[ 0.041005] [<ffffffff8148f83f>] general_protection+0x1f/0x30 +[ 0.042001] [<ffffffff81aa4955>] ? check_bugs+0x2d/0x2d +[ 0.043004] [<ffffffff81aa553f>] ? intel_pmu_init+0x283/0x85e +[ 0.044001] [<ffffffff81aa4989>] init_hw_perf_events+0x34/0x3ef +[ 0.045005] [<ffffffff81aa4955>] ? check_bugs+0x2d/0x2d +[ 0.046003] [<ffffffff810002ea>] do_one_initcall+0x7a/0x12c +[ 0.047003] [<ffffffff81a9eb45>] kernel_init+0x7a/0x141 +[ 0.048000] [<ffffffff814963b4>] kernel_thread_helper+0x4/0x10 +[ 0.049000] [<ffffffff81a9eacb>] ? start_kernel+0x339/0x339 +[ 0.050008] [<ffffffff814963b0>] ? gs_change+0xb/0xb + + + +i started trace-cmd as suggested on http://www.linux-kvm.org/page/Tracing and started the vm. after the panic i aborted trace-cmd and here is the trace file + +i forgot to mention that the PID was 27374 + +I had exactly the same problem using custom kernel on Debian GNU/Linux / qemu-kvm 1.1.1 or 1.2.0. + +CPU: Intel(R) Xeon(R) CPU E5-2667 0 @ 2.90GHz stepping 7 microcode 0x70b + +I have two solutions: (VERY UGGLY) patch the kernel to remove intel perf events (hardware events): + +--- ../linux-3.4.10-fai-server/arch/x86/kernel/cpu/perf_event.c 2012-08-27 00:02:10.000000000 +0200 ++++ arch/x86/kernel/cpu/perf_event.c 2012-09-10 18:56:11.870774243 +0200 +@@ -1324,7 +1328,8 @@ + struct event_constraint *c; + int err; + +- pr_info("Performance Events: "); ++ pr_info("Performance Events: (DISABLED BY UGGLY PATCH)"); ++ return 0; + + switch (boot_cpu_data.x86_vendor) { + case X86_VENDOR_INTEL: + + +*OR* + +Add support for KVM Guest in the *GUEST* kernel config: + + ++CONFIG_KVM_CLOCK=y ++CONFIG_KVM_GUEST=y ++CONFIG_PARAVIRT=y ++# CONFIG_PARAVIRT_SPINLOCKS is not set ++CONFIG_PARAVIRT_CLOCK=y + + +changing the guest config to enable paravirt seems to do the trick! + +I am seeing more or less the same thing. I am trying to boot Puppy Linux from Gentoo with qemu-kvm-1.1.1-r3 and gentoo-sources-3.6.0. Interestingly, I also found that AROS crashed when using "-cpu host" but I initially chalked that up to AROS being flakey - perhaps not. Obviously I can't enable those kernel options in AROS and I don't want to have to build my own Puppy kernel. + +You can pass the level=9 param to disable the PMU emulation, this should fix your issue as well. ( e.g. -cpu host,level=9 ) + +Is there still something left to do here or can we close this bug nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1038070 b/results/classifier/108/other/1038070 new file mode 100644 index 00000000..f60f233e --- /dev/null +++ b/results/classifier/108/other/1038070 @@ -0,0 +1,134 @@ +other: 0.940 +device: 0.932 +permissions: 0.929 +PID: 0.920 +semantic: 0.920 +performance: 0.898 +KVM: 0.897 +graphic: 0.896 +debug: 0.872 +boot: 0.848 +vnc: 0.844 +files: 0.844 +network: 0.825 +socket: 0.824 + +> qemu-kvm-1.1.1-r1 - USB activkey doesn't work anymore + +Linux Distro: Gentoo + +Smartcard Activkey doesn't work anymore. I use it without problem till version +qemu-kvm-1.0.1. + +Follow a log extraction: +2012-08-14 16:27:34.751+0000: 5487: error : qemuProcessReadLogOutput:1298 : +internal error Process exited while reading console log output: char device +redirected to /dev/pts/40 +ccid-card-emulated: failed to initialize vcard +qemu-system-x86_64: -device +ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device +'ccid-card-emulated' could not be initialized + +2012-08-14 16:28:01.018+0000: 5486: error : qemuProcessReadLogOutput:1298 : +internal error Process exited while reading console log output: char device +redirected to /dev/pts/40 +ccid-card-emulated: failed to initialize vcard +qemu-system-x86_64: -device +ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device +'ccid-card-emulated' could not be initialized + +If you need any other info please tell me. + +I've tried with git version with same problem. + +On Fri, Aug 17, 2012 at 12:50:14PM -0000, linuxale wrote: +> Public bug reported: +> +> Linux Distro: Gentoo +> +> Smartcard Activkey doesn't work anymore. I use it without problem till version +> qemu-kvm-1.0.1. +> +> Follow a log extraction: +> 2012-08-14 16:27:34.751+0000: 5487: error : qemuProcessReadLogOutput:1298 : +> internal error Process exited while reading console log output: char device +> redirected to /dev/pts/40 +> ccid-card-emulated: failed to initialize vcard +> qemu-system-x86_64: -device +> ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device +> 'ccid-card-emulated' could not be initialized +> +> 2012-08-14 16:28:01.018+0000: 5486: error : qemuProcessReadLogOutput:1298 : +> internal error Process exited while reading console log output: char device +> redirected to /dev/pts/40 +> ccid-card-emulated: failed to initialize vcard +> qemu-system-x86_64: -device +> ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device +> 'ccid-card-emulated' could not be initialized +> +> If you need any other info please tell me. + +I've tried 1.1.1 and current upstream with a Windows 7 guest and the +device seems to show up and function properly in both cases. + +One way that I *can* reproduce the error is by running your command-line +with an NSS database at some place other than the default search path +(/etc/pki/nssdb in 1.1 and upstream). I don't think this has changed +since 1.0, but maybe something changed on the distro side? + +Can you try reproducing by compiling from upstream source? + +> +> I've tried with git version with same problem. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1038070 +> +> Title: +> > qemu-kvm-1.1.1-r1 - USB activkey doesn't work anymore +> +> Status in QEMU: +> New +> +> Bug description: +> Linux Distro: Gentoo +> +> Smartcard Activkey doesn't work anymore. I use it without problem till version +> qemu-kvm-1.0.1. +> +> Follow a log extraction: +> 2012-08-14 16:27:34.751+0000: 5487: error : qemuProcessReadLogOutput:1298 : +> internal error Process exited while reading console log output: char device +> redirected to /dev/pts/40 +> ccid-card-emulated: failed to initialize vcard +> qemu-system-x86_64: -device +> ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device +> 'ccid-card-emulated' could not be initialized +> +> 2012-08-14 16:28:01.018+0000: 5486: error : qemuProcessReadLogOutput:1298 : +> internal error Process exited while reading console log output: char device +> redirected to /dev/pts/40 +> ccid-card-emulated: failed to initialize vcard +> qemu-system-x86_64: -device +> ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device +> 'ccid-card-emulated' could not be initialized +> +> If you need any other info please tell me. +> +> I've tried with git version with same problem. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1038070/+subscriptions +> + + +Have you ever tried to reproduce this with the upstream QEMU version? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1039 b/results/classifier/108/other/1039 new file mode 100644 index 00000000..926aff63 --- /dev/null +++ b/results/classifier/108/other/1039 @@ -0,0 +1,16 @@ +device: 0.758 +performance: 0.739 +graphic: 0.494 +network: 0.248 +debug: 0.148 +permissions: 0.146 +semantic: 0.104 +boot: 0.052 +other: 0.035 +vnc: 0.018 +files: 0.009 +socket: 0.009 +PID: 0.005 +KVM: 0.001 + +Building qemu in MSYS2 clangarm64 |