diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/140 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1401798 | 69 | ||||
| -rw-r--r-- | results/classifier/108/other/1402 | 74 | ||||
| -rw-r--r-- | results/classifier/108/other/1402289 | 54 | ||||
| -rw-r--r-- | results/classifier/108/other/1402755 | 91 | ||||
| -rw-r--r-- | results/classifier/108/other/1402802 | 33 | ||||
| -rw-r--r-- | results/classifier/108/other/1403 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1404610 | 44 | ||||
| -rw-r--r-- | results/classifier/108/other/1404690 | 150 | ||||
| -rw-r--r-- | results/classifier/108/other/1405176 | 25 | ||||
| -rw-r--r-- | results/classifier/108/other/1405385 | 280 | ||||
| -rw-r--r-- | results/classifier/108/other/1406016 | 122 | ||||
| -rw-r--r-- | results/classifier/108/other/1407 | 91 | ||||
| -rw-r--r-- | results/classifier/108/other/1407808 | 34 | ||||
| -rw-r--r-- | results/classifier/108/other/1407813 | 31 | ||||
| -rw-r--r-- | results/classifier/108/other/1408152 | 31 | ||||
| -rw-r--r-- | results/classifier/108/other/1409 | 16 |
17 files changed, 1177 insertions, 0 deletions
diff --git a/results/classifier/108/other/140 b/results/classifier/108/other/140 new file mode 100644 index 000000000..4947f44bd --- /dev/null +++ b/results/classifier/108/other/140 @@ -0,0 +1,16 @@ +device: 0.613 +performance: 0.610 +debug: 0.472 +network: 0.392 +graphic: 0.327 +other: 0.228 +semantic: 0.208 +boot: 0.180 +vnc: 0.180 +PID: 0.154 +permissions: 0.070 +socket: 0.052 +files: 0.044 +KVM: 0.035 + +linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert) diff --git a/results/classifier/108/other/1401798 b/results/classifier/108/other/1401798 new file mode 100644 index 000000000..bcd9090f2 --- /dev/null +++ b/results/classifier/108/other/1401798 @@ -0,0 +1,69 @@ +other: 0.856 +permissions: 0.847 +KVM: 0.824 +device: 0.818 +graphic: 0.812 +debug: 0.805 +vnc: 0.801 +files: 0.796 +socket: 0.795 +performance: 0.789 +PID: 0.789 +network: 0.770 +semantic: 0.751 +boot: 0.738 + +Qemu 2.2.0 savevm crash. + +qemu 2.1.2 is good. + +(gdb) bt +#0 0x00007ffff4aae445 in raise () from /lib/x86_64-linux-gnu/libc.so.6 +#1 0x00007ffff4ab1bab in abort () from /lib/x86_64-linux-gnu/libc.so.6 +#2 0x0000555555997951 in qcow2_cache_find_entry_to_replace (c=0x555556389780) at block/qcow2-cache.c:262 +#3 0x0000555555997a1a in qcow2_cache_do_get (bs=0x5555563836f0, c=0x555556389780, offset=1094713344, table=0x7fffffffc528, + read_from_disk=true) at block/qcow2-cache.c:285 +#4 0x0000555555997c45 in qcow2_cache_get (bs=0x5555563836f0, c=0x555556389780, offset=1094713344, table=0x7fffffffc528) + at block/qcow2-cache.c:331 +#5 0x0000555555991ca9 in l2_allocate (bs=0x5555563836f0, l1_index=1, table=0x7fffffffc5a0) at block/qcow2-cluster.c:247 +#6 0x000055555599290c in get_cluster_table (bs=0x5555563836f0, offset=549755813888, new_l2_table=0x7fffffffc610, + new_l2_index=0x7fffffffc62c) at block/qcow2-cluster.c:620 +#7 0x0000555555994213 in discard_single_l2 (bs=0x5555563836f0, offset=549755813888, nb_clusters=156, type=QCOW2_DISCARD_NEVER, + full_discard=false) at block/qcow2-cluster.c:1425 +#8 0x0000555555994491 in qcow2_discard_clusters (bs=0x5555563836f0, offset=549755813888, nb_sectors=638976, type=QCOW2_DISCARD_NEVER, + full_discard=false) at block/qcow2-cluster.c:1516 +#9 0x00005555559965c8 in qcow2_snapshot_create (bs=0x5555563836f0, sn_info=0x7fffffffc830) at block/qcow2-snapshot.c:441 +#10 0x00005555559ad1ad in bdrv_snapshot_create (bs=0x5555563836f0, sn_info=0x7fffffffc830) at block/snapshot.c:167 +#11 0x000055555565e90f in do_savevm (mon=0x555556992d20, qdict=0x5555599d5c00) at /vms/qemu/qemu-2.2.0/savevm.c:1126 + +(gdb) show args +Argument list to give program being debugged when it is started is "-name u1404-01 -S -machine pc,accel=kvm,usb=off -m 1024 -smp 2,sockets=2,cores=1,threads=1 -no-user-config -nodefaults -monitor stdio -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/vms/images/u1404-01.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=directsync -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6". + +Maybe bdrv_snapshot_create() should take s->lock but it's not clear yet what causes all qcow2 cache entries to be referenced. + +How do you reproduce this crash? Please give exact steps including what commands to run inside the guest and what QEMU monitor commands to run. + +Is the crash deterministic (does it happen every time or with a random chance)? + +The bug can be reproduced every time. + +1. I install a Ubuntu 14.04 guest. +2. The monitor command is (qemu) snapshot_blkdev_internal drive-virtio-disk0 s1 +3. Or (qemu) savevm s1 + +I think I get the reason. + +From Qemu 2.2.0, in qcow2_open: l2_cache_size = MAX(DEFAULT_L2_CACHE_BYTE_SIZE/s->cluster_size, MIN_L2_CACHE_SIZE); +Here DEFAULT_L2_CACHE_BYTE_SIZE=1M, MIN_L2_CACHE_SIZE=1. + +If the cluster_size < 1M, the l2_cache_size will be greater than 1, it is ok. + +If the cluster_size>=1M, the l2_cache_size will be 1. After create snapshot, the first qcow2_co_writev will abort at qcow2_cache_find_entry_to_replace, because no free room in l2_table_cache. If change the MIN_L2_CACHE_SIZE to 16, it is ok. + + + + + + +Triaging 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/1402 b/results/classifier/108/other/1402 new file mode 100644 index 000000000..38bb37bcc --- /dev/null +++ b/results/classifier/108/other/1402 @@ -0,0 +1,74 @@ +other: 0.978 +permissions: 0.963 +performance: 0.950 +semantic: 0.948 +graphic: 0.946 +debug: 0.942 +PID: 0.939 +device: 0.937 +socket: 0.935 +vnc: 0.934 +KVM: 0.934 +network: 0.910 +files: 0.898 +boot: 0.898 + +cpu-exec.c fails to compile - code path is reachable +Description of problem: +Building qemu (tested with both gcc11 and gcc12) fails with: + +``` +[34/76] Compiling C object libqemu-aarch64-softmmu.fa.p/accel_tcg_cpu-exec.c.o +FAILED: libqemu-aarch64-softmmu.fa.p/accel_tcg_cpu-exec.c.o +gcc -m64 -mcx16 -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm +-I../target/arm -I../dtc/libfdt -Iqapi -Itrace -Iui -Iui/shader +-I/opt/ooce/include/pixman-1 +-I/data/omnios-build/omniosorg/qemu/libtasn1-4.19.0/out/include +-I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include +-fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g +-iquote . -iquote /data/omnios-build/omniosorg/qemu +-iquote /data/omnios-build/omniosorg/qemu/include +-iquote /data/omnios-build/omniosorg/qemu/tcg/i386 +-pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D__EXTENSIONS__ +-D_XOPEN_SOURCE=600 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE +-Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes +-fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition +-Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers +-Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined +-Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value +-Wno-psabi -fstack-protector-strong -m64 -gdwarf-2 -gstrict-dwarf +-fno-omit-frame-pointer -fno-aggressive-loop-optimizations -DNEED_CPU_H +'-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' +'-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ +libqemu-aarch64-softmmu.fa.p/accel_tcg_cpu-exec.c.o +-MF libqemu-aarch64-softmmu.fa.p/accel_tcg_cpu-exec.c.o.d +-o libqemu-aarch64-softmmu.fa.p/accel_tcg_cpu-exec.c.o +-c ../accel/tcg/cpu-exec.c +In file included from ../accel/tcg/cpu-exec.c:20: +In function 'tb_pc', + inlined from 'cpu_tb_exec' at ../accel/tcg/cpu-exec.c:465:13: +/data/omnios-build/omniosorg/qemu/include/qemu/osdep.h:184:35: error: call to 'qemu_build_not_reached_always' declared with attribute error: code path is reachable + 184 | #define qemu_build_not_reached() qemu_build_not_reached_always() + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/data/omnios-build/omniosorg/qemu/include/exec/exec-all.h:608:5: note: in expansion of macro 'qemu_build_not_reached' + 608 | qemu_build_not_reached(); + | ^~~~~~~~~~~~~~~~~~~~~~ +``` +Additional information: +It appears that the compiler is not smart enough to realise that `TARGET_TB_PCREL` is false in the branch there or is not able to infer that from the `assert()`. + +Adding an explicit check as a workaround allows compilation to continue. + +```diff +--- a/accel/tcg/cpu-exec.c ++++ b/accel/tcg/cpu-exec.c +@@ -459,7 +459,7 @@ cpu_tb_exec(CPUState *cpu, TranslationBlock *itb, int *tb_exit) + + if (cc->tcg_ops->synchronize_from_tb) { + cc->tcg_ops->synchronize_from_tb(cpu, last_tb); +- } else { ++ } else if (!TARGET_TB_PCREL) { + assert(!TARGET_TB_PCREL); + assert(cc->set_pc); + cc->set_pc(cpu, tb_pc(last_tb)); +``` diff --git a/results/classifier/108/other/1402289 b/results/classifier/108/other/1402289 new file mode 100644 index 000000000..1c53a4063 --- /dev/null +++ b/results/classifier/108/other/1402289 @@ -0,0 +1,54 @@ +network: 0.916 +debug: 0.848 +device: 0.788 +performance: 0.779 +semantic: 0.696 +socket: 0.658 +files: 0.584 +other: 0.570 +vnc: 0.509 +permissions: 0.500 +boot: 0.500 +PID: 0.495 +graphic: 0.468 +KVM: 0.246 + +netware 5.1 and SCSI (LSI Logic 53c895a) = lsi_scsi: error: readb 0x49 + +Subj. + +This error occurs while loading LSIHINW.HAM driver in the netware5.1 SP8 installer. + +Affected versions: qemu 2.1.2 and 2.2.50 from git (2014-12-14). +Linux kernel: 3.17.6 and 3.18.0. + +Debug log for machine in the attachment. + + + +Netware 6.5 SP8: affected. + +On Sat, Dec 13, 2014 at 10:31:20PM -0000, Ainur Shakirov wrote: +> This error occurs while loading LSIHINW.HAM driver in the netware5.1 SP8 +> installer. +> +> Affected versions: qemu 2.1.2 and 2.2.50 from git (2014-12-14). +> Linux kernel: 3.17.6 and 3.18.0. +> +> Debug log for machine in the attachment. + +The LSI SCSI controller has known issues and is not actively maintained. + +Stefan + + +This also affects NW 4.2 with the Novell LSI8XXNW.HAM driver. + +lsi_scsi: error: readb 0x49 + + + +Triaging 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/1402755 b/results/classifier/108/other/1402755 new file mode 100644 index 000000000..248ec6c12 --- /dev/null +++ b/results/classifier/108/other/1402755 @@ -0,0 +1,91 @@ +permissions: 0.896 +device: 0.883 +debug: 0.882 +other: 0.879 +KVM: 0.874 +network: 0.873 +performance: 0.873 +vnc: 0.871 +graphic: 0.854 +PID: 0.851 +semantic: 0.846 +files: 0.838 +socket: 0.830 +boot: 0.803 + +qemu-kvm: e1000 RX ring is filled with partial-pkt of size 0 + +Hello, +We are using CentOS 6.5 with qemu-kvm-0.12.1.2-2.415 as a host of or VMs. +In the VM we use e1000 as the NIC emulation. +We've modified the e1000 driver to our needs. This modification start the RX engine while the RX ring is empty (RDH == RDT) +and at a later stage we fill the RX descriptors with buffers. This scheme works well on intel chips and VMware. +What we observe in this setup is that from time to time the RX ring is filled with "partial packets" of size 0 (meaning, DD bit is set, +No other status bits are set and packet size is also 0). + +Looking at the e1000 RX routine in qemu-kvm you can observe the following flow: +1. A packet is avail for receive: +2. The routine checks for RCTL_EN - it is enabled +3. The routine checks that the RDH equal RDT (they are as the ring is empty) but also checks if rxov is on (it is still off) so it doesn’t +Exit as it is supposed to. +4. The routine now updates the descriptor status with the DD bit (and vlan which we don’t care) +5. The routine checks if a buffer address is not NULL (it is as NULL since we haven’t filled it yet) – so is logs something. +6. The routine now updates the guest memory with this value (DD is 1) +7. The routine updates the check_rxov flag in order to allow ovf check the next time around. +(but ovf will not occur since in the next iteration RDH != RDT) +8. The routine loops over all the descriptors with the NULL buffer (which is all our ring) and writes the DD bit +9. We get this endless partial packet problem we see. + +qemu-kvm-0.12.1.2-2.415.el6_5.3/qemu-kvm-0.12.1.2/hw/e1000.c +static ssize_t +e1000_receive(VLANClientState *nc, const uint8_t *buf, size_t size) +{ +: : : +if (!(s->mac_reg[RCTL] & E1000_RCTL_EN)) +return -1; + +: : : +do { +if (s->mac_reg[RDH] == s->mac_reg[RDT] && s->check_rxov) { +set_ics(s, 0, E1000_ICS_RXO); +return -1; +} +base = ((uint64_t)s->mac_reg[RDBAH] << 32) + s->mac_reg[RDBAL] + +sizeof(desc) * s->mac_reg[RDH]; +cpu_physical_memory_read(base, (void *)&desc, sizeof(desc)); +desc.special = vlan_special; +desc.status |= (vlan_status | E1000_RXD_STAT_DD); +if (desc.buffer_addr) { +cpu_physical_memory_write(le64_to_cpu(desc.buffer_addr), +(void *)(buf + vlan_offset), size); +desc.length = cpu_to_le16(size); +desc.status |= E1000_RXD_STAT_EOP|E1000_RXD_STAT_IXSM; +} else // as per intel docs; skip descriptors with null buf addr +DBGOUT(RX, "Null RX descriptor!!\n"); +cpu_physical_memory_write(base, (void *)&desc, sizeof(desc)); + +: : : +if (++s->mac_reg[RDH] * sizeof(desc) >= s->mac_reg[RDLEN]) +s->mac_reg[RDH] = 0; +s->check_rxov = 1; +: : : +} while (desc.buffer_addr == 0); +} + + +A workaround is to enable the RX machine only after the descriptor ring is filled for the first time. + +Moti + +On Mon, Dec 15, 2014 at 04:59:55PM -0000, Moti wrote: +> We are using CentOS 6.5 with qemu-kvm-0.12.1.2-2.415 as a host of or VMs. + +Do you see the problem with qemu.git/master? + +Stefan + + +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/1402802 b/results/classifier/108/other/1402802 new file mode 100644 index 000000000..8584aea11 --- /dev/null +++ b/results/classifier/108/other/1402802 @@ -0,0 +1,33 @@ +graphic: 0.652 +device: 0.520 +semantic: 0.472 +network: 0.446 +files: 0.421 +performance: 0.355 +socket: 0.344 +vnc: 0.288 +other: 0.210 +debug: 0.180 +PID: 0.177 +permissions: 0.155 +boot: 0.142 +KVM: 0.080 + +target-tricore/translate.c:3812: possible bad expression ? + + +From a run of cppcheck, a static analysis checker, over the +source code of qemu trunk, dated 20141215, is the new error: + +[qemu/target-tricore/translate.c:3812]: (style) Expression '(X & 0x3f) == 0x6f' is always false. + +Source code is + + if (unlikely((op1 & 0x3f) == OPCM_32_BRN_JTT)) { + +Suggest code rework. + +Absolutly correct. The mask should be 0x7f. I will fix that asap. + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7f13420ec000ad7644b65e + diff --git a/results/classifier/108/other/1403 b/results/classifier/108/other/1403 new file mode 100644 index 000000000..2e90ad43f --- /dev/null +++ b/results/classifier/108/other/1403 @@ -0,0 +1,16 @@ +device: 0.782 +performance: 0.744 +network: 0.639 +graphic: 0.379 +vnc: 0.326 +socket: 0.302 +semantic: 0.272 +PID: 0.260 +boot: 0.238 +permissions: 0.099 +other: 0.087 +debug: 0.080 +files: 0.052 +KVM: 0.006 + +qemu 7.2: test-io-channel-command fails sporadically diff --git a/results/classifier/108/other/1404610 b/results/classifier/108/other/1404610 new file mode 100644 index 000000000..befdf6205 --- /dev/null +++ b/results/classifier/108/other/1404610 @@ -0,0 +1,44 @@ +other: 0.741 +device: 0.625 +semantic: 0.618 +boot: 0.599 +network: 0.523 +permissions: 0.516 +performance: 0.457 +vnc: 0.419 +files: 0.395 +socket: 0.359 +graphic: 0.319 +PID: 0.289 +debug: 0.229 +KVM: 0.135 + +[feature request] HP300 m68k system? + +QEMU seems to support nothing (specific) that 4.4BSD was targeted to...would be useful to have a complete emulator for a full HP300 to run the binary dist from McKusick's CD set. + +Devices that'd be needed: +* 68020, 68030, or 68040 (How much of these are already present? Not sure if there was a non-standard MMU/FPU...but there was definitely a slightly-uncommon bus used for some peripherals) +* Networking was lance I am pretty sure...at least the onboard one. +* SCSI (Probably a standard chip as used EVERYWHERE ELSE..not sure off hand) +* Framebuffers optional, serial is sufficient for basic booting of 4.4. + +Tape/disk can also be done via HP-IB...but SCSI would probably be easier unless extra peripherals were required (some serial stuff.) + +I'm not aware of anybody from the QEMU community working on emulating such 68k system ... so if you want support for that, you likely have to write the patches on your own... Anyway, you might want to have a look at Laurent Vivier's 68k tree - it features full 680x0 emulation (i.e. not only ColdFire) already: https://github.com/vivier/qemu-m68k + +I have Quadra 800 system emulation in the branch q800-v2.4.0. + +You can create a bootable disk image following this wiki: + +https://github.com/vivier/qemu-m68k/wiki + +But this is not fully functional: fork() doesn't work well... + +You can also find a working image from: + +http://landley.net/aboriginal/ + +This image works better as it is based on busybox and uClibc +(the fork() bug is triggered by the lazy symbol resolution mode of glibc) + diff --git a/results/classifier/108/other/1404690 b/results/classifier/108/other/1404690 new file mode 100644 index 000000000..f9fd2de03 --- /dev/null +++ b/results/classifier/108/other/1404690 @@ -0,0 +1,150 @@ +graphic: 0.890 +other: 0.855 +semantic: 0.848 +KVM: 0.765 +vnc: 0.761 +PID: 0.760 +permissions: 0.754 +performance: 0.753 +boot: 0.737 +device: 0.737 +network: 0.708 +socket: 0.692 +debug: 0.636 +files: 0.625 + +Qemu crashes with chrooted m68k + +I'm using qemu-m68k 2.2.0 to chroot into a m68k coldfire linux, which works fine on the coldfire machine. + +I've been able to use binfmt_msc and used the above code to use qemu with strace: + +#include <unistd.h> +#include <string.h> + +int main(int argc, char **argv, char **envp) { + char *newargv[argc + 4]; + + newargv[0] = argv[0]; + newargv[1] = "-cpu"; + newargv[2] = "cfv4e"; + newargv[3] = "-strace"; + + memcpy(&newargv[4], &argv[1], sizeof(*argv) * (argc - 1)); + newargv[argc + 3] = NULL; + return execve("/usr/bin/qemu-m68k", newargv, envp); +} + +Everything works fine. I can run bash, busybox, ash, but when I try to run a ls or just type an invalid command, I got the attached sequence of messages, which end like so: + +11351 waitpid(-1,0xf6fffa00,0x3) = -1 errno=10 (No child processes) +qemu: fatal: Illegal instruction: 0000 @ f6fffa30 +D0 = ffffffff A0 = f67dcf50 F0 = 0000000000000000 ( 0) +D1 = 0000000a A1 = f66e0898 F1 = 0000000000000000 ( 0) +D2 = f6fffaa8 A2 = f67df268 F2 = 0000000000000000 ( 0) +D3 = 00000000 A3 = 00000000 F3 = 0000000000000000 ( 0) +D4 = 00000008 A4 = 800026c4 F4 = 0000000000000000 ( 0) +D5 = 00000000 A5 = f67d98e0 F5 = 0000000000000000 ( 0) +D6 = f6fffaa8 A6 = f6fffa7c F6 = 0000000000000000 ( 0) +D7 = 00000002 A7 = f6fffa24 F7 = 0000000000000000 ( 0) +PC = f6fffa30 SR = 0000 ----- FPRESULT = 0 +Aborted + +How can I debug it further to try to figure out if this is a qemu issue or not? Thanks + + + +On 21 December 2014 at 16:21, Michel Boaventura +<email address hidden> wrote: +> Everything works fine. I can run bash, busybox, ash, but when I try to +> run a ls or just type an invalid command, I got the attached sequence of +> messages, which end like so: +> +> 11351 waitpid(-1,0xf6fffa00,0x3) = -1 errno=10 (No child processes) +> qemu: fatal: Illegal instruction: 0000 @ f6fffa30 +> D0 = ffffffff A0 = f67dcf50 F0 = 0000000000000000 ( 0) +> D1 = 0000000a A1 = f66e0898 F1 = 0000000000000000 ( 0) +> D2 = f6fffaa8 A2 = f67df268 F2 = 0000000000000000 ( 0) +> D3 = 00000000 A3 = 00000000 F3 = 0000000000000000 ( 0) +> D4 = 00000008 A4 = 800026c4 F4 = 0000000000000000 ( 0) +> D5 = 00000000 A5 = f67d98e0 F5 = 0000000000000000 ( 0) +> D6 = f6fffaa8 A6 = f6fffa7c F6 = 0000000000000000 ( 0) +> D7 = 00000002 A7 = f6fffa24 F7 = 0000000000000000 ( 0) +> PC = f6fffa30 SR = 0000 ----- FPRESULT = 0 +> Aborted +> +> How can I debug it further to try to figure out if this is a qemu issue +> or not? Thanks + +This is almost certainly a QEMU bug -- m68k/Coldfire is +unmaintained upstream right now. + +I would start debugging this with QEMU's -d and -D options: +you can use "-d in_asm,exec,cpu -D logfile.out" to write +a lot of logging information about the guest code QEMU executes. +(This can be a huge volume, so best to use the shortest possible +reproducing command. Take out 'exec' if it's really too slow.) +Then you can see what the code the guest executed was and figure +out what happened. Alternatively you can try using qemu's +debug stub: pass QEMU "-g 1234" and then connect a coldfire gdb +using gdb's "target remote :1234" command. Either way, what you +want to find out is what exactly happened in the instructions +between the waitpid and the crash. + +My current guess is that either we've messed up the waitpid +(seems unlikely, it's not very complicated), or we're not +getting signal handling right (much more complicated and +likely to have bugs): your crash happens at about the point +where the shell is due to receive a SIGCHLD for the child +process it spawned. If you send the shell a signal in some +other way (eg type ctrl-C at it, or send it a SIGINT from +outside QEMU) does it die in a similar way? + +PS: an easier way to enable strace for linux-user in a binfmt-misc +chroot is to use the QEMU_STRACE environment variable. (All the +linux-user command line options have environment variable versions; +check --help.) + +You can also just use a command like + 'chroot my-chroot /usr/bin/qemu-m68k-static -strace /bin/sh -c /bin/ls' +for a one-off command run. + +-- PMM + + +Oh, if you're able to put your chroot up for download somewhere so I can reproduce the problem, I can have a look at it for you. (I don't otherwise have a coldfire chroot or toolchain.) + + +Hi Peter, + +Thanks for you time! I've attached my mini chroot environment. As you can see, it is very minimal, but enough to be chrooted and to test this. I will try your suggestions in a couple of days, but if you could please try it before, I will really appreciate. + +Michel + +I have a fix for this (our code for setting up the signal return trampoline used the wrong types and only worked on 32 bit hosts). + +I notice that /bin/ls can't ls directories (it seems ok with single files) but that's a different bug. + + +Patch fixing this: https://patchwork.ozlabs.org/patch/423460/ + + +I've identified the cause of "ls" not returning any output, but I don't think we can fix it in QEMU. + +This happens if the host fs is ext3 or ext4 on a 64 bit system. Here the "d_off" entry in a linux_dirent64 is actually a hashtable hash, and so can be a full 64 bits. Unfortunately the guest binary here is trying to convert getdents64() syscall return information into a dirent with only a 32 bit offset field, and so it (guest libc, I think) just ignores dirents with offsets >4GB, which is all of them. + +Sadly although ext3/4 support an f_mode bit for "make hash offsets fit in 32 bit", this is only for the benefit of kernel internal APIs (it's used by NFS) and AFAICT can't be set by userspace. So I can't at the moment think of any way for QEMU to deal with this... + + +Hi Peter, + +Thank you very much for your help, I really appreciate it. I've tested both your patch and your workaround to make ls work (I've created a xfs partition to put my image) and everything works greatly. + +Merry Xmas. + +Michel + +Peter's patch had been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=1669add752d9f2928 +==> Fix released + diff --git a/results/classifier/108/other/1405176 b/results/classifier/108/other/1405176 new file mode 100644 index 000000000..82110a59d --- /dev/null +++ b/results/classifier/108/other/1405176 @@ -0,0 +1,25 @@ +graphic: 0.737 +device: 0.656 +performance: 0.450 +semantic: 0.438 +permissions: 0.430 +other: 0.414 +network: 0.398 +socket: 0.339 +files: 0.242 +PID: 0.237 +debug: 0.185 +vnc: 0.162 +boot: 0.135 +KVM: 0.094 + +ctrl+alt+2 not work on gtk display + +I download 2.2.0 release on http://wiki.qemu.org/Download +the monitor console does not appear in gtk display but works for sdl and vnc. +my gtk is 3.12.2 + +Triaging 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/1405385 b/results/classifier/108/other/1405385 new file mode 100644 index 000000000..5ae78d092 --- /dev/null +++ b/results/classifier/108/other/1405385 @@ -0,0 +1,280 @@ +KVM: 0.826 +vnc: 0.765 +other: 0.763 +device: 0.635 +permissions: 0.631 +network: 0.600 +graphic: 0.598 +PID: 0.592 +performance: 0.582 +boot: 0.577 +files: 0.577 +debug: 0.574 +socket: 0.544 +semantic: 0.536 + +QEMU crashes when virtio network cards are used together with e1000 network cards + +QEMU version: QEMU emulator version 2.2.50, Copyright (c) 2003-2008 Fabrice Bellard +QEMU GIT version: ab0302ee764fd702465aef6d88612cdff4302809 +Configure flags: ./configure --enable-kvm --prefix=/opt/qemu-devel +Linux version: Ubuntu 14.04.1 LTS +Kernel version: 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux + +Problem: + + QEMU crashes when using one (or more) virtio network cards together with one (or more) e1000 (and possibly others) network cards when those cards are bound to a linux bridge. When the cards are *not* bound to a bridge QEMU does not crash. + +Bridge configuration: + + iface bridge0 inet dhcp + bridge_ports eth1 + bridge_stp off + bridge_fd 0 + +Start-up command (including binding the network cards to the bridge + strace logging): + +./qemu-system-x86_64 -daemonize -smp 1 -m 128 -vnc 0.0.0.0:0 \ +-netdev tap,id=tap_1,script=no,downscript=no,ifname=net_1_1,vhost=on \ +-device virtio-net-pci,bootindex=1,id=nic_1,netdev=tap_1,mac=02:16:3F:00:00:FA \ +-netdev tap,id=tap_2,script=no,downscript=no,ifname=net_1_2 \ +-device e1000,bootindex=2,id=nic_2,netdev=tap_2,mac=02:16:3F:00:00:FB; \ +brctl addif bridge0 net_1_1; \ +brctl addif bridge0 net_1_2; \ +ifconfig net_1_1 0.0.0.0 up; \ +ifconfig net_1_2 0.0.0.0 up; \ +sleep 2; \ +strace -p `ps x |grep qemu-system-x86_64 |grep -v grep|awk '{print $1}'` -o /tmp/qemu-devel-trace.txt + +Kernel log: + +Dec 24 11:12:08 bramws kernel: [12466.885581] device net_1_1 entered promiscuous mode +Dec 24 11:12:08 bramws kernel: [12466.886238] device net_1_2 entered promiscuous mode +Dec 24 11:12:08 bramws kernel: [12466.887084] bridge0: port 2(net_1_1) entered forwarding state +Dec 24 11:12:08 bramws kernel: [12466.887089] bridge0: port 2(net_1_1) entered forwarding state +Dec 24 11:12:08 bramws kernel: [12466.888940] bridge0: port 3(net_1_2) entered forwarding state +Dec 24 11:12:08 bramws kernel: [12466.888947] bridge0: port 3(net_1_2) entered forwarding state +Dec 24 11:12:29 bramws kernel: [12488.026376] bridge0: port 2(net_1_1) entered disabled state +Dec 24 11:12:29 bramws kernel: [12488.026820] device net_1_1 left promiscuous mode +Dec 24 11:12:29 bramws kernel: [12488.026832] bridge0: port 2(net_1_1) entered disabled state +Dec 24 11:12:29 bramws kernel: [12488.049636] bridge0: port 3(net_1_2) entered disabled state +Dec 24 11:12:29 bramws kernel: [12488.050058] device net_1_2 left promiscuous mode +Dec 24 11:12:29 bramws kernel: [12488.050074] bridge0: port 3(net_1_2) entered disabled state + +Strace log: (full log attached) + +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 28646613}, NULL, 8) = 0 (Timeout) +write(5, "\1\0\0\0\0\0\0\0", 8) = 8 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 10899760}, NULL, 8) = 1 ([{fd=5, revents=POLLIN}], left {0, 10895457}) +write(6, "\1\0\0\0\0\0\0\0", 8) = 8 +read(5, "\1\0\0\0\0\0\0\0", 512) = 8 +write(6, "\1\0\0\0\0\0\0\0", 8) = 8 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 0}) +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 0}) +read(6, "\2\0\0\0\0\0\0\0", 16) = 8 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 0 (Timeout) +read(6, 0x7fff697320e0, 16) = -1 EAGAIN (Resource temporarily unavailable) +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 9570429}, NULL, 8) = 0 (Timeout) +futex(0x7f011c8ef094, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f011aaa0860, 224) = 1 +write(5, "\1\0\0\0\0\0\0\0", 8) = 8 +write(5, "\1\0\0\0\0\0\0\0", 8) = 8 +futex(0x7f011aaa0860, FUTEX_WAKE_PRIVATE, 1) = 1 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 54463396}, NULL, 8) = 1 ([{fd=5, revents=POLLIN}], left {0, 54459649}) +tgkill(7779, 7784, SIGUSR1) = 0 +futex(0x7f011aaa0824, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f011aaa0860, 1650) = 1 +write(6, "\1\0\0\0\0\0\0\0", 8) = 8 +read(5, "\2\0\0\0\0\0\0\0", 512) = 8 +write(6, "\1\0\0\0\0\0\0\0", 8) = 8 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 0}) +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 0}) +read(6, "\2\0\0\0\0\0\0\0", 16) = 8 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 0 (Timeout) +read(6, 0x7fff697320e0, 16) = -1 EAGAIN (Resource temporarily unavailable) +futex(0x7f011aaa0860, FUTEX_WAKE_PRIVATE, 1) = 1 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 53843633}, NULL, 8 <unfinished ...> ++++ killed by SIGABRT +++ + + + +What does qemu say when aborting? + +Hm. I guess it says nothing, as else some write(2) should be seen by strace. So it is like abort() not assert(). And we have about 800 abort() calls in the code. Oh well. + +Indeed, it does not say anything, it simply crashes. Besides the strace log I created I can't find any other usefull information in other logfiles. + +a backtrace from a coredump or gdb would be better; it'll tell us the line the abort is on and the state at that point. +Run it under gdb and do + +bt full + +and paste the result. + +I can't reproduce this, no matter how hard I try. Tried 4 virtio devices and 4 e1000 devices (8 network devices in total). Tried 2.1 and 2.2 and current git. It all Just Works (tm). What I'm doing wrong? :) + +I think your just not trying hard enough ;-) + +I have reproduced this on four different (bare metal) machines. I used the default ubuntu QEMU (2.0.0) and the latest GIT version. All machines where running ubuntu 14.04. I also tried to reproduce it on a virtualbox VM and I could only get it to crash when I put the network card of my virtual machine (the virtualbox one) in promiscuous modus. If I would set promiscuous modus to "deny all" in virtual box QEMU would not crash. + +I will do the gdb debug trace when I get back at work, I don't have a suitable system available at home to test this with. + +I have a hard time getting a full backtrace. I recompiled qemu with --enable-debug. Running QEMU with -s -S and then using GDB with debug using: attach remote localhost:1234 works but when QEMU has crashed the command "bt full" always gives back: + +(gdb) bt full +No stack. + +I then ran QEMU directly from GDB using: run -nographic -smp 1 -m 128 -vnc 0.0.0.0:0 -netdev tap,id=tap_1,script=no,downscript=no,ifname=net_1_1,vhost=on -device virtio-net-pci,bootindex=1,id=nic_1,netdev=tap_1,mac=02:16:3F:00:00:FA -netdev tap,id=tap_2,script=no,downscript=no,ifname=net_1_2 -device e1000,bootindex=2,id=nic_2,netdev=tap_2,mac=02:16:3F:00:00:FB + +I have to press a key continuously to get QEMU "running" (otherwise it halts). Right before QEMU crashes I get this error in gdb: + +Program received signal SIGUSR1, User defined signal 1. +spin_lock (lock=0x5a4f072640e15f00) at /home/bram/git/qemu/include/exec/spinlock.h:42 +42 { +(gdb) +Continuing. +qemu: fatal: Trying to execute code outside RAM or ROM at 0x0000000074f0a5f9 + +EAX=00000000 EBX=0001939c ECX=00009cf3 EDX=00001c79 +ESI=f81ac248 EDI=0009bd70 EBP=0009bd20 ESP=0009bd14 +EIP=6d016c49 EFL=00000083 [--S---C] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 07ef39b0 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 07ef39b0 ffffffff 00cf9f00 DPL=0 CS32 [CRA] +SS =0010 07ef39b0 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 07ef39b0 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 07ef39b0 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 07ef39b0 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 0009cf40 00000037 +IDT= 07f8df10 00006deb +CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=000193bc CCD=ffffffe0 CCO=SUBL +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 + +Program received signal SIGABRT, Aborted. +0x00007ffff2797bb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. +(gdb) +Continuing. +[Thread 0x7fffdadff700 (LWP 27991) exited] +[Thread 0x7ffff7fa8980 (LWP 27930) exited] + +Program terminated with signal SIGABRT, Aborted. + +If I run bt full right after that I get the exact same "No stack." error. I then created a core dump and ran the bt full on that, giving me this output: + +#0 0x00007f038ec86bb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 + resultvar = 0 + pid = 29457 + selftid = 29462 +#1 0x00007f038ec89fc8 in __GI_abort () at abort.c:89 + save_stage = 2 + act = {__sigaction_handler = {sa_handler = 0x4c425553, sa_sigaction = 0x4c425553}, sa_mask = {__val = {139653355451349, 893353197568, 139653355450960, 139653355450970, + 15179618306775321344, 1, 139653029951232, 0, 0, 139653029951936, 139653029951232, 139653029947664, 139653353918150, 1688849860263936, 139653257249376, + 139653260837312}}, sa_flags = -1760754560, sa_restorer = 0x7f039708a7e0} + sigs = {__val = {32, 0 <repeats 15 times>}} +#2 0x00007f039459377f in cpu_abort (cpu=0x7f03970d0480, fmt=0x7f03949f2830 "Trying to execute code outside RAM or ROM at 0x%016lx\n") at /home/bram/git/qemu/exec.c:805 + ap = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7f03813dea30, reg_save_area = 0x7f03813de970}} + ap2 = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7f03813dea30, reg_save_area = 0x7f03813de970}} +#3 0x00007f03945f4d20 in get_page_addr_code (env1=0x7f03970d86d0, addr=1961928185) at /home/bram/git/qemu/cputlb.c:357 + cc = 0x7f039708a7e0 + mmu_idx = 2 + page_index = 10 + pd = 0 + p = 0x7ef5000 + mr = 0x7f0394e79620 <io_mem_unassigned> + cpu = 0x7f03970d0480 + __func__ = "get_page_addr_code" +#4 0x00007f039459c38e in tb_find_slow (env=0x7f03970d86d0, pc=1961928185, cs_base=133118384, flags=244) at /home/bram/git/qemu/cpu-exec.c:243 + cpu = 0x7f03970d0480 + tb = 0x4fb813deb00 + ptb1 = 0x7f0394a03680 + h = 32515 + phys_pc = 139653395842176 + phys_page1 = 139653029948228 + virt_page2 = 139653029948232 +#5 0x00007f039459c63c in tb_find_fast (env=0x7f03970d86d0) at /home/bram/git/qemu/cpu-exec.c:300 + cpu = 0x7f03970d0480 + tb = 0x0 + cs_base = 133118384 + pc = 1961928185 + flags = 244 +#6 0x00007f039459cade in cpu_x86_exec (env=0x7f03970d86d0) at /home/bram/git/qemu/cpu-exec.c:456 + cpu = 0x7f03970d0480 + cc = 0x7f039708a7e0 + __func__ = "cpu_x86_exec" + x86_cpu = 0x7f03970d0480 + ret = 65536 + interrupt_request = 2 + tb = 0x7f038166b6d8 + tc_ptr = 0x7f0383576ad0 "A\213n\364\205\355\017\205\245" + next_tb = 0 + sc = {diff_clk = 139653029948416, last_cpu_icount = 139653351987455, realtime_clock = 139653029948448} + have_tb_lock = true +#7 0x00007f03945ca913 in tcg_cpu_exec (env=0x7f03970d86d0) at /home/bram/git/qemu/cpus.c:1363 + cpu = 0x7f03970d0480 + ret = 32515 +#8 0x00007f03945caa28 in tcg_exec_all () at /home/bram/git/qemu/cpus.c:1396 + cpu = 0x7f03970d0480 + env = 0x7f03970d86d0 + r = 32515 +#9 0x00007f03945c9d47 in qemu_tcg_cpu_thread_fn (arg=0x7f03970d0480) at /home/bram/git/qemu/cpus.c:1042 + cpu = 0x0 +#10 0x00007f038f01e182 in start_thread (arg=0x7f03813df700) at pthread_create.c:312 + __res = <optimized out> + pd = 0x7f03813df700 + now = <optimized out> + unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139653029951232, 5823000673722110008, 0, 0, 139653029951936, 139653029951232, -5852297728485158856, -5852310887850110920}, + mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} + not_first_call = <optimized out> + pagesize_m1 = <optimized out> + sp = <optimized out> + freesize = <optimized out> + __PRETTY_FUNCTION__ = "start_thread" +#11 0x00007f038ed4aefd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 +No locals. + + +Im not sure if this is all the information needed? I attached the core dump. + +On 29 December 2014 at 08:29, Bram Klein Gunnewiek +<email address hidden> wrote: +> Right before QEMU crashes I get this error in gdb: +> +> Program received signal SIGUSR1, User defined signal 1. + +SIGUSR1 is used internally by QEMU. You can tell gdb not to +bother you about it: + + handle SIGUSR1 pass noprint nostop + +before running. + +-- PMM + + +I'm not sure if there is more information required from my side? I can still reproduce this and have no clue where to look for more information. + +On Fri, Jan 09, 2015 at 07:30:05AM -0000, Bram Klein Gunnewiek wrote: +> I'm not sure if there is more information required from my side? I can +> still reproduce this and have no clue where to look for more +> information. + +I cannot reproduce a crash from your command-line with qemu.git/master +(3e5f6234b4f45a11b7c357dde2d6da36641bc6f6). + + +Looking through old bug tickets... Bram, 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/1406016 b/results/classifier/108/other/1406016 new file mode 100644 index 000000000..5e61513a4 --- /dev/null +++ b/results/classifier/108/other/1406016 @@ -0,0 +1,122 @@ +performance: 0.854 +graphic: 0.852 +permissions: 0.832 +device: 0.810 +other: 0.800 +semantic: 0.783 +debug: 0.778 +KVM: 0.758 +vnc: 0.746 +boot: 0.733 +PID: 0.696 +socket: 0.696 +network: 0.683 +files: 0.653 + +qemu-system-arm hangs at start on OS X + +Both from release 2.1.2 and built from a recent source, qemu-system-arm seems to hang on a mutex immediately after starting up, never getting to the point of actually booting. + +I've tried qemu-system-mipsel with another image and it worked fine, so this seems to be specific to the ARM runtime. I've tried two different ARM kernels, and I also ran into this with QEMU 2.1.2 release, installed from a bottle using homebrew. + +Host: Mac OS X 10.9.5 (Darwin Kernel Version 13.4.0) +QEMU version: built from HEAD@ab0302ee76 +Build command: ./configure --enable-cocoa --target-list=arm-softmmu,mipsel-softmmu && make +Run command: + +qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 256 -sd disk.img -net nic,macaddr=52:54:00:fa:ce:13 -kernel vmlinuz-3.2.0-4-vexpress -initrd initrd.gz -append "root=/dev/ram" -display vnc=localhost:17 -net user,hostfwd=tcp::5022-:22 -append "console=ttyS0" + +I also tried this, with a different kernel & root: + +qemu-system-arm -kernel zImage -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -hda rootfs-chromium.ext2 -append "root=/dev/sda" + +Thread dump: + +(lldb) thread list +Process 34364 stopped +* thread #1: tid = 0x135966, 0x00007fff89f4a746 libsystem_kernel.dylib`__psynch_mutexwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP + thread #2: tid = 0x13598b, 0x00007fff89f4ae6a libsystem_kernel.dylib`__workq_kernreturn + 10 + thread #3: tid = 0x13598c, 0x00007fff89f4b662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager' + thread #7: tid = 0x1359b2, 0x00007fff89f4acc2 libsystem_kernel.dylib`__sigwait + 10 + thread #9: tid = 0x1359c1, 0x00000001091bc5d9 + thread #11: tid = 0x1359cc, 0x00007fff89f4a716 libsystem_kernel.dylib`__psynch_cvwait + 10 + thread #12: tid = 0x1359da, 0x00007fff89f46a1a libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.audio.IOThread.client' + +------- +* thread #1: tid = 0x135966, 0x00007fff89f4a746 libsystem_kernel.dylib`__psynch_mutexwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP + * frame #0: 0x00007fff89f4a746 libsystem_kernel.dylib`__psynch_mutexwait + 10 + frame #1: 0x00007fff8e05f779 libsystem_pthread.dylib`_pthread_mutex_lock + 372 + frame #2: 0x000000010033e8e9 qemu-system-arm`qemu_mutex_lock(mutex=<unavailable>) + 25 at qemu-thread-posix.c:76 + frame #3: 0x000000010002d742 qemu-system-arm`qemu_mutex_lock_iothread + 98 at cpus.c:1137 + frame #4: 0x00000001002c84b5 qemu-system-arm`main_loop_wait [inlined] os_host_main_loop_wait(timeout=<unavailable>) + 191 at main-loop.c:242 + frame #5: 0x00000001002c83f6 qemu-system-arm`main_loop_wait(nonblocking=<unavailable>) + 278 at main-loop.c:494 + frame #6: 0x000000010014961a qemu-system-arm`qemu_main [inlined] main_loop + 73 at vl.c:1789 + frame #7: 0x00000001001495d1 qemu-system-arm`qemu_main(argc=<unavailable>, argv=<unavailable>, envp=<unavailable>) + 17057 at vl.c:4353 + frame #8: 0x000000010029b45e qemu-system-arm`-[QemuCocoaAppController startEmulationWithArgc:argv:](self=<unavailable>, _cmd=<unavailable>, argc=<unavailable>, argv=<unavailable>) + 30 at cocoa.m:897 + +Do these guest images and command lines work on Linux QEMU? (The most common cause of "nothing happens" is "wrong kernel for this board" or similar misconfiguration, where QEMU is correctly emulating a crashed guest that never made any output...) + + +Ah, good question! I found an image and instructions at http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu#Using_QEMU_without_libvirt that was a bit easier to work through, and sure enough, it works on Linux but not on OS X. + +Linux precise64 3.2.0-37-generic: + +vagrant@precise64:/opt/qemu-images/arm/fedora$ /home/vagrant/qemu-2.2.0/arm-softmmu/qemu-system-arm -M versatilepb -kernel zImage-qemu-versatile-3.0.8-4.fc17.armv5tel -hdc rootfs-f12 -append "root=0800 console=ttyAMA0" -nographic +audio: Could not init `oss' audio driver +Uncompressing Linux... done, booting the kernel. +Linux version 3.0.8 (jcapik@vega) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33.fa1)) #16 Wed Mar 28 15:07:56 CEST 2012 +CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00093177 +CPU: VIVT data cache, VIVT instruction cache +Machine: ARM-Versatile PB +Memory policy: ECC disabled, Data cache writeback +sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms +... + +------------------------- + + +OS X (just built QEMU 2.2.0 from source): + +$ /Users/epall/bigcode/qemu/arm-softmmu/qemu-system-arm -M versatilepb -kernel zImage-qemu-versatile-3.0.8-4.fc17.armv5tel -hdc rootfs-f12 -append "root=0800 console=ttyAMA0" -nographic +Uncompressing Linux... done, booting the kernel. + +That zImage works for me with QEMU commit ab0302ee76 on OSX 10.9.5 (at least it boots fine to the point of the kernel complaining it couldn't find the rootfs, because I didn't bother to build that.) I tested with the v2.2.0 tag and that works fine too. + +Sanity check: use md5sum to check that the images you ended up with on OSX and Linux are actually the same and didn't get corrupted in download somehow. Otherwise I'm not sure what's going on. + + +Peter, the bug occurs when mounting the rootfs. + +I can reproduce this bug too, with a kernel that works perfectly on QEMU on linux, windows and linux running on the same mac under vmware. In the case where I ran it under vmware on the mac the raspi kernel is the same file shared between the host os (os x) and the guest (linux) os. + +Here's how I built QEMU on my brandy new mac + + 34 xcode-select --install + 35 ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" + 38 brew doctor + 47 brew install pkg-config + 51 git checkout 2b7b4b3 Library/Formula/qemu.rb + 53 $: brew install https://raw.github.com/Homebrew/homebrew-dupes/master/apple-gcc42.rb + 54 brew install https://raw.github.com/Homebrew/homebrew-dupes/master/apple-gcc42.rb + 55 brew install qemu --env=std --cc=gcc-4.2 + 56 cd + 57 cd Desktop/qemu + +here's what happens when I run it: + +GSSLA40052111:Qemu jgallun$ cat pi.sh +#!/bin/sh + +qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 2014-09-09-wheezy-raspbian.img + +I've attached a screenshot of what happens when I boot this kernel on the mac. + +The kernel I used in this example came from this website: http://xecdesign.com/qemu-emulating-raspberry-pi-the-easy-way/ + + > brew install qemu --env=std --cc=gcc-4.2 + +Aha. Don't do that, that's an ancient gcc. Use the system 'clang' (which configure should pick by default). + + +Thanks for the quick response. Being a total mac n00b I just followed the directions in the top google link for installing qemu on os x and I ended up where I did. I replaced the old version of the qemu formula in my brew library with the current one and re-installed and all is well, running qemu 2.2.0. Not that it matters, but the directions I followed have you checkout an old version of qemu (1.1.0) that won't compile with clang or a modern gcc, hence the ancient version of gcc + diff --git a/results/classifier/108/other/1407 b/results/classifier/108/other/1407 new file mode 100644 index 000000000..3ead001a4 --- /dev/null +++ b/results/classifier/108/other/1407 @@ -0,0 +1,91 @@ +graphic: 0.915 +other: 0.904 +debug: 0.840 +KVM: 0.834 +permissions: 0.833 +semantic: 0.816 +vnc: 0.814 +PID: 0.784 +performance: 0.779 +network: 0.777 +socket: 0.769 +boot: 0.761 +device: 0.756 +files: 0.723 + +Assertion failure in fimd_update_memory_section() +Description of problem: +It seems the frame buffer is not properly initialized before usage. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-arm + +cat << EOF | $QEMU \ +-machine smdkc210 -monitor none -serial none \ +-display none -nodefaults -qtest stdio +writel 0x11c00020 0x3454d403 +writel 0x11c00000 0x61988eaf +EOF +``` +Additional information: +``` +==13250==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x5590b12d2240). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 3376651198 +INFO: Loaded 1 modules (583356 inline 8-bit counters): 583356 [0x5590b4672000, 0x5590b47006bc), +INFO: Loaded 1 PC tables (583356 PCs): 583356 [0x5590b3d8b3b0,0x5590b4671f70), +/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-exynos4210-fimd: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +Matching objects by name , *exynos4210.fimd* +This process will fuzz the following MemoryRegions: + * exynos4210.fimd[0] (size 4114) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * exynos4210.fimd, EVENT_TYPE_MMIO_READ, 0x11c00000 +0x4114, 4,4 + * exynos4210.fimd, EVENT_TYPE_MMIO_WRITE, 0x11c00000 +0x4114, 4,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 227Mb +Running: poc-qemu-videzzo-arm-target-videzzo-fuzz-exynos4210-fimd-crash-eda3de9b6941dd8c14e22959b56dbe5d8d07dae3 +qemu-videzzo-arm-target-videzzo-fuzz-exynos4210-fimd: ../hw/display/exynos4210_fimd.c:1152: void fimd_update_memory_section(Exynos4210fimdState *, unsigned int): Assertion `w->mem_section.mr' failed. +==13250== ERROR: libFuzzer: deadly signal + #0 0x5590acce30ee in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x5590acc31d61 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x5590acc0ac96 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x5590acc0ad62 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x5590acc0ad62 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7f9ed33c741f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7f9ed31d900a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7f9ed31d900a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7f9ed31b8858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7f9ed31b8728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7f9ed31c9fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x5590ad56dce3 in fimd_update_memory_section /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/exynos4210_fimd.c:1152:5 + #12 0x5590ad565fb7 in exynos4210_fimd_enable /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/exynos4210_fimd.c:1198:13 + #13 0x5590ad5590a3 in exynos4210_fimd_write /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/exynos4210_fimd.c:1387:13 + #14 0x5590b03e7bc3 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:493:5 + #15 0x5590b03e7501 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18 + #16 0x5590b03e5e26 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1515:16 + #17 0x5590b047669e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2825:23 + #18 0x5590b046444b in flatview_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2867:12 + #19 0x5590b0463f08 in address_space_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2963:18 + #20 0x5590acd23d38 in qemu_writel /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1096:5 + #21 0x5590acd220a3 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1245:28 + #22 0x5590b12cd6bf in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5 + #23 0x5590b12c4a3d in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9 + #24 0x5590b12c47e4 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9 + #25 0x5590acd2b07c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12 + #26 0x5590b12d250b in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18 + #27 0x5590acc0b806 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #28 0x5590acbee434 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #29 0x5590acbf93de in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #30 0x5590acbe59c6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #31 0x7f9ed31ba082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #32 0x5590acbe5a1d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-exynos4210-fimd+0x31cea1d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +``` diff --git a/results/classifier/108/other/1407808 b/results/classifier/108/other/1407808 new file mode 100644 index 000000000..496a12b99 --- /dev/null +++ b/results/classifier/108/other/1407808 @@ -0,0 +1,34 @@ +semantic: 0.800 +performance: 0.767 +graphic: 0.736 +device: 0.624 +other: 0.565 +network: 0.475 +debug: 0.425 +permissions: 0.415 +socket: 0.363 +vnc: 0.341 +files: 0.299 +boot: 0.289 +PID: 0.207 +KVM: 0.158 + +virtual console gives strange response to ANSI DSR + +With "-serial vc" (which is the default), qemu make strange responses to the ANSI DSR escape sequence (\033[6n) which can confuse guests. + +Terminal emulators supporting the ANSI escape sequences usually support the "Device Status Report" escape sequence, \033[6n, to which as a response the terminal injects as input the response \033[n;mR, containing the current cursor position. An application running in the guest can use this escape sequence to, for example, figure out the size of the terminal it is running under, which can be useful as the guest has no other standard way to figure out a "size" for the serial port. + +Unfortunately, it seems that qemu when run with "-serial vc" (which appears to be the default), when qemu gets the \033[6n escape sequence on the serial port, it just responds with a single \033, and that's it! This can confuse an application, could concievably assume that a terminal either supports this escape sequence and injects the correct response (\033[n;mR), or doesn't support it and injects absolutely nothing as input - but not something in between. + +This caused a problem on one shell implementation on OSv that tried to figure out the terminal's size, and had to work around this unexpected behavior (see https://github.com/cloudius-systems/osv/commit/b79223584be40459861d1c12e1cb67e3e49e2a12). + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +The bug still very much exists (I tested qemu 4.2.1): +If you don't use "-serial stdio" (or its newer variants), by default Qemu opens a new black "console" to run the application. It is not clear to me exactly which terminal this console is supposed to emulate, but it does seem to support most ANSI escape sequences I tried. However, it supports the ANSI "DSR" (Device Status Report) escape sequence, ESC [ 6 n (see https://en.wikipedia.org/wiki/ANSI_escape_code), incorrectly, just as I reported in the original issue. This is still true today. + +This should be fixed in head-of-git by commit 8eb13bbbac08a, which will be in QEMU 6.0. (The underlying bug is that when the GTK front-end tries to send sequences of more than one byte to a UART, it didn't account for UARTs which don't have a FIFO capable of holding the whole sequence at once.) + + diff --git a/results/classifier/108/other/1407813 b/results/classifier/108/other/1407813 new file mode 100644 index 000000000..bac96cedb --- /dev/null +++ b/results/classifier/108/other/1407813 @@ -0,0 +1,31 @@ +device: 0.683 +semantic: 0.661 +vnc: 0.627 +graphic: 0.596 +network: 0.587 +performance: 0.583 +other: 0.551 +socket: 0.506 +files: 0.358 +debug: 0.326 +permissions: 0.324 +PID: 0.264 +boot: 0.190 +KVM: 0.163 + +QEMU wrongly translates newlines on serial output + +When using "-serial stdio", QEMU shows the guest serial port's output on the tty running qemu. As it should, QEMU sets the tty to raw mode. Or almost... Strangely, it neglects to remove one output-translation bit, ONLCR (see termios(3)) enabled on the tty. And it should have removed this output translation! + +The problem is that with this ONLCR, the guest has no way of outputting a bare linefeed ('\n') - every time the guest tries to output a bare linefeed to the serial port, the host tty will translate it to \r\n which will be sent to the underlying terminal (e.g., xterm). + +In most cases, this issue doesn't cause a problem: When the guest is running a Unix-like operating system which is itself in cooked mode, the guest itself will always output \r\n, and the hosts second translation (to \r\r\n) does no harm. But in certain cases, the guest can *really* want to output just \n, and have this \n reach the terminal emulator and do what a linefeed is supposed to do without a carriage-return - namely - just go one line down in the same column. + +As an illustration of this bug, consider a guest running a Unix-like operating system running a curses-based application (e.g., "vi"). If you look at the output of "infocmp xterm", you'll notice that cud1=^J. This means that if the curses library decides to move one line down (it can happen in some cursor movement situations) it might decide to print a linefeed (\n) to move one line down. The guest's operating system will not mess with this linefeed (because the guest is in raw mode), but then qemu's tty, because it was wrongly left in ONLCR mode, will change this \n to \r\n before it reaches the terminal - causing wrong cursor movement (instead the cursor going straight down, it moves to the first column of the next line). + +I think this bug relates to: +https://bugs.launchpad.net/qemu/+bug/1715296 + +Patch has now been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=12fb0ac0575df83cec72ec + diff --git a/results/classifier/108/other/1408152 b/results/classifier/108/other/1408152 new file mode 100644 index 000000000..9884586f1 --- /dev/null +++ b/results/classifier/108/other/1408152 @@ -0,0 +1,31 @@ +KVM: 0.894 +boot: 0.806 +network: 0.699 +device: 0.675 +socket: 0.579 +graphic: 0.521 +performance: 0.494 +semantic: 0.430 +PID: 0.392 +permissions: 0.368 +files: 0.367 +vnc: 0.365 +other: 0.359 +debug: 0.220 + +latest qemu git doesn't load + +commit ab0302ee764fd702465aef6d88612cdff4302809This is with + +qemu-system-x86_64: util/qemu-option.c:387: qemu_opt_get_bool_helper: Assertion `opt->desc && opt->desc->type == QEMU_OPT_BOOL' failed. +/home/njh/bin/kfreebsd-amd64: line 7: 32549 Aborted (core dumped) qemu-system-x86_64 -drive file=kfreebsd-amd64,index=0,media=disk,cache=writeback,aio=native -drive file=/dev/sr0,index=1,media=cdrom -boot c -redir tcp:2232::22 -m 1024 -machine accel=kvm,kernel_irqchip=on -cpu host -net user,hostname=qemu.bandsman.co.uk -net nic,model=e1000 -k en-us + +Seems to be failing to parse kernel_irqchip=on correctly. + +This issue seems to be similar to 1406706 and 1407454. Looks Marcel is working on a fix, and he also posted something to first address USB stuff, + +https://<email address hidden>/msg272607.html + +Hi; we fixed this with commit 446f16a6906e9d0 in March 2015, so I'm going to mark this as fixed. + + diff --git a/results/classifier/108/other/1409 b/results/classifier/108/other/1409 new file mode 100644 index 000000000..b8e55e5e3 --- /dev/null +++ b/results/classifier/108/other/1409 @@ -0,0 +1,16 @@ +performance: 0.758 +device: 0.698 +graphic: 0.486 +debug: 0.443 +permissions: 0.308 +semantic: 0.228 +network: 0.194 +vnc: 0.188 +files: 0.083 +boot: 0.076 +socket: 0.075 +PID: 0.073 +other: 0.063 +KVM: 0.017 + +make check failed about qemu@7.2.0on suse15_aarch64 |