diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/131 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1310 | 205 | ||||
| -rw-r--r-- | results/classifier/108/other/1310324 | 95 | ||||
| -rw-r--r-- | results/classifier/108/other/1310714 | 196 | ||||
| -rw-r--r-- | results/classifier/108/other/1311 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1311614 | 137 | ||||
| -rw-r--r-- | results/classifier/108/other/1312561 | 93 | ||||
| -rw-r--r-- | results/classifier/108/other/1313816 | 48 | ||||
| -rw-r--r-- | results/classifier/108/other/1314 | 55 | ||||
| -rw-r--r-- | results/classifier/108/other/1314293 | 28 | ||||
| -rw-r--r-- | results/classifier/108/other/1314667 | 128 | ||||
| -rw-r--r-- | results/classifier/108/other/1315 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1315257 | 70 | ||||
| -rw-r--r-- | results/classifier/108/other/1315747 | 31 | ||||
| -rw-r--r-- | results/classifier/108/other/1316 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1318091 | 70 | ||||
| -rw-r--r-- | results/classifier/108/other/1318281 | 53 | ||||
| -rw-r--r-- | results/classifier/108/other/1318474 | 35 | ||||
| -rw-r--r-- | results/classifier/108/other/1319100 | 150 |
19 files changed, 1458 insertions, 0 deletions
diff --git a/results/classifier/108/other/131 b/results/classifier/108/other/131 new file mode 100644 index 000000000..b9f500575 --- /dev/null +++ b/results/classifier/108/other/131 @@ -0,0 +1,16 @@ +device: 0.862 +performance: 0.818 +network: 0.451 +graphic: 0.446 +semantic: 0.343 +socket: 0.177 +files: 0.174 +debug: 0.168 +boot: 0.166 +other: 0.137 +PID: 0.078 +vnc: 0.067 +permissions: 0.033 +KVM: 0.000 + +QEMU's default msrs handling causes Windows 10 64 bit to crash diff --git a/results/classifier/108/other/1310 b/results/classifier/108/other/1310 new file mode 100644 index 000000000..3de5c8e32 --- /dev/null +++ b/results/classifier/108/other/1310 @@ -0,0 +1,205 @@ +graphic: 0.918 +other: 0.908 +semantic: 0.835 +performance: 0.829 +permissions: 0.821 +debug: 0.809 +vnc: 0.806 +device: 0.759 +KVM: 0.728 +socket: 0.690 +network: 0.673 +boot: 0.668 +PID: 0.645 +files: 0.616 + +qemu-nbd export img and detect block if is zero with libnbd +Description of problem: +In our project,we use qemu-nbd to export a img,and use libnbd to read/write data.if the img is preallocated,we wonder the data block if is zero,we use api nbd_block_status in libnbd to get the block status,but it shows server does not support structured replies: Operation not supported.I know our qemu is too old.so,i want to know how can i know if the block in preallocated is zero or not in nbd client. +Steps to reproduce: +1.qemu-nbd -p 8889 -f raw a.img + +2.the nbd client use libnbd,code is: +```c +#include <config.h> + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <assert.h> +#include <stdbool.h> +#include <errno.h> + +#include <libnbd.h> + +static const char *bitmap; + +struct data { + bool req_one; /* input: true if req_one was passed to request */ + int count; /* input: count of expected remaining calls */ + bool fail; /* input: true to return failure */ + bool seen_base; /* output: true if base:allocation encountered */ + bool seen_dirty; /* output: true if qemu:dirty-bitmap encountered */ +}; + +static int +cb (void *opaque, const char *metacontext, uint64_t offset, + uint32_t *entries, size_t len, int *error) +{ + struct data *data = opaque; + + /* libnbd does not actually verify that a server is fully compliant + * to the spec; the asserts marked [qemu-nbd] are thus dependent on + * the fact that qemu-nbd is compliant. Furthermore, qemu 5.2 and + * 6.0 disagree on whether base:allocation includes the hole bit for + * the zeroes at 512k (both answers are compliant); but we care more + * that the zeroes show up in the dirty bitmap + */ + assert (offset == 0); + assert (!*error || (data->fail && data->count == 1 && *error == EPROTO)); + assert (data->count-- > 0); /* [qemu-nbd] */ + + if (strcmp (metacontext, LIBNBD_CONTEXT_BASE_ALLOCATION) == 0) { + assert (!data->seen_base); /* [qemu-nbd] */ + data->seen_base = true; + if (data->req_one) + assert (len == 2); /* [qemu-nbd] */ + else + assert ((len & 1) == 0 && len > 2); /* [qemu-nbd] */ + + /* Data block offset 0 size 128k */ + assert (entries[0] == 131072); assert (entries[1] == 0); + if (!data->req_one) { + if (len == 4) { + /* hole|zero offset 128k size 896k */ + assert (entries[2] == 917504); + assert (entries[3] == (LIBNBD_STATE_HOLE| + LIBNBD_STATE_ZERO)); + } + else { + assert (len == 8); + /* hole|zero offset 128k size 384k */ + assert (entries[2] == 393216); + assert (entries[3] == (LIBNBD_STATE_HOLE| + LIBNBD_STATE_ZERO)); + /* allocated zero offset 512k size 64k */ + assert (entries[4] == 65536); + assert (entries[5] == LIBNBD_STATE_ZERO); + /* hole|zero offset 576k size 448k */ + assert (entries[6] == 458752); + assert (entries[7] == (LIBNBD_STATE_HOLE| + LIBNBD_STATE_ZERO)); + } + } + } + else if (strcmp (metacontext, bitmap) == 0) { + assert (!data->seen_dirty); /* [qemu-nbd] */ + data->seen_dirty = true; + assert (len == (data->req_one ? 2 : 10)); /* [qemu-nbd] */ + + assert (entries[0] == 65536); assert (entries[1] == 0); + if (!data->req_one) { + /* dirty block offset 64K size 64K */ + assert (entries[2] == 65536); assert (entries[3] == 1); + assert (entries[4] == 393216); assert (entries[5] == 0); + /* dirty block offset 512K size 64K */ + assert (entries[6] == 65536); assert (entries[7] == 1); + assert (entries[8] == 458752); assert (entries[9] == 0); + } + } + else { + fprintf (stderr, "unexpected context %s\n", metacontext); + exit (EXIT_FAILURE); + } + + if (data->fail) { + /* Something NBD servers can't send */ + *error = data->count == 1 ? EPROTO : ECONNREFUSED; + return -1; + } + return 0; +} + +int +main (int argc, char *argv[]) +{ + struct nbd_handle *nbd; + int64_t exportsize; + struct data data; + char c; + + if (argc < 3) { + fprintf (stderr, "%s bitmap qemu-nbd [args ...]\n", argv[0]); + exit (EXIT_FAILURE); + } + bitmap = argv[1]; + + nbd = nbd_create (); + if (nbd == NULL) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + nbd_add_meta_context (nbd, LIBNBD_CONTEXT_BASE_ALLOCATION); + nbd_add_meta_context (nbd, bitmap); + + if (nbd_connect_tcp (nbd, argv[2],argv[3]) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + exportsize = nbd_get_size (nbd); + if (exportsize == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + data = (struct data) { .count = 2, }; + if (nbd_block_status (nbd, exportsize, 0, + (nbd_extent_callback) { .callback = cb, .user_data = &data }, + 0) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + assert (data.seen_base && data.seen_dirty); + + data = (struct data) { .req_one = true, .count = 2, }; + if (nbd_block_status (nbd, exportsize, 0, + (nbd_extent_callback) { .callback = cb, .user_data = &data }, + LIBNBD_CMD_FLAG_REQ_ONE) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + assert (data.seen_base && data.seen_dirty); + + /* Trigger a failed callback, to prove connection stays up. */ + data = (struct data) { .count = 2, .fail = true, }; + if (nbd_block_status (nbd, exportsize, 0, + (nbd_extent_callback) { .callback = cb, .user_data = &data }, + 0) != -1) { + fprintf (stderr, "unexpected block status success\n"); + exit (EXIT_FAILURE); + } + assert (nbd_get_errno () == EPROTO && nbd_aio_is_ready (nbd)); + assert (data.seen_base && data.seen_dirty); + + if (nbd_pread (nbd, &c, 1, 0, 0) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + if (nbd_shutdown (nbd, 0) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + nbd_close (nbd); + + exit (EXIT_SUCCESS); +} + +``` +3. +Additional information: + diff --git a/results/classifier/108/other/1310324 b/results/classifier/108/other/1310324 new file mode 100644 index 000000000..23dafb61b --- /dev/null +++ b/results/classifier/108/other/1310324 @@ -0,0 +1,95 @@ +permissions: 0.872 +debug: 0.841 +semantic: 0.820 +boot: 0.816 +PID: 0.785 +other: 0.785 +device: 0.783 +performance: 0.772 +socket: 0.745 +network: 0.734 +graphic: 0.726 +files: 0.699 +vnc: 0.699 +KVM: 0.615 + +Commit 0f842f8a introduces regression when using tcg-interpreter + +Hi. + +Commit 0f842f8a246f2b5b51a11c13f933bf7a90ae8e96 apparently introduces a regression when using --enable-tcg-interpreter. The regression is manifested as follows: + + 1. Checkout any qemu commit later or equal that the one said above. Beside that one, I tested v1.7.1, v2.0.0 and a few other commits suggested to my by git bisect. + 2. Possibly cherry-pick commit a32b12741bf45bf3f46bffe5a79cb2548a060cd8, which fixes a compilation bug with --enable-tcg-interpreter. + 3. Compile with: ./configure --target-list=i386-softmmu --enable-tcg-interpreter && make -j8 + 4. Create an empty virtual disk and try to install Windows XP on it booting from Windows CD-ROM. After the loading program, the installer immediately crashes with blue screen (it should instead show the installation confirmation dialog and then the EULA acceptance dialog, if it worked correctly). + +I'm mentioning Windows XP because it is the problem I found. Probably other operating systems would fail as well. I can test others, if you think it would be helpful. I can also give you access to the very exact CD-ROM image I'm using. + +The exact command line I'm using is: +build_location/i386-softmmu/qemu-system-i386 -m 512 -drive file=winxp_test.img -cdrom wipxp_cdrom.iso + +Attached is the blue screen that I see (unfortunately it is Italian, but that's a standard error message and I hope this is not a problem). + +I'm not able to understand the nature of the commit to identify what could be the problem. My nose tells me that it may be some stupid mistake, for example in some offset constant, that nobody ever saw because tcg-interpreter is not much used. + +Thanks, Giovanni. + + + +I forgot: winxp_test.img is just an empty 15 GB (sparse) file. + +On 04/21/2014 06:14 AM, Stefan Weil wrote: +> That commit changed the use of the GETPC macro. I just tried to debug +> the tci.c code and noticed that cputlb.c no longer works as expected: + +Ouch, yes, I see that. + +> This is not specific for the TCG interpreter, but I don't know how the +> normal TCG is affected. + +I believe that normal TCG is not affected, because the value returned for the +return address is outside the code_buffer, so tb_find_pc returns NULL, so +cpu_restore_state does nothing. Whereas the interpreter continues to produce +the address of the last opcode executed. + +To solve this, I believe you need to clear tci_tb_ptr on all exits from the +interpreter loop. That is, both on normal exit (return from tcg_qemu_tb_exec) +as well as exceptional exit (longjmp landing in cpu_exec; see the Reload env +after longjmp section). + +Only setting tci_tb_ptr at the places it's needed, calls and qemu_ld/st calls, +is a good optimization of memory traffic, but is unrelated to this bug. + +> I also noticed that other code like target-i386/seg_helper.c which +> includes exec/softmmu_template.h also results in undefined usage of the +> GETRA macro. + +Huh? That's the normal backend expansion of its load/store helpers. + + + +r~ + + +I can reproduce a similar problem when running the latest ReactOS live CD from http://downloads.sourceforge.net/reactos/ReactOS-0.3.16-REL-live.zip and see the regression caused by the same commit. + +It can be fixed by a small modification in cputlb.c: replace GETPC by GETRA in these two lines + +cputlb.c:#undef GETPC +cputlb.c:#define GETPC() ((uintptr_t)0) + +Giovanni, could you please try your XP image with this modification, so we can confirm that it fixes the regression? +Richard suggested a modification which would be even more safe, but we did not need it before commit +0f842f8a246f2b5b51a11c13f933bf7a90ae8e96, so for a first fix, replacing GETPC by GETRA might be sufficient. + +Regards +Stefan + + +I can confirm that your change fixes my problem as well. Thank you very much! + +The fix mentioned in comment #4 has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7e4e88656c1e6192e9e47 +==> Setting status to "Fix released". + diff --git a/results/classifier/108/other/1310714 b/results/classifier/108/other/1310714 new file mode 100644 index 000000000..e7313600b --- /dev/null +++ b/results/classifier/108/other/1310714 @@ -0,0 +1,196 @@ +other: 0.852 +KVM: 0.836 +vnc: 0.820 +graphic: 0.816 +permissions: 0.787 +device: 0.785 +network: 0.780 +performance: 0.776 +debug: 0.772 +semantic: 0.768 +socket: 0.736 +PID: 0.712 +files: 0.698 +boot: 0.676 + +User mode networking SLIRP rapid memory leak + +QEMU compiled from git HEAD at 2d03b49c3f225994c4b0b46146437d8c887d6774 and reproducible at tag v2.0.0. I first noticed this bug using Ubuntu Trusty's QEMU 2.0.0~rc1. I used to run QEMU 1.7 without this problem. + +This is the command I ran: + +qemu-system-x86_64 -enable-kvm -smp 2 -m 1G -usbdevice tablet -net nic,model=e1000 -net user -vnc localhost:99 -drive if=ide,file=test.img,cache=none -net nic -net user,tftp=/tmp/tftpdata -no-reboot + +The guest is Windows 7 64-bit. The VM starts off normally, but after a couple of minutes, the memory usage starts to swell. If let running, it eventually consumes all host memory and grinds the host to a halt due to heavy swapping. + +When running under gdb, I set a breakpoint on mmap, and this is the stack trace I obtained. + +Breakpoint 1, mmap64 () at ../sysdeps/unix/syscall-template.S:81 +81 in ../sysdeps/unix/syscall-template.S +(gdb) where +#0 mmap64 () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007ffff0e65091 in new_heap (size=135168, size@entry=1728, + top_pad=<optimized out>) at arena.c:554 +#2 0x00007ffff0e687b2 in sysmalloc (av=0x7fffd0000020, nb=1664) + at malloc.c:2386 +#3 _int_malloc (av=0x7fffd0000020, bytes=1650) at malloc.c:3740 +#4 0x00007ffff0e69f50 in __GI___libc_malloc (bytes=1650) at malloc.c:2855 +#5 0x00005555557a091a in m_get (slirp=0x5555561fe960) + at /src/qemu/slirp/mbuf.c:73 +#6 0x00005555557a3151 in slirp_input (slirp=0x5555561fe960, + pkt=0x7ffff7e94b20 "RU\n", pkt_len=<optimized out>) + at /src/qemu/slirp/slirp.c:747 +#7 0x0000555555758b24 in net_slirp_receive (nc=<optimized out>, + buf=<optimized out>, size=54) at /src/qemu/net/slirp.c:113 +#8 0x00005555557567d1 in qemu_deliver_packet (sender=<optimized out>, + flags=<optimized out>, data=<optimized out>, size=<optimized out>, + opaque=<optimized out>) at /src/qemu/net/net.c:471 +#9 0x00005555557588d3 in qemu_net_queue_deliver (size=54, + data=0x7ffff7e94b20 "RU\n", flags=0, sender=0x5555561fe5e0, + queue=0x5555561fe1d0) at /src/qemu/net/queue.c:157 +#10 qemu_net_queue_send (queue=0x5555561fe1d0, sender=0x5555561fe5e0, flags=0, + data=0x7ffff7e94b20 "RU\n", size=54, sent_cb=<optimized out>) + at /src/qemu/net/queue.c:192 +---Type <return> to continue, or q <return> to quit--- +#11 0x000055555575536b in net_hub_receive (len=54, buf=0x7ffff7e94b20 "RU\n", + source_port=0x5555561fe310, hub=<optimized out>) at /src/qemu/net/hub.c:55 +#12 net_hub_port_receive (nc=0x5555561fe310, buf=0x7ffff7e94b20 "RU\n", len=54) + at /src/qemu/net/hub.c:114 +#13 0x00005555557567d1 in qemu_deliver_packet (sender=<optimized out>, + flags=<optimized out>, data=<optimized out>, size=<optimized out>, + opaque=<optimized out>) at /src/qemu/net/net.c:471 +#14 0x00005555557588d3 in qemu_net_queue_deliver (size=54, + data=0x7ffff7e94b20 "RU\n", flags=0, sender=0x555556531920, + queue=0x5555561fe090) at /src/qemu/net/queue.c:157 +#15 qemu_net_queue_send (queue=0x5555561fe090, sender=0x555556531920, flags=0, + data=0x7ffff7e94b20 "RU\n", size=54, sent_cb=<optimized out>) + at /src/qemu/net/queue.c:192 +#16 0x00005555556db95d in xmit_seg (s=0x7ffff7e72010) + at /src/qemu/hw/net/e1000.c:628 +#17 0x00005555556dbd38 in process_tx_desc (dp=0x7fffdf7fda30, s=0x7ffff7e72010) + at /src/qemu/hw/net/e1000.c:723 +#18 start_xmit (s=0x7ffff7e72010) at /src/qemu/hw/net/e1000.c:778 +#19 set_tctl (s=0x7ffff7e72010, index=<optimized out>, val=<optimized out>) + at /src/qemu/hw/net/e1000.c:1142 +#20 0x0000555555840fb0 in access_with_adjusted_size (addr=14360, + value=0x7fffdf7fdb10, size=4, access_size_min=<optimized out>, + access_size_max=<optimized out>, +---Type <return> to continue, or q <return> to quit--- + access=0x555555841160 <memory_region_write_accessor>, mr=0x7ffff7e747c0) + at /src/qemu/memory.c:478 +#21 0x00005555558462fe in memory_region_dispatch_write (size=4, data=454, + addr=14360, mr=0x7ffff7e747c0) at /src/qemu/memory.c:990 +#22 io_mem_write (mr=0x7ffff7e747c0, addr=14360, val=<optimized out>, size=4) + at /src/qemu/memory.c:1744 +#23 0x00005555557e8717 in address_space_rw ( + as=0x555556159c80 <address_space_memory>, addr=4273485848, + buf=0x7ffff7fed028 "\306\001", len=4, is_write=true) + at /src/qemu/exec.c:2034 +#24 0x000055555583ff65 in kvm_cpu_exec (cpu=<optimized out>) + at /src/qemu/kvm-all.c:1704 +#25 0x00005555557ddb6c in qemu_kvm_cpu_thread_fn (arg=0x55555651b730) + at /src/qemu/cpus.c:873 +#26 0x00007ffff11b6182 in start_thread (arg=0x7fffdf7fe700) + at pthread_create.c:312 +#27 0x00007ffff0ee1b2d in clone () + at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 + +Let me know if you have any questions. Thanks. + +liulk + +I investigated further and found that a program in guest (jusched.exe Java Updater) is simultaneously sending and receiving network packets rapidly. This is what exacerbates the memory leak. + +When the mmap breakpoint triggers, I now set additional breakpoints in m_get() and m_free() and found that the number of calls to these functions do not balance, hence making the leak evident. + +Breakpoint 1, mmap64 () at ../sysdeps/unix/syscall-template.S:81 +81 in ../sysdeps/unix/syscall-template.S +(gdb) info break +Num Type Disp Enb Address What +1 breakpoint keep y 0x00007ffff0edbfb0 ../sysdeps/unix/syscall-template.S:81 + breakpoint already hit 6 times +2 breakpoint keep y 0x0000555555848dfa in m_get + at /src/qemu/slirp/mbuf.c:66 + breakpoint already hit 645487 times + ignore next 354513 hits +3 breakpoint keep y 0x0000555555848eff in m_free + at /src/qemu/slirp/mbuf.c:103 + breakpoint already hit 484477 times + ignore next 515523 hits + +About 25% of the m_get() do not get m_free()'d. + +liulk + +I also noticed that the command I ran is causing this bug to happen. I had accidentally repeated -net nic twice, so there are two -net user network interfaces. Removing one of them makes the problem go away. + +liulk + +On Mon, Apr 21, 2014 at 08:53:43PM -0000, Likai Liu wrote: +> I also noticed that the command I ran is causing this bug to happen. I +> had accidentally repeated -net nic twice, so there are two -net user +> network interfaces. Removing one of them makes the problem go away. + +This is still a bug, the packets should be freed even with 2 -net user. + +Stefan + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I believe this is the issue i am seeing as well. QEMU continues to consume memory (>6GB) until the host machine runs out of memory (I am also using slirp for networking). I am able to reproduce it from qemu 2.5 (version found in apt-get for ubuntu 16.04.3 LTS) and I verified it exists after I compiled from source both 2.8.1.1 and 2.10.2 as well. + +$ uname -a +Linux siemens 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux + +$ cat qemu.cfg +# qemu config file + +[drive] + format = "raw" + file = "qemu_rootfs_512.img" + +[drive] + format = "raw" + file = "hmi_sl_oa.img" + +[drive] + format = "raw" + file = "swap_512m.img" + +[net] + type = "nic" + +[net] + type = "user" + +[machine] + kernel = "vmlinuz-2.6.11.12-vanilla.bz" + initrd = "initrd-2.6.11.12.img.gz" + append = "root=/dev/hda" + +[memory] + size = "2048" + +[vnc "default"] + vnc = ":1" + +$ qemu-system-x86_64 -readconfig qemu.cfg + +Let me know what other information you need. + +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 please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1311 b/results/classifier/108/other/1311 new file mode 100644 index 000000000..6951d4648 --- /dev/null +++ b/results/classifier/108/other/1311 @@ -0,0 +1,16 @@ +device: 0.692 +other: 0.607 +network: 0.390 +performance: 0.327 +files: 0.304 +permissions: 0.275 +vnc: 0.246 +semantic: 0.244 +PID: 0.203 +graphic: 0.199 +debug: 0.152 +socket: 0.147 +boot: 0.144 +KVM: 0.029 + +riscv-qemu can't record interrupt diff --git a/results/classifier/108/other/1311614 b/results/classifier/108/other/1311614 new file mode 100644 index 000000000..0eb5298e3 --- /dev/null +++ b/results/classifier/108/other/1311614 @@ -0,0 +1,137 @@ +device: 0.901 +permissions: 0.839 +vnc: 0.832 +other: 0.827 +debug: 0.826 +network: 0.805 +PID: 0.801 +semantic: 0.797 +graphic: 0.789 +performance: 0.782 +socket: 0.770 +files: 0.766 +KVM: 0.743 +boot: 0.682 + +qemu-arm segfaults with gcc 4.9.0 + +I have an ARM chroot that working with qemu-arm emulation + +[root@filzbach fedya]# cat /proc/sys/fs/binfmt_misc/arm +enabled +interpreter /usr/bin/qemu-arm-binfmt +flags: P +offset 0 +magic 7f454c4601010100000000000000000002002800 +mask ffffffffffffff00fffffffffffffffffeffffff + + +In chroot installed gcc dependencies with 4.9.0 version + +sudo rpm --root /home/fedya/root/ -qa | grep 4.9.0 + +libgcc1-4.9.0_2014.04-1-omv2013.0.armv7hl +libgomp1-4.9.0_2014.04-1-omv2013.0.armv7hl +libstdc++6-4.9.0_2014.04-1-omv2013.0.armv7hl +gcc-4.9.0_2014.04-1-omv2013.0.armv7hl +gcc-cpp-4.9.0_2014.04-1-omv2013.0.armv7hl +libstdc++-devel-4.9.0_2014.04-1-omv2013.0.armv7hl +gcc-c++-4.9.0_2014.04-1-omv2013.0.armv7hl + + +When i try to run "rpm" , "rpmbuild", "rpm2cpio"command i always see qemu segfault message + + +example: + +[root@filzbach /]# uname -a +Linux filzbach.lindev.ch 3.13.6-nrjQL-desktop-70omv #1 SMP PREEMPT Wed Mar 12 21:40:00 UTC 2014 armv7l armv7l armv7l GNU/Linux + +[root@filzbach /]# rpm +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + + +Segfault became apparent only after gcc upgrade from 4.8.3 to 4.9.0. + +When i downgrade it to 4.8.3 all working fine again. +It looks like a qemu bug with gcc. + + +P.S. +I tried to rebuild qemu with gcc 4.9.0 +I tried to build qemu from git sources, from fedora sources, from suse sources etc. + +And of course i rebuilt rpm package with latest gcc 4.9.0 +Btw all working fine on a real hardware. + +Bump + +A backtrace of where the crash is in QEMU might be interesting. + +Do you have any howto to produce backtrace? + +I debugged it originally but did only suggest a temporary workaround... +The crash, not really in qemu, looks like this: + +--%<-- +Remote debugging using localhost:1235 +Reading symbols from +/home/fedya/openmandriva/home/fedya/root/lib/ld-linux-armhf.so.3...Reading +symbols from +/home2/fedya/openmandriva/home/fedya/root/usr/lib/debug/lib/ld-2.19.so.debug...done. +done. +Loaded symbols for /home/fedya/openmandriva/home/fedya/root/lib/ld-linux-armhf.so.3 +0xf67dfd00 in _start () + from /home/fedya/openmandriva/home/fedya/root/lib/ld-linux-armhf.so.3 +(gdb) c +Continuing. + +Program received signal SIGSEGV, Segmentation fault. +memset () at ../ports/sysdeps/arm/memset.S:53 +53 sfi_breg r3, \ +(gdb) bt +#0 memset () at ../ports/sysdeps/arm/memset.S:53 +#1 0xf650b5da in __pthread_getaffinity_new (th=th@entry=4123619328, cpusetsize=4, + cpuset=0xf008) at ../nptl/sysdeps/unix/sysv/linux/pthread_getaffinity.c:41 +#2 0xf60ca6d8 in gomp_init_num_threads () at +../../../libgomp/config/linux/proc.c:93 +#3 0xf60c28b2 in initialize_env () at ../../../libgomp/env.c:1187 +#4 0xf67ea514 in call_init (env=<optimized out>, argv=<optimized out>, + argc=<optimized out>, l=<optimized out>) at dl-init.c:76 +#5 _dl_init (main_map=0xf67fe908, argc=1, argv=0xf6ffecf4, env=0xf6ffecfc) + at dl-init.c:124 +#6 0xf67dfd32 in _dl_start_user () + from /home/fedya/openmandriva/home/fedya/root/lib/ld-linux-armhf.so.3 +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) q +A debugging session is active. + + Inferior 1 [Remote target] will be killed. + +Quit anyway? (y or n) y +--%<-- + +My suggestion was to report problems upstream ofcourse, and +a temporary quick fix would be to replace libgomp from the one +from gcc 4.8x or replace the body of gomp_init_num_threads +from gcc-4.9.0/libgomp/config/linux/proc.c with the one from +gcc-4.8.2/libgomp/config/linux/proc.c + +I believe gcc 4.9 is too smart, and some stub is missing somewhere, +e.g. in the arm chroot checking /proc/cpuinfo shows x86_64 cpus. + + +Hmm, getaffinity? Can you try applying this qemu patch: +https://patches.linaro.org/30259/ + +and see if it resolves the problem? + + +Will do! +Thanks + +Fixed, thanks + +Fixed by commit be3bd286bc06 back in 2014. + + diff --git a/results/classifier/108/other/1312561 b/results/classifier/108/other/1312561 new file mode 100644 index 000000000..a5562f7b5 --- /dev/null +++ b/results/classifier/108/other/1312561 @@ -0,0 +1,93 @@ +other: 0.860 +permissions: 0.857 +semantic: 0.851 +network: 0.840 +device: 0.827 +PID: 0.792 +debug: 0.780 +performance: 0.771 +vnc: 0.753 +socket: 0.749 +graphic: 0.718 +files: 0.714 +KVM: 0.641 +boot: 0.637 + +libstdc++-6.dll is missing from your computer + +qemu-w64-setup-20140418.exe + +Windows 7 64 bit PC. + +qemu-system-armw -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda c:\11\rasimg\test.vhd + + +qemu-system-armw.exe - System Error +The program can't start because libstdc++-6.dll is missing from your computer. + +Try reinstalling the program to fix this problem. + +I tried reinstalling, but no change. + +Also getting same error when running the following command on Windows 7 64 bit. + +qemu-system-arm -cpu? + +I also reinstalled qemu without any luck. + +Also getting same error when running the following command on Windows 7 64 bit. + +qemu-system-arm -cpu? + +I also reinstalled qemu without any luck. + +That DLL is the mingw C++ runtime library. We should probably make our Windows executables build with a static libstdc++. + +Ok, so we need to wait for a recompiled version I guess. +I did after your post get the dll from the mingw site, and that error went away, but then replaced by application failed with (0x000007b) error. +How much of the mingw package would we need to install to fix the problem if a recompiled version is some time away please? + +I think dynamic is fine, after all how is libstdc++ different from glib? Both of them need to be deployed together with the executable on Windows, because they aren't a common prerequisite. + +Ah, we're dynamically linking with glib too? In that case, yes, whatever mechanism we're currently using to distribute the glib DLL we should use for the libstdc++ too. + +So the answer to my basic question, how to make this work is Download the mingw windows installer from here. +http://cznic.dl.sourceforge.net/project/mingwbuilds/mingw-builds-install/mingw-builds-install.exe + +Install for W 64 posix or win32 and VERSION 4.6.3 (later one doesn't work with qemu-w64-setup-20140418.exe. +Add to the environment path (Something like +C:\Program Files\mingw-builds\x64-4.6.3-posix-sjlj-rev2\mingw\bin or +C:\Program Files\mingw-builds\x64-4.6.3-win32-sjlj-rev2\mingw\bin both seem to work. + +Hi... + This is still a problem with the latest build(qemu-wXX-setup-20150510.exe). + +I've tried with several different versions from the MinGW, neither work +So, which is the correct NinGW version ? + Thanks + JR + +Hello, + +Same problem here with qemu-w64-setup-20150510.exe. +As suggested above I tried to install mingw 4.6.3 posix and set path like: +set PATH=C:\Program Files\mingw-builds\x64-4.6.3-posix-sjlj-rev2\;C:\Program Files\mingw-builds\x64-4.6.3-posix-sjlj-rev2\bin;%PATH% + +I do not have the libstdc++-6.dll missing error message anymore, but now I have a entry point "__gxx_personality_seh0" missing from libstdc++-6.dll error message, so this is not the appropriate runtime. + + + +Forgot to tell I am running Windows 7 x64, and trying to launch qemu-system-arm. + +This is not a QEMU bug, but a problem of some installers from http://qemu.weilnetz.de/. +http://qemu.weilnetz.de/w64/qemu-w64-setup-20150424.exe should work. + +Get the missing dll from http://qemu.weilnetz.de/w64/dll/. + +Reporting problems to the right address (here the owner of weilnetz.de) would help to +get a faster response in the future. + +Regards +Stefan + + diff --git a/results/classifier/108/other/1313816 b/results/classifier/108/other/1313816 new file mode 100644 index 000000000..3b72fcb87 --- /dev/null +++ b/results/classifier/108/other/1313816 @@ -0,0 +1,48 @@ +device: 0.637 +performance: 0.622 +other: 0.619 +semantic: 0.591 +graphic: 0.450 +PID: 0.423 +boot: 0.350 +socket: 0.329 +network: 0.328 +KVM: 0.326 +permissions: 0.306 +vnc: 0.269 +debug: 0.219 +files: 0.176 + +qemu should close sound device when no more needs. + +I use alsa directly or via pulseaudio on qemu. +And I use xmms2 as well as qemu. + +When I use alsa, one of xmms2 or qemu can play sound. +When I use pulseaudio with qemu and pulseaudio -k, and pulseaudio --start, +qemu can't play sound. + +I think that: +- qemu should open sound device when needs. +- qemu should close sound device when no more needs. + +One of xmms2 or qemu can play sound, but both of them rarely play sound +at the same time. +qemu occurs error on pulseaudio -k, but once close and open the device, +the error will be recovered, I hope. + +Host: slackware64 14.1, linux kernel 3.14.2 +Qemu: 2.0.0 +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 host -usb -usbdevice tablet -display sdl -rtc base=localtime +Guest: Windows 8.1 x64 + +This will not work if qemu is chrooted, because audio devices (/dev) aren't usually available there. + +So at least a naive approach should not be used. If nothing else, it should be an option. + +But really, with pulseaudio backend, there should be no need to go this route and to add new code. + +Looking through old bug tickets... can you still reproduce this 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/1314 b/results/classifier/108/other/1314 new file mode 100644 index 000000000..5d9ce3f6a --- /dev/null +++ b/results/classifier/108/other/1314 @@ -0,0 +1,55 @@ +graphic: 0.746 +PID: 0.738 +other: 0.715 +device: 0.668 +debug: 0.648 +semantic: 0.636 +files: 0.615 +performance: 0.608 +permissions: 0.604 +network: 0.597 +vnc: 0.593 +KVM: 0.558 +socket: 0.528 +boot: 0.505 + +68k: issues with fremx and fmodx +Description of problem: +Some of the mac68k folks have been testing my MacOS branch at https://github.com/mcayland/qemu/tree/q800.upstream2-vm and noticed problems with the values of some of the MacOS _Pack5 transcendental functions. This is easily visible when calling the `sin()` and `cos()` functions whereby some angle ranges use the values from the wrong section of the waveform and/or return values with the incorrect sign. + +SolraBizna was kind enough to write a 68K MacOS test program to generate a sine table (including dumping the hex values of the FP registers) that could be run on real hardware for comparison with QEMU. Using this it was discovered that the issue is related to the implementation of the `fremx` and `fmodx` instructions which can be found in [`floatx80_modrem()`](https://gitlab.com/qemu-project/qemu/-/blob/master/fpu/softfloat.c#L2601). + +I have taken the output of the test program run on a real 68040 Mac and used it to create a test harness at https://github.com/mcayland/qemu/commits/68k-fmodrem-bug [(diff from git master)](https://github.com/mcayland/qemu/commit/4afd6b7c3cad89df943ec43395f95dad7f368338.diff) which iterates over 100 points of the sine table and uses the registers to indicate any failures according to the following comment: + +``` + /* + * The test program below hangs when it completes and the exit + * condition can be determined using the monitor via "info + * registers" command as follows: + * + * D7 is the test number (0-99) + * D6 is the error code + * 0 = no error + * 1 = frem result incorrect + * 2 = frem fpsr result incorrect + * 3 = fmod result incorrect + * 4 = fmod fpsr result incorrect + * D2 is the actual result of the long comparison + * D1 is the expected result of the long comparison + * + * A successful termination of the test program is when D7 == 100 + * and D6 == 0. + */ +``` + +This enables the majority of debugging to be done directly using `info registers` in the monitor rather than manually stepping through the example code using the gdbstub. + +Based upon my local testing on `qemu-system-m68k` there are 2 main differences between QEMU and the output from a real 68040: + +- Differences in precision + +The very first `fremx` result comparison fails here returning `0x3ffe0000 0xc90fdaa2 0x2168c23c 0x........` instead of `0x3ffe0000 0xc90fdaa2 0x2168c238 0x........`. Fortunately the difference in precision is small, and while it may not be possible to fix this, at least it gives a measure of how QEMU's emulation compares to a real 68040. + +- Incorrect setting of the quotient byte + +Bits 16-23 of the FPSR are supposed to contain the sign and 7 LSBs of the quotient for `fremx` and `fmodx` instructions, which is used in _Pack5 to generate an offset into a lookup table for the transcendental functions. It appears that the main cause of the incorrect `sin()` and `cos()` functions is due to the quotient byte being set incorrectly by `fremx`, causing MacOS to jump to the wrong segment of the lookup table for certain angle ranges. diff --git a/results/classifier/108/other/1314293 b/results/classifier/108/other/1314293 new file mode 100644 index 000000000..347da432d --- /dev/null +++ b/results/classifier/108/other/1314293 @@ -0,0 +1,28 @@ +device: 0.786 +graphic: 0.728 +performance: 0.710 +network: 0.658 +semantic: 0.632 +other: 0.600 +vnc: 0.514 +socket: 0.489 +debug: 0.472 +PID: 0.462 +KVM: 0.431 +boot: 0.391 +files: 0.352 +permissions: 0.276 + +screendump with qxl + spice shows stale data + +The monitor 'screendump' command returns stale data for VMs using qxl + spice. If you perform multiple screendumps, screendump #N will show roughly the display from the time screendump #N-1 was taken. This affects 'virsh screenshot' and libvirt screenshot APIs by association. + +Gerd explains that new monitor commands/infrastructure is likely required to handle this correctly: + +https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg03840.html + +Looking through old bug tickets... can you still reproduce this 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/1314667 b/results/classifier/108/other/1314667 new file mode 100644 index 000000000..288fd3425 --- /dev/null +++ b/results/classifier/108/other/1314667 @@ -0,0 +1,128 @@ +permissions: 0.889 +boot: 0.826 +device: 0.822 +other: 0.811 +socket: 0.810 +performance: 0.781 +files: 0.772 +PID: 0.770 +semantic: 0.750 +vnc: 0.724 +debug: 0.720 +graphic: 0.683 +network: 0.675 +KVM: 0.673 + +PMPrebUSB - appcrash of qemu in Win-7-64bit + +I am not sure if this issue is a bug of qemu or by Win-7. +I want to test in advance with QEMU the ability if my USB-Rescue-Drive is +booting correctly. I have Win-7-64 and run qemu v.o.15.1.0 out of the installed RMPrepUSB v.2.1.719 +program. The settings for the preparation of my USB drive were FAT32 boot as +HD, bootloader WinPE/Win-7/Vista, set for running iso-files directly in %_ISO +\MAINMENU\Hiren’sBootCD.iso. When I run Qemu I get the messages in the cmd starting window it says: + +Administrator: RMPrepUSB QEMU Launcher +************************************** +EXECUTING "C:\Program Files (x86)\RMPrepUSB\qemu\STARTFROMUSB.cmd" +DRIVE NUMBER=3 +MEMORY SIZE=1000 +HARD DISK IMAGE=harddisk.img +NOWRITE= +Found OS=VISTA_OR_LATER +Sending command Start_VM.exe 3 500 qemu.exe -L . -name "RMPrepUSB Emulation +Session RAM=1000MB VirtualHDD=harddisk.i +lt+LCtrl)" -boot c -m 1000 -drive file=\\. +\PhysicalDrive3,if=ide,index=0,media=disk -hdb harddisk.img to shell... + +Win-7: in the second window appears: +*********************************** +-->qemu funktioniert nicht mehr +Problemsignatur: + Problemereignisname: APPCRASH + Anwendungsname: qemu.exe + Anwendungsversion: 0.15.1.0 + Anwendungszeitstempel: 4f478c16 + Fehlermodulname: qemu.exe + Fehlermodulversion: 0.15.1.0 + Fehlermodulzeitstempel: 4f478c16 + Ausnahmecode: 40000015 + Ausnahmeoffset: 00053b06 + Betriebsystemversion: 6.1.7601.2.1.0.256.48 + Gebietsschema-ID: 1031 + Zusatzinformation 1: bf8d + Zusatzinformation 2: bf8d49108a2e5a0707fc48438e01652a + Zusatzinformation 3: b0f1 + Zusatzinformation 4: b0f155b0f1de9c5eb22bd6d100737cbe + +If somebody can understand that behaviour I appreciate everybodies help. Thank you with regards +H.O. + +The QEMU used in RMPrepUSB is 32-bit only - it won't run 64-bit programs. Normally, Windows will just display an error message saying it needs a 64-bit system. Use Virtual Box for 64-bit OS testing and DavidB's Virtual Machine USB Boot application - see www.rmprepusb.com Tutorial #4 + +Hello, +thank you for answering very fast. But in Google is advertised +/"//RMPrepUSB/ <http://www.rmprepusb.com/> + + + www.rmprepusb.com/Diese Seite übersetzen + <http://translate.google.com/translate?hl=de&sl=en&u=http://www.rmprepusb.com/&prev=/search%3Fq%3DRMPrepUSB%2B64%2Bbit%2Bqemu%26hl%3Dde%26biw%3D905%26bih%3D508> + +Rating for /rmprepusb/.com .... 32-bit and /64/-/bit/ versions are fully +supported. ... 2 /RMPrepUSB/ Help form screenshot (includes F11 = Run +/QEMU/ emulator, and ... +Download <http://www.rmprepusb.com/documents/release-2-0> - Latest +RMPrepUSB versions +<http://www.rmprepusb.com/documents/rmprepusb-beta-versions> +- Easy2Boot +<http://www.rmprepusb.com/tutorials/72---easyboot---a-grubdos-multiboot-drive-that-is-easy-to-maintain/e2bv1> +- 47 - How to install Windows +<http://www.rmprepusb.com/tutorials/win7onusb>" +is that correct and valid or not? Fully supported means to me, that qemu +should work too on Win-7-64bit.. Or why does RMPrepUSB +<http://www.rmprepusb.com/documents/rmprepusb-beta-versions> not change +this at times of XP-64 bit, Vista-64 bit, Win-7 64 bit, Win-8 64bit, +Win-8.1 64bit. Thank you with kind regards +H.Ohlerth + + + + + +Am 30.04.2014 20:55, schrieb Steve Si: +> The QEMU used in RMPrepUSB is 32-bit only - it won't run 64-bit +> programs. Normally, Windows will just display an error message saying it +> needs a 64-bit system. Use Virtual Box for 64-bit OS testing and +> DavidB's Virtual Machine USB Boot application - see www.rmprepusb.com +> Tutorial #4 +> + + + +RMPrepUSB will run ON 32-bit and 64-bit Operating Systems. +That is not the same thing as QEMU will run a 64-bit Operating System. +There is a 64-bit version of QEMU but it is very buggy and won't even boot a 64-bit Vista/7 WinPE, so it is not included. +As I said, normally when booting a 64-bit OS under QEMU, you will see a Windows message saying that the system is not a 64-bit system. For some reason you are not seeing this on your system. + + +Hello Steve, I had a lot of trouble over the weekend building a +sufficiently working bootable "USB-Rescue-Drive". I summed it up in an +attached Word-Dokument and I am sure, you have the knowledge to solve +my problems. For your detailed help I will expect with lots of kind regards + +H.Ohlerth + + +Am 01.05.2014 10:40, schrieb Steve Si: +> RMPrepUSB will run ON 32-bit and 64-bit Operating Systems. +> That is not the same thing as QEMU will run a 64-bit Operating System. +> There is a 64-bit version of QEMU but it is very buggy and won't even boot a 64-bit Vista/7 WinPE, so it is not included. +> As I said, normally when booting a 64-bit OS under QEMU, you will see a Windows message saying that the system is not a 64-bit system. For some reason you are not seeing this on your system. +> + + + +Looking through old bug tickets... can you still reproduce this issue with the latest (64-bit) 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/1315 b/results/classifier/108/other/1315 new file mode 100644 index 000000000..48ca4f3a7 --- /dev/null +++ b/results/classifier/108/other/1315 @@ -0,0 +1,16 @@ +device: 0.874 +network: 0.863 +performance: 0.598 +debug: 0.512 +graphic: 0.438 +semantic: 0.254 +PID: 0.180 +permissions: 0.162 +boot: 0.115 +socket: 0.091 +vnc: 0.085 +KVM: 0.066 +other: 0.041 +files: 0.014 + +Assertion failure in vmxnet3_activate_device diff --git a/results/classifier/108/other/1315257 b/results/classifier/108/other/1315257 new file mode 100644 index 000000000..804af2009 --- /dev/null +++ b/results/classifier/108/other/1315257 @@ -0,0 +1,70 @@ +graphic: 0.818 +permissions: 0.815 +performance: 0.814 +debug: 0.768 +semantic: 0.734 +PID: 0.728 +device: 0.725 +KVM: 0.718 +other: 0.714 +socket: 0.678 +boot: 0.666 +files: 0.588 +network: 0.556 +vnc: 0.502 + +QEMU get black screen when adjust resolution in full screen mode. + +Description: +QEMU cause X11 error when adjust resolution in full screen mode or start QEMU with "-full-screen". + +Additional info: +* host OS infomation + Archlinux 64bit +* gest OS infomation + Windows XP SP3 32bit +* Archlinux package version(s) +qemu 1.7.1-1 +cinnamon 2.2.3-3 +sdl 1.2.15-5 +xf86-video-ati 1:7.3.0-1 +xf86-video-fbdev 0.4.4-2 +xf86-video-modesetting 0.8.1-2 +xf86-video-vesa 2.3.2-4 +xorg-server 1.15.1-1 + +* error output in Xterm +X Error of failed request: BadValue (integer parameter out of range for operation) + Major opcode of failed request: 153 (XFree86-VidModeExtension) + Minor opcode of failed request: 10 (XF86VidModeSwitchToMode) + Value in failed request: 0x2c2 + Serial number of failed request: 412 + Current serial number in output stream: 414 + +* Xorg log output + *with the command "grep EE /var/log/Xorg.0.log" + (WW) warning, (EE) error, (NI) not implemented, (??) unknown. +[ 7726.317] Initializing built-in extension MIT-SCREEN-SAVER + *with the command "grep WW /var/log/Xorg.0.log" + (WW) warning, (EE) error, (NI) not implemented, (??) unknown. +[ 7726.314] (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/misc/". +[ 7726.314] (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/100dpi/". +[ 7726.314] (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/75dpi/". +[ 7726.316] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) +[ 7726.334] (WW) Falling back to old probe method for modesetting +[ 7726.334] (WW) Falling back to old probe method for fbdev +[ 7726.335] (WW) Falling back to old probe method for vesa + +Steps to reproduce: +1.Start QEMU with the command: + qemu-system-i386 -enable-kvm -machine type=pc,accel=kvm -rtc base=localtime -nodefaults -no-quit -usbdevice tablet -cpu host -smp 2 -m 1G -vga std -soundhw ac97 -net nic,model=virtio -net bridge,br=virbr0 -drive if=virtio,index=0,media=disk,format=raw,cache=none,file=/home/user/VM/WinXP.img +2.Press ctl + alt + f to full screen. +3.Adjust resolution in guest OS. +or +1.Make sure the guest OS resolution is not the same as host OS. +2.Start QEMU with parameter "-full-screen". + +Looking through old bug tickets... can you still reproduce this 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/1315747 b/results/classifier/108/other/1315747 new file mode 100644 index 000000000..1af487064 --- /dev/null +++ b/results/classifier/108/other/1315747 @@ -0,0 +1,31 @@ +device: 0.618 +graphic: 0.587 +performance: 0.587 +boot: 0.490 +semantic: 0.483 +permissions: 0.400 +network: 0.378 +files: 0.367 +other: 0.329 +socket: 0.260 +PID: 0.186 +vnc: 0.180 +debug: 0.130 +KVM: 0.014 + +Qemu on Windows + +I have a problem with the latest snapshot from http://qemu.weilnetz.de/. Where should I raise it? Here? It's not clear to me that I should do it since that's probably an unsupported build, whereas there is no support forum or e-mail address on that website. + +THanks. + +Please describe the problem, maybe I can help you then. Yes, qemu.weilnetz.de contains experimental software which might contain bugs - see the comments on that site. If I get a qualified problem report, I usually try to fix it. + +I have found the following symptoms with any combination of image and guest operating system, including Linux and freebsd, with qemu-system-x86_64 and qemu-system-sparc, so I'm pretty sure it's a systematic problem. The images all boot fine on a Linux host. + +What's happening is that the guest operating system bootloader finds the operating system and starts to boot, but it fails as soon as it tries to read /etc/init with messages implying it can't read the root filesystem. This is strange because the booter has read it. I wonder if the difference is that the booter uses polled I/O whereas the operating systems use DMA and interrupts? What ever the reason is I'm baffled on how to proceed. + +The host operating system is Windows 8. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1316 b/results/classifier/108/other/1316 new file mode 100644 index 000000000..881907ccc --- /dev/null +++ b/results/classifier/108/other/1316 @@ -0,0 +1,16 @@ +device: 0.631 +performance: 0.475 +graphic: 0.428 +network: 0.385 +files: 0.311 +permissions: 0.260 +debug: 0.259 +socket: 0.239 +semantic: 0.204 +boot: 0.120 +vnc: 0.115 +PID: 0.112 +other: 0.081 +KVM: 0.057 + +qemu.qmp.protocol.ConnectError: Failed to establish connection: AF_UNIX path too long (on Darwin) diff --git a/results/classifier/108/other/1318091 b/results/classifier/108/other/1318091 new file mode 100644 index 000000000..167e2f8a9 --- /dev/null +++ b/results/classifier/108/other/1318091 @@ -0,0 +1,70 @@ +permissions: 0.904 +debug: 0.896 +other: 0.894 +semantic: 0.893 +graphic: 0.845 +device: 0.844 +PID: 0.837 +vnc: 0.826 +performance: 0.817 +files: 0.814 +network: 0.806 +KVM: 0.789 +socket: 0.788 +boot: 0.774 + +Perfctr MSRs not available to Guest OS on AMD Phenom II + +The AMD Phenom(tm) II X4 965 Processor (family 16, model 4, stepping 3) has the 4 architecturally supported perf counters at MSRs. The selectors are c001000-c001003, and the counters are c001004-c001007. I've verified that the MSRs are there and working by manually setting the MSRs with msr-tools to count cycles. + +The processor does not support the extended perfctr or the perfctr_nb. These are in cpuid leaf 8000_0001. Qemu also sees that these cpuid flags are not set, when I try launching with -cpu host,perfctr_core,check. However, this flag is only for the extended perfctr MSRs, which also happen to map the original four counters at c0010200. + +When I run a Guest OS, that OS is unable to use the perf counter registers from c001000-7. rdmsr and wrmsr complete, but the results are always 0. By contrast, a wrmsr to one of the c0010200 registers causes a general protection fault (as it should, since those aren't supported). + +Kernel: 3.14.0-gentoo +Qemu: 2.0.0 (gentoo) and also with 2.0.50 (commit 06b4f00d5) +Qemu command: qemu-system-x86_64 -enable-kvm -cpu host -smp 8 -m 1024 -nographic -monitor /dev/pts/4 mnt/hdd.img +cat /proc/cpuinfo: +processor : 3 +vendor_id : AuthenticAMD +cpu family : 16 +model : 4 +model name : AMD Phenom(tm) II X4 965 Processor +stepping : 3 +cpu MHz : 800.000 +cache size : 512 KB +physical id : 0 +siblings : 4 +core id : 3 +cpu cores : 4 +apicid : 3 +initial apicid : 3 +fpu : yes +fpu_exception : yes +cpuid level : 5 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save +bogomips : 6803.79 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm stc 100mhzsteps hwpstate + +thanks. + +i don't understand this in detail, but since the last update of qemu i can't start my virtual win7 machine. i use gnome-boxes 3.24. qemu 2.8 works, 2.9 leads to this: +Preformatted text(gnome-boxes:4301): Boxes-WARNING **: machine.vala:611: Failed to start win7: Unable to start domain: the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor, rdtscp, svm + +i ask, because i also use an phenom 2 x4 and if this is the bug i don't need to opan a new one. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Hi - + +I don't have the hardware readily available anymore, so I can't test it. Might as well close the bug. + +Regarding Oliver's question, it doesn't sound like the same issue I had. I do recall that processor and qemu not supporting rdtscp (which is fine), so that problem might be some qemu startup script requesting features that aren't available. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1318281 b/results/classifier/108/other/1318281 new file mode 100644 index 000000000..45637fff1 --- /dev/null +++ b/results/classifier/108/other/1318281 @@ -0,0 +1,53 @@ +graphic: 0.798 +performance: 0.779 +device: 0.693 +semantic: 0.676 +other: 0.626 +files: 0.466 +permissions: 0.362 +debug: 0.351 +PID: 0.321 +network: 0.316 +vnc: 0.315 +boot: 0.285 +socket: 0.252 +KVM: 0.077 + +linux-user: x86_64 target fails to call sys_futex() + +I'm building the latest QEMU (06b4f00d53637f2c16a62c2cbaa30bffb045cf88) on ARM to run some x86_64 executables in user mode. This is my configuration: + +./configure \ + --prefix=/root/qemu-x86_64 \ + --target-list=x86_64-linux-user \ + --disable-system \ + --disable-tools + +The following program is used for testing: + +https://gist.github.com/hujiajie/e8cff43b574b399c8f59#file-test-c + +I compile the test program in Debian-7.5-amd64 like this: + +gcc -o test `pkg-config --cflags glib-2.0` test.c `pkg-config --static --libs glib-2.0` -static + +and launch the program on ARM with + +qemu-x86_64 test + +The test crashes with the following message: + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +The output of `strace qemu-x86_64 test` is here: + +https://gist.github.com/hujiajie/88d1d5e580d432d11b2d#file-test-strace-log + +It seems that the error is caused by the failure of the futex syscall. + +qemu-i386 could launch the 32-bit test perfectly, the problem only happens on a x86_64 target. + +The test program works fine with current git master, so I think we have fixed this bug at some point in the last two years. + + diff --git a/results/classifier/108/other/1318474 b/results/classifier/108/other/1318474 new file mode 100644 index 000000000..ff63f06d5 --- /dev/null +++ b/results/classifier/108/other/1318474 @@ -0,0 +1,35 @@ +device: 0.751 +graphic: 0.656 +other: 0.569 +vnc: 0.545 +boot: 0.528 +semantic: 0.503 +network: 0.469 +socket: 0.465 +permissions: 0.457 +performance: 0.440 +PID: 0.373 +KVM: 0.326 +files: 0.318 +debug: 0.265 + +QEMU update causes Windows reactivation + +After updating QEMU the guest OS's detect new hardware. As a result any Windows OS sees it as a significant change in hardware and require a reactivation. + +Host OS: Ubuntu 14.04 64-bit + +Guest OS's: +Windows Server 2003 R2 Enterprise +Windows Server 2008 R2 Enterprise +Windows Server 2008 R2 Web +Windows Server 2008 R2 Data Center + +QEMU version: 2.0.0 + +How did you start QEMU with the new version here? You might need to specify the correct machine type with the new version to avoid that the guest sees different hardware (e.g. with the "-machine pc-i440fx-2.0" option). + +[Expired for QEMU because there has been no activity for 60 days.] + +When updating QEMU use specific machine type and this will keep "old" HW. + diff --git a/results/classifier/108/other/1319100 b/results/classifier/108/other/1319100 new file mode 100644 index 000000000..badf30c3f --- /dev/null +++ b/results/classifier/108/other/1319100 @@ -0,0 +1,150 @@ +permissions: 0.880 +other: 0.873 +debug: 0.848 +KVM: 0.842 +device: 0.820 +vnc: 0.815 +performance: 0.802 +socket: 0.800 +semantic: 0.793 +graphic: 0.789 +network: 0.779 +PID: 0.761 +boot: 0.761 +files: 0.729 + +qemu-arm-static bug in signal handling causes mono and java to hang + +Note, this bug is already reported to debian, but it seems to also affect the upstream code. +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748043 + +running mono in a chroot environment with qemu-user-static is not posible +because at least one signal used during termination of mono is routed to the +host. + +This can be reproduced by: +debootstrap --include=mono-runtime --foreign --arch=armel "wheezy" "mono-test" "http://ftp.de.debian.org//debian" +cp /usr/bin/qemu-arm-static mono-test/usr/bin +mount -t proc none mono-test/proc +mount -o bind /dev mono-test/dev +mount -o bind /sys mono-test/sys +chroot mono-test +../debootstrap/debootstrap --second-stage +exit +mount -t proc none mono-test/proc +mount -o bind /sys mono-test/sys +chroot mono-test +QEMU_STRACE=1 /usr/bin/mono /usr/lib/mono/4.0/gacutil.exe + +This will block on a futex: + +--8<-- +18663 sched_yield(0,0,2582980,0,0,2582928) = 0 +18663 clock_gettime(1,-150996384,2,1,2585016,2585600) = 0 +18663 tgkill(18663,18664,30,18664,30,-161951744) = 0 +18663 futex(0x00293774,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,0,NULL,NULL,0) +--8<-- + +If you use mono within strace on a native x86 box you can see, that signals +between threads are used during termination: + +strace -f -o log.txt /usr/bin/mono /usr/lib/mono/4.0/gacutil.exe + +--8<-- +14075 sched_yield() = 0 +14075 tgkill(14075, 14083, SIGPWR) = 0 +14075 futex(0x983f00, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...> +14083 <... futex resumed> ) = ? ERESTARTSYS (To be restarted) +14083 --- SIGPWR (Power failure) @ 0 (0) --- +14083 futex(0x983f00, FUTEX_WAKE_PRIVATE, 1) = 1 +14075 <... futex resumed> ) = 0 +14083 rt_sigsuspend(~[INT QUIT ABRT TERM XCPU RTMIN RT_1] <unfinished ...> +14075 futex(0x94d9a4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x94da20, 24) = 3 +14078 <... futex resumed> ) = 0 +14078 futex(0x94da20, FUTEX_WAKE_PRIVATE, 1) = 1 +14077 <... futex resumed> ) = 0 +14075 futex(0x94d9a4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x94da20, 26 <unfinished ...> +--8<-- + +This also blocks the installation of libnunit2.6-cil within a armel chroot, +because it uses mono in its postinst script. +E.g. (/usr/bin/mono /usr/share/mono/MonoGetAssemblyName.exe /usr/lib/cli/nunit.core-2.6/nunit.core.dll) + +Obviously the same as described in: +http://lists.opensuse.org/opensuse-arm/2011-12/msg00000.html +is happening here. + +There is an openSuSE patch against qemu: +https://build.opensuse.org/package/view_file/Virtualization:Qemu/qemu/0002-XXX-work-around-SA_RESTART-race-wit.patch?expand=1 + +This patch also applies against qemu from backports-wheezy and resolves this +issue. + +As it seems, that this issue is not Debian specific i will also report it to +the qemu project and reference this bug report. + +On 13 May 2014 16:56, manut <email address hidden> wrote: +> running mono in a chroot environment with qemu-user-static is not posible +> because at least one signal used during termination of mono is routed to the +> host. +> +> This can be reproduced by: +> debootstrap --include=mono-runtime --foreign --arch=armel "wheezy" "mono-test" "http://ftp.de.debian.org//debian" +> cp /usr/bin/qemu-arm-static mono-test/usr/bin +> mount -t proc none mono-test/proc +> mount -o bind /dev mono-test/dev +> mount -o bind /sys mono-test/sys +> chroot mono-test +> ../debootstrap/debootstrap --second-stage +> exit +> mount -t proc none mono-test/proc +> mount -o bind /sys mono-test/sys +> chroot mono-test +> QEMU_STRACE=1 /usr/bin/mono /usr/lib/mono/4.0/gacutil.exe +> +> This will block on a futex: +> +> --8<-- +> 18663 sched_yield(0,0,2582980,0,0,2582928) = 0 +> 18663 clock_gettime(1,-150996384,2,1,2585016,2585600) = 0 +> 18663 tgkill(18663,18664,30,18664,30,-161951744) = 0 +> 18663 futex(0x00293774,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,0,NULL,NULL,0) +> --8<-- +> +> If you use mono within strace on a native x86 box you can see, that signals +> between threads are used during termination: + +Multithreaded guest process are unreliable under qemu +linux-user mode anyway, even ignoring the signal handling +related races here. + +See also: +https://bugs.launchpad.net/qemu/+bug/955379 + +> There is an openSuSE patch against qemu: +> https://build.opensuse.org/package/view_file/Virtualization:Qemu/qemu/0002-XXX-work-around-SA_RESTART-race-wit.patch?expand=1 + +This patch is a very hacky bandaid papering over the +real problem. It is not suitable for upstream (and +personally I wouldn't ship it in a distro either :-)). + +thanks +-- PMM + + +Status changed to 'Confirmed' because the bug affects multiple users. + +also causes problems with java. + +Recent changes to QEMU's handling of signals fix this hang trying to run mono under QEMU; they should be out in QEMU 2.7. + + +Did this fix end up making it into QEMU 2.7? + +Yes it did. + + +Fixed in 2.7 and thereby >=Zesty + +I can't guess very well how important this would be for an SRU (or not), leaving that up for user feedback to be decided. + |