diff options
Diffstat (limited to 'results/classifier/zero-shot/108/all')
201 files changed, 48811 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/all/1010 b/results/classifier/zero-shot/108/all/1010 new file mode 100644 index 000000000..0d0f2696c --- /dev/null +++ b/results/classifier/zero-shot/108/all/1010 @@ -0,0 +1,93 @@ +semantic: 0.974 +other: 0.973 +graphic: 0.971 +debug: 0.964 +performance: 0.960 +device: 0.959 +permissions: 0.958 +PID: 0.954 +vnc: 0.948 +network: 0.946 +socket: 0.946 +boot: 0.925 +KVM: 0.913 +files: 0.905 + +Errors on 9p mounts +Description of problem: +I'm trying to run Docker VMs with [Lima](https://github.com/lima-vm/lima), which uses QEMU. I'm trying to expose my home directory on macOS to the Ubuntu VM using `9p`. This is how the mount point looks like inside the Ubuntu VM: + +``` +root@lima-docker:~# mount | grep Users +mount0 on /Users/carlos type 9p (rw,relatime,dirsync,fscache,cachetag=4294894070,access=user,trans=virtio,version=9p2000.u) +root@lima-docker:~# +``` + +The problem I'm seeing is that doing an `ls -l /Users/carlos` gives a "Timer expired" error, and no output: + +``` +root@lima-docker:~# ls -l /Users/carlos +ls: reading directory '/Users/carlos': Timer expired +total 0 +``` + +Under `strace`, it seems that the timer error is raised by the `getdents64` system call: + +``` +root@lima-docker:~# strace -f ls -l /Users/carlos +[..] +openat(AT_FDCWD, "/Users/carlos", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 +newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=1984, ...}, AT_EMPTY_PATH) = 0 +mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffa16bf000 +getdents64(3, 0xffffa16bf040, 131072) = -1 ETIME (Timer expired) +[..] +``` + +I've also tried the `9p2000.L` protocol instead, and the results are a bit better. I do get a directory listing, but I see "xxx" errors: + +``` +root@lima-docker:~# ls -l /Users/carlos +ls: /Users/carlos: Network dropped connection on reset +ls: /Users/carlos/Music: Network dropped connection on reset +ls: /Users/carlos/Pictures: Network dropped connection on reset +ls: /Users/carlos/Desktop: Network dropped connection on reset +ls: /Users/carlos/Library: Network dropped connection on reset +ls: /Users/carlos/Public: Network dropped connection on reset +ls: /Users/carlos/Movies: Network dropped connection on reset +ls: /Users/carlos/Applications: Network dropped connection on reset +ls: /Users/carlos/Dropbox: Network dropped connection on reset +ls: /Users/carlos/Maildir: Network dropped connection on reset +ls: /Users/carlos/Documents: Network dropped connection on reset +ls: /Users/carlos/Downloads: Network dropped connection on reset +total 0 +drwx------ 5 carlos dialout 160 Dec 6 10:31 Applications +drwx------ 4 carlos dialout 128 Apr 28 14:40 Desktop +drwx------ 12 carlos dialout 384 Apr 30 08:44 Documents +drwx------ 164 carlos dialout 5248 Apr 29 13:50 Downloads +drwx------ 8 carlos dialout 256 Sep 4 2021 Dropbox +drwx------ 82 carlos dialout 2624 Apr 8 14:05 Library +drwxr-xr-x 3 carlos dialout 96 Nov 12 12:28 Maildir +drwx------ 4 carlos dialout 128 Jul 19 2021 Movies +drwx------ 4 carlos dialout 128 Aug 19 2021 Music +drwx------ 4 carlos dialout 128 Jul 19 2021 Pictures +drwxr-xr-x 4 carlos dialout 128 Jul 19 2021 Public +``` + +The errors in this case seem to come from the `lgetxattr`system call: + +``` +root@lima-docker:~# strace -f ls -l /Users/carlos +[..] +statx(AT_FDCWD, "/Users/carlos/Downloads", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_SIZE, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFDIR|0700, stx_size=5248, ...}) = 0 +lgetxattr("/Users/carlos/Downloads", "security.selinux", 0xaaaaec72da70, 255) = -1 ENETRESET (Network dropped connection on reset) +write(2, "ls: ", 4ls: ) = 4 +write(2, "/Users/carlos/Downloads", 23/Users/carlos/Downloads) = 23 +write(2, ": Network dropped connection on "..., 37: Network dropped connection on reset) = 37 +[..] +``` + +I've reported this to the Lima folks at https://github.com/lima-vm/lima/issues/831, and they suggested opening an issue here. Any ideas? +Steps to reproduce: +1. If you have Lima installed (I'm using version 0.10.0): `limactl start --name=docker ./lima-templates/docker.yaml` +Additional information: + diff --git a/results/classifier/zero-shot/108/all/1026 b/results/classifier/zero-shot/108/all/1026 new file mode 100644 index 000000000..7a5be6142 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1026 @@ -0,0 +1,131 @@ +device: 0.991 +graphic: 0.982 +other: 0.982 +vnc: 0.981 +performance: 0.978 +debug: 0.977 +semantic: 0.975 +network: 0.972 +permissions: 0.971 +socket: 0.969 +PID: 0.966 +KVM: 0.954 +boot: 0.947 +files: 0.917 + +Backup with large RBD disk is slow since QEMU 6.2.0 (since commit 0347a8fd) +Description of problem: +Since commit 0347a8fd4c ("block/rbd: implement bdrv_co_block_status"), there is a big slowdown for large RBD images for backup. +Steps to reproduce: +I used the following script +``` +root@pve701 ~ # cat rbdbackup.sh +#!/bin/bash +rbd create emptytestA -p rbdkvm --size $2 +rbd create emptytestB -p rbdkvm --size $2 +$1 \ + -qmp stdio \ + -drive file=rbd:rbdkvm/emptytestA:conf=/etc/pve/ceph.conf:id=admin:keyring=/etc/pve/priv/ceph/rbdkvm.keyring,if=none,id=driveA,format=raw \ + -drive file=rbd:rbdkvm/emptytestB:conf=/etc/pve/ceph.conf:id=admin:keyring=/etc/pve/priv/ceph/rbdkvm.keyring,if=none,id=driveB,format=raw \ +<<EOF +{"execute": "qmp_capabilities"} +{"execute": "blockdev-backup", + "arguments": { "device": "driveA", + "sync": "full", + "target": "driveB" } } +EOF +rbd -p rbdkvm rm emptytestA +rbd -p rbdkvm rm emptytestB +``` +with 200G and 500G images respectively and QEMU binaries built from current master (i.e. 10c2a0c5e7d48e590d945c017b5b8af5b4c89a3c) and from current master with fc176116cdea816ceb8dd969080b2b95f58edbc0, 9e302f64bb407a9bb097b626da97228c2654cfee and 0347a8fd4c3faaedf119be04c197804be40a384b reverted. + + +Timings: +``` +200G master: 92s +200G master+reverts: 57s +500G master: 526s +500G master+reverts: 142s +``` + +I checked how long a single call to `rbd_diff_iterate2()` in `block/rbd.c` takes, and it seems to take about linearly more time the bigger the image is. But it is also called linearly more often, resulting in about quadratic slowdown overall. +Additional information: +Full commands/output: +``` +root@pve701 ~ # ./rbdbackup.sh ./qemu-upstream/10c2a0c5e7d48e590d945c017b5b8af5b4c89a3c/qemu-system-x86_64 200G +{"QMP": {"version": {"qemu": {"micro": 50, "minor": 0, "major": 7}, "package": "v7.0.0-981-g10c2a0c5e7"}, "capabilities": ["oob"]}} +VNC server running on 127.0.0.1:5900 +{"return": {}} +{"timestamp": {"seconds": 1652695629, "microseconds": 651397}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "driveA"}} +{"timestamp": {"seconds": 1652695629, "microseconds": 651447}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "driveA"}} +{"timestamp": {"seconds": 1652695629, "microseconds": 651464}, "event": "JOB_STATUS_CHANGE", "data": {"status": "paused", "id": "driveA"}} +{"timestamp": {"seconds": 1652695629, "microseconds": 651490}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "driveA"}} +{"return": {}} +{"timestamp": {"seconds": 1652695721, "microseconds": 415892}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "driveA"}} +{"timestamp": {"seconds": 1652695721, "microseconds": 416066}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "driveA"}} +{"timestamp": {"seconds": 1652695721, "microseconds": 416197}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "driveA", "len": 214748364800, "offset": 214748364800, "speed": 0, "type": "backup"}} +{"timestamp": {"seconds": 1652695721, "microseconds": 416239}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "driveA"}} +{"timestamp": {"seconds": 1652695721, "microseconds": 416265}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "driveA"}} +^Cqemu-system-x86_64: terminating on signal 2 +{"timestamp": {"seconds": 1652695727, "microseconds": 145031}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-signal"}} +Removing image: 100% complete...done. +Removing image: 100% complete...done. +./rbdbackup.sh 200G 81.15s user 6.31s system 89% cpu 1:38.21 total +root@pve701 ~ # ./rbdbackup.sh ./qemu-upstream/10c2a0c5e7d48e590d945c017b5b8af5b4c89a3c-with-rbd-reverts/qemu-system-x86_64 200G +{"QMP": {"version": {"qemu": {"micro": 50, "minor": 0, "major": 7}, "package": "v7.0.0-984-g20a19f8eae"}, "capabilities": ["oob"]}} +VNC server running on 127.0.0.1:5900 +{"return": {}} +{"timestamp": {"seconds": 1652695737, "microseconds": 444734}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "driveA"}} +{"timestamp": {"seconds": 1652695737, "microseconds": 444818}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "driveA"}} +{"timestamp": {"seconds": 1652695737, "microseconds": 444860}, "event": "JOB_STATUS_CHANGE", "data": {"status": "paused", "id": "driveA"}} +{"timestamp": {"seconds": 1652695737, "microseconds": 444885}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "driveA"}} +{"return": {}} +{"timestamp": {"seconds": 1652695794, "microseconds": 437168}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "driveA"}} +{"timestamp": {"seconds": 1652695794, "microseconds": 437248}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "driveA"}} +{"timestamp": {"seconds": 1652695794, "microseconds": 437341}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "driveA", "len": 214748364800, "offset": 214748364800, "speed": 0, "type": "backup"}} +{"timestamp": {"seconds": 1652695794, "microseconds": 437368}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "driveA"}} +{"timestamp": {"seconds": 1652695794, "microseconds": 437381}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "driveA"}} +^Cqemu-system-x86_64: terminating on signal 2 +{"timestamp": {"seconds": 1652695803, "microseconds": 242148}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-signal"}} +Removing image: 100% complete...done. +Removing image: 100% complete...done. +./rbdbackup.sh 200G 40.68s user 111.12s system 228% cpu 1:06.47 total +root@pve701 ~ # ./rbdbackup.sh ./qemu-upstream/10c2a0c5e7d48e590d945c017b5b8af5b4c89a3c/qemu-system-x86_64 500G +{"QMP": {"version": {"qemu": {"micro": 50, "minor": 0, "major": 7}, "package": "v7.0.0-981-g10c2a0c5e7"}, "capabilities": ["oob"]}} +VNC server running on 127.0.0.1:5900 +{"return": {}} +{"timestamp": {"seconds": 1652695970, "microseconds": 663752}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "driveA"}} +{"timestamp": {"seconds": 1652695970, "microseconds": 663892}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "driveA"}} +{"timestamp": {"seconds": 1652695970, "microseconds": 663920}, "event": "JOB_STATUS_CHANGE", "data": {"status": "paused", "id": "driveA"}} +{"timestamp": {"seconds": 1652695970, "microseconds": 663980}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "driveA"}} +{"return": {}} +{"timestamp": {"seconds": 1652696496, "microseconds": 556219}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "driveA"}} +{"timestamp": {"seconds": 1652696496, "microseconds": 556386}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "driveA"}} +{"timestamp": {"seconds": 1652696496, "microseconds": 556497}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "driveA", "len": 536870912000, "offset": 536870912000, "speed": 0, "type": "backup"}} +{"timestamp": {"seconds": 1652696496, "microseconds": 556536}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "driveA"}} +{"timestamp": {"seconds": 1652696496, "microseconds": 556555}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "driveA"}} +^Cqemu-system-x86_64: terminating on signal 2 +{"timestamp": {"seconds": 1652696786, "microseconds": 408273}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-signal"}} +Removing image: 100% complete...done. +Removing image: 100% complete...done. +./rbdbackup.sh 500G 453.34s user 28.30s system 58% cpu 13:36.48 total +root@pve701 ~ # ./rbdbackup.sh ./qemu-upstream/10c2a0c5e7d48e590d945c017b5b8af5b4c89a3c-with-rbd-reverts/qemu-system-x86_64 500G +{"QMP": {"version": {"qemu": {"micro": 50, "minor": 0, "major": 7}, "package": "v7.0.0-984-g20a19f8eae"}, "capabilities": ["oob"]}} +VNC server running on 127.0.0.1:5900 +{"return": {}} +{"timestamp": {"seconds": 1652695810, "microseconds": 648931}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "driveA"}} +{"timestamp": {"seconds": 1652695810, "microseconds": 649012}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "driveA"}} +{"timestamp": {"seconds": 1652695810, "microseconds": 649057}, "event": "JOB_STATUS_CHANGE", "data": {"status": "paused", "id": "driveA"}} +{"timestamp": {"seconds": 1652695810, "microseconds": 649080}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "driveA"}} +{"return": {}} +{"timestamp": {"seconds": 1652695952, "microseconds": 13070}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "driveA"}} +{"timestamp": {"seconds": 1652695952, "microseconds": 13144}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "driveA"}} +{"timestamp": {"seconds": 1652695952, "microseconds": 13210}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "driveA", "len": 536870912000, "offset": 536870912000, "speed": 0, "type": "backup"}} +{"timestamp": {"seconds": 1652695952, "microseconds": 13233}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "driveA"}} +{"timestamp": {"seconds": 1652695952, "microseconds": 13249}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "driveA"}} +^Cqemu-system-x86_64: terminating on signal 2 +{"timestamp": {"seconds": 1652695955, "microseconds": 692599}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-signal"}} +Removing image: 100% complete...done. +Removing image: 100% complete...done. +./rbdbackup.sh 500G 99.49s user 277.78s system 258% cpu 2:25.78 total +``` diff --git a/results/classifier/zero-shot/108/all/1038136 b/results/classifier/zero-shot/108/all/1038136 new file mode 100644 index 000000000..75cf36f9c --- /dev/null +++ b/results/classifier/zero-shot/108/all/1038136 @@ -0,0 +1,95 @@ +debug: 0.987 +other: 0.984 +PID: 0.979 +permissions: 0.978 +device: 0.977 +performance: 0.967 +semantic: 0.960 +boot: 0.959 +network: 0.952 +socket: 0.950 +KVM: 0.934 +vnc: 0.934 +files: 0.930 +graphic: 0.925 + +lack of keycode 89 for br-abnt2 keyboards + +qemu-kvm-1.1.1 +host system: slackware64-13.37 +Bug detailed description: +Independent of Guest OS nothing happens when keycode 89 is pressed. +If you select option "-k pt-br" at qemu commandline you get keycode 89 but there is no more keycode 26 (dead_acute dead_grave) and keycode 51 fails on "less" sign. +If you have a numeric keyboard you can use its "slash" key but there is no means to use the question mark, causing discomfort when you are scripting or programming. + +I have the exact same problem. + + +Bug is confirmed and at least one and a half year old, according to this blog post, with a hack for solving it: +http://blog.nielshorn.net/2011/03/qemu-and-brazilian-keyboards/ + +I've managed to resolve it applying the following patch (without "-k pt-br"): + +--- qemu-1.6.0+dfsg.orig/ui/x_keymap.c ++++ qemu-1.6.0+dfsg/ui/x_keymap.c +@@ -94,7 +94,7 @@ static const uint8_t x_keycode_to_pc_key + */ + + static const uint8_t evdev_keycode_to_pc_keycode[61] = { +- 0, /* 97 EVDEV - RO ("Internet" Keyboards) */ ++ 0x73, /* 97 EVDEV - /?° (ABNT2 Keyboards) */ + 0, /* 98 EVDEV - KATA (Katakana) */ + 0, /* 99 EVDEV - HIRA (Hiragana) */ + 0x79, /* 100 EVDEV - HENK (Henkan) */ + + +Attached patch (may not apply cleanly as I edited it manually to correct for space alignment; but c'mon, it is so straight forward). + +Thanks +I will test it +Gilcio + +Em 27/11/2013, às 07:25, rslemos <email address hidden> escreveu: + +> I've managed to resolve it applying the following patch (without "-k pt- +> br"): +> +> --- qemu-1.6.0+dfsg.orig/ui/x_keymap.c +> +++ qemu-1.6.0+dfsg/ui/x_keymap.c +> @@ -94,7 +94,7 @@ static const uint8_t x_keycode_to_pc_key +> */ +> +> static const uint8_t evdev_keycode_to_pc_keycode[61] = { +> - 0, /* 97 EVDEV - RO ("Internet" Keyboards) */ +> + 0x73, /* 97 EVDEV - /?° (ABNT2 Keyboards) */ +> 0, /* 98 EVDEV - KATA (Katakana) */ +> 0, /* 99 EVDEV - HIRA (Hiragana) */ +> 0x79, /* 100 EVDEV - HENK (Henkan) */ +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1038136 +> +> Title: +> lack of keycode 89 for br-abnt2 keyboards +> +> Status in QEMU: +> Confirmed +> +> Bug description: +> qemu-kvm-1.1.1 +> host system: slackware64-13.37 +> Bug detailed description: +> Independent of Guest OS nothing happens when keycode 89 is pressed. +> If you select option "-k pt-br" at qemu commandline you get keycode 89 but there is no more keycode 26 (dead_acute dead_grave) and keycode 51 fails on "less" sign. +> If you have a numeric keyboard you can use its "slash" key but there is no means to use the question mark, causing discomfort when you are scripting or programming. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1038136/+subscriptions + + +Looks like this the key has been added by this commit here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=33aa30cafcce053b83 +So I think we can close this bug ticket now. + diff --git a/results/classifier/zero-shot/108/all/1060928 b/results/classifier/zero-shot/108/all/1060928 new file mode 100644 index 000000000..12b4ab55a --- /dev/null +++ b/results/classifier/zero-shot/108/all/1060928 @@ -0,0 +1,490 @@ +other: 0.980 +KVM: 0.954 +boot: 0.953 +permissions: 0.953 +vnc: 0.948 +device: 0.945 +debug: 0.945 +graphic: 0.943 +performance: 0.934 +network: 0.926 +socket: 0.924 +semantic: 0.924 +PID: 0.910 +files: 0.904 + +Error in launch virtual server port + +.- configure +.- uname -a +.- script bash launcher +.- Error +.- output serial.c in statusRUN + +----------------------------------- + +.- configure + +./configure --target-list=i386-softmmu,x86_64-softmmu,\ +i386-linux-user,x86_64-linux-user --enable-vde --disable-vnc --enable-sdl \ +--audio-drv-list=oss,alsa,sdl,esd,pa \ +--audio-card-list=ac97,es1370,sb16,cs4231a,adlib,gus,hda &>status + +----------------------------------- + +.- uname -a +Linux Aspire5250 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux + +----------------------------------- + +.- script bash launcher + +#!/bin/bash + +qemu-system-i386 -m 128 -display sdl -cpu pentium \ +-k es \ +-net nic,vlan=0,macaddr=52:54:00:12:02:04,model=pcnet \ +-net vde,vlan=0,sock=/var/run/vde2/tap0.ctl \ +-serial unix:/tmp/com1,server,nowait \ +-vga cirrus \ +-boot c -hda "/home/VirtualMachines/Discos/Hispa70_1.vmdk" \ +-cdrom "/home/VirtualMachines/CDROM/hf-7.0a.iso" 2>statusRUN + +echo -n "Pulsa enter para continuar . . . " && read REPLY + +----------------------------------- + +.- Error + +*** buffer overflow detected ***: qemu-system-i386 terminated +======= Backtrace: ========= +/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f2759892007] +/lib/x86_64-linux-gnu/libc.so.6(+0x107f00)[0x7f2759890f00] +/lib/x86_64-linux-gnu/libc.so.6(+0x108fbe)[0x7f2759891fbe] +qemu-system-i386(+0xe5153)[0x7f275bfd8153] +qemu-system-i386(+0x1744f6)[0x7f275c0674f6] +qemu-system-i386(main+0xe77)[0x7f275bf5ef37] +/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f27597aa76d] +qemu-system-i386(+0x70229)[0x7f275bf63229] +======= Memory map: ======== +41912000-43912000 rwxp 00000000 00:00 0 +7f2730000000-7f2730054000 rw-p 00000000 00:00 0 +7f2730054000-7f2734000000 ---p 00000000 00:00 0 +7f2736539000-7f273bdff000 r--p 00000000 08:05 1978631 /usr/lib/locale/locale-archive +7f273bdff000-7f273be00000 rw-p 00000000 00:00 0 +7f273be00000-7f2743e00000 rw-p 00000000 00:00 0 +7f2743e00000-7f2744000000 rw-p 00000000 00:00 0 +7f2744000000-7f2744021000 rw-p 00000000 00:00 0 +7f2744021000-7f2748000000 ---p 00000000 00:00 0 +7f274c000000-7f274c021000 rw-p 00000000 00:00 0 +7f274c021000-7f2750000000 ---p 00000000 00:00 0 +7f27500c5000-7f27500ca000 r-xp 00000000 08:05 1979531 /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 +7f27500ca000-7f27502c9000 ---p 00005000 08:05 1979531 /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 +7f27502c9000-7f27502ca000 r--p 00004000 08:05 1979531 /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 +7f27502ca000-7f27502cb000 rw-p 00005000 08:05 1979531 /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 +7f27502cb000-7f27502d4000 r-xp 00000000 08:05 1979549 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 +7f27502d4000-7f27504d3000 ---p 00009000 08:05 1979549 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 +7f27504d3000-7f27504d4000 r--p 00008000 08:05 1979549 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 +7f27504d4000-7f27504d5000 rw-p 00009000 08:05 1979549 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 +7f27504d5000-7f27504de000 r-xp 00000000 08:05 1979523 /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2 +7f27504de000-7f27506dd000 ---p 00009000 08:05 1979523 /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2 +7f27506dd000-7f27506de000 r--p 00008000 08:05 1979523 /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2 +7f27506de000-7f27506df000 rw-p 00009000 08:05 1979523 /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2 +7f27506df000-7f2750763000 rw-p 00000000 00:00 0 +7f2750775000-7f2750776000 rw-p 00000000 00:00 0 +7f2750776000-7f2750890000 rw-s 00000000 00:04 1736706 /SYSV00000000 (deleted) +7f2750890000-7f2750a00000 rw-p 00000000 00:00 0 +7f2750a00000-7f2751200000 rw-p 00000000 00:00 0 +7f2751200000-7f2751291000 rw-p 00000000 00:00 0 +7f2751291000-7f2751292000 ---p 00000000 00:00 0 +7f2751292000-7f2751a92000 rw-p 00000000 00:00 0 +7f2751a92000-7f2751a93000 ---p 00000000 00:00 0 +7f2751a93000-7f2752293000 rw-p 00000000 00:00 0 +7f2752293000-7f2752294000 ---p 00000000 00:00 0 +7f2752294000-7f2752a94000 rw-p 00000000 00:00 0 +7f2752a94000-7f2752a95000 ---p 00000000 00:00 0 +7f2752a95000-7f2753295000 rw-p 00000000 00:00 0 +7f2753295000-7f2753296000 ---p 00000000 00:00 0 +7f2753296000-7f2753a96000 rw-p 00000000 00:00 0 +7f2753a96000-7f2753aa2000 r-xp 00000000 08:05 660536 /lib/x86_64-linux-gnu/libnss_files-2.15.so +7f2753aa2000-7f2753ca1000 ---p 0000c000 08:05 660536 /lib/x86_64-linux-gnu/libnss_files-2.15.so +7f2753ca1000-7f2753ca2000 r--p 0000b000 08:05 660536 /lib/x86_64-linux-gnu/libnss_files-2.15.so +7f2753ca2000-7f2753ca3000 rw-p 0000c000 08:05 660536 /lib/x86_64-linux-gnu/libnss_files-2.15.so +7f2753ca3000-7f2753cad000 r-xp 00000000 08:05 660540 /lib/x86_64-linux-gnu/libnss_nis-2.15.so +7f2753cad000-7f2753ead000 ---p 0000a000 08:05 660540 /lib/x86_64-linux-gnu/libnss_nis-2.15.so +7f2753ead000-7f2753eae000 r--p 0000a000 08:05 660540 /lib/x86_64-linux-gnu/libnss_nis-2.15.so +7f2753eae000-7f2753eaf000 rw-p 0000b000 08:05 660540 /lib/x86_64-linux-gnu/libnss_nis-2.15.so +7f2753eaf000-7f2753eb7000 r-xp 00000000 08:05 660532 /lib/x86_64-linux-gnu/libnss_compat-2.15.so +7f2753eb7000-7f27540b6000 ---p 00008000 08:05 660532 /lib/x86_64-linux-gnu/libnss_compat-2.15.so +7f27540b6000-7f27540b7000 r--p 00007000 08:05 660532 /lib/x86_64-linux-gnu/libnss_compat-2.15.so +7f27540b7000-7f27540b8000 rw-p 00008000 08:05 660532 /lib/x86_64-linux-gnu/libnss_compat-2.15.so +7f27540b8000-7f2755cb9000 rw-p 00000000 00:00 0 +7f2755cb9000-7f2755cce000 r-xp 00000000 08:05 660506 /lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2755cce000-7f2755ecd000 ---p 00015000 08:05 660506 /lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2755ecd000-7f2755ece000 r--p 00014000 08:05 660506 /lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2755ece000-7f2755ecf000 rw-p 00015000 08:05 660506 /lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2755ecf000-7f2755ee7000 r-xp 00000000 08:05 660569 /lib/x86_64-linux-gnu/libresolv-2.15.so +7f2755ee7000-7f27560e7000 ---p 00018000 08:05 660569 /lib/x86_64-linux-gnu/libresolv-2.15.so +7f27560e7000-7f27560e8000 r--p 00018000 08:05 660569 /lib/x86_64-linux-gnu/libresolv-2.15.so +7f27560e8000-7f27560e9000 rw-p 00019000 08:05 660569 /lib/x86_64-linux-gnu/libresolv-2.15.so +7f27560e9000-7f27560eb000 rw-p 00000000 00:00 0 +7f27560eb000-7f27560f1000 r-xp 00000000 08:05 1979942 /usr/lib/x86_64-linux-gnu/libogg.so.0.7.1 +7f27560f1000-7f27562f0000 ---p 00006000 08:05 1979942 /usr/lib/x86_64-linux-gnu/libogg.so.0.7.1 +7f27562f0000-7f27562f1000 r--p 00005000 08:05 1979942 /usr/lib/x86_64-linux-gnu/libogg.so.0.7.1 +7f27562f1000-7f27562f2000 rw-p 00006000 08:05 1979942 /usr/lib/x86_64-linux-gnu/libogg.so.0.7.1 +7f27562f2000-7f275631d000 r-xp 00000000 08:05 1980105 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5 +7f275631d000-7f275651c000 ---p 0002b000 08:05 1980105 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5 +7f275651c000-7f275651d000 r--p 0002a000 08:05 1980105 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5 +7f275651d000-7f275651e000 rw-p 0002b000 08:05 1980105 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5 +7f275651e000-7f27567d1000 r-xp 00000000 08:05 1980107 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 +7f27567d1000-7f27569d0000 ---p 002b3000 08:05 1980107 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 +7f27569d0000-7f27569ec000 r--p 002b2000 08:05 1980107 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 +7f27569ec000-7f27569ed000 rw-p 002ce000 08:05 1980107 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 +7f27569ed000-7f2756a35000 r-xp 00000000 08:05 1979438 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0 +7f2756a35000-7f2756c35000 ---p 00048000 08:05 1979438 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0 +7f2756c35000-7f2756c36000 r--p 00048000 08:05 1979438 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0 +7f2756c36000-7f2756c37000 rw-p 00049000 08:05 1979438 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0 +7f2756c37000-7f2756c4e000 r-xp 00000000 08:05 660530 /lib/x86_64-linux-gnu/libnsl-2.15.so +7f2756c4e000-7f2756e4d000 ---p 00017000 08:05 660530 /lib/x86_64-linux-gnu/libnsl-2.15.so +7f2756e4d000-7f2756e4e000 r--p 00016000 08:05 660530 /lib/x86_64-linux-gnu/libnsl-2.15.so +7f2756e4e000-7f2756e4f000 rw-p 00017000 08:05 660530 /lib/x86_64-linux-gnu/libnsl-2.15.so +7f2756e4f000-7f2756e51000 rw-p 00000000 00:00 0 +7f2756e51000-7f2756e56000 r-xp 00000000 08:05 1979527 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 +7f2756e56000-7f2757055000 ---p 00005000 08:05 1979527 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 +7f2757055000-7f2757056000 r--p 00004000 08:05 1979527 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 +7f2757056000-7f2757057000 rw-p 00005000 08:05 1979527 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 +7f2757057000-7f2757059000 r-xp 00000000 08:05 1979516 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 +7f2757059000-7f2757258000 ---p 00002000 08:05 1979516 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 +7f2757258000-7f2757259000 r--p 00001000 08:05 1979516 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 +7f2757259000-7f275725a000 rw-p 00002000 08:05 1979516 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 +7f275725a000-7f2757286000 r-xp 00000000 08:05 660525 /lib/x86_64-linux-gnu/libncursesw.so.5.9 +7f2757286000-7f2757485000 ---p 0002c000 08:05 660525 /lib/x86_64-linux-gnu/libncursesw.so.5.9 +7f2757485000-7f2757486000 r--p 0002b000 08:05 660525 /lib/x86_64-linux-gnu/libncursesw.so.5.9 +7f2757486000-7f2757487000 rw-p 0002c000 08:05 660525 /lib/x86_64-linux-gnu/libncursesw.so.5.9 +7f2757487000-7f2757578000 r-xp 00000000 08:05 660575 /lib/x86_64-linux-gnu/libslang.so.2.2.4 +7f2757578000-7f2757778000 ---p 000f1000 08:05 660575 /lib/x86_64-linux-gnu/libslang.so.2.2.4 +7f2757778000-7f275777c000 r--p 000f1000 08:05 660575 /lib/x86_64-linux-gnu/libslang.so.2.2.4 +7f275777c000-7f2757794000 rw-p 000f5000 08:05 660575 /lib/x86_64-linux-gnu/libslang.so.2.2.4 +7f2757794000-7f27577f8000 rw-p 00000000 00:00 0 +7f27577f8000-7f27578da000 r-xp 00000000 08:05 1980059 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 +7f27578da000-7f2757ad9000 ---p 000e2000 08:05 1980059 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 +7f2757ad9000-7f2757ae1000 r--p 000e1000 08:05 1980059 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 +7f2757ae1000-7f2757ae3000 rw-p 000e9000 08:05 1980059 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 +7f2757ae3000-7f2757af8000 rw-p 00000000 00:00 0 +7f2757af8000-7f2757afd000 r-xp 00000000 08:05 1979573 /usr/lib/x86_64-linux-gnu/libasyncns.so.0.3.1 +7f2757afd000-7f2757cfc000 ---p 00005000 08:05 1979573 /usr/lib/x86_64-linux-gnu/libasyncns.so.0.3.1 +7f2757cfc000-7f2757cfd000 r--p 00004000 08:05 1979573 /usr/lib/x86_64-linux-gnu/libasyncns.so.0.3.1 +7f2757cfd000-7f2757cfe000 rw-p 00005000 08:05 1979573 /usr/lib/x86_64-linux-gnu/libasyncns.so.0.3.1 +7f2757cfe000-7f2757d5e000 r-xp 00000000 08:05 1980037 /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.25 +7f2757d5e000-7f2757f5e000 ---p 00060000 08:05 1980037 /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.25 +7f2757f5e000-7f2757f60000 r--p 00060000 08:05 1980037 /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.25 +7f2757f60000-7f2757f61000 rw-p 00062000 08:05 1980037 /usr/lib/x86_64-linux-gnu/libsndfile.so.1.0.25 +7f2757f61000-7f2757f65000 rw-p 00000000 00:00 0 +7f2757f65000-7f2757f6d000 r-xp 00000000 08:05 660594 /lib/x86_64-linux-gnu/libwrap.so.0.7.6 +7f2757f6d000-7f275816c000 ---p 00008000 08:05 660594 /lib/x86_64-linux-gnu/libwrap.so.0.7.6 +7f275816c000-7f275816d000 r--p 00007000 08:05 660594 /lib/x86_64-linux-gnu/libwrap.so.0.7.6 +7f275816d000-7f275816e000 rw-p 00008000 08:05 660594 /lib/x86_64-linux-gnu/libwrap.so.0.7.6 +7f275816e000-7f275818b000 r-xp 00000000 08:05 1980136 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 +7f275818b000-7f275838a000 ---p 0001d000 08:05 1980136 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 +7f275838a000-7f275838b000 r--p 0001c000 08:05 1980136 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 +7f275838b000-7f275838c000 rw-p 0001d000 08:05 1980136 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 +7f275838c000-7f27583ae000 r-xp 00000000 08:05 1979609 /usr/lib/x86_64-linux-gnu/libcaca.so.0.99.17 +7f27583ae000-7f27585ae000 ---p 00022000 08:05 1979609 /usr/lib/x86_64-linux-gnu/libcaca.so.0.99.17 +7f27585ae000-7f27585af000 r--p 00022000 08:05 1979609 /usr/lib/x86_64-linux-gnu/libcaca.so.0.99.17 +7f27585af000-7f2758652000 rw-p 00023000 08:05 1979609 /usr/lib/x86_64-linux-gnu/libcaca.so.0.99.17 +7f2758652000-7f2758657000 rw-p 00000000 00:00 0 +7f2758657000-7f2758667000 r-xp 00000000 08:05 1979529 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 +7f2758667000-7f2758866000 ---p 00010000 08:05 1979529 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 +7f2758866000-7f2758867000 r--p 0000f000 08:05 1979529 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 +7f2758867000-7f2758868000 rw-p 00010000 08:05 1979529 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 +7f2758868000-7f275886b000 r-xp 00000000 08:05 1993708 /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.0.3 +7f275886b000-7f2758a6a000 ---p 00003000 08:05 1993708 /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.0.3 +7f2758a6a000-7f2758a6b000 r--p 00002000 08:05 1993708 /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.0.3 +7f2758a6b000-7f2758a6c000 rw-p 00003000 08:05 1993708 /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.0.3 +7f2758a6c000-7f2758a9b000 r-xp 00000000 08:05 1982675 /usr/lib/x86_64-linux-gnu/libaudiofile.so.1.0.0 +7f2758a9b000-7f2758c9b000 ---p 0002f000 08:05 1982675 /usr/lib/x86_64-linux-gnu/libaudiofile.so.1.0.0 +7f2758c9b000-7f2758c9d000 r--p 0002f000 08:05 1982675 /usr/lib/x86_64-linux-gnu/libaudiofile.so.1.0.0 +7f2758c9d000-7f2758c9e000 rw-p 00031000 08:05 1982675 /usr/lib/x86_64-linux-gnu/libaudiofile.so.1.0.0 +7f2758c9e000-7f2758ce0000 r-xp 00000000 08:05 660497 /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8 +7f2758ce0000-7f2758ee0000 ---p 00042000 08:05 660497 /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8 +7f2758ee0000-7f2758ee1000 r--p 00042000 08:05 660497 /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8 +7f2758ee1000-7f2758ee2000 rw-p 00043000 08:05 660497 /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8 +7f2758ee2000-7f2758f3e000 r-xp 00000000 08:05 1993709 /usr/lib/x86_64-linux-gnu/libpulsecommon-1.1.so +7f2758f3e000-7f275913e000 ---p 0005c000 08:05 1993709 /usr/lib/x86_64-linux-gnu/libpulsecommon-1.1.so +7f275913e000-7f275913f000 r--p 0005c000 08:05 1993709 /usr/lib/x86_64-linux-gnu/libpulsecommon-1.1.so +7f275913f000-7f2759140000 rw-p 0005d000 08:05 1993709 /usr/lib/x86_64-linux-gnu/libpulsecommon-1.1.so +7f2759140000-7f2759147000 r-xp 00000000 08:05 1979876 /usr/lib/x86_64-linux-gnu/libjson.so.0.0.1 +7f2759147000-7f2759346000 ---p 00007000 08:05 1979876 /usr/lib/x86_64-linux-gnu/libjson.so.0.0.1 +7f2759346000-7f2759347000 r--p 00006000 08:05 1979876 /usr/lib/x86_64-linux-gnu/libjson.so.0.0.1 +7f2759347000-7f2759348000 rw-p 00007000 08:05 1979876 /usr/lib/x86_64-linux-gnu/libjson.so.0.0.1./RUN_HISPA_1: línea 17: 2952 Abortado (`core' generado) qemu-system-i386 -m 128 -display sdl -cpu pentium -k es -net nic,vlan=0,macaddr=52:54:00:12:02:04,model=pcnet -net vde,vlan=0,sock=/var/run/vde2/tap0.ctl -serial unix:/tmp/com1,server,nowait -vga cirrus -boot c -hda "/home/VirtualMachines/Discos/Hispa70_1.vmdk" -cdrom "/home/VirtualMachines/CDROM/hf-7.0a.iso" 2> statusRUN + +----------------------------------- + +.- output serial.c in statusRUN + +serial: write addr=0x01 val=0x02 +serial: read addr=0x01 val=0x02 +serial: read addr=0x02 val=0x02 +serial: write addr=0x01 val=0x00 +serial: read addr=0x01 val=0x00 +serial: write addr=0x01 val=0x00 +serial: read addr=0x01 val=0x00 +serial: write addr=0x01 val=0x00 +serial: read addr=0x03 val=0x00 +serial: write addr=0x03 val=0xbf +serial: speed=9600 parity=E data=8 stop=2 +serial: write addr=0x02 val=0x00 +serial: write addr=0x03 val=0x00 +serial: speed=9600 parity=N data=5 stop=1 +serial: write addr=0x02 val=0x01 +serial: read addr=0x02 val=0xc1 +serial: write addr=0x03 val=0x80 +serial: speed=9600 parity=N data=5 stop=1 +serial: read addr=0x02 val=0xc1 +serial: write addr=0x03 val=0xbf +serial: speed=9600 parity=E data=8 stop=2 +serial: read addr=0x02 val=0xc1 +serial: write addr=0x03 val=0x80 +serial: speed=9600 parity=N data=5 stop=1 +serial: write addr=0x02 val=0x21 +serial: read addr=0x02 val=0xc1 +serial: write addr=0x02 val=0x01 +serial: write addr=0x03 val=0x00 +serial: speed=9600 parity=N data=5 stop=1 +serial: write addr=0x04 val=0x00 +serial: write addr=0x02 val=0x06 +serial: read addr=0x00 val=0x00 +serial: write addr=0x01 val=0x00 +serial: write addr=0x02 val=0x06 +serial: read addr=0x05 val=0x60 +serial: read addr=0x00 val=0x00 +serial: read addr=0x02 val=0x01 +serial: read addr=0x06 val=0xb0 +serial: write addr=0x03 val=0x03 +serial: speed=9600 parity=N data=8 stop=1 +serial: write addr=0x04 val=0x0b +serial: write addr=0x01 val=0x0d +serial: read addr=0x05 val=0x60 +serial: read addr=0x00 val=0x00 +serial: read addr=0x02 val=0x01 +serial: read addr=0x06 val=0xb0 +serial: write addr=0x01 val=0x05 +serial: write addr=0x03 val=0x93 +serial: speed=9600 parity=N data=8 stop=1 +serial: write addr=0x00 val=0x0c +serial: speed=9600 parity=N data=8 stop=1 +serial: write addr=0x01 val=0x00 +serial: speed=9600 parity=N data=8 stop=1 +serial: write addr=0x03 val=0x13 +serial: speed=9600 parity=N data=8 stop=1 +serial: write addr=0x02 val=0x01 +serial: write addr=0x02 val=0x81 +serial: read addr=0x06 val=0xb0 +serial: write addr=0x04 val=0x09 +serial: read addr=0x05 val=0x60 +serial: read addr=0x06 val=0xb0 +serial: write addr=0x01 val=0x05 +serial: read addr=0x02 val=0xc1 +serial: read addr=0x06 val=0xb0 +serial: write addr=0x01 val=0x05 +serial: write addr=0x03 val=0x96 +serial: speed=9600 parity=N data=7 stop=2 +serial: write addr=0x00 val=0x60 +serial: speed=1200 parity=N data=7 stop=2 +serial: write addr=0x01 val=0x00 +serial: speed=1200 parity=N data=7 stop=2 +serial: write addr=0x03 val=0x16 +serial: speed=1200 parity=N data=7 stop=2 +serial: write addr=0x02 val=0x01 +serial: write addr=0x02 val=0x01 +serial: write addr=0x04 val=0x08 +serial: write addr=0x04 val=0x09 +serial: write addr=0x04 val=0x0b +serial: write addr=0x01 val=0x07 +serial: read addr=0x05 val=0x60 +serial: read addr=0x06 val=0xb0 +serial: write addr=0x00 val=0x41 + +On Wed, Oct 03, 2012 at 12:57:32PM -0000, javier navarro altimira wrote: +> ----------------------------------- +> +> .- script bash launcher +> +> #!/bin/bash +> +> qemu-system-i386 -m 128 -display sdl -cpu pentium \ +> -k es \ +> -net nic,vlan=0,macaddr=52:54:00:12:02:04,model=pcnet \ +> -net vde,vlan=0,sock=/var/run/vde2/tap0.ctl \ +> -serial unix:/tmp/com1,server,nowait \ +> -vga cirrus \ +> -boot c -hda "/home/VirtualMachines/Discos/Hispa70_1.vmdk" \ +> -cdrom "/home/VirtualMachines/CDROM/hf-7.0a.iso" 2>statusRUN +> +> echo -n "Pulsa enter para continuar . . . " && read REPLY +> +> ----------------------------------- +> +> .- Error +> +> *** buffer overflow detected ***: qemu-system-i386 terminated +> ======= Backtrace: ========= +> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f2759892007] +> /lib/x86_64-linux-gnu/libc.so.6(+0x107f00)[0x7f2759890f00] +> /lib/x86_64-linux-gnu/libc.so.6(+0x108fbe)[0x7f2759891fbe] +> qemu-system-i386(+0xe5153)[0x7f275bfd8153] +> qemu-system-i386(+0x1744f6)[0x7f275c0674f6] +> qemu-system-i386(main+0xe77)[0x7f275bf5ef37] +> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f27597aa76d] +> qemu-system-i386(+0x70229)[0x7f275bf63229] + +Thanks for the bug report. The backtrace has no symbol information so it is +hard to tell where in QEMU goes wrong. + +Please ./configure --enable-debug or install the debuginfo package that comes +with your qemu package. This will add symbol information to the backtrace when +you reproduce the buffer overflow again. + +Stefan + + +My english language is very bad, sorry. + +Recompiled by configure whith --enable-debug quit the problem, +I have testesd the serial port with minicom, it works!!!, sorry + +.- steps + .- configure + .- make + .- make install + .- ifup tap0 + .- ifconfig + .- run script 1 + .- run script 2 + .- Inside the machines whith minicom works ok. + +script 1 +-------- +#!/bin/bash + +echo "Launch machine 1" + +qemu-system-i386 -m 128 -display sdl -cpu pentium \ +-k es \ +-net nic,vlan=0,macaddr=52:54:00:12:02:04,model=pcnet \ +-net vde,vlan=0,sock=/var/run/vde2/tap0.ctl \ +-serial unix:/tmp/com1,server,nowait \ +-vga cirrus \ +-boot c -hda "/home/VirtualMachines/Discos/Hispa70_1.vmdk" \ +-cdrom "/home/VirtualMachines/CDROM/hf-7.0a.iso" + +script 2 +-------- +#!/bin/bash + +echo "Launch machine 2" + +qemu-system-i386 -display sdl -cpu pentium \ +-net nic,vlan=0,macaddr=52:54:00:12:FF:04,model=pcnet \ +-net vde,vlan=0,sock=/var/run/vde2/tap0.ctl \ +-serial unix:/tmp/com1,nowait \ +-vga cirrus \ +-boot c -hda "/home/VirtualMachines/Discos/Hispa70_2.vmdk" + +.- configure +./configure --enable-debug --target-list=i386-softmmu,x86_64-softmmu,\ +i386-linux-user,x86_64-linux-user --enable-vde --disable-vnc --enable-sdl \ +--audio-drv-list=oss,alsa,sdl,esd,pa \ +--audio-card-list=ac97,es1370,sb16,cs4231a,adlib,gus,hda &>status + +.- Result of configure + +Install prefix /usr/local +BIOS directory /usr/local/share/qemu +binary directory /usr/local/bin +library directory /usr/local/lib +include directory /usr/local/include +config directory /usr/local/etc +Manual directory /usr/local/share/man +ELF interp prefix /usr/gnemul/qemu-%M +Source path /home/javier/COMPILACIONES/qemu-1.2.0 +C compiler gcc +Host C compiler gcc +Objective-C compiler gcc +CFLAGS -g +QEMU_CFLAGS -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits +LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g +make make +install install +python python +smbd /usr/sbin/smbd +host CPU x86_64 +host big endian no +target list i386-softmmu x86_64-softmmu i386-linux-user x86_64-linux-user +tcg debug enabled yes +gprof enabled no +sparse enabled no +strip binaries no +profiler no +static build no +-Werror enabled no +SDL support yes +curses support yes +curl support no +mingw32 support no +Audio drivers oss alsa sdl esd pa +Extra audio cards ac97 es1370 sb16 cs4231a adlib gus hda +Block whitelist +Mixer emulation no +VirtFS support no +VNC support no +xen support no +brlapi support no +bluez support no +Documentation yes +NPTL support yes +GUEST_BASE yes +PIE yes +vde support yes +Linux AIO support no +ATTR/XATTR support yes +Install blobs yes +KVM support yes +TCG interpreter no +fdt support no +preadv support yes +fdatasync yes +madvise yes +posix_madvise yes +uuid support no +libcap-ng support no +vhost-net support yes +Trace backend nop +Trace output file trace-<pid> +spice support no +rbd support no +xfsctl support no +nss used no +usb net redir no +OpenGL support yes +libiscsi support no +build guest agent yes +seccomp support no +coroutine backend ucontext + +.- ifconfig +tap0 Link encap:Ethernet direcciónHW 1e:b9:3d:8d:cd:29 + Direc. inet:10.0.2.1 Difus.:10.0.2.255 Másc:255.255.255.0 + Dirección inet6: fe80::1cb9:3dff:fe8d:cd29/64 Alcance:Enlace + ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST MTU:1500 Métrica:1 + Paquetes RX:0 errores:0 perdidos:0 overruns:0 frame:0 + Paquetes TX:89 errores:0 perdidos:0 overruns:0 carrier:0 + colisiones:0 long.colaTX:500 + Bytes RX:0 (0.0 B) TX bytes:17478 (17.4 KB) + + + +Triaging old bug tickets... can you anyhow 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/zero-shot/108/all/1062201 b/results/classifier/zero-shot/108/all/1062201 new file mode 100644 index 000000000..3700c604d --- /dev/null +++ b/results/classifier/zero-shot/108/all/1062201 @@ -0,0 +1,252 @@ +permissions: 0.992 +debug: 0.990 +other: 0.990 +semantic: 0.984 +device: 0.982 +boot: 0.982 +performance: 0.979 +PID: 0.976 +files: 0.964 +network: 0.962 +socket: 0.949 +graphic: 0.949 +KVM: 0.932 +vnc: 0.928 + +qemu core dumped by kvm-spice + +Hi there, + +I am trying to use kvm-spice to start the qemu virtual machines. They start fine with the /usr/ bin/kvm command, but when I use the kvm-spice command the VM will not start and the core is dumped. + +Command I used: +kvm-spice -cpu host -enable-kvm -name win-7 -m 3000 -drive file=/var/vmmachines/win-7.img -net nic,model=rtl8139 -net user -localtime -usb -vga qxl -global qxl-vga.vram_size=67108864 -spice port=5901,disable-ticketing -boot d + + +Response: +do_spice_init: starting 0.10.1 +spice_server_add_interface: SPICE_INTERFACE_MIGRATION +spice_server_add_interface: SPICE_INTERFACE_KEYBOARD +spice_server_add_interface: SPICE_INTERFACE_MOUSE +spice_server_add_interface: SPICE_INTERFACE_QXL +red_worker_main: begin +display_channel_create: create display channel +cursor_channel_create: create cursor channel +kvm-spice: /build/buildd/qemu-linaro-1.0.50-2012.03/exec.c:2641: register_subpage: Assertion `existing.mr->subpage || existing.mr == &io_mem_unassigned' failed. +Aborted (core dumped) + + +I am running Ubuntu 12.04 sserver for this. Any information about this issue would be appreciated, i'm stuck on this one. + +Kind regards, +Tom + +Hi, + +I can't reproduce this on either precise or quantal with the stock packages. + +Does it crash before starting to boot windows? + +Can you try installing the qemu-linaro-dbgsym package (per https://wiki.ubuntu.com/DebuggingProgramCrash) and re-run to get a stack trace? + +Sorry, that debug package would be called qemu-kvm-spice-dbgsym. + +Hey Serge, thanks for your response. + +Running the debug module like you asked me to, the attached text file was generated. + +About the crashing before booting Windows: I have no idea. It starts the VM for about one or two seconds, then dumps the core and kills the VM. I'd like to point out it kills the VM with any OS, not just Windows 7. I've tried this with Ubuntu 12.04 (client and server), Windows XP and I think I also tried it with Windows 2k8 R2. It just crashes the VM if I start it this way. + +The way I am using it now is by using the /usr/bin/kvm command. The way I installed the server was by using this PPA: https://launchpad.net/~bderzhavets/+archive/lib-usbredir81 + +Hope you can help, +Tom + +-----Oorspronkelijk bericht----- +Van: <email address hidden> [mailto:<email address hidden>] Namens Serge Hallyn +Verzonden: vrijdag 5 oktober 2012 16:16 +Aan: <email address hidden> +Onderwerp: [Bug 1062201] Re: qemu core dumped by kvm-spice + +Sorry, that debug package would be called qemu-kvm-spice-dbgsym. + +** Also affects: qemu-kvm-spice (Ubuntu) + Importance: Undecided + Status: New + +** Changed in: qemu-kvm-spice (Ubuntu) + Importance: Undecided => Medium + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1062201 + +Title: + qemu core dumped by kvm-spice + +Status in QEMU: + New +Status in “qemu-kvm-spice” package in Ubuntu: + New + +Bug description: + Hi there, + + I am trying to use kvm-spice to start the qemu virtual machines. They + start fine with the /usr/ bin/kvm command, but when I use the kvm- + spice command the VM will not start and the core is dumped. + + Command I used: + kvm-spice -cpu host -enable-kvm -name win-7 -m 3000 -drive file=/var/vmmachines/win-7.img -net nic,model=rtl8139 -net user -localtime -usb -vga qxl -global qxl-vga.vram_size=67108864 -spice port=5901,disable-ticketing -boot d + + + Response: + do_spice_init: starting 0.10.1 + spice_server_add_interface: SPICE_INTERFACE_MIGRATION + spice_server_add_interface: SPICE_INTERFACE_KEYBOARD + spice_server_add_interface: SPICE_INTERFACE_MOUSE + spice_server_add_interface: SPICE_INTERFACE_QXL + red_worker_main: begin + display_channel_create: create display channel + cursor_channel_create: create cursor channel + kvm-spice: /build/buildd/qemu-linaro-1.0.50-2012.03/exec.c:2641: register_subpage: Assertion `existing.mr->subpage || existing.mr == &io_mem_unassigned' failed. + Aborted (core dumped) + + + I am running Ubuntu 12.04 sserver for this. Any information about this issue would be appreciated, i'm stuck on this one. + + Kind regards, + Tom + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1062201/+subscriptions + + +@Tom, + +you are running an experimental PPA containing unstable usb redirection code. +Your best bets are to (a) try with the quantal or upstream package, (b) +if you don't really need the experimental usb redirection, use the precise +packages, or (c) contact the owner of the PPA. Qemu 1.1 (which is in that +PPA) was rather buggy compared to 1.2 (which is upstream and in quantal), +so it would seem worthwhile for the PPA owner to upload a newer version. + + +@ Serge, + +Ah oke, I was not aware of the big version issues. But as Quantal is not officially released yet and only RC's are out, won't that cause issues? +All I am trying to do is get a working demo of the capabilities of the Spice protocol but many of the how-to's and PPA's are heavely out of date / support. Would you have any advice, as manyally building the protocol isn't working for me + +Cheers for the quick responses. + + +Quoting Tom Wijmenga (<email address hidden>): +> @ Serge, +> +> Ah oke, I was not aware of the big version issues. But as Quantal is not officially released yet and only RC's are out, won't that cause issues? + +I'm not sure what you mean by issues - bugs reported against Q will +definately be addressed. The qemu versions in Q are basically set +in stone. If you need features added, then indeed that won't happen +in Q at this point. + +> All I am trying to do is get a working demo of the capabilities of the Spice protocol but many of the how-to's and PPA's are heavely out of date / support. Would you have any advice, as manyally building the protocol isn't working for me + +What do you mean by manually building the protocol? + +In Q, I've been doing: + +sudo apt-get install qemu-kvm-spice +qemu-img create spice.img 10G +kvm-spice -cpu host -enable-kvm -m 1024 -M pc-1.2 -drive file=spice.img,if=virtio,cache=none -vga qxl -spice port=5900,disable-ticketing + +(except also using tap bridged to eth0) + +It's worked great for ubuntu quantal and fedora 18 guests. + + +Oeh boy, do I like feeling like an idiot :) Thanks a lot for that easy way to do it... the guides on forums and the spice-space.org page make it look way more difficult than it needs to be. Big love to you man! + +Regards, Tom + +-----Oorspronkelijk bericht----- +Van: <email address hidden> [mailto:<email address hidden>] Namens Serge Hallyn +Verzonden: maandag 8 oktober 2012 16:22 +Aan: <email address hidden> +Onderwerp: Re: [Bug 1062201] Re: qemu core dumped by kvm-spice + +Quoting Tom Wijmenga (<email address hidden>): +> @ Serge, +> +> Ah oke, I was not aware of the big version issues. But as Quantal is not officially released yet and only RC's are out, won't that cause issues? + +I'm not sure what you mean by issues - bugs reported against Q will +definately be addressed. The qemu versions in Q are basically set +in stone. If you need features added, then indeed that won't happen +in Q at this point. + +> All I am trying to do is get a working demo of the capabilities of the +Spice protocol but many of the how-to's and PPA's are heavely out of +date / support. Would you have any advice, as manyally building the +protocol isn't working for me + +What do you mean by manually building the protocol? + +In Q, I've been doing: + +sudo apt-get install qemu-kvm-spice +qemu-img create spice.img 10G +kvm-spice -cpu host -enable-kvm -m 1024 -M pc-1.2 -drive file=spice.img,if=virtio,cache=none -vga qxl -spice port=5900,disable-ticketing + +(except also using tap bridged to eth0) + +It's worked great for ubuntu quantal and fedora 18 guests. + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1062201 + +Title: + qemu core dumped by kvm-spice + +Status in QEMU: + New +Status in “qemu-kvm-spice” package in Ubuntu: + Invalid + +Bug description: + Hi there, + + I am trying to use kvm-spice to start the qemu virtual machines. They + start fine with the /usr/ bin/kvm command, but when I use the kvm- + spice command the VM will not start and the core is dumped. + + Command I used: + kvm-spice -cpu host -enable-kvm -name win-7 -m 3000 -drive file=/var/vmmachines/win-7.img -net nic,model=rtl8139 -net user -localtime -usb -vga qxl -global qxl-vga.vram_size=67108864 -spice port=5901,disable-ticketing -boot d + + + Response: + do_spice_init: starting 0.10.1 + spice_server_add_interface: SPICE_INTERFACE_MIGRATION + spice_server_add_interface: SPICE_INTERFACE_KEYBOARD + spice_server_add_interface: SPICE_INTERFACE_MOUSE + spice_server_add_interface: SPICE_INTERFACE_QXL + red_worker_main: begin + display_channel_create: create display channel + cursor_channel_create: create cursor channel + kvm-spice: /build/buildd/qemu-linaro-1.0.50-2012.03/exec.c:2641: register_subpage: Assertion `existing.mr->subpage || existing.mr == &io_mem_unassigned' failed. + Aborted (core dumped) + + + I am running Ubuntu 12.04 sserver for this. Any information about this issue would be appreciated, i'm stuck on this one. + + Kind regards, + Tom + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1062201/+subscriptions + + + diff --git a/results/classifier/zero-shot/108/all/1077514 b/results/classifier/zero-shot/108/all/1077514 new file mode 100644 index 000000000..767aa9133 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1077514 @@ -0,0 +1,140 @@ +other: 0.988 +graphic: 0.981 +vnc: 0.973 +debug: 0.973 +KVM: 0.973 +device: 0.972 +permissions: 0.972 +performance: 0.971 +semantic: 0.968 +files: 0.956 +network: 0.956 +PID: 0.954 +socket: 0.948 +boot: 0.946 + +*** buffer overflow detected ***: qemu-system-x86_64 terminated with nowait enabled + +qemu-system-x86_64 -m 1024 -nographic -cpu coreduo -icount auto -hdachs 980,16,32 -kernel asa842-vmlinuz -initrd asa842-initrd.gz -append "ide_generic.probe_mask=0x01 ide_core.chs=0.0:980,16,32 auto nousb console=ttyS0,9600 bigphysarea=65536 no-hlt" -net nic -serial telnet::3020,server,nowait +failed to initialize KVM: Device or resource busy +Back to tcg accelerator. +QEMU 1.2.0 monitor - type 'help' for more information +(qemu) Warning: vlan 0 is not connected to host network +*** buffer overflow detected ***: qemu-system-x86_64 terminated +======= Backtrace: ========= +/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fd9f04b882c] +/lib/x86_64-linux-gnu/libc.so.6(+0x109700)[0x7fd9f04b7700] +/lib/x86_64-linux-gnu/libc.so.6(+0x10a7be)[0x7fd9f04b87be] +qemu-system-x86_64(+0xf1b5d)[0x7fd9f4bb1b5d] +qemu-system-x86_64(+0x18f148)[0x7fd9f4c4f148] +qemu-system-x86_64(main+0xfe3)[0x7fd9f4b35353] +/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fd9f03cf76d] +qemu-system-x86_64(+0x796e9)[0x7fd9f4b396e9] +======= Memory map: ======== +40f54000-50f54000 rwxp 00000000 00:00 0 +7fd990000000-7fd990029000 rw-p 00000000 00:00 0 +7fd990029000-7fd994000000 ---p 00000000 00:00 0 +7fd995907000-7fd995a34000 rw-p 00000000 00:00 0 +7fd995a34000-7fd995a76000 rw-p 00000000 00:00 0 +7fd995a76000-7fd995c00000 rw-p 00000000 00:00 0 +7fd995c00000-7fd996c00000 rw-p 00000000 00:00 0 +7fd996c00000-7fd99842c000 rw-p 00000000 00:00 0 +7fd99842d000-7fd99842e000 rw-p 00000000 00:00 0 +7fd99842e000-7fd99844e000 rw-p 00000000 00:00 0 +7fd99844e000-7fd998450000 rw-p 00000000 00:00 0 +7fd998450000-7fd998470000 rw-p 00000000 00:00 0 +7fd998470000-7fd998472000 rw-p 00000000 00:00 0 +7fd998472000-7fd998492000 rw-p 00000000 00:00 0 +7fd998492000-7fd998493000 rw-p 00000000 00:00 0 +7fd998493000-7fd998494000 ---p 00000000 00:00 0 +7fd998494000-7fd998d95000 rw-p 00000000 00:00 0 [stack:4808] +7fd998dd6000-7fd998e00000 rw-p 00000000 00:00 0 +7fd998e00000-7fd9d8e00000 rw-p 00000000 00:00 0 +7fd9d8e00000-7fd9d8fd7000 rw-p 00000000 00:00 0 +7fd9d8fd7000-7fd9d8fd8000 ---p 00000000 00:00 0 +7fd9d8fd8000-7fd9e87d9000 rw-p 00000000 00:00 0 [stack:4807] +7fd9e87d9000-7fd9e87e2000 r-xp 00000000 08:05 1577354 /lib/x86_64-linux-gnu/libcrypt-2.15.so +7fd9e87e2000-7fd9e89e2000 ---p 00009000 08:05 1577354 /lib/x86_64-linux-gnu/libcrypt-2.15.so +7fd9e89e2000-7fd9e89e3000 r--p 00009000 08:05 1577354 /lib/x86_64-linux-gnu/libcrypt-2.15.so +7fd9e89e3000-7fd9e89e4000 rw-p 0000a000 08:05 1577354 /lib/x86_64-linux-gnu/libcrypt-2.15.so +7fd9e89e4000-7fd9e8a12000 rw-p 00000000 00:00 0 +7fd9e8a12000-7fd9e8ab7000 r-xp 00000000 08:05 4341908 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 +7fd9e8ab7000-7fd9e8cb7000 ---p 000a5000 08:05 4341908 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 +7fd9e8cb7000-7fd9e8cb9000 r--p 000a5000 08:05 4341908 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 +7fd9e8cb9000-7fd9e8cbb000 rw-p 000a7000 08:05 4341908 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 +7fd9e8cbb000-7fd9e8cbc000 rw-p 00000000 00:00 0 +7fd9e8cbc000-7fd9e8d00000 r-xp 00000000 08:05 4341652 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0 +7fd9e8d00000-7fd9e8f00000 ---p 00044000 08:05 4341652 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0 +7fd9e8f00000-7fd9e8f02000 r--p 00044000 08:05 4341652 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0 +7fd9e8f02000-7fd9e8f04000 rw-p 00046000 08:05 4341652 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0 +7fd9e8f04000-7fd9e8f11000 r-xp 00000000 08:05 4341646 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0 +7fd9e8f11000-7fd9e9110000 ---p 0000d000 08:05 4341646 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0 +7fd9e9110000-7fd9e9111000 r--p 0000c000 08:05 4341646 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0 +7fd9e9111000-7fd9e9112000 rw-p 0000d000 08:05 4341646 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0 +7fd9e9112000-7fd9e913a000 r-xp 00000000 08:05 4341985 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0 +7fd9e913a000-7fd9e9339000 ---p 00028000 08:05 4341985 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0 +7fd9e9339000-7fd9e933a000 r--p 00027000 08:05 4341985 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0 +7fd9e933a000-7fd9e933b000 rw-p 00028000 08:05 4341985 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0 +7fd9e933b000-7fd9e933c000 rw-p 00000000 00:00 0 +7fd9e933c000-7fd9e9342000 r-xp 00000000 08:05 4341777 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.0 +7fd9e9342000-7fd9e9541000 ---p 00006000 08:05 4341777 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.0 +7fd9e9541000-7fd9e9542000 r--p 00005000 08:05 4341777 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.0 +7fd9e9542000-7fd9e9543000 rw-p 00006000 08:05 4341777 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.0 +7fd9e9543000-7fd9e956e000 r-xp 00000000 08:05 4341974 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5 +7fd9e956e000-7fd9e976e000 ---p 0002b000 08:05 4341974 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5 +7fd9e976e000-7fd9e976f000 r--p 0002b000 08:05 4341974 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5 +7fd9e976f000-7fd9e9770000 rw-p 0002c000 08:05 4341974 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.5 +7fd9e9770000-7fd9e9a23000 r-xp 00000000 08:05 4341976 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 +7fd9e9a23000-7fd9e9c22000 ---p 002b3000 08:05 4341976 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 +7fd9e9c22000-7fd9e9c3e000 r--p 002b2000 08:05 4341976 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 +7fd9e9c3e000-7fd9e9c3f000 rw-p 002ce000 08:05 4341976 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 +7fd9e9c3f000-7fd9e9c89000 r-xp 00000000 08:05 4336879 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0 +7fd9e9c89000-7fd9e9e89000 ---p 0004a000 08:05 4336879 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0 +7fd9e9e89000-7fd9e9e8a000 r--p 0004a000 08:05 4336879 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0 +7fd9e9e8a000-7fd9e9e8b000 rw-p 0004b000 08:05 4336879 /usr/lib/x86_64-linux-gnu/libFLAC.so.8.2.0 +7fd9e9e8b000-7fd9e9ea2000 r-xp 00000000 08:05 1577610 /lib/x86_64-linux-gnu/libnsl-2.15.so +7fd9e9ea2000-7fd9ea0a1000 ---p 00017000 08:05 1577610 /lib/x86_64-linux-gnu/libnsl-2.15.so +7fd9ea0a1000-7fd9ea0a2000 r--p 00016000 08:05 1577610 /lib/x86_64-linux-gnu/libnsl-2.15.so +7fd9ea0a2000-7fd9ea0a3000 rw-p 00017000 08:05 1577610 /lib/x86_64-linux-gnu/libnsl-2.15.so +7fd9ea0a3000-7fd9ea0a6000 rw-p 00000000 00:00 0 +7fd9ea0a6000-7fd9ea0a8000 r-xp 00000000 08:05 1579638 /lib/x86_64-linux-gnu/libkeyutils.so.1.4 +7fd9ea0a8000-7fd9ea2a8000 ---p 00002000 08:05 1579638 /lib/x86_64-linux-gnu/libkeyutils.so.1.4 +7fd9ea2a8000-7fd9ea2a9000 r--p 00002000 08:05 1579638 /lib/x86_64-linux-gnu/libkeyutils.so.1.4 +7fd9ea2a9000-7fd9ea2aa000 rw-p 00003000 08:05 1579638 /lib/x86_64-linux-gnu/libkeyutils.so.1.4Afbrudt (SIGABRT) (core dumped) + +this only happens with "nowait" enabled. + +On Sun, Nov 11, 2012 at 12:24 AM, Kaare Baastrup <email address hidden> wrote: +> Public bug reported: +> +> qemu-system-x86_64 -m 1024 -nographic -cpu coreduo -icount auto -hdachs 980,16,32 -kernel asa842-vmlinuz -initrd asa842-initrd.gz -append "ide_generic.probe_mask=0x01 ide_core.chs=0.0:980,16,32 auto nousb console=ttyS0,9600 bigphysarea=65536 no-hlt" -net nic -serial telnet::3020,server,nowait +> failed to initialize KVM: Device or resource busy +> Back to tcg accelerator. +> QEMU 1.2.0 monitor - type 'help' for more information +> (qemu) Warning: vlan 0 is not connected to host network +> *** buffer overflow detected ***: qemu-system-x86_64 terminated + +I'm unable to reproduce this on Fedora 18 with qemu.git/master. + +> ======= Backtrace: ========= +> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fd9f04b882c] +> /lib/x86_64-linux-gnu/libc.so.6(+0x109700)[0x7fd9f04b7700] +> /lib/x86_64-linux-gnu/libc.so.6(+0x10a7be)[0x7fd9f04b87be] +> qemu-system-x86_64(+0xf1b5d)[0x7fd9f4bb1b5d] +> qemu-system-x86_64(+0x18f148)[0x7fd9f4c4f148] +> qemu-system-x86_64(main+0xfe3)[0x7fd9f4b35353] +> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fd9f03cf76d] +> qemu-system-x86_64(+0x796e9)[0x7fd9f4b396e9] + +The backtrace is missing symbol information. Please install the +debuginfo packages and repost the backtrace: +https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages + +Alternatively, please build qemu.git/master from source (it has symbol +information) and try to reproduce the bug. + +Stefan + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1080086 b/results/classifier/zero-shot/108/all/1080086 new file mode 100644 index 000000000..bc9eaa1ac --- /dev/null +++ b/results/classifier/zero-shot/108/all/1080086 @@ -0,0 +1,226 @@ +permissions: 0.981 +files: 0.969 +semantic: 0.969 +debug: 0.964 +socket: 0.963 +other: 0.963 +PID: 0.962 +performance: 0.962 +device: 0.959 +boot: 0.956 +vnc: 0.949 +network: 0.923 +graphic: 0.923 +KVM: 0.908 + +MC146818 RTC breaks when SET bit in Register B is on. + +This bug occurs when the SET flag of Register B is enabled. When an RTC +data register (i.e. any of the 10 bytes of time/calender data in CMOS) is set, +the data is (as expected) correctly stored in the cmos_data array. However, +since the SET flag is enabled, the function rtc_set_time is not invoked. +As a result, the field base_rtc in RTCState remains uninitialized. This appears to +cause a problem on subsequent writes which can end up overwriting data. + +To see this, consider writing data to Register A after having written +data to any of the RTC data registers; the following figure illustrates +the call stack for the Register A write operation: + + +- cmos_io_port_write + +-- check_update_timer + +---- get_next_alarm + +------ rtc_update_time + +In rtc_update_time, get_guest_rtc calculates the wrong time and +overwrites the previously written RTC data register values. + +I have created a standalone test case which exposes this bug: + + https://github.com/ahorn/benchmarks/commit/fff1ca40694bbef6f7f9de323bb0bed63419ef99 + +I have attached a patch for the most recent version of the file hw/mc146818rtc.c [1]. The patch also features a functional test which executes through the QTest framework. + +I would appreciate your thoughts on this. + +[1] http://git.qemu.org/?p=qemu.git;a=blob;f=hw/mc146818rtc.c;h=98839f278d93452d071054e2a017b3d909b45ab2;hb=9cb535fe4ef08b01e583ec955767a0899ff79afe#l563 + +Cross reference: + + https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg01759.html + +> [...] the patch is almost good for inclusion. I'd ask for two changes: +> 1) please test == 0, not != REG_B_SET; +> 2) please leave the fuzzicsng test last + +I have attached a new patch with the requested changes. + +This patch also improves the quality of the functional test by +checking that RTC_SECONDS is equal (==) to the previously written data +provided the SET flag in Register B is still enabled. This is +justified by the data sheet which states that an enabled SET bit +"stops an existing update" and prevents "a new one from occurring" [1, +p. 15]. In contrast, once the SET flag is disabled, the RTC_SECONDS +check uses an inequality (>=) as in the original test case. + +Out of curiosity, does anyone know how long this particular bug has +been undetected or how/when it was introduced? This could help me +explain to others my research interest in symbolic execution of +hardware models and its application in form of automated test +generation. + +Finally, if there is interest to improve the robustness of the RTC +model, I could send a patch with several verification conditions (i.e. +assertions) which can help to expose these kind of bugs in the RTC +hardware model. Recall that most compiler can usually optimize these +assertions away unless a developer explicitly enables them. They also +serve as unambiguous code documentation. + +With best regards, +Alex + +[1] http://www.freescale.com/files/microcontrollers/doc/data_sheet/MC146818.pdf + +On 18 November 2012 08:52, Paolo Bonzini <email address hidden> wrote: +> Il 17/11/2012 19:47, Alex Horn ha scritto: +>> I have attached a patch for the most recent version of the file +>> hw/mc146818rtc.c [1]. The patch also features a functional test which +>> executes through the QTest framework. +>> +>> I would appreciate your thoughts on this. +>> +>> [1] +>> http://git.qemu.org/?p=qemu.git;a=blob;f=hw/mc146818rtc.c;h=98839f278d93452d071054e2a017b3d909b45ab2;hb=9cb535fe4ef08b01e583ec955767a0899ff79afe#l563 +>> +>> ** Patch added: "register_b_set_flag.patch" +>> https://bugs.launchpad.net/qemu/+bug/1080086/+attachment/3436808/+files/register_b_set_flag.patch +>> +> +> Hi Alex, the patch is almost good for inclusion. I'd ask for two +> changes: 1) please test == 0, not != REG_B_SET; 2) please leave the +> fuzzing test last, because it may leave some registers in an undefined +> state. +> +> Paolo + + +>> Out of curiosity, does anyone know how long this particular bug has +>> been undetected or how/when it was introduced? +> +> Probably it was introduced last September when the model was rewritten. +> But it's really unlikely that the bug would have been detected. + +Thanks for that quick assessment. + +> On the other hand, the bug in commit b6db4ac (which also includes a +> qtest) was detected by autotest. Could your tool find it, too? + +That's a very respectable achievement. I understand that Autotest runs +predefined (i.e. hand-written) tests on a large scale. In contrast, we +seek a higher degree of automation but on a smaller scale. These +differences could make a comparison difficult. However, your example +is much appreciated because it helps us to set our work in +perspective. + +>> This could help me explain to others my research interest in symbolic +>> execution of hardware models and its application in form of automated +>> test generation. +> +> Very interesting (at least to me :)). + +Perhaps you find the following background helpful. To kick start our +work, we extracted from QEMU a standalone RTC hardware model [2] +because QOM, QMP, TCG or QTest would render the semi-automatic +analysis infeasible. As a next step, we would like to combine this +standalone hardware model with a Linux x86 driver [3]. The reported +bug is a good exemplar of the type of firmware/hardware interface +properties we are interested in. Note that this is only the initial +phase of our research and there is much work yet to be done. + +Of course, any comments or collaboration are always welcome. + +With kind regards, +Alex + +[2] https://github.com/ahorn/benchmarks/tree/master/qemu-hw +[3] https://github.com/ahorn/benchmarks/tree/master/sw-hw/linux/rtc_x86 + +On 19 November 2012 11:42, Paolo Bonzini <email address hidden> wrote: +> Il 19/11/2012 12:34, Alex Horn ha scritto: +>>> [...] the patch is almost good for inclusion. I'd ask for two changes: +>>> 1) please test == 0, not != REG_B_SET; +>>> 2) please leave the fuzzicsng test last +>> +>> I have attached a new patch with the requested changes. +>> +>> This patch also improves the quality of the functional test by +>> checking that RTC_SECONDS is equal (==) to the previously written data +>> provided the SET flag in Register B is still enabled. This is +>> justified by the data sheet which states that an enabled SET bit +>> "stops an existing update" and prevents "a new one from occurring" [1, +>> p. 15]. In contrast, once the SET flag is disabled, the RTC_SECONDS +>> check uses an inequality (>=) as in the original test case. +> +> Right. +> +>> Out of curiosity, does anyone know how long this particular bug has +>> been undetected or how/when it was introduced? +> +> Probably it was introduced last September when the model was rewritten. +> But it's really unlikely that the bug would have been detected. +> +> On the other hand, the bug in commit b6db4ac (which also includes a +> qtest) was detected by autotest. Could your tool find it, too? +> +>> This could help me explain to others my research interest in symbolic +>> execution of hardware models and its application in form of automated +>> test generation. +> +> Very interesting (at least to me :)). +> +>> Finally, if there is interest to improve the robustness of the RTC +>> model, I could send a patch with several verification conditions (i.e. +>> assertions) which can help to expose these kind of bugs in the RTC +>> hardware model. +> +> Sure, that's welcome. +> +> In particular, I assume you verified the "next alarm" code to be correct? :) +> +> Paolo +> +>> Recall that most compiler can usually optimize these +>> assertions away unless a developer explicitly enables them. They also +>> serve as unambiguous code documentation. +>> +>> With best regards, +>> Alex +>> +>> [1] http://www.freescale.com/files/microcontrollers/doc/data_sheet/MC146818.pdf +>> +>> On 18 November 2012 08:52, Paolo Bonzini <email address hidden> wrote: +>>> Il 17/11/2012 19:47, Alex Horn ha scritto: +>>>> I have attached a patch for the most recent version of the file +>>>> hw/mc146818rtc.c [1]. The patch also features a functional test which +>>>> executes through the QTest framework. +>>>> +>>>> I would appreciate your thoughts on this. +>>>> +>>>> [1] +>>>> http://git.qemu.org/?p=qemu.git;a=blob;f=hw/mc146818rtc.c;h=98839f278d93452d071054e2a017b3d909b45ab2;hb=9cb535fe4ef08b01e583ec955767a0899ff79afe#l563 +>>>> +>>>> ** Patch added: "register_b_set_flag.patch" +>>>> https://bugs.launchpad.net/qemu/+bug/1080086/+attachment/3436808/+files/register_b_set_flag.patch +>>>> +>>> +>>> Hi Alex, the patch is almost good for inclusion. I'd ask for two +>>> changes: 1) please test == 0, not != REG_B_SET; 2) please leave the +>>> fuzzing test last, because it may leave some registers in an undefined +>>> state. +>>> +>>> Paolo +> + + +We fixed this bug long ago in 2012, in commit 02c6ccc6dde90d (thanks for your patch!) but forgot to close the bug...so I'm doing it now. + + diff --git a/results/classifier/zero-shot/108/all/1087974 b/results/classifier/zero-shot/108/all/1087974 new file mode 100644 index 000000000..b4dc6d879 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1087974 @@ -0,0 +1,382 @@ +debug: 0.986 +other: 0.979 +semantic: 0.979 +graphic: 0.979 +performance: 0.978 +PID: 0.973 +vnc: 0.973 +device: 0.972 +permissions: 0.970 +socket: 0.961 +files: 0.943 +KVM: 0.939 +network: 0.933 +boot: 0.931 + +[regression] vnc tight png produces garbled output + +VNC Tight PNG compression did work fine two or three month ago but don't anymore. Now when Tight PNG is used parts of the desktop are shown but they are scrambled together. +I have always tested this feature against QEMU git with noVNC by only allowing Tight PNG compression. + +On Sat, Dec 8, 2012 at 12:46 PM, Tim Hardeck <email address hidden> wrote: +> Public bug reported: +> +> VNC Tight PNG compression did work fine two or three month ago but don't anymore. Now when Tight PNG is used parts of the desktop are shown but they are scrambled together. +> I have always tested this feature against QEMU git with noVNC by only allowing Tight PNG compression. + +Hi Tim, +If you have a few minutes please use git-bisect(1) to identify the +commit that causes the regression. + +The rough steps are: +1. Verify that qemu.git/master is broken and find an older commit +where it works. +2. Use git-bisect(1) to binary search the commit history between these +two points - it will leave you with the commit that caused the +regression. + +Here some quick links to get you started: +http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search +http://blog.evan.pro/getting-started-with-git-bisect-in-60-seconds + +Stefan + + +47683d669f993308c2b84bed4ce64aafb5d7ced4 is the first bad commit +commit 47683d669f993308c2b84bed4ce64aafb5d7ced4 +Author: Gerd Hoffmann <email address hidden> +Date: Thu Oct 11 12:04:33 2012 +0200 + + pixman/vnc: remove rgb_prepare_row* functions + + Let pixman do it instead. + + Signed-off-by: Gerd Hoffmann <email address hidden> + +:040000 040000 653d58e66bf3a2d8240b2f9176979c44ccd720e1 6b6e367a8522cb58b42ad8f204387a354d3b3d00 M ui + + +Just reverting this particular commit isn't enough thou but it is connected. + +On Mon, Dec 10, 2012 at 03:54:58PM -0000, Tim Hardeck wrote: +> 47683d669f993308c2b84bed4ce64aafb5d7ced4 is the first bad commit +> commit 47683d669f993308c2b84bed4ce64aafb5d7ced4 +> Author: Gerd Hoffmann <email address hidden> +> Date: Thu Oct 11 12:04:33 2012 +0200 +> +> pixman/vnc: remove rgb_prepare_row* functions +> +> Let pixman do it instead. +> +> Signed-off-by: Gerd Hoffmann <email address hidden> +> +> :040000 040000 653d58e66bf3a2d8240b2f9176979c44ccd720e1 +> 6b6e367a8522cb58b42ad8f204387a354d3b3d00 M ui +> +> +> Just reverting this particular commit isn't enough thou but it is connected. + +This suggests the conversion to pixman has introduced the bug. + +Tim: can you provide steps to reproduce the bug? + +Stefan + + +* make sure that qemu is compiled with --enable-vnc-png + +* git clone git://github.com/kanaka/noVNC +* edit include/rfb.js at line 50 and comment out or remove all encodings above "['TIGHT_PNG', -260 ]," +* open vnc.html in Firefox or Chrome + +*apply either my patch to QEMU https://lists.nongnu.org/archive/html/qemu-devel/2012-12/msg00869.html or use Websockify https://github.com/kanaka/websockify to get Websocket support. + +* in case of my patch run QEMU with `-vnc :0,websocket` and connect with noVNC to port 5700. + +* in case of Websockify run QEMU with `./websockify.py 5900 -- qemu-system-x86_64 -vnc :0` and connect to port 5900 + +On 12/11/12 09:57, Stefan Hajnoczi wrote: +> On Mon, Dec 10, 2012 at 03:54:58PM -0000, Tim Hardeck wrote: +>> 47683d669f993308c2b84bed4ce64aafb5d7ced4 is the first bad commit +>> commit 47683d669f993308c2b84bed4ce64aafb5d7ced4 +>> Author: Gerd Hoffmann <email address hidden> +>> Date: Thu Oct 11 12:04:33 2012 +0200 +>> +>> pixman/vnc: remove rgb_prepare_row* functions +>> +>> Let pixman do it instead. +>> +>> Signed-off-by: Gerd Hoffmann <email address hidden> +>> +>> :040000 040000 653d58e66bf3a2d8240b2f9176979c44ccd720e1 +>> 6b6e367a8522cb58b42ad8f204387a354d3b3d00 M ui +>> +>> +>> Just reverting this particular commit isn't enough thou but it is connected. +> +> This suggests the conversion to pixman has introduced the bug. + +Quite possible. I've tested tight via 'vncviewer +PreferredEncoding=Tight', but that doesn't force png, so there is a +chance for issues I havn't seen. + +> Tim: can you provide steps to reproduce the bug? + +That will certainly help fixing. + +Also: How garbled? Totally messed up? Just colors wrong? Any other +visible pattern? + +cheers, + Gerd + + + + +On 12/11/12 11:09, Tim Hardeck wrote: +> * make sure that qemu is compiled with --enable-vnc-png +> +> * git clone git://github.com/kanaka/noVNC +> * edit include/rfb.js at line 50 and comment out or remove all encodings above "['TIGHT_PNG', -260 ]," +> * open vnc.html in Firefox or Chrome +> +> *apply either my patch to QEMU https://lists.nongnu.org/archive/html +> /qemu-devel/2012-12/msg00869.html or use Websockify +> https://github.com/kanaka/websockify to get Websocket support. +> +> * in case of my patch run QEMU with `-vnc :0,websocket` and connect +> with noVNC to port 5700. +> +> * in case of Websockify run QEMU with `./websockify.py 5900 -- qemu- +> system-x86_64 -vnc :0` and connect to port 5900 + +Hmm, doesn't reproduce here (using websockify proxy). + +--- a/include/rfb.js ++++ b/include/rfb.js +@@ -48,8 +48,8 @@ var that = {}, // Public API methods + + // In preference order + encodings = [ +- ['COPYRECT', 0x01 ], +- ['TIGHT', 0x07 ], ++// ['COPYRECT', 0x01 ], ++// ['TIGHT', 0x07 ], + ['TIGHT_PNG', -260 ], + ['HEXTILE', 0x05 ], + ['RRE', 0x02 ], + + +cheers, + Gerd + + +If you had opened vnc.html before the rfb.js might be still in the browser cache, at least I had a similar issue once. +I have tested this with Chrome but I think it happened in Firefox too. + +This patch adds an x argument to qemu_pixman_linebuf_fill so it can +also be used to convert a partial scanline. Then fix tight + png/jpeg +encoding by passing in the x+y offset, so the data is read from the +correct screen location instead of the upper left corner. + +Cc: <email address hidden> +Cc: <email address hidden> +Reported-by: Tim Hardeneck <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + hw/vga.c | 2 +- + qemu-pixman.c | 4 ++-- + qemu-pixman.h | 2 +- + ui/vnc-enc-tight.c | 4 ++-- + ui/vnc.c | 2 +- + 5 files changed, 7 insertions(+), 7 deletions(-) + +diff --git a/hw/vga.c b/hw/vga.c +index 568083a..22561a5 100644 +--- a/hw/vga.c ++++ b/hw/vga.c +@@ -2413,7 +2413,7 @@ void ppm_save(const char *filename, struct DisplaySurface *ds, Error **errp) + } + linebuf = qemu_pixman_linebuf_create(PIXMAN_BE_r8g8b8, width); + for (y = 0; y < height; y++) { +- qemu_pixman_linebuf_fill(linebuf, ds->image, width, y); ++ qemu_pixman_linebuf_fill(linebuf, ds->image, width, 0, y); + clearerr(f); + ret = fwrite(pixman_image_get_data(linebuf), 1, + pixman_image_get_stride(linebuf), f); +diff --git a/qemu-pixman.c b/qemu-pixman.c +index e46e180..1473835 100644 +--- a/qemu-pixman.c ++++ b/qemu-pixman.c +@@ -52,10 +52,10 @@ pixman_image_t *qemu_pixman_linebuf_create(pixman_format_code_t format, + } + + void qemu_pixman_linebuf_fill(pixman_image_t *linebuf, pixman_image_t *fb, +- int width, int y) ++ int width, int x, int y) + { + pixman_image_composite(PIXMAN_OP_SRC, fb, NULL, linebuf, +- 0, y, 0, 0, 0, 0, width, 1); ++ x, y, 0, 0, 0, 0, width, 1); + } + + pixman_image_t *qemu_pixman_mirror_create(pixman_format_code_t format, +diff --git a/qemu-pixman.h b/qemu-pixman.h +index bee55eb..3c05c83 100644 +--- a/qemu-pixman.h ++++ b/qemu-pixman.h +@@ -31,7 +31,7 @@ pixman_format_code_t qemu_pixman_get_format(PixelFormat *pf); + pixman_image_t *qemu_pixman_linebuf_create(pixman_format_code_t format, + int width); + void qemu_pixman_linebuf_fill(pixman_image_t *linebuf, pixman_image_t *fb, +- int width, int y); ++ int width, int x, int y); + pixman_image_t *qemu_pixman_mirror_create(pixman_format_code_t format, + pixman_image_t *image); + void qemu_pixman_image_unref(pixman_image_t *image); +diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c +index 9ae4cab..62d0fde 100644 +--- a/ui/vnc-enc-tight.c ++++ b/ui/vnc-enc-tight.c +@@ -1212,7 +1212,7 @@ static int send_jpeg_rect(VncState *vs, int x, int y, int w, int h, int quality) + buf = (uint8_t *)pixman_image_get_data(linebuf); + row[0] = buf; + for (dy = 0; dy < h; dy++) { +- qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, dy); ++ qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, x, y + dy); + jpeg_write_scanlines(&cinfo, row, 1); + } + qemu_pixman_image_unref(linebuf); +@@ -1356,7 +1356,7 @@ static int send_png_rect(VncState *vs, int x, int y, int w, int h, + if (color_type == PNG_COLOR_TYPE_PALETTE) { + memcpy(buf, vs->tight.tight.buffer + (dy * w), w); + } else { +- qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, dy); ++ qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, x, y + dy); + } + png_write_row(png_ptr, buf); + } +diff --git a/ui/vnc.c b/ui/vnc.c +index f4486ad..4b15dd4 100644 +--- a/ui/vnc.c ++++ b/ui/vnc.c +@@ -2570,7 +2570,7 @@ static int vnc_refresh_server_surface(VncDisplay *vd) + uint8_t *server_ptr; + + if (vd->guest.format != VNC_SERVER_FB_FORMAT) { +- qemu_pixman_linebuf_fill(tmpbuf, vd->guest.fb, width, y); ++ qemu_pixman_linebuf_fill(tmpbuf, vd->guest.fb, width, 0, y); + guest_ptr = (uint8_t *)pixman_image_get_data(tmpbuf); + } else { + guest_ptr = guest_row; +-- +1.7.1 + + + +This patch adds an x argument to qemu_pixman_linebuf_fill so it can +also be used to convert a partial scanline. Then fix tight + png/jpeg +encoding by passing in the x+y offset, so the data is read from the +correct screen location instead of the upper left corner. + +Cc: <email address hidden> +Cc: <email address hidden> +Reported-by: Tim Hardeneck <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + hw/vga.c | 2 +- + qemu-pixman.c | 4 ++-- + qemu-pixman.h | 2 +- + ui/vnc-enc-tight.c | 4 ++-- + ui/vnc.c | 2 +- + 5 files changed, 7 insertions(+), 7 deletions(-) + +diff --git a/hw/vga.c b/hw/vga.c +index 2b0200a..c266161 100644 +--- a/hw/vga.c ++++ b/hw/vga.c +@@ -2413,7 +2413,7 @@ void ppm_save(const char *filename, struct DisplaySurface *ds, Error **errp) + } + linebuf = qemu_pixman_linebuf_create(PIXMAN_BE_r8g8b8, width); + for (y = 0; y < height; y++) { +- qemu_pixman_linebuf_fill(linebuf, ds->image, width, y); ++ qemu_pixman_linebuf_fill(linebuf, ds->image, width, 0, y); + clearerr(f); + ret = fwrite(pixman_image_get_data(linebuf), 1, + pixman_image_get_stride(linebuf), f); +diff --git a/qemu-pixman.c b/qemu-pixman.c +index 79e175b..e7263fb 100644 +--- a/qemu-pixman.c ++++ b/qemu-pixman.c +@@ -52,10 +52,10 @@ pixman_image_t *qemu_pixman_linebuf_create(pixman_format_code_t format, + } + + void qemu_pixman_linebuf_fill(pixman_image_t *linebuf, pixman_image_t *fb, +- int width, int y) ++ int width, int x, int y) + { + pixman_image_composite(PIXMAN_OP_SRC, fb, NULL, linebuf, +- 0, y, 0, 0, 0, 0, width, 1); ++ x, y, 0, 0, 0, 0, width, 1); + } + + pixman_image_t *qemu_pixman_mirror_create(pixman_format_code_t format, +diff --git a/qemu-pixman.h b/qemu-pixman.h +index bee55eb..3c05c83 100644 +--- a/qemu-pixman.h ++++ b/qemu-pixman.h +@@ -31,7 +31,7 @@ pixman_format_code_t qemu_pixman_get_format(PixelFormat *pf); + pixman_image_t *qemu_pixman_linebuf_create(pixman_format_code_t format, + int width); + void qemu_pixman_linebuf_fill(pixman_image_t *linebuf, pixman_image_t *fb, +- int width, int y); ++ int width, int x, int y); + pixman_image_t *qemu_pixman_mirror_create(pixman_format_code_t format, + pixman_image_t *image); + void qemu_pixman_image_unref(pixman_image_t *image); +diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c +index 9ae4cab..62d0fde 100644 +--- a/ui/vnc-enc-tight.c ++++ b/ui/vnc-enc-tight.c +@@ -1212,7 +1212,7 @@ static int send_jpeg_rect(VncState *vs, int x, int y, int w, int h, int quality) + buf = (uint8_t *)pixman_image_get_data(linebuf); + row[0] = buf; + for (dy = 0; dy < h; dy++) { +- qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, dy); ++ qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, x, y + dy); + jpeg_write_scanlines(&cinfo, row, 1); + } + qemu_pixman_image_unref(linebuf); +@@ -1356,7 +1356,7 @@ static int send_png_rect(VncState *vs, int x, int y, int w, int h, + if (color_type == PNG_COLOR_TYPE_PALETTE) { + memcpy(buf, vs->tight.tight.buffer + (dy * w), w); + } else { +- qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, dy); ++ qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, x, y + dy); + } + png_write_row(png_ptr, buf); + } +diff --git a/ui/vnc.c b/ui/vnc.c +index ba30362..04afcff 100644 +--- a/ui/vnc.c ++++ b/ui/vnc.c +@@ -2569,7 +2569,7 @@ static int vnc_refresh_server_surface(VncDisplay *vd) + uint8_t *server_ptr; + + if (vd->guest.format != VNC_SERVER_FB_FORMAT) { +- qemu_pixman_linebuf_fill(tmpbuf, vd->guest.fb, width, y); ++ qemu_pixman_linebuf_fill(tmpbuf, vd->guest.fb, width, 0, y); + guest_ptr = (uint8_t *)pixman_image_get_data(tmpbuf); + } else { + guest_ptr = guest_row; +-- +1.7.1 + + + +The patch does fix the issue for me, thanks. + +Gerd's patch had been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=bc210eb163b162ff2 +==> Setting status to "Fix released" + diff --git a/results/classifier/zero-shot/108/all/1089496 b/results/classifier/zero-shot/108/all/1089496 new file mode 100644 index 000000000..582e94d29 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1089496 @@ -0,0 +1,80 @@ +other: 0.952 +permissions: 0.946 +KVM: 0.945 +vnc: 0.943 +device: 0.941 +files: 0.940 +performance: 0.938 +graphic: 0.935 +debug: 0.934 +PID: 0.933 +semantic: 0.931 +socket: 0.930 +network: 0.930 +boot: 0.926 + +qemu doesn't set vnc port correctly + +Qemu Version: 1.1.1 + +In the past it was possible to set the port for vnc with: +-vnc :1 +That would mean the port would be 5901, Starting from 5900 plus the given number. However, it was also possible to set the port directly with a custom given port. Usually i set the port to something like 5801. With qemu-1.1.1 (and maybe prior versions too, i usually use spice) that's not possible anymore. For example: +-vnc 192.168.1.1:5804 +Here the 'real' port would be 11704 (that's 5900 + 5804). I'm sure that worked correctly in the past and i'm pretty sure it's easy to fix. + +Would be nice if we can fix that. + +System Info: +Portage 2.1.11.31 (default/linux/amd64/10.0/no-multilib, gcc-4.5.4, glibc-2.15-r3, 3.5.7-gentoo x86_64) +================================================================= +System uname: Linux-3.5.7-gentoo-x86_64-Intel-R-_Xeon-R-_CPU_E5405_@_2.00GHz-with-gentoo-2.1 +Timestamp of tree: Wed, 12 Dec 2012 05:15:01 +0000 +ld GNU ld (GNU Binutils) 2.22 +app-shells/bash: 4.2_p37 +dev-lang/python: 2.7.3-r2, 3.2.3 +dev-util/cmake: 2.8.9 +dev-util/pkgconfig: 0.27.1 +sys-apps/baselayout: 2.1-r1 +sys-apps/openrc: 0.11.8 +sys-apps/sandbox: 2.5 +sys-devel/autoconf: 2.68 +sys-devel/automake: 1.11.6 +sys-devel/binutils: 2.22-r1 +sys-devel/gcc: 4.5.4 +sys-devel/gcc-config: 1.7.3 +sys-devel/libtool: 2.4-r1 +sys-devel/make: 3.82-r3 +sys-kernel/linux-headers: 3.6 (virtual/os-headers) +sys-libs/glibc: 2.15-r3 +Repositories: gentoo x-local x11 sunrise virtualization +ACCEPT_KEYWORDS="amd64" +ACCEPT_LICENSE="* -@EULA" +CBUILD="x86_64-pc-linux-gnu" +CFLAGS="-O2 -pipe -march=native -fopenmp" +CHOST="x86_64-pc-linux-gnu" +CONFIG_PROTECT="/etc /usr/share/openvpn/easy-rsa" +CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" +CXXFLAGS="-O2 -pipe -march=native -fopenmp" +DISTDIR="/usr/portage/distfiles" +FCFLAGS="-O2 -pipe" +FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" +FFLAGS="-O2 -pipe" +GENTOO_MIRRORS=" http://gentoo.supp.name/ http://ftp.fi.muni.cz/pub/linux/gentoo/ http://gentoo.mirror.web4u.cz/ http://gentoo.mirror.dkm.cz/pub/gentoo/ http://gentoo.ynet.sk/pub" +LANG="de_DE.utf8" +LDFLAGS="-Wl,-O1 -Wl,--as-needed -fopenmp" +MAKEOPTS="-j12" +PKGDIR="/usr/portage/packages" +PORTAGE_CONFIGROOT="/" +PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" +PORTAGE_TMPDIR="/var/tmp" +PORTDIR="/usr/portage" +PORTDIR_OVERLAY="/mnt/data/public/overlays/local /mnt/data/public/overlays/layman/x11 /mnt/data/public/overlays/layman/sunrise /mnt/data/public/overlays/layman/virtualization" +SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage/" +USE="acl acpi amd64 berkdb bzip2 cli cracklib crypt cups cxx dbus dri fortran gdbm gif gpm iconv ipv6 mmx modules mudflap ncurses nls nptl openmp pam pbm pcre png pppd readline session sqlite sse sse2 ssl ssse3 tcpd threads unicode zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" QEMU_SOFTMMU_TARGETS="i386 x86_64 mips arm ppc ppc64" QEMU_USER_TARGETS="i386 x86_64 mips arm ppc ppc64" RUBY_TARGETS="ruby18 ruby19" SANE_BACKENDS="niash" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" +Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON + +The problem with this is that the behaviour is inherently ambiguous. We have no way to distinguish whether a user specifying ":5804" wants port 11704 or port 5804, so it is not in fact easy to fix. + +If we were writing this again from scratch I would avoid the offset concept entirely and always require absolute port, but given where we are, unconditionally treating the port number as an offset relative to 5900 is the only sane approach, unless we introduce completely new syntax. + diff --git a/results/classifier/zero-shot/108/all/1101210 b/results/classifier/zero-shot/108/all/1101210 new file mode 100644 index 000000000..b948b9ad5 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1101210 @@ -0,0 +1,223 @@ +semantic: 0.974 +performance: 0.972 +graphic: 0.968 +device: 0.967 +PID: 0.967 +other: 0.967 +debug: 0.967 +permissions: 0.963 +vnc: 0.962 +boot: 0.957 +files: 0.957 +KVM: 0.946 +socket: 0.946 +network: 0.944 + +qemu 1.4.2: usb keyboard not fully working + +When using the usb keyboard, I can't type the | character. I'm using german keyboard layout (de) on the host and inside the guest. As a guest OS, I use Linux (e.g. a recent KNOPPIX cd). To obtain the | character on a german keyboard, I need to press AltGr + the < or > key, i.e. the key right to the left shift. + +The qemu command line is something like this: +./qemu-system-i386 -device pci-ohci -device usb-kbd +I also tried +./qemu-system-i386 -usb -usbdevice keyboard +with the same effect. + +Actually, the whole < > | key doesn't work. It's just dead. I can't type any of those characters. + +Any comment? The <>| key is still not working in qemu 1.4.2. + +Affects as well Win8.1 as Host System and Debian as Client, tested with latest qemu 2.1.50 (fetched from git). + +Debian : 3.2.0-4-vexpress #1 SMP Debian 3.2.57-3 armv71 + +with startup parameters : +h:\qemu\test\qemu-system-armw" -M vexpress-a9 -kernel vmlinuz-3.2.0-4-vexpress -initrd initrd.img-3.2.0-4-vexpress -append "root=/dev/mmcblk0p2" -drive if=sd,cache=unsafe,file=hda.img -redir tcp:6666::8080 -k de + +Any key combined with AltGr doesn't work in Linux clients, which is @|}{ etc. on german keyboards. +setxkb and locale is set to german keyboard. + +Testing the same Debian virtual machine under Ubuntu Linux 14.10 with same qemu 2.1.50 compiled from latest git as of today, AltGr key combinations just work fine. + +On Windows host showkey in Debian client outputs when trying to press AltGr + < to obtain "|" two times : + +Keycode 28 released +Keycode 29 pressed +Keycode 56 pressed +Keycode 86 pressed +Keycode 86 released +Keycode 29 released +Keycode 56 released +Keycode 29 pressed +Keycode 56 pressed +Keycode 86 pressed +Keycode 86 released +Keycode 29 released +Keycode 56 released + +Entering the same key combo in QEmu monitor just seems to be working fine, resulting in "|" output in the monitor. + +Using sendkey in monitor "sendkey ctrl-alt-<" results in : +Keycode 28 released +Keycode 29 pressed +Keycode 56 pressed +Keycode 86 pressed +Keycode 29 released +Keycode 56 released +Keycode 86 released + +However, this also results in no "|" Symbol being printed on Debian console. + +Thus, issue seems to affect just Windows Hosts using Linux clients such as Debian. Any ideas, maybe wrong keycodes ? + + +Additional : +Running the same debian virtual machine under Linux host where "AltGr+<" in order to get "|" on german keyboard seems to work properly, I get the following result running sendkey in console : + +Keycode 28 released; +Keycode 100 pressed; +Keycode 86 pressed; +Keycode 86 released; +Keycode 100 released; +Keycode 100 pressed; +Keycode 86 pressed; +Keycode 86 released; +Keycode 100 released; + +As you can clearly see, as on Windows host Keycode for Altgr being sent is "29 + 56" whereas it clearly should be sending Keycode "100" instead in order to work properly. + +xev log using ubuntu host and debian virtual machine for pressing altgr + < key to obtain "|" using german layout : + +KeyPress event, serial 43, synthetic NO, window 0x1600001, + root 0x43, subw 0x0, time 4278157, (165,-105), root:(446,164), + state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, + XKeysymToKeycode returns keycode: 92 + XLookupString gives 0 bytes: + XmbLookupString gives 0 bytes: + XFilterEvent returns: False + +KeyPress event, serial 46, synthetic NO, window 0x1600001, + root 0x43, subw 0x0, time 4278365, (165,-105), root:(446,164), + state 0x80, keycode 94 (keysym 0x7c, bar), same_screen YES, + XLookupString gives 1 bytes: (7c) "|" + XmbLookupString gives 1 bytes: (7c) "|" + XFilterEvent returns: False + + +After some digging, it seems that windows itself is responsible for that bug. On international keyboards, it tend to send "Ctrl" and "Alt" instead of "AltGr" keycode. + +A possible patch would be to add an option to QEMU command line to handle Ctrl and Alt keystrokes being pressed at the same time as AltGr keystroke. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I am testing the qemu windows version from: + +https://qemu.weilnetz.de/w64/qemu-w64-setup-20180519.exe + +And AltGr does not work at all. + +Another issue is that it seems that Spanish keyboard layout has been changed and in my Spanish (from Spain -Europe-) does not work fine. Maybe the layout has been changed into Spanish Latin layout. I think that two diferent layouts are needed. + + +Looks like people report different issues here... if you report a keyboard mapping problem, please try to either make sure that it matches the bug, or open a new ticket. + +So the original problem (with the < > | not working at all) seems to be fixed nowadays, at least it works for me with a Linux guest running on a Linux host. + +But I'll leave this ticket opened for the Windows problems that have been reported. + +José, could you please add the information about your guest? Are you running Linux or Windows in QEMU? + +Hi, Thomas, + +Thanks for your answer. + +The mapping keyboard problem happens only from latests versions of qemu for windows. December one, was correct. + +My host system is windows 10 and my guest system is an Spanish (Spain -Europe-) msdos 5.0. + +But if I boot whithout any system (network booting), the altgr problem still remains. + +Thanks for your answer. + +With a freshly compiled version of qemu 4.0.50 +on Widows 10 (host) + +I am using 3 different Belgian keyboards and I have the same behaviour +- 2 USB keyboards (Logitech and HP) and +- the keyboard of my laptop (HP) + +3 characters on the same key cannot be used (the key seams to be dead): +< (less than), +> (greater than) used with the combination of LShift or RShift +\ (backslash) used with the combination of AltGr + +Using grub command mode from an archlinux installation (5.1.4) +The keyboard seams to be a mix of azerty and qwerty keyboard +all letters are correctly mapped but all numbers and special +characters are not + +Using sendkey in monitor +"sendkey <" results in : \ +"sendkey shift-<" results in : | +"sendkey ctrl-alt-<" results in : nothing + +REM: VirtualBox can handle this key and with the showkey command + from the archlinux kbd package, it shows : + keycode 86 press + keycode 86 release + +Same issue with the qemu version 4.1.0 +Host: Windows 10 +Guest: Archlinux 5.0.10 + +showkey output : + +keycode 100 # Alt Gr +keycode 29 # Left Control +keycode 97 # Right Contol +keycode 56 # Left Alt +no output # '> < \' key, should be 86 + +If I change the keyboard layout on the Host (Windows 10), showkey reports different keycode: + +Keyboard layout Belgian (Comma) AZERTY +key 'A' keycode 30 (VirtualBox reports keycode 16) + +Keyboard layout US QWERTY +key 'A' keycode 16 + + +With qemu version 2.9.94 + +Host: Windows 10 +Guest: Archlinux 5.0.10 + +showkey output : + +keycode 56 press # Alt Gr +keycode 29 release # Alt Gr +keycode 56 release # Alt Gr + +keycode 29 press # Left Control +keycode 29 release # Left Control + +keycode 29 press # Right Contol +keycode 29 release # Right Contol + +keycode 56 press # Left Alt +keycode 56 release # Left Alt + +keycode 86 press # '> < \' key +keycode 86 release # '> < \' key + +As you can see the key 'Alt Gr' is not correctly mapped, it should return 100 + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/93 + + diff --git a/results/classifier/zero-shot/108/all/1158912 b/results/classifier/zero-shot/108/all/1158912 new file mode 100644 index 000000000..5e6b9338f --- /dev/null +++ b/results/classifier/zero-shot/108/all/1158912 @@ -0,0 +1,325 @@ +debug: 0.979 +semantic: 0.976 +graphic: 0.976 +other: 0.975 +permissions: 0.974 +PID: 0.969 +device: 0.967 +socket: 0.961 +network: 0.960 +performance: 0.952 +files: 0.947 +boot: 0.947 +vnc: 0.943 +KVM: 0.931 + +QEMU Version 1.4.0 - SLIRP hangs VM + +(Note: problem is not present in version 1.3.0) + +Stacktrace: please see attached gdb log file. + +Steps to reproduce: + +1. gdb -x debug-qemu.gdb testing/qemu-1.4.0/ppc64-softmmu/qemu-system-ppc64 + +Contents of debug-qemu.gdb: + +run -L ./testing/qemu-1.4.0/pc-bios -name "[DEBUG] Software und System-Entwicklung IBM POWER7" -cpu POWER7_v2.3 -M pseries -m 1024 -rtc base=utc -nodefaults -vga std -monitor vc -serial vc -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9011-10.0.2.11:22 -device virtio-net-pci,netdev=mynet0 -drive file=images/suse-ppc.img,if=virtio,index=0,media=disk,cache=unsafe -kernel images/iso/suseboot/vmlinux -append "root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0" -initrd images/iso/suseboot/initrd.img -drive if=scsi,bus=0,unit=0,media=cdrom + + +2. build information + QEMU: ppc64 full emulation, version 1.4.0 + Host OS: Windows XP + Guest OS: openSUSE 12.2 kernel 3.4.6-2.10-ppc64 + + PATH=/usr/i686-pc-mingw32/sys-root/mingw/bin:$PATH + PKG_CONFIG_LIBDIR=/usr/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig + THREADS=4 + export PKG_CONFIG_LIBDIR + + sed -i 's/--static-libs/--static --libs/' configure + CC=i686-pc-mingw32-gcc ./configure \ + --target-list=ppc64-softmmu \ + --enable-debug \ + --enable-sdl \ + --static \ + --enable-fdt && \ + sed -i 's/ -Wl,--dynamicbase//g; s/-Wl,--nxcompat //g;' config-host.mak && \ + make -j$THREADS && { + echo "renaming binw.exe to bin.exe..." + for i in `echo $TARGET_LIST | tr ',' ' '`; do + BINARCH=`echo $i | sed 's/-softmmu//'` + mv $i/qemu-system-${BINARCH}w.exe \ + $i/qemu-system-$BINARCH.exe + done + } + + +3. From VM: + Command to hang VM: zypper dup + Last message before VM hang: Retrieving repository 'openSUSE-12.2-12.2-0' metadata -----------------------[|] + + + +On Fri, Mar 22, 2013 at 05:51:14PM -0000, Kenneth Salerno wrote: +> Public bug reported: +> +> (Note: problem is not present in version 1.3.0) + +Please run git-bisect(1) to identify the commit that introduced the bug. + +Information about git-bisect(1): +http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search +http://code-worrier.com/blog/git-bisect-basics/ +https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html + +Stefan + + +Result of git bisect: + +commit 837d1f978224f7e7b020c71ffb10b291952cc596 +Merge: a6fc23e 2b35e93 +Author: Blue Swirl <email address hidden> +Date: Sat Jan 12 12:46:57 2013 +0000 + + Merge branch 's390-reorg' of git://repo.or.cz/qemu/rth + + * 's390-reorg' of git://repo.or.cz/qemu/rth: (149 commits) + target-s390: Claim maintainership + target-s390: Use noreturn for exception and load_psw + target-s390: Use TCG_CALL_NO_WG for misc helpers + target-s390: Use TCG_CALL_NO_WG for integer helpers + target-s390: Use TCG_CALL_NO_WG for floating-point helpers + target-s390: Use TCG_CALL_NO_WG for memory helpers + target-s390: Perform COMPARE AND SWAP inline + target-s390: Optimize get_address + target-s390: Optimize ADDC/SUBB + target-s390: Optimize ADDU/SUBU CC testing + target-s390: Tidy comparisons + target-s390: Optmize emitting discards + target-s390: Optimize XC + target-s390: Fix cpu_clone_regs + target-s390: Implement LOAD/SET FP AND SIGNAL + target-s390: Implement SET ROUNDING MODE + target-s390: Use uint64_to_float128 + target-s390: Implement LCDFR + target-s390: Check insn operand specifications + target-s390: Implement CPSDR + ... + + +There are 1,484 files affected by this commit - Is there a way I can narrow this down even further within this commit? + +Also attaching "strace -f" output from guest during execution of "zypper dup" leading to hang, as well as corresponding qemu gdb log following hang. + +The last lines of the strace are: + +time(NULL) = 1364222018 +stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 +uname({sys="Linux", node="suse-ppc", ...}) = 0 +write(3, "2013-03-25 10:33:38 <1> suse-ppc"..., 127) = 127 +time(NULL) = 1364222018 +stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 +uname({sys="Linux", node="suse-ppc", ...}) = 0 +write(3, "2013-03-25 10:33:38 <1> suse-ppc"..., 137) = 137 +close(9) = 0 +time(NULL) = 1364222018 +stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 +uname({sys="Linux", node="suse-ppc", ...}) = 0 +write(3, "2013-03-25 10:33:38 <1> suse-ppc"..., 127) = 127 +time(NULL) = 1364222018 +stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 +uname({sys="Linux", node="suse-ppc", ...}) = 0 +write(3, "2013-03-25 10:33:38 <1> suse-ppc"..., 137 <------------ QEMU window becomes unresponsive + + + +On Mon, Mar 25, 2013 at 08:57:46PM -0000, Kenneth Salerno wrote: +> Result of git bisect: +> +> commit 837d1f978224f7e7b020c71ffb10b291952cc596 +> Merge: a6fc23e 2b35e93 +> Author: Blue Swirl <email address hidden> +> Date: Sat Jan 12 12:46:57 2013 +0000 +> +> Merge branch 's390-reorg' of git://repo.or.cz/qemu/rth +> +> * 's390-reorg' of git://repo.or.cz/qemu/rth: (149 commits) +> target-s390: Claim maintainership +> target-s390: Use noreturn for exception and load_psw +> target-s390: Use TCG_CALL_NO_WG for misc helpers +> target-s390: Use TCG_CALL_NO_WG for integer helpers +> target-s390: Use TCG_CALL_NO_WG for floating-point helpers +> target-s390: Use TCG_CALL_NO_WG for memory helpers +> target-s390: Perform COMPARE AND SWAP inline +> target-s390: Optimize get_address +> target-s390: Optimize ADDC/SUBB +> target-s390: Optimize ADDU/SUBU CC testing +> target-s390: Tidy comparisons +> target-s390: Optmize emitting discards +> target-s390: Optimize XC +> target-s390: Fix cpu_clone_regs +> target-s390: Implement LOAD/SET FP AND SIGNAL +> target-s390: Implement SET ROUNDING MODE +> target-s390: Use uint64_to_float128 +> target-s390: Implement LCDFR +> target-s390: Check insn operand specifications +> target-s390: Implement CPSDR +> ... +> +> +> There are 1,484 files affected by this commit - Is there a way I can narrow this down even further within this commit? + +Looks like git-bisect(1) got stuck on a merge - maybe it followed the +wrong parent commit. + +Please manually check whether a6fc23e hangs: + + $ cd qemu + $ git checkout a6fc23e + $ ...build and test hang... + +If a6fc23e is indeed broken then you can start a new git bisect between +v1.3.0 (good) and a6fc23e (bad). + +If a6fc23e is not broken then that really suggestes the 's390-reorg' +merge broke SLIRP, which is unlikely. + +Hope this helps. + +Regarding the QEMU backtrace, it shows SLIRP is waiting in a blocking +accept() call: + +Thread 1 (Thread 416.0x228): +#0 0x7c90e514 in ntdll!KiFastSystemCallRet () + from /cygdrive/c/WINDOWS/system32/ntdll.dll +#1 0x7c90df5a in ntdll!ZwWaitForSingleObject () + from /cygdrive/c/WINDOWS/system32/ntdll.dll +#2 0x71a5402b in ?? () from /cygdrive/c/WINDOWS/system32/mswsock.dll +#3 0x71a6b858 in StartWsdpService () + from /cygdrive/c/WINDOWS/system32/mswsock.dll +#4 0x71ac0e46 in WSAAccept () from /cygdrive/c/WINDOWS/system32/WS2_32.dll +#5 0x71ac1057 in accept () from /cygdrive/c/WINDOWS/system32/WS2_32.dll +#6 0x0057caff in tcp_connect (inso=0x1c07c68) at slirp/tcp_subr.c:423 +#7 0x005763d0 in slirp_select_poll (readfds=0xa19a40 <rfds>, + writefds=0xa19b60 <wfds>, xfds=0xa19c80 <xfds>, select_error=0) + at slirp/slirp.c:485 +#8 0x0053688b in main_loop_wait (nonblocking=0) at main-loop.c:419 +#9 0x005a8333 in main_loop () at vl.c:2001 +#10 0x005af134 in qemu_main (argc=34, argv=0x1c08048, envp=0x0) at vl.c:4326 +#11 0x005a4d84 in SDL_main (argc=34, argv=0x1c08048) at vl.c:102 +#12 0x0073a951 in console_main () +#13 0x00000022 in ?? () +#14 0x01c08048 in ?? () + +Since the main loop holds the global mutex the guest is unable to make +progress and appears to hang. + +Stefan + + +Sorry for the confusion, I was impatient for the first bisect run to complete - this time I figured out how to automate the testing portion of the git bisect run script so I could walk away and let it run until full completion. + +Here is the result: + +acbb090b2400f627a801074c4e3e006c7501bb26 is the first bad commit +commit acbb090b2400f627a801074c4e3e006c7501bb26 +Author: Andreas Färber <email address hidden> +Date: Wed Aug 15 14:15:41 2012 +0200 + + prep: Include devices for ppc64 as well + + Allows running qemu-system-ppc64 -M prep for consistency. + + Reported-by: Markus Armbruster <email address hidden> + Signed-off-by: Andreas Färber <email address hidden> + Acked-by: Hervé Poussineau <email address hidden> + +:040000 040000 efe2ed40eeef1863d210ab089033fdb0ce1eaea5 05c5174a00f99176a57398b32c5af659b8b0096c M default-configs +bisect run success + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Hi, you can close this bug. +Ken + +Sent from Yahoo Mail on Android + + On Tue, Jan 2, 2018 at 11:19 AM, Thomas Huth<email address hidden> wrote: Triaging old bug tickets... can you still reproduce this issue with the +latest version of QEMU? Or could we close this ticket nowadays? + +** Changed in: qemu + Status: New => Incomplete + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1158912 + +Title: + QEMU Version 1.4.0 - SLIRP hangs VM + +Status in QEMU: + Incomplete + +Bug description: + (Note: problem is not present in version 1.3.0) + + Stacktrace: please see attached gdb log file. + + Steps to reproduce: + + 1. gdb -x debug-qemu.gdb testing/qemu-1.4.0/ppc64-softmmu/qemu-system- + ppc64 + + Contents of debug-qemu.gdb: + + run -L ./testing/qemu-1.4.0/pc-bios -name "[DEBUG] Software und + System-Entwicklung IBM POWER7" -cpu POWER7_v2.3 -M pseries -m 1024 + -rtc base=utc -nodefaults -vga std -monitor vc -serial vc -netdev + type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9011-10.0.2.11:22 -device + virtio-net-pci,netdev=mynet0 -drive file=images/suse- + ppc.img,if=virtio,index=0,media=disk,cache=unsafe -kernel + images/iso/suseboot/vmlinux -append "root=/dev/mapper/system-root ro + audit=0 selinux=0 apparmor=0" -initrd images/iso/suseboot/initrd.img + -drive if=scsi,bus=0,unit=0,media=cdrom + + + 2. build information + QEMU: ppc64 full emulation, version 1.4.0 + Host OS: Windows XP + Guest OS: openSUSE 12.2 kernel 3.4.6-2.10-ppc64 + + PATH=/usr/i686-pc-mingw32/sys-root/mingw/bin:$PATH + PKG_CONFIG_LIBDIR=/usr/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig + THREADS=4 + export PKG_CONFIG_LIBDIR + + sed -i 's/--static-libs/--static --libs/' configure + CC=i686-pc-mingw32-gcc ./configure \ + --target-list=ppc64-softmmu \ + --enable-debug \ + --enable-sdl \ + --static \ + --enable-fdt && \ + sed -i 's/ -Wl,--dynamicbase//g; s/-Wl,--nxcompat //g;' config-host.mak && \ + make -j$THREADS && { + echo "renaming binw.exe to bin.exe..." + for i in `echo $TARGET_LIST | tr ',' ' '`; do + BINARCH=`echo $i | sed 's/-softmmu//'` + mv $i/qemu-system-${BINARCH}w.exe \ + $i/qemu-system-$BINARCH.exe + done + } + + + 3. From VM: + Command to hang VM: zypper dup + Last message before VM hang: Retrieving repository 'openSUSE-12.2-12.2-0' metadata -----------------------[|] + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1158912/+subscriptions + + diff --git a/results/classifier/zero-shot/108/all/1178101 b/results/classifier/zero-shot/108/all/1178101 new file mode 100644 index 000000000..e28c8d38f --- /dev/null +++ b/results/classifier/zero-shot/108/all/1178101 @@ -0,0 +1,65 @@ +other: 0.992 +semantic: 0.990 +permissions: 0.990 +device: 0.990 +socket: 0.989 +files: 0.989 +graphic: 0.989 +PID: 0.989 +network: 0.989 +performance: 0.989 +debug: 0.989 +vnc: 0.988 +KVM: 0.988 +boot: 0.987 + +Could not enable gtk UI on build for Windows target + +$ ${QEMU_SRC_DIR}/configure --prefix=${BIN_ROOT} --cross-prefix=${HOST_TRIPLET}- --extra-cflags="-I${BIN_ROOT}/include" --extra-ldflags="-L${BIN_ROOT}/lib" --enable-gtk --disable-xen + +ERROR: User requested feature gtk + configure was not able to find it + + +$ cat config.log +# QEMU configure log Thu May 9 13:50:40 CST 2013 +# Configured with: '/home/cauchy/vcs/git/qemu/configure' '--prefix=/home/cauchy/w32' '--cross-prefix=i686-w64-mingw32-' '--extra-cflags=-I/home/cauchy/w32/include' '--extra-ldflags=-L/home/cauchy/w32/lib' '--enable-gtk' '--disable-xen' +# +i686-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -c -o /tmp/qemu-conf--18025-.o /tmp/qemu-conf--18025-.c +/tmp/qemu-conf--18025-.c:2:2: error: #error __linux__ not defined + #error __linux__ not defined + ^ +i686-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -c -o /tmp/qemu-conf--18025-.o /tmp/qemu-conf--18025-.c +i686-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -c -o /tmp/qemu-conf--18025-.o /tmp/qemu-conf--18025-.c +i686-w64-mingw32-gcc -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -g -L/home/cauchy/w32/lib -liberty +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -c -o /tmp/qemu-conf--18025-.o /tmp/qemu-conf--18025-.c +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Werror -Winitializer-overrides -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc: error: unrecognized command line option ‘-Winitializer-overrides’ +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Werror -Wendif-labels -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Werror -Wmissing-include-dirs -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Werror -Wempty-body -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Werror -Wnested-externs -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Werror -Wformat-security -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Werror -Wformat-y2k -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Werror -Winit-self -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Werror -Wignored-qualifiers -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Werror -Wold-style-declaration -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Werror -Wold-style-definition -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Werror -Wtype-limits -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -Werror -fstack-protector-all -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -Werror -fno-gcse -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +/tmp/qemu-conf--18025-.c:4:2: error: #error No bug in this compiler. + #error No bug in this compiler. + ^ +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -c -o /tmp/qemu-conf--18025-.o /tmp/qemu-conf--18025-.c +/tmp/qemu-conf--18025-.c:1:19: fatal error: sched.h: No such file or directory + #include <sched.h> + ^ +compilation terminated. +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib -lz + +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/zero-shot/108/all/1184616 b/results/classifier/zero-shot/108/all/1184616 new file mode 100644 index 000000000..71949c2b0 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1184616 @@ -0,0 +1,220 @@ +graphic: 0.968 +other: 0.966 +permissions: 0.965 +semantic: 0.963 +performance: 0.957 +debug: 0.955 +network: 0.955 +socket: 0.954 +files: 0.951 +PID: 0.950 +device: 0.946 +boot: 0.945 +vnc: 0.944 +KVM: 0.932 + + undefined reference to `trace_qemu_anon_ram_alloc' + +The latest git version (commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29) fails to compile: + +... + LINK qemu-ga +libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': +oslib-posix.c:(.text+0x154): undefined reference to `trace_qemu_anon_ram_alloc' +libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': +oslib-posix.c:(.text+0x1e7): undefined reference to `trace_qemu_anon_ram_free' +collect2: error: ld returned 1 exit status +make: *** [qemu-ga] Error 1 + +This is on Ubuntu 13.04, gcc 4.7.3, configure flags: +'./configure' '--enable-linux-aio' '--enable-kvm' '--enable-vhost-net' + +On Mon, May 27, 2013 at 4:02 PM, Nigel Horne <email address hidden> wrote: +> The latest git version (commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29) +> fails to compile: +> +> ... +> LINK qemu-ga +> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': +> oslib-posix.c:(.text+0x154): undefined reference to `trace_qemu_anon_ram_alloc' +> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': +> oslib-posix.c:(.text+0x1e7): undefined reference to `trace_qemu_anon_ram_free' +> collect2: error: ld returned 1 exit status +> make: *** [qemu-ga] Error 1 +> +> This is on Ubuntu 13.04, gcc 4.7.3, configure flags: +> './configure' '--enable-linux-aio' '--enable-kvm' '--enable-vhost-net' + +Please try: +make distclean && ./configure --enable-linux-aio --enable-kvm +--enable-vhost-net && make + +Stefan + + +> On Mon, May 27, 2013 at 4:02 PM, Nigel Horne <email address hidden> +> wrote: +>> The latest git version (commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29) +>> fails to compile: +>> +>> ... +>> LINK qemu-ga +>> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': +>> oslib-posix.c:(.text+0x154): undefined reference to +>> `trace_qemu_anon_ram_alloc' +>> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': +>> oslib-posix.c:(.text+0x1e7): undefined reference to +>> `trace_qemu_anon_ram_free' +>> collect2: error: ld returned 1 exit status +>> make: *** [qemu-ga] Error 1 +>> +>> This is on Ubuntu 13.04, gcc 4.7.3, configure flags: +>> './configure' '--enable-linux-aio' '--enable-kvm' '--enable-vhost-net' +> +> Please try: +> make distclean && ./configure --enable-linux-aio --enable-kvm +> --enable-vhost-net && make + +I tried that before I raised the bug. However I tried it again to be sure, +and yes I still get the same error. + +> +> Stefan + +Regards, + +-Nigel + + + +On Mon, May 27, 2013 at 09:04:26PM -0000, Nigel Horne wrote: +> > On Mon, May 27, 2013 at 4:02 PM, Nigel Horne <email address hidden> +> > wrote: +> >> The latest git version (commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29) +> >> fails to compile: +> >> +> >> ... +> >> LINK qemu-ga +> >> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': +> >> oslib-posix.c:(.text+0x154): undefined reference to +> >> `trace_qemu_anon_ram_alloc' +> >> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': +> >> oslib-posix.c:(.text+0x1e7): undefined reference to +> >> `trace_qemu_anon_ram_free' +> >> collect2: error: ld returned 1 exit status +> >> make: *** [qemu-ga] Error 1 +> >> +> >> This is on Ubuntu 13.04, gcc 4.7.3, configure flags: +> >> './configure' '--enable-linux-aio' '--enable-kvm' '--enable-vhost-net' +> > +> > Please try: +> > make distclean && ./configure --enable-linux-aio --enable-kvm +> > --enable-vhost-net && make +> +> I tried that before I raised the bug. However I tried it again to be sure, +> and yes I still get the same error. + +Please post the output of "git status". I wonder if there are stale +files because the build works fine here. + +Stefan + + + +>>> On Mon, May 27, 2013 at 4:02 PM, Nigel Horne <email address hidden> +>>> wrote: +>>>> The latest git version (commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29) +>>>> fails to compile: +>>>> +>>>> ... +>>>> LINK qemu-ga +>>>> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': +>>>> oslib-posix.c:(.text+0x154): undefined reference to +>>>> `trace_qemu_anon_ram_alloc' +>>>> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': +>>>> oslib-posix.c:(.text+0x1e7): undefined reference to +>>>> `trace_qemu_anon_ram_free' +>>>> collect2: error: ld returned 1 exit status +>>>> make: *** [qemu-ga] Error 1 +>>>> +>>>> This is on Ubuntu 13.04, gcc 4.7.3, configure flags: +>>>> './configure' '--enable-linux-aio' '--enable-kvm' '--enable-vhost-net' +>>> Please try: +>>> make distclean && ./configure --enable-linux-aio --enable-kvm +>>> --enable-vhost-net && make +>> I tried that before I raised the bug. However I tried it again to be sure, +>> and yes I still get the same error. +> Please post the output of "git status". I wonder if there are stale +> files because the build works fine here. + +Here it is: + +# On branch master +# Untracked files: +# (use "git add <file>..." to include in what will be committed) +# +# libhw32/ +# libhw64/ +# trace.c +# trace.h + +I don't do any local modification just 'git pull' and recompile. Perhaps +git is broken so I should 'git clone' and start again. + +-Nigel + + + +On Tue, May 28, 2013 at 3:18 PM, Nigel Horne <email address hidden> wrote: +>>>> On Mon, May 27, 2013 at 4:02 PM, Nigel Horne <email address hidden> +>>>> wrote: +>>>>> The latest git version (commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29) +>>>>> fails to compile: +>>>>> +>>>>> ... +>>>>> LINK qemu-ga +>>>>> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': +>>>>> oslib-posix.c:(.text+0x154): undefined reference to +>>>>> `trace_qemu_anon_ram_alloc' +>>>>> libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': +>>>>> oslib-posix.c:(.text+0x1e7): undefined reference to +>>>>> `trace_qemu_anon_ram_free' +>>>>> collect2: error: ld returned 1 exit status +>>>>> make: *** [qemu-ga] Error 1 +>>>>> +>>>>> This is on Ubuntu 13.04, gcc 4.7.3, configure flags: +>>>>> './configure' '--enable-linux-aio' '--enable-kvm' '--enable-vhost-net' +>>>> Please try: +>>>> make distclean && ./configure --enable-linux-aio --enable-kvm +>>>> --enable-vhost-net && make +>>> I tried that before I raised the bug. However I tried it again to be sure, +>>> and yes I still get the same error. +>> Please post the output of "git status". I wonder if there are stale +>> files because the build works fine here. +> +> Here it is: +> +> # On branch master +> # Untracked files: +> # (use "git add <file>..." to include in what will be committed) +> # +> # libhw32/ +> # libhw64/ +> # trace.c +> # trace.h + +rm trace.[ch] + +Then try again. + +The problem is that the auto-generated tracing files moved into +trace/generated-* but the Makefile and C compiler include paths still +pick up the old trace.[ch]. + +You probably built an older version of QEMU first in the same +directory. The latest make distclean doesn't know about the old +trace.[ch] files. + +Stefan + + diff --git a/results/classifier/zero-shot/108/all/1185395 b/results/classifier/zero-shot/108/all/1185395 new file mode 100644 index 000000000..292283598 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1185395 @@ -0,0 +1,115 @@ +permissions: 0.976 +debug: 0.975 +socket: 0.974 +graphic: 0.973 +PID: 0.968 +semantic: 0.968 +vnc: 0.962 +network: 0.960 +boot: 0.947 +device: 0.945 +performance: 0.940 +files: 0.938 +KVM: 0.936 +other: 0.926 + +qemu-1.5.0 savevm error -95 while writing vm with ceph-rbd as storage-backend + +With a running VM I encounter this strange behaviour, former qemu-versions don't show up such an error. +Perhaps this comes from the rbd-backend in qemu-1.5.0 in combination with ceph-0.56.6? + +( -95 might be a general "Operation not supported" error? ) + +Up to 1.4.2 everything is OK with savevm, though. + +Any help welcome, + +Oliver. + +Sorry for not providing enough informations, here we go: + +typical longish start for qemu is: + +/usr/local/bin/qemu-system-x86_64 -usbdevice tablet -enable-kvm -daemonize -pidfile /var/run/qemu-server/760.pid -monitor unix:/var/run/qemu-server/760.mon,server,nowait -vnc unix:/var/run/qemu-server/760.vnc,password -qmp unix:/var/run/qemu-server/760.qmp,server,nowait -nodefaults -serial none -parallel none -device rtl8139,mac=00:F1:70:00:2F:80,netdev=vlan0d0 -netdev type=tap,id=vlan0d0,ifname=tap760i0d0,script=/etc/fcms/add_if.sh,downscript=/etc/fcms/downscript.sh -name 1155823384-4 -m 512 -vga cirrus -k de -smp sockets=1,cores=1 -device virtio-blk-pci,drive=virtio0 -drive format=raw,file=rbd:1155823384/vm-760-disk-1.rbd:rbd_cache=false,cache=writeback,if=none,id=virtio0,media=disk,index=0 -drive format=raw,file=rbd:1155823384/vm-760-swap-1.rbd:rbd_cache=false,cache=writeback,if=virtio,media=disk,index=1 -drive if=ide,media=cdrom,id=ide1-cd0,readonly=on -drive if=ide,media=cdrom,id=ide1-cd1,readonly=on -boot order=dc + +after fired up I go to the monitor socket and try a: + +QEMU 1.5.0 monitor - type 'help' for more information +(qemu) savevm test123 +Error -95 while writing VM +(qemu) + +If I only let the error -95 happen and ignore, everything seems to be OK, though. Might be easy to fix, but not for me... +qemu up to 1.4.2 is not affected. + +Please let me know, if you need more informations. + +Oliver. + + + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)? + +Hi Thomas, + +thnx for coming back on this. Currently on vacation, but just gave it a shot on fresh compiled qemu-2.9.0: + +— + +savevm +Error while writing VM state: Operation not supported + +— + +I think there once existed a patch from the Proxmox guys dealing with the VM state informations. But +apparently did not make it into main-stream. + +Kind regards, + +Oliver. + +> Am 20.07.2017 um 13:52 schrieb Thomas Huth <email address hidden>: +> +> Triaging old bug tickets ... can you still reproduce this problem with +> the latest version of QEMU (currently v2.9.0)? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1185395 +> +> Title: +> qemu-1.5.0 savevm error -95 while writing vm with ceph-rbd as storage- +> backend +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> With a running VM I encounter this strange behaviour, former qemu-versions don't show up such an error. +> Perhaps this comes from the rbd-backend in qemu-1.5.0 in combination with ceph-0.56.6? +> +> ( -95 might be a general "Operation not supported" error? ) +> +> Up to 1.4.2 everything is OK with savevm, though. +> +> Any help welcome, +> +> Oliver. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1185395/+subscriptions + + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/96 + + diff --git a/results/classifier/zero-shot/108/all/1202289 b/results/classifier/zero-shot/108/all/1202289 new file mode 100644 index 000000000..c931e3ce4 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1202289 @@ -0,0 +1,105 @@ +KVM: 0.959 +vnc: 0.958 +permissions: 0.955 +device: 0.946 +performance: 0.944 +other: 0.943 +semantic: 0.942 +graphic: 0.942 +debug: 0.936 +files: 0.935 +PID: 0.935 +boot: 0.930 +network: 0.929 +socket: 0.929 + +Windows 2008/7 Guest to Guest Very slow 10-20Mbit/s + +I'm not sure if I'm submitting this to the proper place or not, if not, please direct me accordingly. + +At this point I'm starting to get desperate, I'll take any options or suggestions that spring to mind: + +Anyway, the problem exists on multiple hosts of various quality. From 4 core 8g mem machines to 12 core 64Gig mem machines with LVM and Raid-10. + +Using iperf as the testing utility: (windows guest can be either Windows 7 or 2008R2) +-Windows Guest -> Windows Guest averages 20Mbit/s (The problem) +-Windows Guest -> Host averages 800Mbit/s +-Host -> Windows Guest averages 1.1Gbit/s +-Linux Guest -> Host averages 12GBit/s +-Linux Guest -> Linux Guest averages 10.2Gbit/s + +For windows guests, switching between e1000 and virtio drivers doesn't make much of a difference. + +I use openvswitch to handle the bridging (makes bonding nics much easier) + +Disabling TSO GRO on all the host nics, and virtual nics, as well as modding the registry using: +netsh int tcp set global (various params here) can slightly improve Windows -> windows throughput. up to maybe 100Mbit/s but even that is spotty at best. + +The Particulars of the fastest host which benchmarks about the same as the slowest host. + +Ubuntu 12.04 64bit (updated to lastest as of July 15th) +Linux cckvm03 3.5.0-36-generic #57~precise1-Ubuntu SMP Thu Jun 20 18:21:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux + +libvirt: +Source: libvirt +Version: 0.9.8-2ubuntu17.10 + +qemu-kvm +Package: qemu-kvm +Version: 1.0+noroms-0ubuntu14.8 +Replaces: kvm (<< 1:84+dfsg-0ubuntu16+0.11.0), kvm-data, qemu + +openvswitch +Source: openvswitch +Version: 1.4.0-1ubuntu1.5 + +/proc/cpuifo + +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 45 +model name : Intel(R) Xeon(R) CPU E5-2440 0 @ 2.40GHz +stepping : 7 +microcode : 0x70d +cpu MHz : 2400.226 +cache size : 15360 KB +physical id : 0 +siblings : 12 +core id : 0 +cpu cores : 6 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov +pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdt +scp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc ap +erfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdc +m pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm +ida arat xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid +bogomips : 4800.45 +clflush size : 64 +cache_alignment : 64 +address sizes : 46 bits physical, 48 bits virtual +power management: + + +-Sample KVM line +usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 4096 -smp 2,sockets=2,cores=1,threads=1 -name gvexch01 -uuid d28ffb4b-d809-3b40-ae3d-2925e6995394 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/gvexch01.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot order=dc,menu=on -drive file=/dev/vgroup/gvexch01,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=native -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/dev/vgroup/gvexch01-d,if=none,id=drive-virtio-disk1,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1 -drive if=none,media=cdrom,id=drive-ide0-0-0,readonly=on,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=18,id=hostnet0,vhost=on,vhostfd=21 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:bf:4e:1c,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:2 -vga std -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 + +I'm not sure yet, but I think the TSO problem affects much more setups, not only windows guests. You might try to set GSO to off in windows guests too, if there is such an option (GSO might be a linux kernel feature). + +I currently think that we have similar problems with centos7 hosts and guests as well as with some windows7 guests. + +I also read about similar centos6 problems. There is even a original setup guide for centos6 from redhat, to set "tso off gso off" in the host bridge adapter, when you use virtio. + +This whole topic is disturbingly distributed through several setups. The diagnosis of this problem is far from being trivial. + + +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/zero-shot/108/all/1212402 b/results/classifier/zero-shot/108/all/1212402 new file mode 100644 index 000000000..afe2cf29f --- /dev/null +++ b/results/classifier/zero-shot/108/all/1212402 @@ -0,0 +1,175 @@ +boot: 0.981 +debug: 0.980 +permissions: 0.978 +other: 0.977 +semantic: 0.976 +performance: 0.972 +device: 0.969 +graphic: 0.967 +PID: 0.966 +socket: 0.957 +KVM: 0.952 +vnc: 0.943 +files: 0.936 +network: 0.910 + +Enabling KVM with recent QEMU builds from GIT hang at boot on Ubuntu Precise AMD64 kernel 3.8.0 + +When I compile QEMU from GIT and run it with './x86_64-softmmu/qemu-system-x86_64 -enable-kvm' it just hangs, the QEMU screen stays black. (Everything else in the GTK UI is responsive though, I can use the QEMU console as well.) +I'm running Ubuntu Precise with kernel 3.8.0-27-generic on an Intel Core2 Duo P9500. + +With bisecting, I found this commit caused the problem: + +235e8982ad393e5611cb892df54881c872eea9e1 is the first bad commit +commit 235e8982ad393e5611cb892df54881c872eea9e1 +Author: Jordan Justen <email address hidden> +Date: Wed May 29 01:27:26 2013 -0700 + + kvm: support using KVM_MEM_READONLY flag for regions + + For readonly memory regions and rom devices in romd_mode, + we make use of the KVM_MEM_READONLY. A slot that uses + KVM_MEM_READONLY can be read from and code can execute from the + region, but writes will exit to qemu. + + For rom devices with !romd_mode, we force the slot to be + removed so reads or writes to the region will exit to qemu. + (Note that a memory region in this state is not executable + within kvm.) + + v7: + * Update for readable => romd_mode rename (5f9a5ea1) + + Signed-off-by: Jordan Justen <email address hidden> + Reviewed-by: Xiao Guangrong <email address hidden> (v4) + Reviewed-by: Paolo Bonzini <email address hidden> (v5) + Message-id: <email address hidden> + Signed-off-by: Anthony Liguori <email address hidden> + +:100644 100644 327ae12f08b9dddc796d753d8adfb1f70c78b2c1 8e7bbf8698f6bcaa5ae945ef86e7b51effde06fe M kvm-all.c + +We have discussed this issue in this mail: +http://<email address hidden>/msg174932.html (VM can +not boot after commit 235e898) + +You can upgrade your kernel to 3.9.x to work around. + + +On Thu, Aug 15, 2013 at 3:23 AM, Julius Schwartzenberg < +<email address hidden>> wrote: + +> Public bug reported: +> +> When I compile QEMU from GIT and run it with +> './x86_64-softmmu/qemu-system-x86_64 -enable-kvm' it just hangs, the QEMU +> screen stays black. (Everything else in the GTK UI is responsive though, I +> can use the QEMU console as well.) +> I'm running Ubuntu Precise with kernel 3.8.0-27-generic on an Intel Core2 +> Duo P9500. +> +> With bisecting, I found this commit caused the problem: +> +> 235e8982ad393e5611cb892df54881c872eea9e1 is the first bad commit +> commit 235e8982ad393e5611cb892df54881c872eea9e1 +> Author: Jordan Justen <email address hidden> +> Date: Wed May 29 01:27:26 2013 -0700 +> +> kvm: support using KVM_MEM_READONLY flag for regions +> +> For readonly memory regions and rom devices in romd_mode, +> we make use of the KVM_MEM_READONLY. A slot that uses +> KVM_MEM_READONLY can be read from and code can execute from the +> region, but writes will exit to qemu. +> +> For rom devices with !romd_mode, we force the slot to be +> removed so reads or writes to the region will exit to qemu. +> (Note that a memory region in this state is not executable +> within kvm.) +> +> v7: +> * Update for readable => romd_mode rename (5f9a5ea1) +> +> Signed-off-by: Jordan Justen <email address hidden> +> Reviewed-by: Xiao Guangrong <email address hidden> (v4) +> Reviewed-by: Paolo Bonzini <email address hidden> (v5) +> Message-id: +> <email address hidden> +> Signed-off-by: Anthony Liguori <email address hidden> +> +> :100644 100644 327ae12f08b9dddc796d753d8adfb1f70c78b2c1 +> 8e7bbf8698f6bcaa5ae945ef86e7b51effde06fe M kvm-all.c +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1212402 +> +> Title: +> Enabling KVM with recent QEMU builds from GIT hang at boot on Ubuntu +> Precise AMD64 kernel 3.8.0 +> +> Status in QEMU: +> New +> +> Bug description: +> When I compile QEMU from GIT and run it with +> './x86_64-softmmu/qemu-system-x86_64 -enable-kvm' it just hangs, the QEMU +> screen stays black. (Everything else in the GTK UI is responsive though, I +> can use the QEMU console as well.) +> I'm running Ubuntu Precise with kernel 3.8.0-27-generic on an Intel +> Core2 Duo P9500. +> +> With bisecting, I found this commit caused the problem: +> +> 235e8982ad393e5611cb892df54881c872eea9e1 is the first bad commit +> commit 235e8982ad393e5611cb892df54881c872eea9e1 +> Author: Jordan Justen <email address hidden> +> Date: Wed May 29 01:27:26 2013 -0700 +> +> kvm: support using KVM_MEM_READONLY flag for regions +> +> For readonly memory regions and rom devices in romd_mode, +> we make use of the KVM_MEM_READONLY. A slot that uses +> KVM_MEM_READONLY can be read from and code can execute from the +> region, but writes will exit to qemu. +> +> For rom devices with !romd_mode, we force the slot to be +> removed so reads or writes to the region will exit to qemu. +> (Note that a memory region in this state is not executable +> within kvm.) +> +> v7: +> * Update for readable => romd_mode rename (5f9a5ea1) +> +> Signed-off-by: Jordan Justen <email address hidden> +> Reviewed-by: Xiao Guangrong <email address hidden> (v4) +> Reviewed-by: Paolo Bonzini <email address hidden> (v5) +> Message-id: +> <email address hidden> +> Signed-off-by: Anthony Liguori <email address hidden> +> +> :100644 100644 327ae12f08b9dddc796d753d8adfb1f70c78b2c1 +> 8e7bbf8698f6bcaa5ae945ef86e7b51effde06fe M kvm-all.c +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1212402/+subscriptions +> +> + + +-- +Best Regards, + +Dunrong Huang + +Homepage: http://mathslinux.org + + +It seems reverting this exact commit also works around the problem. I have attached a patch against current head. + +According to comment #1, this has been fixed with kernel 3.9, so setting the status to "Fix released" now. + diff --git a/results/classifier/zero-shot/108/all/1235 b/results/classifier/zero-shot/108/all/1235 new file mode 100644 index 000000000..db3814cf0 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1235 @@ -0,0 +1,195 @@ +permissions: 0.955 +graphic: 0.952 +semantic: 0.951 +performance: 0.951 +other: 0.939 +device: 0.938 +debug: 0.937 +socket: 0.934 +files: 0.926 +vnc: 0.924 +boot: 0.920 +PID: 0.916 +network: 0.908 +KVM: 0.906 + +Using packer and plugin qemu in the json file to create a RHEL 8.4 guest kvm vm, but ssh timeout error coming, but it is running fine in RHEL 7.9 +Description of problem: +I have RHEL 8.5 as the KVM host. I want to create a guest vm of RHEL 8.4 through packer type qemu and have a json file where all the configurations are mentioned. + +{ + +“builders”: [ + +{ + +“type”: “qemu”, + +“iso_url”: “/var/lib/libvirt/images/test.iso”, + +“iso_checksum”: “md5:3959597d89e8c20d58c4514a7cf3bc7f”, + +“output_directory”: “/var/lib/libvirt/images/iso-dir/test”, + +“disk_size”: “55G”, + +“headless”: “true”, + +“qemuargs”: [ + + [ + + "-m", + + "4096" + + ], + + [ + + "-smp", + + "2" + + ] +], + +“format”: “qcow2”, + +“shutdown_command”: “echo ‘nonrootuser’ | sudo -S shutdown -P now”, + +“accelerator”: “kvm”, + +“ssh_username”: “nonrootuser”, + +“ssh_password”: “********”, + +“ssh_timeout”: “20m”, + +“vm_name”: “test”, + +“net_device”: “virtio-net”, + +“disk_interface”: “virtio”, + +“http_directory”: “/home/azureuser/http”, + +“boot_wait”: “10s”, + +“boot_command”: [ + +“e inst.ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/anaconda-ks.cfg” + +] + +} + +], + +“provisioners”: + +[ + +{ + + "type": "file", + + "source": "/home/azureuser/service_status_check.sh", + + "destination": "/tmp/service_status_check.sh" + +}, + +{ + + "type": "file", + + "source": "/home/azureuser/service_check.sh", + + "destination": "/tmp/service_check.sh" + +}, + +{ + + "type": "file", + + "source": "/home/azureuser/azure.sh", + + "destination": "/tmp/azure.sh" + +}, + +{ + + + "type": "file", + + "source": "/home/azureuser/params.cfg", + + "destination": "/tmp/params.cfg" + +}, + + + +{ + + "type": "shell" , + + + + "execute_command": "echo 'siedgerexuser' | {{.Vars}} sudo -E -S bash '{{.Path}}'", + + + + "inline": [ +"echo copying" , "cp /tmp/params.cfg /root/", + "sudo ls -lrt /root/params.cfg", + "sudo ls -lrt /opt/scripts/" + ], + + + "inline_shebang": "/bin/sh -x" + +}, + +{ + + "type": "shell", + + "pause_before": "5s", + "expect_disconnect": true , + + "inline": [ + "echo runningconfigurescript" , "sudo sh /opt/scripts/configure-env.sh" + + ] + +}, + +{ + + "type": "shell", + + "pause_before": "200s", + + "inline": [ + + "sudo sh /tmp/service_check.sh", + "sudo sh /tmp/azure.sh" + + ] + +} +] + +} + +It is working fine in rhel 7.9, but the same thing giving ssh timeout error in RHEL 8.4. + +But when i am creating guest vm with virt-install it is able to create a vm and i am able to see it in cockpit web ui, but when i initiate packer build with qemu plugin then giving ssh timeout error it is not visible in cockpit UI, so not able to see where the guest vm created get stuck. + +Can anyone please help me to fix this issue where why vm not able to come up and also why qemu created vm not visible in cockpit web ui as that will be really helpful while debugging +Additional information: + diff --git a/results/classifier/zero-shot/108/all/1236 b/results/classifier/zero-shot/108/all/1236 new file mode 100644 index 000000000..f50159dfd --- /dev/null +++ b/results/classifier/zero-shot/108/all/1236 @@ -0,0 +1,61 @@ +debug: 0.978 +other: 0.976 +permissions: 0.974 +files: 0.972 +graphic: 0.970 +performance: 0.970 +device: 0.969 +semantic: 0.963 +vnc: 0.961 +PID: 0.959 +network: 0.958 +socket: 0.953 +boot: 0.951 +KVM: 0.951 + +blockdev fixed vhdx trying to reserve space, also misleading error, Could not open file: Invalid argument +Description of problem: +The qemu-storage-daemon/other qemu commands will not start and will choke on requiring vhdx driver for the blockdev layer. +Opening a fixed-virtual-disk like fixed-vhdx should not reserve extra space, and should only overwrite as all blocks are already allocated. +Steps to reproduce: +1. Ensure that a partition size is such that after deciding a fixed-vhdx size, the remainder space after creation of fixed-vhdx is less than the fixed-vhdx. +2. Create a fixed-vhdx file +3. Try to start an nbd server with it +the qemu-storage-daemon will not start +Additional information: +I want to mention that I am testing qemu-storage-daemon under windows/hyperv + +So far, I want to report that it has **worked** for rawimg and qcow2-fixed. +See comment of 20220926 https://github.com/cloudbase/wnbd/issues/63#issuecomment-1257148849 + +The driver parameter ```vhdx``` to the blockdev argument seems to struggle with it. + +I wanted to check if the vhdx blockdev driver has the same VHDX-related-bugs as qemu-nbd +- #727 VHDX is corrupted on expansion. +- #806 Fixed VHDX inflates beyond its fixed size when data is copied onto it and also corrupts + +Even the the blockdev reference entries seem to have VHDX all over the place +- pg 318 https://readthedocs.org/projects/qemu/downloads/pdf/latest/ +- https://www.qemu.org/docs/master/system/qemu-block-drivers.html +- except conspicuously here !! https://www.qemu.org/docs/master/interop/qemu-storage-daemon-qmp-ref.html?highlight=blockdev#qapidoc-265 + + +``` +C:\Windows\System32>qemu-storage-daemon --version +qemu-storage-daemon version 7.1.0 (v7.1.0-11925-g4ec481870e-dirty) + +C:\Windows\System32>qemu-storage-daemon --blockdev driver=file,node-name=file,filename=H:\gkpics01.vhdx --blockdev driver=vhdx,node-name=vhdx,file=file --nbd-server addr.type=inet,addr.host=127.0.0.1,addr.port=10809 --export type=nbd,id=export,node-name=vhdx,name=gkpics01,writable=on +qemu-storage-daemon: --blockdev driver=vhdx,node-name=vhdx,file=file: Could not open 'H:\gkpics01.vhdx': Invalid argument + +C:\Windows\System32>qemu-storage-daemon --blockdev driver=file,node-name=file,filename=H:\gkpics01.vhdx --blockdev driver=vhdx,node-name=vhdx,file=file,subformat=fixed --nbd-server addr.type=inet,addr.host=127.0.0.1,addr.port=10809 --export type=nbd,id=export,node-name=vhdx,name=gkpics01,writable=on +qemu-storage-daemon: --blockdev driver=vhdx,node-name=vhdx,file=file,subformat=fixed: Parameter 'subformat' is unexpected + +C:\Windows\System32>dir H:\gkpics01.vhdx + Volume in drive H is CPERF0 + Volume Serial Number is F196-DB9E + Directory of H:\ +09/29/2022 08:55 PM 99,727,966,208 gkpics01.vhdx + 1 File(s) 99,727,966,208 bytes + 0 Dir(s) 4,312,399,872 bytes free +``` +## diff --git a/results/classifier/zero-shot/108/all/1248959 b/results/classifier/zero-shot/108/all/1248959 new file mode 100644 index 000000000..a006a65b6 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1248959 @@ -0,0 +1,105 @@ +other: 0.984 +permissions: 0.982 +semantic: 0.978 +performance: 0.976 +graphic: 0.976 +device: 0.975 +debug: 0.974 +files: 0.973 +PID: 0.972 +network: 0.969 +vnc: 0.967 +socket: 0.959 +boot: 0.954 +KVM: 0.942 + +pdpe1gb flag is missing in guest running on Intel h/w + +I need to utilize 1G hugepages on my guest system. But this is not possible as long as there is no pdpe1gb support in guest system. The latest source code contains pdpe1gb support for AMD but not for Intel. + +Are there any obstacles that does not allow to implement it for modern Intel chips? + +My configuration: +Host: +------- +uname -a +Linux tripel.salab.cic.nsn-rdnet.net 2.6.32-358.14.1.el6.x86_64 #1 SMP Tue Jul 16 23:51:20 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux + +cat /etc/*-release +CentOS release 6.4 (Final) + +yum list installed | grep qemu +gpxe-roms-qemu.noarch 0.9.7-6.9.el6 @base +qemu-img.x86_64 2:0.12.1.2-2.355.0.1.el6.centos.5 +qemu-kvm.x86_64 2:0.12.1.2-2.355.0.1.el6.centos.5 + +cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 45 +model name : Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz +stepping : 7 +cpu MHz : 2700.000 +cache size : 20480 KB +physical id : 0 +siblings : 16 +core id : 0 +cpu cores : 8 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid +bogomips : 5387.09 +clflush size : 64 +cache_alignment : 64 +address sizes : 46 bits physical, 48 bits virtual + +/usr/libexec/qemu-kvm -cpu ? +Recognized CPUID flags: + f_edx: pbe ia64 tm ht ss sse2 sse fxsr mmx acpi ds clflush pn pse36 pat cmov mca pge mtrr sep apic cx8 mce pae msr tsc pse de vme fpu + f_ecx: hypervisor rdrand f16c avx osxsave xsave aes tsc-deadline popcnt movbe x2apic sse4.2|sse4_2 sse4.1|sse4_1 dca pcid pdcm xtpr cx16 fma cid ssse3 tm2 est smx vmx ds_cpl monitor dtes64 pclmulqdq|pclmuldq pni|sse3 + extf_edx: 3dnow 3dnowext lm|i64 rdtscp pdpe1gb fxsr_opt|ffxsr fxsr mmx mmxext nx|xd pse36 pat cmov mca pge mtrr syscall apic cx8 mce pae msr tsc pse de vme fpu + extf_ecx: perfctr_nb perfctr_core topoext tbm nodeid_msr tce fma4 lwp wdt skinit xop ibs osvw 3dnowprefetch misalignsse sse4a abm cr8legacy extapic svm cmp_legacy lahf_lm + +ps ax | grep qemu + 7197 ? Sl 0:15 /usr/libexec/qemu-kvm -name vladimir.AS-0 -S -M rhel6.4.0 -cpu SandyBridge,+pdpe1gb,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -enable-kvm -m 8192 -mem-prealloc -mem-path /var/lib/hugetlbfs/pagesize-1GB/libvirt/qemu -smp 4,sockets=4,cores=1,threads=1 -uuid ec2d3c58-a7f0-fdbd-9de5-b547a5b3130f -nographic -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/vladimir.AS-0.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -netdev tap,fd=28,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:81:5b:df,bus=pci.0,addr=0x3,bootindex=1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device pci-assign,host=02:00.0,id=hostdev0,configfd=29,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 + +Guest: +--------- +# uname -a +Linux AS-0 2.6.34.13-WR4.3.fp_x86_64_standard-00019-g052bb3e #1 SMP Wed May 8 12:21:02 EEST 2013 x86_64 x86_64 x86_64 GNU/Linux + +# cat /etc/*-release +Wind River Linux 4.3 glibc_cgl + +# cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 42 +model name : Intel Xeon E312xx (Sandy Bridge) +stepping : 1 +cpu MHz : 2693.893 +cache size : 4096 KB +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx lm constant_tsc rep_good pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes xsave avx hypervisor lahf_lm xsaveopt +bogomips : 5387.78 +clflush size : 64 +cache_alignment : 64 +address sizes : 46 bits physical, 48 bits virtual + +I observe the same situation. My host CPU (Intel Xeon CPU E5-2690) supports 1gb pages but qemu keeps it disabled by default. I have to use either '-cpu phenom' or '-cpu host' with KVM. + +It makes me wondering what is the default CPU for QEMU? Is it possible to set qemu CPU featureset closer to what host CPU has? + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1254672 b/results/classifier/zero-shot/108/all/1254672 new file mode 100644 index 000000000..9a5fbef47 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1254672 @@ -0,0 +1,100 @@ +other: 0.991 +semantic: 0.990 +permissions: 0.990 +vnc: 0.989 +debug: 0.988 +performance: 0.987 +device: 0.987 +PID: 0.985 +boot: 0.984 +graphic: 0.984 +socket: 0.983 +files: 0.982 +KVM: 0.980 +network: 0.966 + +ps segfaults with qemu-{arm,armel,mips,powerpc}-static + +Host: Ubuntu Precise AMD64 +Guest: Debian Testing armhf + +After running a debootstrap for Debian testing/armhf and entering the chroot, simply running "ps" causes a segmentation fault. + +$ sudo qemu-debootstrap --arch=armhf testing armhf http://ftp.uk.debian.org/debian/ +[...] +$ sudo chroot armhf +# ps +Signal 11 (SEGV) caught by ps (procps-ng version 3.3.4). +/bin/ps:display.c:59: please report this bug + +I couldn't find a bug report for procps, which would be unusual if such a bug existed, so I'm assuming the bug is in qemu. + +Unfortunately trying to run debootstrap for an Ubuntu variant fails to find the release file. + +ps is used a lot, as you can imagine, but specifically it fails when trying to install some packages via "apt-get install" and no attempt is made to recover. + +ProblemType: Bug +DistroRelease: Ubuntu 12.04 +Package: qemu-user-static 1.0.50-2012.03-0ubuntu2.1 +ProcVersionSignature: Ubuntu 3.8.0-33.48~precise1-generic 3.8.13.11 +Uname: Linux 3.8.0-33-generic x86_64 +NonfreeKernelModules: wl +ApportVersion: 2.0.1-0ubuntu17.6 +Architecture: amd64 +Date: Mon Nov 25 10:43:12 2013 +Dependencies: + +InstallationMedia: Ubuntu 12.04.3 LTS "Precise Pangolin" - Release amd64 (20130820.1) +MarkForUpload: True +ProcEnviron: + LANGUAGE=en_GB:en + TERM=xterm + PATH=(custom, no user) + LANG=en_GB.UTF-8 + SHELL=/bin/bash +SourcePackage: qemu-linaro +UpgradeStatus: No upgrade log present (probably fresh install) + + + +Same thing with qemu-mips-static too by the looks of things. + +qemu-powerpc-static on i386: + +# ps +Invalid data memory access: 0x00000000 +NIP 0feb05e4 LR 0feb1440 CTR 0feb13f0 XER 00000000 +MSR 00006040 HID0 00000000 HF 00006000 idx 0 +TB 00000000 00000000 +GPR00 000000000ffc178c 00000000407fffa0 000000004083f720 0000000000000001 +GPR04 0000000029292929 000000000a000000 00000000fefefeff 000000007f7f7f7f +GPR08 0000000000000000 0000000080808080 0000000000000008 00000000ffffffff +GPR12 0000000024000442 000000001002c180 0000000000000000 0000000000000000 +GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000001 +GPR28 000000004080088c 0000000000000000 000000000ffa6ff4 0000000000000029 +CR 44000444 [ G G - - - G G G ] RES ffffffff +FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPSCR 00000000 +Signal 11 (SEGV) caught by ps (procps-ng version 3.3.4). +/bin/ps:display.c:59: please report this bug + +I suspect this is a NULL pointer access that happens in procps where it isn't handling an error path that it's not expecting somehow (either a syscall we're not implementing, or perhaps something like /proc not being mounted in your chroot environment, or something about qemu's emulation of some file in /proc isn't right). The next stage would be to debug where exactly ps is crashing (attaching a debugger to the qemu gdbstub is probably easiest, or good old printfs...) + + +Version: 1.6.0+dfsg-2ubuntu4 + +This is fixed in Trusty in the qemu package. Doesn't look like qemu-linaro has been updated for Trusty. I don't know what is going on with these two packages. + +Tested ps in a bunch of arm* mips* and powerpc chroots with a Jammy host to check and it seems fine. + +Releases above are EOL, so can assume fixed. qemu-linaro is no more. + diff --git a/results/classifier/zero-shot/108/all/1256122 b/results/classifier/zero-shot/108/all/1256122 new file mode 100644 index 000000000..69a79fa9f --- /dev/null +++ b/results/classifier/zero-shot/108/all/1256122 @@ -0,0 +1,72 @@ +graphic: 0.990 +permissions: 0.988 +semantic: 0.987 +socket: 0.986 +other: 0.985 +performance: 0.984 +debug: 0.984 +network: 0.984 +device: 0.983 +KVM: 0.982 +boot: 0.981 +PID: 0.978 +vnc: 0.976 +files: 0.953 + +vfio bug with all no VGA card + +Hello, + +I whant to report to you a realy big bug. + +vfio passthrough work only with VGA card ! When i try to use vfio with any other PCI or PCI-E card it does not work. + +When i use vfio for VGA i can reboot (or shutdown and start again) my VM with out problem, but for any other PCI card the VM refuse to reboot. + +In dmesg i have this error : + +dmar: DRHD: handling fault status reg 2 +dmar: DMAR:[DMA Read] Request device [xx:xx.x] fault addr 2affde000 +DMAR:[fault reason 06] PTE Read access is not set + +and some time the same but for Write and not Read. + +I found a kind of work around but it's ugly. Just detach your devices from vfio, re-atach to his normal driver and bind again to vfio. + +For information i use an Asrock Z87 Extrem 6 with a CoreI5 4570S +My kernel is 3.12 and Qemu is 1.7-rc0 + +Some adjustment, + +It's seem this not appear with my Intel network card i211. + +But i can confirme this bug appear with AsMedia 1061 sata3 controler. + +the complete dmesg : + +[ 404.206866] dmar: DRHD: handling fault status reg 2 +[ 404.206870] dmar: DMAR:[DMA Write] Request device [07:00.0] fault addr 2affdf000 +[ 404.206870] DMAR:[fault reason 05] PTE Write access is not set +[ 404.206877] dmar: DRHD: handling fault status reg 2 +[ 404.206879] dmar: DMAR:[DMA Read] Request device [07:00.0] fault addr 2affda000 +[ 404.206879] DMAR:[fault reason 06] PTE Read access is not set + +I start my VM with : + +sudo qemu-system-x86_64 -M q35 -m 8G -enable-kvm -cpu Haswell -vga none -nographic -parallel none -boot menu=on \ +-smp 4,sockets=1,cores=4,threads=1 \ +-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \ +-device vfio-pci,host=01:00.0,x-vga=on,addr=0.0,multifunction=on,bus=root.1 \ //AMD HD7770 +-device vfio-pci,host=01:00.1,bus=pcie.0 \ //AMD audio HDMI +-device vfio-pci,host=07:00.0,bus=pcie.0 \ //AsMedia 1061 sata3 controler +-device vfio-pci,host=00:19.0,bus=pcie.0 \ //Intel i211 network +-net none \ +-usb -usbdevice host:05e3:0607 -usbdevice host:1532:002f -usbdevice host:046d:c229 -usbdevice host:046d:c228 //Logiteck G19s and razer mouse + +It's appear with linux kernel 3.12.0 and 3.13-rc2 +Qemu version is 1.7 (no rc). + +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/zero-shot/108/all/1277433 b/results/classifier/zero-shot/108/all/1277433 new file mode 100644 index 000000000..10fd58082 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1277433 @@ -0,0 +1,278 @@ +other: 0.988 +graphic: 0.986 +permissions: 0.985 +socket: 0.982 +device: 0.981 +semantic: 0.981 +files: 0.979 +vnc: 0.977 +debug: 0.977 +performance: 0.972 +PID: 0.967 +KVM: 0.958 +boot: 0.937 +network: 0.904 + +GDB context is inconsistent after "monitor system_reset" + +After a "monitor system_reset" the GDB view to the system state differs from QEMUs processor state. + +Breakpoint 8, _ARMV4_Exception_interrupt () at /home/sh/rtems-4.11/c/src/../../cpukit/score/cpu/arm/arm_exc_interrupt.S:74 +74 mov EXCHANGE_LR, lr +(gdb) info registers +r0 0x2027e8 2107368 +r1 0x204208 2114056 +r2 0x13 19 +r3 0x204238 2114104 +r4 0x0 0 +r5 0x0 0 +r6 0x0 0 +r7 0x0 0 +r8 0x0 0 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x0 0 +sp 0x201480 0x201480 +lr 0x110958 1116504 +pc 0x11073c 0x11073c <_ARMV4_Exception_interrupt+4> +cpsr 0x192 402 +(gdb) monitor info registers +R00=002027e8 R01=00204208 R02=00000013 R03=00204238 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00201480 R14=00110958 R15=0011073c +PSR=00000192 ---- A irq32 +(gdb) monitor system_reset +(gdb) info registers +r0 0x2027e8 2107368 +r1 0x204208 2114056 +r2 0x13 19 +r3 0x204238 2114104 +r4 0x0 0 +r5 0x0 0 +r6 0x0 0 +r7 0x0 0 +r8 0x0 0 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x0 0 +sp 0x201480 0x201480 +lr 0x110958 1116504 +pc 0x11073c 0x11073c <_ARMV4_Exception_interrupt+4> +cpsr 0x192 402 +(gdb) monitor info registers +R00=00000000 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00000000 R14=00000000 R15=00100040 +PSR=400001d3 -Z-- A svc32 + +Why does the second "info registers" and "monitor info registers" differ? + +After a single instruction step they are synchronized at least on ARM (on SPARC this is different). + +(gdb) si +bsp_start_vector_table_end () at /home/sh/rtems-4.11/c/src/lib/libbsp/arm/realview-pbx-a9/../shared/start/start.S:144 +144 msr cpsr, r0 +(gdb) info registers +r0 0xd3 211 +r1 0x0 0 +r2 0x0 0 +r3 0x0 0 +r4 0x0 0 +r5 0x0 0 +r6 0x0 0 +r7 0x0 0 +r8 0x0 0 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x0 0 +sp 0x0 0x0 +lr 0x0 0 +pc 0x100044 0x100044 <bsp_start_vector_table_end+4> +cpsr 0x400001d3 1073742291 +(gdb) monitor info registers +R00=000000d3 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00000000 R14=00000000 R15=00100044 +PSR=400001d3 -Z-- A svc32 + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +With this Qemu: + +qemu-system-arm --version +QEMU emulator version 4.2.50 (v4.2.0-1276-g863d2ed582) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +I still have the same issue: + +(gdb) info registers +r0 0x0 0 +r1 0x9010001 151060481 +r2 0x0 0 +r3 0x428c89 4361353 +r4 0x640f08 6557448 +r5 0x672480 6759552 +r6 0x0 0 +r7 0x0 0 +r8 0x0 0 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x60bb80 6339456 +sp 0x6783f0 0x6783f0 <_Thread_Idle_stacks+4080> +lr 0x425fa1 4349857 +pc 0x428c8a 0x428c8a <_CPU_Thread_Idle_body+2> +cpsr 0x60070173 1611071859 +fpscr 0x0 0 +fpsid 0x41033090 1090728080 +fpexc 0x40000000 1073741824 +[...] +(gdb) monitor info registers +R00=00000000 R01=09010001 R02=00000000 R03=00428c89 +R04=00640f08 R05=00672480 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=0060bb80 R13=006783f0 R14=00425fa1 R15=00428c8a +PSR=60070173 -ZC- T svc32 +s00=00013831 s01=00000000 d00=0000000000013831 +s02=00000e0f s03=00000000 d01=0000000000000e0f +s04=00000000 s05=00000000 d02=0000000000000000 +s06=00000000 s07=00000000 d03=0000000000000000 +s08=00000000 s09=00000000 d04=0000000000000000 +s10=00000000 s11=00000000 d05=0000000000000000 +s12=00000000 s13=00000000 d06=0000000000000000 +s14=00000000 s15=00000000 d07=0000000000000000 +s16=00000000 s17=00000000 d08=0000000000000000 +s18=00000000 s19=00000000 d09=0000000000000000 +s20=00000000 s21=00000000 d10=0000000000000000 +s22=00000000 s23=00000000 d11=0000000000000000 +s24=00000000 s25=00000000 d12=0000000000000000 +s26=00000000 s27=00000000 d13=0000000000000000 +s28=00000000 s29=00000000 d14=0000000000000000 +s30=00000000 s31=00000000 d15=0000000000000000 +s32=00000000 s33=00000000 d16=0000000000000000 +s34=00000000 s35=00000000 d17=0000000000000000 +s36=00000000 s37=00000000 d18=0000000000000000 +s38=00000000 s39=00000000 d19=0000000000000000 +s40=00000000 s41=00000000 d20=0000000000000000 +s42=00000000 s43=00000000 d21=0000000000000000 +s44=00000000 s45=00000000 d22=0000000000000000 +s46=00000000 s47=00000000 d23=0000000000000000 +s48=00000000 s49=00000000 d24=0000000000000000 +s50=00000000 s51=00000000 d25=0000000000000000 +s52=00000000 s53=00000000 d26=0000000000000000 +s54=00000000 s55=00000000 d27=0000000000000000 +s56=00000000 s57=00000000 d28=0000000000000000 +s58=00000000 s59=00000000 d29=0000000000000000 +s60=00000000 s61=00000000 d30=0000000000000000 +s62=00000000 s63=00000000 d31=0000000000000000 +FPSCR: 00000000 +(gdb) monitor system_reset +(gdb) info registers +r0 0x0 0 +r1 0x9010001 151060481 +r2 0x0 0 +r3 0x428c89 4361353 +r4 0x640f08 6557448 +r5 0x672480 6759552 +r6 0x0 0 +r7 0x0 0 +r8 0x0 0 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x60bb80 6339456 +sp 0x6783f0 0x6783f0 <_Thread_Idle_stacks+4080> +lr 0x425fa1 4349857 +pc 0x428c8a 0x428c8a <_CPU_Thread_Idle_body+2> +cpsr 0x60070173 1611071859 +fpscr 0x0 0 +fpsid 0x41033090 1090728080 +fpexc 0x40000000 1073741824 +[...] +(gdb) monitor info registers +R00=00000000 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00000000 R14=00000000 R15=00104040 +PSR=400001d3 -Z-- A svc32 +s00=00000000 s01=00000000 d00=0000000000000000 +s02=00000000 s03=00000000 d01=0000000000000000 +s04=00000000 s05=00000000 d02=0000000000000000 +s06=00000000 s07=00000000 d03=0000000000000000 +s08=00000000 s09=00000000 d04=0000000000000000 +s10=00000000 s11=00000000 d05=0000000000000000 +s12=00000000 s13=00000000 d06=0000000000000000 +s14=00000000 s15=00000000 d07=0000000000000000 +s16=00000000 s17=00000000 d08=0000000000000000 +s18=00000000 s19=00000000 d09=0000000000000000 +s20=00000000 s21=00000000 d10=0000000000000000 +s22=00000000 s23=00000000 d11=0000000000000000 +s24=00000000 s25=00000000 d12=0000000000000000 +s26=00000000 s27=00000000 d13=0000000000000000 +s28=00000000 s29=00000000 d14=0000000000000000 +s30=00000000 s31=00000000 d15=0000000000000000 +s32=00000000 s33=00000000 d16=0000000000000000 +s34=00000000 s35=00000000 d17=0000000000000000 +s36=00000000 s37=00000000 d18=0000000000000000 +s38=00000000 s39=00000000 d19=0000000000000000 +s40=00000000 s41=00000000 d20=0000000000000000 +s42=00000000 s43=00000000 d21=0000000000000000 +s44=00000000 s45=00000000 d22=0000000000000000 +s46=00000000 s47=00000000 d23=0000000000000000 +s48=00000000 s49=00000000 d24=0000000000000000 +s50=00000000 s51=00000000 d25=0000000000000000 +s52=00000000 s53=00000000 d26=0000000000000000 +s54=00000000 s55=00000000 d27=0000000000000000 +s56=00000000 s57=00000000 d28=0000000000000000 +s58=00000000 s59=00000000 d29=0000000000000000 +s60=00000000 s61=00000000 d30=0000000000000000 +s62=00000000 s63=00000000 d31=0000000000000000 +FPSCR: 00000000 +(gdb) si +bsp_start_vector_table_end () at /home/EB/sebastian_h/src/rtems/bsps/arm/shared/start/start.S:166 +166 mov r6, r2 /* physical address of ATAGs or DTB */ +(gdb) info registers +r0 0x0 0 +r1 0x0 0 +r2 0x0 0 +r3 0x0 0 +r4 0x0 0 +r5 0x0 0 +r6 0x0 0 +r7 0x0 0 +r8 0x0 0 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x0 0 +sp 0x0 0x0 +lr 0x0 0 +pc 0x104044 0x104044 <bsp_start_vector_table_end+4> +cpsr 0x400001d3 1073742291 +fpscr 0x0 0 +fpsid 0x41033090 1090728080 +fpexc 0x0 0 +[...] + +I can also build the latest Git master of Qemu if this helps. + +I suspect that gdb has cached the values of the registers and we haven't done anything to tell it that they're now stale. I'm not sure the gdbstub protocol even has a mechanism for doing this -- after all, from gdb's point of view the target is stopped and it does not expect that its state will change until gdb asks it to resume execution. + +I'm not sure how this could be dealt with -- in theory one could forbid actions like system reset while the gdbstub had control, but that seems likely to have unwelcome side-effects... + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/100 + + diff --git a/results/classifier/zero-shot/108/all/1286253 b/results/classifier/zero-shot/108/all/1286253 new file mode 100644 index 000000000..6c45ef04d --- /dev/null +++ b/results/classifier/zero-shot/108/all/1286253 @@ -0,0 +1,120 @@ +permissions: 0.986 +other: 0.983 +performance: 0.974 +device: 0.969 +graphic: 0.967 +debug: 0.966 +semantic: 0.960 +files: 0.953 +PID: 0.949 +KVM: 0.945 +vnc: 0.943 +network: 0.938 +boot: 0.913 +socket: 0.913 + +virtio-net acceleration features not set when plugged into backend dynamically + +When using indpendent transport and backend in this case virtio-net-device transport, none of the acceleration features are set after guest probes the transport the backend is plugged into. For virtio-net this leads to low throughput/performance. This holds true for virtio-mmio, PCI transports and most likely for others as well (CCW, S390) and other backends + +Command to run: +./qemu-system-arm -enable-kvm -smp 2 -kernel zImage -dtb ./guest-a15.dtb -m 512 -M vexpress-a15 -cpu cortex-a15 -nographic \ + -append "root=/dev/vda rw console=ttyAMA0 rootwait" -drive if=none,file=/mnt/gauss.root,id=vm1 \ + -device virtio-blk-device,drive=vm1 -netdev type=tap,id=net0,ifname=tap0 \ + -device virtio-net-device,netdev=net0,mac="52:54:00:12:34:58" + +For x86 same virtio command for network. + +On Fri, Feb 28, 2014 at 05:40:19PM -0000, Mario Smarduch wrote: +> When using indpendent transport and backend in this case virtio-net- +> device transport, none of the acceleration features are set after guest +> probes the transport the backend is plugged into. For virtio-net this +> leads to low throughput/performance. This holds true for virtio-mmio, +> PCI transports and most likely for others as well (CCW, S390) and other +> backends +> +> Command to run: +> ./qemu-system-arm -enable-kvm -smp 2 -kernel zImage -dtb ./guest-a15.dtb -m 512 -M vexpress-a15 -cpu cortex-a15 -nographic \ +> -append "root=/dev/vda rw console=ttyAMA0 rootwait" -drive if=none,file=/mnt/gauss.root,id=vm1 \ +> -device virtio-blk-device,drive=vm1 -netdev type=tap,id=net0,ifname=tap0 \ +> -device virtio-net-device,netdev=net0,mac="52:54:00:12:34:58" +> +> For x86 same virtio command for network. + +Can you explain in more detail? + +The command-line looks sane. The virtio-net-device instance should +figure out the tap supports offloads. + +Did you try adding a printf to virtio_net_get_features() to see why the +offload features are not being detected? + +Stefan + + +I don't have an x86 setup handy, but looking through the code 'virtio-net-pci' will +work but not 'virtio-net-device'. My understanding was the goal is for any +backend to plug into any transport on any platform. I'll try an x86 test with +'virtio-net-device' option and see what happens. + +Yes I did check the options on host after device is plugged and guest after features +are probed, only the MAC feature is set. + +Thanks, +- Mario + +-----Original Message----- +From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Michael S. Tsirkin +Sent: Monday, March 03, 2014 4:49 AM +To: Stefan Hajnoczi +Cc: Bug 1286253; <email address hidden> +Subject: Re: [Qemu-devel] [Bug 1286253] [NEW] virtio-net acceleration features not set when plugged into backend dynamically + +On Mon, Mar 03, 2014 at 01:37:46PM +0100, Stefan Hajnoczi wrote: +> On Fri, Feb 28, 2014 at 05:40:19PM -0000, Mario Smarduch wrote: +> > When using indpendent transport and backend in this case virtio-net- +> > device transport, none of the acceleration features are set after +> > guest probes the transport the backend is plugged into. For +> > virtio-net this leads to low throughput/performance. This holds +> > true for virtio-mmio, PCI transports and most likely for others as +> > well (CCW, S390) and other backends +> > +> > Command to run: +> > ./qemu-system-arm -enable-kvm -smp 2 -kernel zImage -dtb ./guest-a15.dtb -m 512 -M vexpress-a15 -cpu cortex-a15 -nographic \ +> > -append "root=/dev/vda rw console=ttyAMA0 rootwait" -drive if=none,file=/mnt/gauss.root,id=vm1 \ +> > -device virtio-blk-device,drive=vm1 -netdev type=tap,id=net0,ifname=tap0 \ +> > -device virtio-net-device,netdev=net0,mac="52:54:00:12:34:58" +> > +> > For x86 same virtio command for network. +> +> Can you explain in more detail? +> +> The command-line looks sane. The virtio-net-device instance should +> figure out the tap supports offloads. +> +> Did you try adding a printf to virtio_net_get_features() to see why +> the offload features are not being detected? +> +> Stefan + +IIUC mmio does not set any feature bits, so you get the fallback behaviour: + +$ git grep DEFINE_VIRTIO_NET_FEATURES +hw/s390x/s390-virtio-bus.c: DEFINE_VIRTIO_NET_FEATURES(VirtIOS390Device, host_featur +hw/s390x/virtio-ccw.c: DEFINE_VIRTIO_NET_FEATURES(VirtioCcwDevice, host_features[0]) +hw/virtio/virtio-pci.c: DEFINE_VIRTIO_NET_FEATURES(VirtIOPCIProxy, host_features), +include/hw/virtio/virtio-net.h:#define DEFINE_VIRTIO_NET_FEATURES(_state, _field) \ + +But it should work for pci, and certainly does for x86. + + +-- +MST + + + + +Which version of QEMU did you use here? Can you still reproduce this problem with the latest version of QEMU (currently v2.9)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1306 b/results/classifier/zero-shot/108/all/1306 new file mode 100644 index 000000000..9b19f96da --- /dev/null +++ b/results/classifier/zero-shot/108/all/1306 @@ -0,0 +1,174 @@ +permissions: 0.992 +other: 0.988 +performance: 0.988 +semantic: 0.987 +debug: 0.985 +device: 0.983 +files: 0.979 +vnc: 0.977 +PID: 0.975 +boot: 0.973 +graphic: 0.972 +KVM: 0.964 +socket: 0.944 +network: 0.925 + +OpenIndiana fails with "BAD TRAP" & "Page fault" in guest with SATA optical drive +Additional information: +I am not experienced in QEMU, and have not been able to isolate with a simple command line. However, I will attempt any test cases provided by the community. + +The problem in the domain reproduced below resolves by removing the SATA optical drive (even if the SATA controller remains). + +The working case may be derived through the following patch: + +``` +1c1 +< <domain type='kvm' id='83'> +--- +> <domain type='kvm' id='82'> +18a19 +> <boot dev='hd'/> +42c43 +< <source file='/srv/store/epl/img/OI-hipster-minimal-20211031.iso' index='2'/> +--- +> <source file='/srv/store/epl/img/OI-hipster-minimal-20211031.iso' index='1'/> +46d46 +< <boot order='1'/> +48,54d47 +< <address type='drive' controller='0' bus='0' target='0' unit='0'/> +< </disk> +< <disk type='file' device='cdrom'> +< <driver name='qemu'/> +< <target dev='sda' bus='sata'/> +< <readonly/> +< <alias name='sata0-0-0'/> +``` + +For consistency, the boot media is installed on an IDE optical drive, which appears not to cause problems. The problem was originally discovered attempting to boot from a SATA optical drive, following the intended layout of the guest system. + +--- + +``` +<domain type='kvm' id='84'> + <name>openindiana-clone</name> + <uuid>7a0550ec-ff03-4894-80b8-affe0dfd8177</uuid> + <metadata> + <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> + <libosinfo:os id="http://oracle.com/solaris/11"/> + </libosinfo:libosinfo> + </metadata> + <memory unit='KiB'>2097152</memory> + <currentMemory unit='KiB'>2097152</currentMemory> + <vcpu placement='static'>4</vcpu> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-i440fx-jammy'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE_4M.fd</loader> + <nvram template='/usr/share/OVMF/OVMF_VARS_4M.fd'>/var/lib/libvirt/qemu/nvram/openindiana-clone_VARS.fd</nvram> + </os> + <features> + <acpi/> + <apic/> + <vmport state='off'/> + </features> + <cpu mode='host-passthrough' check='none' migratable='on'/> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/srv/img/OI-hipster-minimal-20211031.iso' index='2'/> + <backingStore/> + <target dev='hda' bus='ide'/> + <readonly/> + <boot order='1'/> + <alias name='ide0-0-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu'/> + <target dev='sda' bus='sata'/> + <readonly/> + <alias name='sata0-0-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <alias name='usb'/> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <alias name='usb'/> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <alias name='usb'/> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='ide' index='0'> + <alias name='ide'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='sata' index='0'> + <alias name='sata0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </controller> + <input type='mouse' bus='ps2'> + <alias name='input0'/> + </input> + <input type='keyboard' bus='ps2'> + <alias name='input1'/> + </input> + <graphics type='spice'> + <listen type='none'/> + <image compression='off'/> + <gl enable='no'/> + </graphics> + <audio id='1' type='spice'/> + <video> + <model type='vga' vram='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </memballoon> + </devices> + <seclabel type='dynamic' model='apparmor' relabel='yes'> + <label>libvirt-7a0550ec-ff03-4894-80b8-affe0dfd8177</label> + <imagelabel>libvirt-7a0550ec-ff03-4894-80b8-affe0dfd8177</imagelabel> + </seclabel> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+64055:+130</label> + <imagelabel>+64055:+130</imagelabel> + </seclabel> +</domain> +``` + + +--- + + diff --git a/results/classifier/zero-shot/108/all/1308542 b/results/classifier/zero-shot/108/all/1308542 new file mode 100644 index 000000000..b818d4dec --- /dev/null +++ b/results/classifier/zero-shot/108/all/1308542 @@ -0,0 +1,191 @@ +other: 0.978 +permissions: 0.977 +performance: 0.972 +graphic: 0.971 +semantic: 0.968 +debug: 0.966 +boot: 0.964 +PID: 0.960 +files: 0.955 +socket: 0.955 +network: 0.954 +device: 0.954 +vnc: 0.937 +KVM: 0.925 + +hang in qemu_gluster_init + +In qemu_gluster_init, if the call to either glfs_set_volfile_server or glfs_set_logging fails into the "out" case, glfs_fini is called without having first calling glfs_init. This causes glfs_lock to spin forever on this bit: + + while (!fs->init) + pthread_cond_wait (&fs->cond, &fs->mutex); + +And here's the bottom part of the backtrace when hung: + +#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183 +#1 0x00007feceebf58c3 in glfs_lock (fs=0x7fecf15660b0) at glfs-internal.h:156 +#2 glfs_active_subvol (fs=0x7fecf15660b0) at glfs-resolve.c:799 +#3 0x00007feceebeb5b4 in glfs_fini (fs=0x7fecf15660b0) at glfs.c:652 +#4 0x00007fecf0043c73 in qemu_gluster_init (gconf=<value optimized out>, filename=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/block/gluster.c:229 + +I believe this can be fixed by simply moving the call to glfs_init after the call to glfs_new but before the calls to glfs_set_volfile_server or glfs_set_logging. + +Am 16.04.2014 um 15:25 hat John Eckersberg geschrieben: +> Public bug reported: +> +> In qemu_gluster_init, if the call to either glfs_set_volfile_server or +> glfs_set_logging fails into the "out" case, glfs_fini is called without +> having first calling glfs_init. This causes glfs_lock to spin forever +> on this bit: +> +> while (!fs->init) +> pthread_cond_wait (&fs->cond, &fs->mutex); +> +> And here's the bottom part of the backtrace when hung: +> +> #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183 +> #1 0x00007feceebf58c3 in glfs_lock (fs=0x7fecf15660b0) at glfs-internal.h:156 +> #2 glfs_active_subvol (fs=0x7fecf15660b0) at glfs-resolve.c:799 +> #3 0x00007feceebeb5b4 in glfs_fini (fs=0x7fecf15660b0) at glfs.c:652 +> #4 0x00007fecf0043c73 in qemu_gluster_init (gconf=<value optimized out>, filename=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/block/gluster.c:229 +> +> I believe this can be fixed by simply moving the call to glfs_init after +> the call to glfs_new but before the calls to glfs_set_volfile_server or +> glfs_set_logging. + +Bharata, can you check whether this is the correct solution, and if so, +send out a patch? + +Kevin + + +On Thu, Apr 17, 2014 at 11:27:52AM +0200, Kevin Wolf wrote: +> Am 16.04.2014 um 15:25 hat John Eckersberg geschrieben: +> > Public bug reported: +> > +> > In qemu_gluster_init, if the call to either glfs_set_volfile_server or +> > glfs_set_logging fails into the "out" case, glfs_fini is called without +> > having first calling glfs_init. This causes glfs_lock to spin forever +> > on this bit: +> > +> > while (!fs->init) +> > pthread_cond_wait (&fs->cond, &fs->mutex); +> > +> > And here's the bottom part of the backtrace when hung: +> > +> > #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183 +> > #1 0x00007feceebf58c3 in glfs_lock (fs=0x7fecf15660b0) at glfs-internal.h:156 +> > #2 glfs_active_subvol (fs=0x7fecf15660b0) at glfs-resolve.c:799 +> > #3 0x00007feceebeb5b4 in glfs_fini (fs=0x7fecf15660b0) at glfs.c:652 +> > #4 0x00007fecf0043c73 in qemu_gluster_init (gconf=<value optimized out>, filename=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/block/gluster.c:229 +> > +> > I believe this can be fixed by simply moving the call to glfs_init after +> > the call to glfs_new but before the calls to glfs_set_volfile_server or +> > glfs_set_logging. +> +> Bharata, can you check whether this is the correct solution, and if so, +> send out a patch? + +I think glfs_set_volfile_server should have been called before glfs_init. +Anyway will check gluster folks and send out an appropriate patch for this. + +BTW we haven't hit this problem till now because glfs_fini was nop when +we wrote this driver but has been functionally implemented now. + +Regards, +Bharata. + + + +" glfs_init" cannot be called before since it checks for cmds_args->volfile_server which is allocated only in "glfs_set_volfile_server". We should either modify "glfs_fini" or define a new function to do the cleanup based on if init is done or not. + +On Fri, Apr 18, 2014 at 02:38:57PM -0000, Soumya Koduri wrote: +> " glfs_init" cannot be called before since it checks for +> cmds_args->volfile_server which is allocated only in +> "glfs_set_volfile_server". We should either modify "glfs_fini" or + +Soumya - Thanks for offering to fix this in gluster. +(Ref: http://lists.gnu.org/archive/html/gluster-devel/2014-04/msg00192.html) + +Kevin - I will wait for this fix to be available in libgfapi before +changing QEMU. + +Regards, +Bharata. + + + +Also I should add a note to this related bug I filed against gluster - https://bugzilla.redhat.com/show_bug.cgi?id=1088589 + +This bug is what causes the glfs_set_logging call to fail, and fall into the hang case. + +A complete fix has been included in the glusterfs master-branch. It has not (yet) been requested or marked for backporting to a stable (3.5.x) branch. + +* https://bugzilla.redhat.com/1091335 with http://review.gluster.org/7857 + +The issue with glfs_set_logging is fixed in the almost released glusterfs-3.5.1 (https://bugzilla.redhat.com/1103413). + +Verified that this fixes the hang and no change is required in gluster +driver of QEMU after this fix in glusterfs code. + + +On Mon, Jun 23, 2014 at 11:59 PM, nixpanic <email address hidden> wrote: + +> A complete fix has been included in the glusterfs master-branch. It has +> not (yet) been requested or marked for backporting to a stable (3.5.x) +> branch. +> +> * https://bugzilla.redhat.com/1091335 with +> http://review.gluster.org/7857 +> +> The issue with glfs_set_logging is fixed in the almost released +> glusterfs-3.5.1 (https://bugzilla.redhat.com/1103413). +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1308542 +> +> Title: +> hang in qemu_gluster_init +> +> Status in QEMU: +> New +> +> Bug description: +> In qemu_gluster_init, if the call to either glfs_set_volfile_server or +> glfs_set_logging fails into the "out" case, glfs_fini is called +> without having first calling glfs_init. This causes glfs_lock to spin +> forever on this bit: +> +> while (!fs->init) +> pthread_cond_wait (&fs->cond, &fs->mutex); +> +> And here's the bottom part of the backtrace when hung: +> +> #0 pthread_cond_wait@@GLIBC_2.3.2 () at +> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183 +> #1 0x00007feceebf58c3 in glfs_lock (fs=0x7fecf15660b0) at +> glfs-internal.h:156 +> #2 glfs_active_subvol (fs=0x7fecf15660b0) at glfs-resolve.c:799 +> #3 0x00007feceebeb5b4 in glfs_fini (fs=0x7fecf15660b0) at glfs.c:652 +> #4 0x00007fecf0043c73 in qemu_gluster_init (gconf=<value optimized +> out>, filename=<value optimized out>) at +> /usr/src/debug/qemu-kvm-0.12.1.2/block/gluster.c:229 +> +> I believe this can be fixed by simply moving the call to glfs_init +> after the call to glfs_new but before the calls to +> glfs_set_volfile_server or glfs_set_logging. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1308542/+subscriptions +> +> + + +-- +http://raobharata.wordpress.com/ + + +Closing according to comment #7. + diff --git a/results/classifier/zero-shot/108/all/1317603 b/results/classifier/zero-shot/108/all/1317603 new file mode 100644 index 000000000..8a507c248 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1317603 @@ -0,0 +1,200 @@ +permissions: 0.985 +other: 0.985 +graphic: 0.975 +semantic: 0.971 +debug: 0.971 +socket: 0.967 +device: 0.965 +performance: 0.965 +boot: 0.957 +files: 0.953 +PID: 0.952 +network: 0.948 +KVM: 0.935 +vnc: 0.922 + +qemu-system-ppc does not terminate on VM exit + +When a VM is created for a p4080-e500mc ; the VM can not be rebooted or terminated. + +The qemu-system-ppc process must be killed. + +ProblemType: Bug +DistroRelease: Ubuntu 14.04 +Package: qemu-system-ppc 2.0.0~rc1+dfsg-0ubuntu3.1 +ProcVersionSignature: Ubuntu 3.13.0-24.46-powerpc-e500mc 3.13.9 +Uname: Linux 3.13.9+ ppc +ApportVersion: 2.14.1-0ubuntu3 +Architecture: powerpc +Date: Thu May 8 12:20:57 2014 +ProcEnviron: + TERM=xterm + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=en_US.UTF-8 + SHELL=/bin/bash +SourcePackage: qemu +UpgradeStatus: Upgraded to trusty on 2014-04-29 (9 days ago) + + + +What do you mean by "cannot be rebooted"? When you log into the guest and type "reboot", nothing happens? Does init call reboot(2) and the kernel ignores it? All of userspace is properly terminated, and kernel hangs at the actual reboot? + +qemu-system-ppc never terminates. + + +Regards, + John. + +-- + +o Energy-efficiency is #1 reason data centers look to expand. -- +Digital Realty Trust +o Green Data Centers spending to increase 300% worldwide by 2016. -- +Pike Research +o Data Centers have become as vital to the functioning of society as +power stations. -- The Economist + + +On Sat, May 24, 2014 at 5:35 PM, Serge Hallyn +<email address hidden> wrote: +> What do you mean by "cannot be rebooted"? When you log into the guest +> and type "reboot", nothing happens? Does init call reboot(2) and the +> kernel ignores it? All of userspace is properly terminated, and kernel +> hangs at the actual reboot? +> +> ** Also affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1317603 +> +> Title: +> qemu-system-ppc does not terminate on VM exit +> +> Status in QEMU: +> New +> Status in “qemu” package in Ubuntu: +> New +> +> Bug description: +> When a VM is created for a p4080-e500mc ; the VM can not be rebooted +> or terminated. +> +> The qemu-system-ppc process must be killed. +> +> ProblemType: Bug +> DistroRelease: Ubuntu 14.04 +> Package: qemu-system-ppc 2.0.0~rc1+dfsg-0ubuntu3.1 +> ProcVersionSignature: Ubuntu 3.13.0-24.46-powerpc-e500mc 3.13.9 +> Uname: Linux 3.13.9+ ppc +> ApportVersion: 2.14.1-0ubuntu3 +> Architecture: powerpc +> Date: Thu May 8 12:20:57 2014 +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> XDG_RUNTIME_DIR=<set> +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> SourcePackage: qemu +> UpgradeStatus: Upgraded to trusty on 2014-04-29 (9 days ago) +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1317603/+subscriptions + + +Quoting <email address hidden> (<email address hidden>): +> qemu-system-ppc never terminates. + +Assuming you are using the same scripts as in the other bugs, you are passing +-no-shutdown to qemu, asking it to not exit when the guest exits. If you +want qemu to exit when the guest is done, then please remove that flag, and +see if that fixes it. + +If you are then manually killing qemu before the guest is done running, that +would also explain why the guest fs is corrupted. + + +It does not change the the behaviour. +With or without those options the VM qemu-system-ppc session never exits. + + + +Regards, + John. + +-- + +o Energy-efficiency is #1 reason data centers look to expand. -- +Digital Realty Trust +o Green Data Centers spending to increase 300% worldwide by 2016. -- +Pike Research +o Data Centers have become as vital to the functioning of society as +power stations. -- The Economist + + +On Sat, May 24, 2014 at 7:12 PM, Serge Hallyn +<email address hidden> wrote: +> Quoting <email address hidden> (<email address hidden>): +>> qemu-system-ppc never terminates. +> +> Assuming you are using the same scripts as in the other bugs, you are passing +> -no-shutdown to qemu, asking it to not exit when the guest exits. If you +> want qemu to exit when the guest is done, then please remove that flag, and +> see if that fixes it. +> +> If you are then manually killing qemu before the guest is done running, that +> would also explain why the guest fs is corrupted. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1317603 +> +> Title: +> qemu-system-ppc does not terminate on VM exit +> +> Status in QEMU: +> New +> Status in “qemu” package in Ubuntu: +> New +> +> Bug description: +> When a VM is created for a p4080-e500mc ; the VM can not be rebooted +> or terminated. +> +> The qemu-system-ppc process must be killed. +> +> ProblemType: Bug +> DistroRelease: Ubuntu 14.04 +> Package: qemu-system-ppc 2.0.0~rc1+dfsg-0ubuntu3.1 +> ProcVersionSignature: Ubuntu 3.13.0-24.46-powerpc-e500mc 3.13.9 +> Uname: Linux 3.13.9+ ppc +> ApportVersion: 2.14.1-0ubuntu3 +> Architecture: powerpc +> Date: Thu May 8 12:20:57 2014 +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> XDG_RUNTIME_DIR=<set> +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> SourcePackage: qemu +> UpgradeStatus: Upgraded to trusty on 2014-04-29 (9 days ago) +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1317603/+subscriptions + + +I've uploaded a build of today's qemu git HEAD to https://launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream . Would it be possible to test with that? I assume you'll need to grab the source and re-build packages for ppc. + +I am no longer working on this project, + +Looking at comment #7, it sounds like you're not interested in this ticket anymore, so I'm closing it as "Won't fix". Feel free to open it again if you are still interested in this. + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1336801 b/results/classifier/zero-shot/108/all/1336801 new file mode 100644 index 000000000..6baa5897d --- /dev/null +++ b/results/classifier/zero-shot/108/all/1336801 @@ -0,0 +1,97 @@ +permissions: 0.977 +graphic: 0.973 +debug: 0.972 +device: 0.971 +semantic: 0.968 +boot: 0.967 +other: 0.967 +PID: 0.964 +network: 0.960 +socket: 0.957 +performance: 0.956 +vnc: 0.948 +KVM: 0.943 +files: 0.929 + +12.04 guest hangs on a 14.04 host server with cirrus graphics + +A new 12.04.4 server guest installation hangs on a 14.04 server host machine. + +I did the following: + +Created a new Virtual Machine with the Ubuntu 12.04 template using virt-manager +Ran through the installation without a hitch to install a LAMP+SSH server. All standard options apart from that. +On reboot the 12.04 guest started but then hung after doing fsck step. +Trying different options (change disk driver, etc) made it progress a couple more steps but still hung. + +The thing that fixed it in the end was to switch to a VGA display driver, away from the default. + +Thanks for reporting this bug. + +When you say you used a "Ubuntu 12.04 template", do you mean you used +an iso, or something else? If iso, could you please give us the full +url so I can try to reproduce? + +As you created the vm in virt-manager, did you change anything from the +defaults? + +Could you please attach the domain's broken xml to this bug? + + status: incomplete + importance: high + + +Hi Serge. + +Update on this post. It seems that the problem is the display driver choice in the VM settings. + +The steps I took in installing were: + +Click "New VM" button in virt-manager +Type in name and select local install media. Press Forward. +Select an ISO image. OS Type Linux. Version Ubuntu 12.04 (this is the template I was referring to). + +After much experimenting I managed to solve the problem by selecting VGA video mode in the VM's settings. The default causing the problem was Cirrus. + +Now that I've got network set up on the VM I've just run the it with Cirrus graphics and am seeing the same problems but I can ssh in. So, it would appear that the console freezes rather than the whole VM freezing. + +The broken VM XML + +I can reproduce the console not being useful, however I can ssh into the VM. Syslog shows: + +[ 7.296919] fb: conflicting fb hw usage cirrusdrmfb vs EFI VGA - removing generic driver +[ 7.433222] [drm:cirrus_vram_init] *ERROR* can't reserve VRAM +[ 7.433234] cirrus 0000:00:02.0: Fatal error during GPU init: -6 + + +A subsequent (clean) reboot results in a working console. + +So it sounds like qemu is not properly resetting its hardware during the first reboot. + +Getting a working console is quite hit-or-miss + +Getting a working console is quite hit-or-miss + +Note that on a successful boot, dmesg | grep cirrus shows: + +[ 9.064581] fb: conflicting fb hw usage cirrusdrmfb vs EFI VGA - removing generic driver +[ 9.133808] fbcon: cirrusdrmfb (fb0) is primary device +[ 9.431359] cirrus 0000:00:02.0: fb0: cirrusdrmfb frame buffer device +[ 9.431362] cirrus 0000:00:02.0: registered panic notifier +[ 9.652851] [drm] Initialized cirrus 1.0.0 20110418 for 0000:00:02.0 on minor 0 + +I can also reproduce this on qemu built from upstream git head (earlier this week) so marking as affecting the upstream project. + +Actually I suppose this could be a seabios bug? (I am on 1.7.4-4) + +I'm also having issues with libvirt/kvm guests becoming unresponsive and they were all using cirrus as their video model. I've tried switching some to vga to see if that helps. + +The errors about the frame buffer device happen because grub is started in graphical mode and then the boot wants to replace the framebuffer device/driver while plymouth still holds it. I thought we should have fixed this before release by adding cirrus to the list of graphics that should get initialized late. So are people still having this issue with the latest updates? +A work around if this really still happens is to change /etc/default/grub and uncomment the console mode. Not ultimately nice but should be working. + +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.] + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1341 b/results/classifier/zero-shot/108/all/1341 new file mode 100644 index 000000000..0fd9afd62 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1341 @@ -0,0 +1,93 @@ +graphic: 0.973 +other: 0.960 +permissions: 0.958 +device: 0.956 +performance: 0.955 +semantic: 0.951 +vnc: 0.949 +socket: 0.947 +PID: 0.947 +KVM: 0.946 +debug: 0.945 +network: 0.941 +boot: 0.933 +files: 0.927 + +Static build failure with clang (clang 14.0.6) +Description of problem: +Static build failure with redefinition of 'iovec'. + +The configure looks like this: + +``` + export CC=clang + ../$pkgbase-$pkgver/configure \ + --prefix=/usr \ + --sysconfdir=/etc \ + --libexecdir=/usr/lib/qemu \ + --enable-attr \ + --enable-linux-user \ + --enable-tcg \ + --disable-bpf \ + --disable-bsd-user \ + --disable-capstone \ + --disable-docs \ + --disable-fdt \ + --disable-gcrypt \ + --disable-glusterfs \ + --disable-gnutls \ + --disable-gtk \ + --disable-install-blobs \ + --disable-kvm \ + --disable-libiscsi \ + --disable-libnfs \ + --disable-libssh \ + --disable-linux-io-uring \ + --disable-nettle \ + --disable-opengl \ + --disable-qom-cast-debug \ + --disable-sdl \ + --disable-system \ + --disable-tools \ + --disable-tpm \ + --disable-vde \ + --disable-vhost-crypto \ + --disable-vhost-kernel \ + --disable-vhost-net \ + --disable-vhost-user \ + --disable-vnc \ + --disable-werror \ + --disable-xen \ + --disable-zstd \ + --static +``` + +The compiling failure looks like this: +``` +FAILED: libqom.fa.p/qom_object.c.o +clang -Ilibqom.fa.p -I. -I../qemu-7.1.0 -Iqapi -Itrace -Iui/shader -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /home/adam/qemu-user-static/src/qemu-7.1.0/linux-headers -isystem linux-headers -iquote . -iquote /home/adam/qemu-user-static/src/qemu-7.1.0 -iquote /home/adam/qemu-user-static/src/qemu-7.1.0/include -iquote /home/adam/qemu-user-static/src/qemu-7.1.0/tcg/aarch64 -pthread -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-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -Wno-missing-braces -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fPIE -MD -MQ libqom.fa.p/qom_object.c.o -MF libqom.fa.p/qom_object.c.o.d -o libqom.fa.p/qom_object.c.o -c ../qemu-7.1.0/qom/object.c +distcc[94580] (dcc_build_somewhere) Warning: failed to distribute, running locally instead +clang-14: warning: argument unused during compilation: '-fstack-clash-protection' [-Wunused-command-line-argument] +In file included from ../qemu-7.1.0/qom/object.c:13: +/home/adam/qemu-user-static/src/qemu-7.1.0/include/qemu/osdep.h:517:8: error: redefinition of 'iovec' +struct iovec { + ^ +/usr/include/bits/types/struct_iovec.h:26:8: note: previous definition is here +struct iovec + ^ +In file included from ../qemu-7.1.0/qom/object.c:13: +/home/adam/qemu-user-static/src/qemu-7.1.0/include/qemu/osdep.h:524:9: warning: 'IOV_MAX' macro redefined [-Wmacro-redefined] +#define IOV_MAX 1024 + ^ +/usr/include/bits/xopen_lim.h:66:10: note: previous definition is here +# define IOV_MAX __IOV_MAX + ^ +1 warning and 1 error generated. +distcc[94580] ERROR: compile ../qemu-7.1.0/qom/object.c on localhost failed +ninja: build stopped: subcommand failed. +``` +Steps to reproduce: +1. Compile qemu using above configure and use clang as the compiler +Additional information: +Full meson log: +[meson-log.txt](/uploads/a63d609852148140e8fa7210c6912982/meson-log.txt) diff --git a/results/classifier/zero-shot/108/all/1348106 b/results/classifier/zero-shot/108/all/1348106 new file mode 100644 index 000000000..c775c2df0 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1348106 @@ -0,0 +1,225 @@ +other: 0.991 +permissions: 0.991 +semantic: 0.990 +graphic: 0.990 +performance: 0.990 +socket: 0.990 +files: 0.989 +vnc: 0.989 +device: 0.989 +debug: 0.988 +network: 0.988 +boot: 0.987 +PID: 0.987 +KVM: 0.985 + +kvm crash on Kali Linux + +platform: DELL Vostro 2421 +#uname -a +Linux x-linux 3.14-kali1-686-pae #1 SMP Debian 3.14.4-1kali1 (2014-05-14) i686 GNU/Linux + +#kvm --version +QEMU emulator version 1.1.2 (qemu-kvm-1.1.2+dfsg-6+deb7u3, Debian), Copyright (c) 2003-2008 Fabrice Bellard + +#qemu --version +QEMU emulator version 1.1.2 (Debian 1.1.2+dfsg-6a+deb7u3), Copyright (c) 2003-2008 Fabrice Bellard + +# cat /etc/issue +Kali GNU/Linux 1.0.7 \n \l + +# cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 58 +model name : Intel(R) Core(TM) i3-3227U CPU @ 1.90GHz +stepping : 9 +microcode : 0x19 +cpu MHz : 790.875 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 2 +apicid : 0 +initial apicid : 0 +fdiv_bug : no +f00f_bug : no +coma_bug : no +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx f16c lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms +bogomips : 3791.39 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 1 +vendor_id : GenuineIntel +cpu family : 6 +model : 58 +model name : Intel(R) Core(TM) i3-3227U CPU @ 1.90GHz +stepping : 9 +microcode : 0x19 +cpu MHz : 790.875 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 1 +cpu cores : 2 +apicid : 2 +initial apicid : 2 +fdiv_bug : no +f00f_bug : no +coma_bug : no +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx f16c lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms +bogomips : 3791.39 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 2 +vendor_id : GenuineIntel +cpu family : 6 +model : 58 +model name : Intel(R) Core(TM) i3-3227U CPU @ 1.90GHz +stepping : 9 +microcode : 0x19 +cpu MHz : 790.875 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 2 +apicid : 1 +initial apicid : 1 +fdiv_bug : no +f00f_bug : no +coma_bug : no +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx f16c lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms +bogomips : 3791.39 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 3 +vendor_id : GenuineIntel +cpu family : 6 +model : 58 +model name : Intel(R) Core(TM) i3-3227U CPU @ 1.90GHz +stepping : 9 +microcode : 0x19 +cpu MHz : 790.875 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 1 +cpu cores : 2 +apicid : 3 +initial apicid : 3 +fdiv_bug : no +f00f_bug : no +coma_bug : no +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx f16c lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms +bogomips : 3791.39 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +# cat /proc/meminfo +MemTotal: 4010792 kB +MemFree: 3123960 kB +MemAvailable: 3307340 kB +Buffers: 44908 kB +Cached: 389772 kB +SwapCached: 0 kB +Active: 476588 kB +Inactive: 348656 kB +Active(anon): 391436 kB +Inactive(anon): 71016 kB +Active(file): 85152 kB +Inactive(file): 277640 kB +Unevictable: 0 kB +Mlocked: 0 kB +HighTotal: 3148696 kB +HighFree: 2431604 kB +LowTotal: 862096 kB +LowFree: 692356 kB +SwapTotal: 2095100 kB +SwapFree: 2095100 kB +Dirty: 64 kB +Writeback: 0 kB +AnonPages: 390604 kB +Mapped: 89160 kB +Shmem: 71892 kB +Slab: 31688 kB +SReclaimable: 14196 kB +SUnreclaim: 17492 kB +KernelStack: 2864 kB +PageTables: 5448 kB +NFS_Unstable: 0 kB +Bounce: 0 kB +WritebackTmp: 0 kB +CommitLimit: 4100496 kB +Committed_AS: 1886836 kB +VmallocTotal: 122880 kB +VmallocUsed: 68924 kB +VmallocChunk: 43084 kB +HardwareCorrupted: 0 kB +AnonHugePages: 0 kB +HugePages_Total: 0 +HugePages_Free: 0 +HugePages_Rsvd: 0 +HugePages_Surp: 0 +Hugepagesize: 2048 kB +DirectMap4k: 26616 kB +DirectMap2M: 882688 kB + + +when I launch kvm with Juniper Simulator, it crashed after 1minute. +all the command line is below +kvm 1-JunOS-10.2R1.8.img \ + -m 128 \ + -net nic,macaddr=00:50:56:C0:00:01 \ + -net tap \ + -net nic,macaddr=00:50:56:C0:00:02 \ + -net tap \ + -net nic,macaddr=00:50:56:C0:00:03 \ + -net tap \ + -net nic,macaddr=00:50:56:C0:00:04 \ + -net tap \ + -net nic,macaddr=00:50:56:C0:00:05 \ + -net tap \ + -net nic,macaddr=00:50:56:C0:00:06 \ + -net tap \ + -display curses + +of course I had loaded the kvm module +#modpro kvm +#modpro kvm-intel + +for more detials, see the srceenshot + + + +Please report this problem in the bug tracker of your Linux distribution instead. + diff --git a/results/classifier/zero-shot/108/all/1363641 b/results/classifier/zero-shot/108/all/1363641 new file mode 100644 index 000000000..e014da56c --- /dev/null +++ b/results/classifier/zero-shot/108/all/1363641 @@ -0,0 +1,311 @@ +permissions: 0.974 +graphic: 0.973 +semantic: 0.970 +device: 0.967 +socket: 0.965 +debug: 0.964 +PID: 0.964 +files: 0.963 +network: 0.960 +other: 0.956 +vnc: 0.948 +performance: 0.947 +KVM: 0.916 +boot: 0.904 + +Build of v2.1.0 fails on armv7l due to undeclared __NR_select + +After `make clean` and `git clean -x -f -d` `git checkout v2.1.0 && configure --prefix=/home/user/prefix-qemu-2.1.0 && make` fails due to missing declarations + + CC qemu-seccomp.o + qemu-seccomp.c:28:1: error: '__NR_select' undeclared here (not in a function) + qemu-seccomp.c:36:1: error: '__NR_mmap' undeclared here (not in a function) + qemu-seccomp.c:57:1: error: '__NR_getrlimit' undeclared here (not in a function) + qemu-seccomp.c:96:1: error: '__NR_time' undeclared here (not in a function) + GEN qmp-marshal.c + qemu-seccomp.c:186:1: error: '__NR_alarm' undeclared here (not in a function) + make: *** [qemu-seccomp.o] Error 1 + +Same errors for master 8b3030114a449e66c68450acaac4b66f26d91416. `configure`should not succeed for a failing build. `config.log` for v2.1.0 and 8b303011... attached. I'm building on a debian 7.6 chroot on Synology DSM 5.0. `uname -a` says `Linux diskstatation 3.2.40 #4493 SMP Thu Aug 21 21:43:02 CST 2014 armv7l GNU/Linux`. + + + + + +On 31 August 2014 13:06, Karl-Philipp Richter <email address hidden> wrote:. +> `configure`should not succeed for a failing build. + +Your compile failures are definitely bugs, but it isn't expected that +configure will detect all possible kinds of build failure +in advance. + +For what it's worth I always build on ARM as part of my +checks before merging things to master, so this issue isn't +"all armv7l builds are broken" but something more specific +(probably some optional bits of the build which my build +platform doesn't have the dependencies for.) + +> qemu-seccomp.c:186:1: error: '__NR_alarm' undeclared here (not in a function) +> make: *** [qemu-seccomp.o] Error 1 + +Ccing Eduardo for the seccomp compile issues. + +> + After installing some of the missing header files (-> configure should +> + fail at the right point with a good error message), i.e. `apt-get +> + install liblzo2-dev libbsd-dev syslinux-common libhwloc-dev librdmacm- +> + dev libsnappy-dev libibverbs-dev valgrind linux-headers-3.2.0-4-common` +> + I'm getting +> + +> + CC migration-rdma.o +> + migration-rdma.c: In function 'ram_chunk_start': +> + migration-rdma.c:523:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] + +This probably hasn't been tested on a 32 bit build system :-( + +I suggest you work around these bugs by passing configure +--disable-rdma --disable-seccomp while we fix things... + +thanks +-- PMM + + +(cc'ing Michael Hines who owns and knows the RDMA code) + +* Karl-Philipp Richter (<email address hidden>) wrote: +> ** Description changed: +> +> After `make clean` and `git clean -x -f -d` `git checkout v2.1.0 && +> configure --prefix=/home/user/prefix-qemu-2.1.0 && make` fails due to +> missing declarations +> +> CC qemu-seccomp.o +> qemu-seccomp.c:28:1: error: '__NR_select' undeclared here (not in a function) +> qemu-seccomp.c:36:1: error: '__NR_mmap' undeclared here (not in a function) +> qemu-seccomp.c:57:1: error: '__NR_getrlimit' undeclared here (not in a function) +> qemu-seccomp.c:96:1: error: '__NR_time' undeclared here (not in a function) +> GEN qmp-marshal.c +> qemu-seccomp.c:186:1: error: '__NR_alarm' undeclared here (not in a function) +> make: *** [qemu-seccomp.o] Error 1 +> +> Same errors for master 8b3030114a449e66c68450acaac4b66f26d91416. +> `configure`should not succeed for a failing build. `config.log` for +> v2.1.0 and 8b303011... attached. The content is mostly compiler output +> which I think is unusual for `config.log`, but see for yourself. +> +> I'm building on a debian 7.6 chroot on Synology DSM 5.0. `uname -a` says +> `Linux diskstatation 3.2.40 #4493 SMP Thu Aug 21 21:43:02 CST 2014 +> armv7l GNU/Linux`. +> + +> + After installing some of the missing header files (-> configure should +> + fail at the right point with a good error message), i.e. `apt-get +> + install liblzo2-dev libbsd-dev syslinux-common libhwloc-dev librdmacm- +> + dev libsnappy-dev libibverbs-dev valgrind linux-headers-3.2.0-4-common` +> + I'm getting +> + +> + CC migration-rdma.o +> + migration-rdma.c: In function 'ram_chunk_start': +> + migration-rdma.c:523:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] + +is that: + return (uint8_t *) (((uintptr_t) rdma_ram_block->local_host_addr) + + (i << RDMA_REG_CHUNK_SHIFT)); + +244: uint8_t *local_host_addr; /* local virtual address */ + +in which case I think the problem is the 'i' which is a uint64_t. + +> + migration-rdma.c: In function '__qemu_rdma_add_block': +> + migration-rdma.c:556:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c:557:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] + +> + migration-rdma.c: In function '__qemu_rdma_delete_block': +> + migration-rdma.c:664:45: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c:699:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c: In function 'qemu_rdma_search_ram_block': +> + migration-rdma.c:1113:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c: In function 'qemu_rdma_register_and_get_keys': +> + migration-rdma.c:1176:50: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + migration-rdma.c:1177:29: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + migration-rdma.c:1177:51: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + migration-rdma.c:1178:29: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + migration-rdma.c: In function 'qemu_rdma_post_send_control': +> + migration-rdma.c:1562:36: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + migration-rdma.c: In function 'qemu_rdma_post_recv_control': +> + migration-rdma.c:1616:37: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + migration-rdma.c: In function 'qemu_rdma_write_one': +> + migration-rdma.c:1864:16: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + migration-rdma.c:1868:53: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c:1922:52: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c:1923:50: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c:1977:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c:1998:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c:2010:58: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> + migration-rdma.c: In function 'qemu_rdma_registration_handle': +> + migration-rdma.c:3027:21: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + migration-rdma.c:3092:41: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> + cc1: all warnings being treated as errors +> + make: *** [migration-rdma.o] Error 1 + +There's lots of stuff there; I think it's one for Michael because it involves understanding the structures +and which ones get passed over the wire etc. +(The quick fix would probably to guard the RDMA configure with a test for 32bit pointers) + +Dave + +> + +> + i.e. earlier errors than before. +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1363641 +> +> Title: +> Build of v2.1.0 fails on armv7l due to undeclared __NR_select +> +> Status in QEMU: +> New +> +> Bug description: +> After `make clean` and `git clean -x -f -d` `git checkout v2.1.0 && +> configure --prefix=/home/user/prefix-qemu-2.1.0 && make` fails due to +> missing declarations +> +> CC qemu-seccomp.o +> qemu-seccomp.c:28:1: error: '__NR_select' undeclared here (not in a function) +> qemu-seccomp.c:36:1: error: '__NR_mmap' undeclared here (not in a function) +> qemu-seccomp.c:57:1: error: '__NR_getrlimit' undeclared here (not in a function) +> qemu-seccomp.c:96:1: error: '__NR_time' undeclared here (not in a function) +> GEN qmp-marshal.c +> qemu-seccomp.c:186:1: error: '__NR_alarm' undeclared here (not in a function) +> make: *** [qemu-seccomp.o] Error 1 +> +> Same errors for master 8b3030114a449e66c68450acaac4b66f26d91416. +> `configure`should not succeed for a failing build. `config.log` for +> v2.1.0 and 8b303011... attached. The content is mostly compiler output +> which I think is unusual for `config.log`, but see for yourself. +> +> I'm building on a debian 7.6 chroot on Synology DSM 5.0. `uname -a` +> says `Linux diskstatation 3.2.40 #4493 SMP Thu Aug 21 21:43:02 CST +> 2014 armv7l GNU/Linux`. +> +> After installing some of the missing header files (-> configure should +> fail at the right point with a good error message), i.e. `apt-get +> install liblzo2-dev libbsd-dev syslinux-common libhwloc-dev librdmacm- +> dev libsnappy-dev libibverbs-dev valgrind linux- +> headers-3.2.0-4-common` I'm getting +> +> CC migration-rdma.o +> migration-rdma.c: In function 'ram_chunk_start': +> migration-rdma.c:523:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c: In function '__qemu_rdma_add_block': +> migration-rdma.c:556:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c:557:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c: In function '__qemu_rdma_delete_block': +> migration-rdma.c:664:45: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c:699:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c: In function 'qemu_rdma_search_ram_block': +> migration-rdma.c:1113:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c: In function 'qemu_rdma_register_and_get_keys': +> migration-rdma.c:1176:50: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> migration-rdma.c:1177:29: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> migration-rdma.c:1177:51: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> migration-rdma.c:1178:29: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> migration-rdma.c: In function 'qemu_rdma_post_send_control': +> migration-rdma.c:1562:36: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> migration-rdma.c: In function 'qemu_rdma_post_recv_control': +> migration-rdma.c:1616:37: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> migration-rdma.c: In function 'qemu_rdma_write_one': +> migration-rdma.c:1864:16: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> migration-rdma.c:1868:53: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c:1922:52: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c:1923:50: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c:1977:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c:1998:49: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c:2010:58: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> migration-rdma.c: In function 'qemu_rdma_registration_handle': +> migration-rdma.c:3027:21: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> migration-rdma.c:3092:41: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] +> cc1: all warnings being treated as errors +> make: *** [migration-rdma.o] Error 1 +> +> i.e. earlier errors than before. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1363641/+subscriptions +> +-- +Dr. David Alan Gilbert / <email address hidden> / Manchester, UK + + +On 23 September 2014 09:25, Michael R. Hines <email address hidden> wrote: + +> I could use some advice from the community on this: In particular, I have +> *zero* 32-bit machine to +> fix this on........ now, I could easily create a 32-bit machine, but I +> simply don't have any RDMA hardware +> for which to run the 32-bit virtual machine against. +> +> So, what are my options? Can I just submit a patch that completely disables +> RDMA in 32-bit environments? + +That's probably better than failing to compile. You might want to +at least shake out the compile errors so you can figure out if +your protocol itself has word-size issues or if it's just the +implementation that needs fixing. + +I assume there's nothing inherent to RDMA that mandates 64 bit... + +-- PMM + + +The fix for the syscalls problem is already upstream at libseccomp [0] . The maintainer said he has no plans yet to make a new release, though. + +[0] -- http://sourceforge.net/p/libseccomp/mailman/libseccomp-discuss/thread/1661272.9kVko5ssCn%40sifl/#msg32956301 + +On 22 October 2014 08:31, Eduardo Otubo <email address hidden> wrote: +> The fix for the syscalls problem is already upstream at libseccomp [0] . +> The maintainer said he has no plans yet to make a new release, though. + +Then you're going to have to put a fix of some kind locally +into QEMU. I don't want to release 2.2 with basic compile +errors like this on some hosts. If seccomp only supports +specific architectures you should probably enforce this in +configure. + +I couldn't identify from your mailing list link what upstream +is proposing to fix this bug either -- could you point me at +the specific changes that they have in mind? + +thanks +-- PMM + + +This commit temporarily fixes this problem. + +http://git.qemu.org/?p=qemu.git;a=commit;h=4cc47f8b3cc4f32586ba2f7fce1dc267da774a69 + +As soon as libseccomp makes a new release I'll update the dependency and hopefully it will be fixed with proper library support. + +Hi Eduardo - your above commit doesn't update the version in the error message (a few lines below, still says >= 2.1.0). +Sorry if this isn't the right place to comment on your patch, but it would be nice to fix (just spent a while trying to figure out why having 2.1.0 installed wasn't satisfying the configure check). + +Also, I think the way the if statement is constructed it will not properly apply the 2.1.1 version check for i386 (only for x86_64). + +Hello Ben, you're completely right on what regards the version on the error message. I'll fix it as soon as possible. Sorry for the trouble on that :( (and sorry for the late reply I was on vacations) + +Regarding the if statement, as Peter said here -- http://lists.gnu.org/archive/html/qemu-devel/2014-11/msg00960.html -- shell evaluates the OR before the AND, so that's Ok. + +Thanks. + +Hello Ben, I just submitted a pull request to fix the issue you reported: + +http://lists.gnu.org/archive/html/qemu-devel/2014-12/msg03134.html + +Thanks again. + +Libseccomp 2.2.0 is now released, can you please try the attached patch and check if it works for you? Regards. + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=8e27fc200457e3f2473d00 + diff --git a/results/classifier/zero-shot/108/all/1364501 b/results/classifier/zero-shot/108/all/1364501 new file mode 100644 index 000000000..443a1a5c1 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1364501 @@ -0,0 +1,160 @@ +files: 0.992 +permissions: 0.991 +debug: 0.991 +performance: 0.991 +other: 0.990 +socket: 0.990 +device: 0.989 +boot: 0.987 +PID: 0.987 +graphic: 0.986 +semantic: 0.985 +vnc: 0.985 +KVM: 0.973 +network: 0.971 + +Gdb hangs when trying to single-step after an invalid instruction + +When using Gdb to remote-debug a program and manually setting its PC to point to an address containing an invalid instruction, then doing a single step Qemu will never return control to the remote Gdb. + +For instance, let's say address 0x114 contains an invalid instruction. On the remote Gdb, we'd do: + +(gdb) set $pc = 0x114 +(gdb) stepi + +After doing that we won't get the (gdb) prompt unless we do a Ctrl-C. If we do so we'll be left at 0x114 instead of going towards the exception handler as we should. This happens with stepi, step and next. If instead of single-stepping we used continue, the program will proceed into the exception handler as it should. + +The reason this is happening is that when Qemu realizes it's about to translate an instruction it doesn't recognize it'll generate a call to helper_exception_with_syndrome(), which will register the exception and then call cpu_loop_exit(). At the same time, because we're doing a single-step, Qemu will also generate a call to helper_exception_internal() passing it an EXCP_DEBUG, which lets the system know it'll give control back to the remote debugger, and it also ends with a call to cpu_loop_exit(). However, because the syndrome exception calls cpu_loop_exit() first, the call to the internal exception won't be reached and Qemu will be stuck in a loop without returning control to the remote debugger. + +What makes this a bit tricky to fix is that we must call cpu_loop_exit() at the end of helper_exception_with_syndrome(), otherwise the target exception will go undetected and its handler won't be excecuted. + +Tested on latest head by emulating a Stellaris lm3s6965 board and running RTEMS 4.11: + +$ qemu-system-arm -nographic -s -S -M lm3s6965evb -kernel my_rtems_app + +Commit hash in qemu.git: 30eaca3acdf17d7bcbd1213eb149c02037edfb0b + +On 2 September 2014 17:38, martin <email address hidden> wrote: +> Public bug reported: +> +> When using Gdb to remote-debug a program and manually setting its PC to +> point to an address containing an invalid instruction and then doing a +> single step, Qemu will never return control to the remote Gdb. +> +> For instance, let's say address 0x114 contains an invalid instruction. +> On the remote Gdb, we'd do: +> +> (gdb) set $pc = 0x114 +> (gdb) stepi +> +> After doing that we won't get the (gdb) prompt unless we do a Ctrl-C. If +> we do so we'll be left at 0x114 instead of going towards the exception +> handler as we should. This happens with stepi, step and next. If instead +> of single-stepping we used continue, the program will proceed into the +> exception handler as it should. +> +> The reason this is happening is that when Qemu realizes it's about to +> translate an instruction it doesn't recognize it'll generate a call to +> helper_exception_with_syndrome(), which will register the exception and +> then call cpu_loop_exit(). At the same time, because we're doing a +> single-step, Qemu will also generate a call to +> helper_exception_internal() passing it an EXCP_DEBUG, which lets the +> system know it'll give control back to the remote debugger, and it also +> ends with a call to cpu_loop_exit(). However, because the syndrome +> exception calls cpu_loop_exit() first, the call to the internal +> exception won't be reached and Qemu will be stuck in a loop without +> returning control to the remote debugger. + +Just to check, does your system image include a valid handler +for the undef exception? I'm wondering if we really never return +control in all cases, or only if we get stuck in an infinite loop +of exceptions beacuse the exception handler's first instruction +causes an exception which causes an exception which... + +> What makes this a bit tricky to fix is that we must call cpu_loop_exit() +> at the end of helper_exception_with_syndrome(), otherwise the target +> exception will go undetected and its handler won't be excecuted. + +I suspect there are actually more general issues with the interaction +of single-stepping with exceptions. See also +https://bugs.launchpad.net/qemu/+bug/757702 which is a report +that singlestepping an invalid instruction stops on the insn after +the first one in the UNDEF handler rather than before it. + +thanks +-- PMM + + +>> Public bug reported: +>> +>> When using Gdb to remote-debug a program and manually setting its PC to +>> point to an address containing an invalid instruction and then doing a +>> single step, Qemu will never return control to the remote Gdb. +>> +>> For instance, let's say address 0x114 contains an invalid instruction. +>> On the remote Gdb, we'd do: +>> +>> (gdb) set $pc = 0x114 +>> (gdb) stepi +>> +>> After doing that we won't get the (gdb) prompt unless we do a Ctrl-C. If +>> we do so we'll be left at 0x114 instead of going towards the exception +>> handler as we should. This happens with stepi, step and next. If instead +>> of single-stepping we used continue, the program will proceed into the +>> exception handler as it should. +>> +>> The reason this is happening is that when Qemu realizes it's about to +>> translate an instruction it doesn't recognize it'll generate a call to +>> helper_exception_with_syndrome(), which will register the exception and +>> then call cpu_loop_exit(). At the same time, because we're doing a +>> single-step, Qemu will also generate a call to +>> helper_exception_internal() passing it an EXCP_DEBUG, which lets the +>> system know it'll give control back to the remote debugger, and it also +>> ends with a call to cpu_loop_exit(). However, because the syndrome +>> exception calls cpu_loop_exit() first, the call to the internal +>> exception won't be reached and Qemu will be stuck in a loop without +>> returning control to the remote debugger. +> +> Just to check, does your system image include a valid handler +> for the undef exception? + +Yes, it does. RTEMS sets a default handler for every exception, and just to be sure I added a bunch of small wrappers so I'll be able to know what kind of exception are we dealing with. + +Notice there are actually two sides to this problem: not only the internal exception instruction isn't being processed, but also when we go back to the cpu_exec loop the syndrome exception won't have any actual effect since we won't compute the new PC we need in order to jump to the exception handler. This happens because of this (at cpu-exec.c:437): + +if (unlikely(cpu->singlestep_enabled & SSTEP_NOIRQ)) { + /* Mask out external interrupts for this step. */ + interrupt_request &= ~CPU_INTERRUPT_SSTEP_MASK; + } + +Because of that, the interrupt request corresponding to our exception will be ignored and we won't call do_interrupt() as we go on within the loop. Thus, the PC will remain the same as before because of the very fact we're single stepping. + +I've found a (very ugly) workaround to this bug by commenting out that line and taking advantage of the fact that env->exception.syndrome isn't cleansed so that when we try to excecute the syndrome exception instruction for the 2nd time it'll notice the syndrome value is the same as before, zero it and procedd without calling cpu_loop_exit(). + +Right now my question is: do we *really* have to mask out external interrupts when single-stepping? Even if I found a better way to get the internal exception to excecute, I'd still have to get past that check in order to get the correct PC value. + +Just wanted to add: after doing some testing, it seems that if we simply don't mask out external interrupts when single-stepping we don't even need to do the syndrome value check. As the interrupt corresponding to the syndrome exception won't be masked, it'll correctly compute the new PC in do_interrupt() and when we proceed through the cpu_exec() loop we'll be generating a new translation block which will also have a call to the internal exception, as we're still in single-step mode. + +The end result is that single-stepping an invalid instruction will lead us to the first instruction of our interrupt handler (at least on ARMv7M, whose vector table only has the addresses of the handlers instead of branch instructions - perhaps on other CPUs it'll be a bit different). + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I honestly don't know, since it's been so long. I'm guessing that if +the code hasn't been touched the issue is still there. In any case, I +don't think this should be closed without you (or anyone, really) +trying to reproduce it again. I posted a detailed explanation of why +the bug happens, so you can even just do some code inspection. + + +[Expired for QEMU because there has been no activity for 60 days.] + +This shouldn't be "Expired", since the bug is likely still there. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/105 + + diff --git a/results/classifier/zero-shot/108/all/1366 b/results/classifier/zero-shot/108/all/1366 new file mode 100644 index 000000000..569ec15b2 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1366 @@ -0,0 +1,99 @@ +performance: 0.986 +permissions: 0.986 +device: 0.986 +graphic: 0.983 +debug: 0.979 +files: 0.979 +other: 0.977 +semantic: 0.977 +socket: 0.975 +PID: 0.972 +vnc: 0.970 +KVM: 0.953 +network: 0.950 +boot: 0.946 + +Data inconsistency on LVM logical volume mounted as partition on ubuntu guest, when the written file's size is equal or greater than 27G. +Description of problem: +On the guest, writing a 27Gib file or larger result in inconsistent file checksum upon subsequent read. +Steps to reproduce: +**On the host** + +0. Create a LVM logical volume on a Linux RAID 1 (with 1 disk only) + +``` + --- Logical volume --- + LV Path /dev/davidahw2-vg4/lv0 + LV Name lv0 + VG Name davidahw2-vg4 + LV UUID 5FbDcl-eSDe-7cXL-22tj-Lg6O-79AL-4Gq7gx + LV Write Access read/write + LV Creation host, time davida-hw2, 2021-12-06 16:45:00 +0800 + LV Status available + # open 1 + LV Size <7.28 TiB + Current LE 1907688 + Segments 1 + Allocation inherit + Read ahead sectors auto + - currently set to 256 + Block device 253:4 + + --- Segments --- + Logical extents 0 to 1907687: + Type linear + Physical volume /dev/md4 + Physical extents 0 to 1907687 +``` + +1. Format the logical volume as ext4 + +``` +mkfs -t ext4 /dev/davidahw2-vg4/lv0 +``` + +2. Create a libvirt x86 64bits Ubuntu 22.04 machine mounting a LVM logical volume + +``` +<controller type='scsi' index='1' model='virtio-scsi'><driver queues='8' iothread='2'/></controller> + + +<disk type='block' device='disk'> + <driver name='qemu' type='raw'/> + <source dev='/dev/davidahw2-vg4/lv0'/> + <target dev='sdd' bus='scsi'/> + <blockio logical_block_size='512' physical_block_size='4096'/> + <address type='drive' controller='1' bus='0' target='1' unit='0'/> +</disk> +``` + + +**On the guest** + +3. Mount libvirt/qemu provided block device /dev/sdd as ext4 partition + +``` +mount /dev/sdd /mnt/test +``` + +4. Write **27G file** or larger **on the guest** causing the **2nd checksum to be different** + +``` +sync; head -c 27G </dev/urandom >myfile; sha256sum myfile; sha256sum myfile +8d3b4b263961d2c510390f99879be89b4b9134dc588139ede75573be1590115b myfile +a8e886b3c39d9b4721e582c5e2ca25c76ff6561750ac6dc7aa7e70404661d1cf myfile <== ERROR: Inconsistent checksum +``` + +5. Write **26G file** or larger **on the guest** and **both checksum are the same** + +``` +sync; head -c 26G </dev/urandom >myfile; sha256sum myfile; sha256sum myfile +598ac5da9b5bfa14d0ee664ae2590e09da772cba64cbc83ec049a656223c9401 myfile +598ac5da9b5bfa14d0ee664ae2590e09da772cba64cbc83ec049a656223c9401 myfile <== CORRECT: Consistent checksum +``` + +**Important**: +- With the VM shutdown, the same commands on the same mounted ext4 partition **on the host** has consistent checksum every time for file sizes from 20G to 40G. +- The disk has no sign of failure (no badblocks reported to the filesystem, MD raid reports a healthy raid setup, smart reports on error) +Additional information: + diff --git a/results/classifier/zero-shot/108/all/1399 b/results/classifier/zero-shot/108/all/1399 new file mode 100644 index 000000000..060463393 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1399 @@ -0,0 +1,87 @@ +other: 0.978 +permissions: 0.978 +vnc: 0.977 +device: 0.973 +debug: 0.972 +semantic: 0.971 +boot: 0.969 +files: 0.967 +socket: 0.966 +network: 0.964 +performance: 0.963 +PID: 0.963 +KVM: 0.962 +graphic: 0.959 + +Early faults when direct booting large Linux kernel images on x86_64 and aarch64 guests. +Description of problem: +When attempting to load a Linux kernel image for direct boot via the `-kernel` command line option, a triple fault occurs shortly after attempting to hand off execution to the kernel if the kernel image is ‘large’ in size (this can be easily reproduced with a custom kernel build by embedding an initramfs in the kernel that includes a few large but mostly incompressible files). I’m not certain of the exact cutoff, but a 75 MB kernel image on x86_64, and a 67 MB kernel image on AArch64 both exhibit the issue, while a 13 MB kernel image on x86_64 does not. +Steps to reproduce: +1. Attempt to direct boot an exceptionally large kernel image as an x86_64 or aarch64 guest. +Additional information: +I have not yet been able to track down exactly where the initial fault is happening, and am not even certain that it’s in Linux’s early boot code, but the fact that this is reproducible across multiple architectures and is unaffected by things like KASLR and the exact compression algorithm for the guest kernel suggests to me that it’s more likely to be an issue in QEMU’s loader code for direct kernel boot than in the Linux kernel itself. + +Running on x86_64, the initial fault appears to be a general protection fault, followed by a double and then triple fault. Output from running QEMU as above with `-d int,guest_error -no-reboot’: + +``` +check_exception old: 0xffffffff new 0xd + 0: v=0d e=0000 i=0 cpl=0 IP=0010:000000000789f7f0 pc=000000000789f7f0 SP=0018:00000000078e6fd8 env->regs[R_EAX]=0000000000000000 +RAX=0000000000000000 RBX=6fb84fe3052f53e2 RCX=00000000fb600000 RDX=00000000078fbed0 +RSI=00000000078f6000 RDI=00000000078e80e0 RBP=00000000078e80e0 RSP=00000000078e6fd8 +R8 =00000000078fb000 R9 =00000000fb600000 R10=000fffffffe00000 R11=0000000000000000 +R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000 +RIP=000000000789f7f0 RFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 00000000 00000000 +CS =0010 0000000000000000 ffffffff 00af9a00 DPL=0 CS64 [-R-] +SS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0000 0000000000000000 00000000 00000000 +GS =0000 0000000000000000 00000000 00000000 +LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT +TR =0020 0000000000000000 00000fff 00808900 DPL=0 TSS64-avl +GDT= 00000000078b1030 0000002f +IDT= 00000000078b1070 000001ff +CR0=80050033 CR2=6fb84fe3052f53ee CR3=00000000078f6000 CR4=00000020 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=0000000000000018 CCD=6fb84fe3052f53e2 CCO=LOGICQ +EFER=0000000000000500 +check_exception old: 0xd new 0xd + 1: v=08 e=0000 i=0 cpl=0 IP=0010:000000000789f7f0 pc=000000000789f7f0 SP=0018:00000000078e6fd8 env->regs[R_EAX]=0000000000000000 +RAX=0000000000000000 RBX=6fb84fe3052f53e2 RCX=00000000fb600000 RDX=00000000078fbed0 +RSI=00000000078f6000 RDI=00000000078e80e0 RBP=00000000078e80e0 RSP=00000000078e6fd8 +R8 =00000000078fb000 R9 =00000000fb600000 R10=000fffffffe00000 R11=0000000000000000 +R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000 +RIP=000000000789f7f0 RFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 00000000 00000000 +CS =0010 0000000000000000 ffffffff 00af9a00 DPL=0 CS64 [-R-] +SS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0000 0000000000000000 00000000 00000000 +GS =0000 0000000000000000 00000000 00000000 +LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT +TR =0020 0000000000000000 00000fff 00808900 DPL=0 TSS64-avl +GDT= 00000000078b1030 0000002f +IDT= 00000000078b1070 000001ff +CR0=80050033 CR2=6fb84fe3052f53ee CR3=00000000078f6000 CR4=00000020 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=0000000000000018 CCD=6fb84fe3052f53e2 CCO=LOGICQ +EFER=0000000000000500 +check_exception old: 0x8 new 0xd +``` + +Running on AArch64, the emulated CPU gets stuck in a loop trying to handle ‘exception 5’, showing the following output when run as above with `-d int, guest_error -no-reboot`, repeated infinitely until the emulator gets killed: + +``` +Taking exception 5 [IRQ] on CPU 0 +...from EL1 to EL1 +...with ESR 0x15/0x56000000 +...with ELR 0xffffffef0dee4098 +...to EL1 PC 0xffffffef0d810a80 PSTATE 0x3c5 +Exception return from AArch64 EL1 to AArch64 EL1 PC 0xffffffef0dee4098 +``` + +I have also attempted to reproduce this on 64-bit little-endian POWER using qemu-system-ppc64 and an equivalent kernel config, and was _not_ able to reproduce it there with a 69 MB kernel image. + +I can provide Linux kernel configs for the affected kernels upon request, but am not (currently) able to provide full system images (the project I was working on when I came across this is not yet public). diff --git a/results/classifier/zero-shot/108/all/1400768 b/results/classifier/zero-shot/108/all/1400768 new file mode 100644 index 000000000..8f5c30c93 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1400768 @@ -0,0 +1,149 @@ +other: 0.978 +graphic: 0.971 +permissions: 0.965 +semantic: 0.963 +debug: 0.961 +device: 0.956 +socket: 0.955 +performance: 0.948 +PID: 0.947 +files: 0.945 +network: 0.944 +boot: 0.941 +KVM: 0.935 +vnc: 0.931 + +Fatal error when running with '-machine isapc' on 2.1.2 + +all I have are the traces, should hopefully be easy to reproduce. + +# qemu-system-i386 -machine isapc +VNC server running on `::1:5900' +qemu: fatal: Trying to execute code outside RAM or ROM at 0x1a0dff44 + +EAX=000f0f88 EBX=00100000 ECX=07fc0000 EDX=0000002c +ESI=00006f5c EDI=08000000 EBP=07fc0000 ESP=fffe0014 +EIP=1a0dff44 EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9b00 DPL=0 CS32 [-RA] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 000f6be8 00000037 +IDT= 000f6c26 00000000 +CR0=60000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000000 CCD=00000000 CCO=ADDB +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 +Aborted + + +# qemu-system-x86_64 -machine isapc +VNC server running on `::1:5900' +qemu: fatal: Trying to execute code outside RAM or ROM at 0x000000001a0dff44 + +EAX=000f0f88 EBX=00100000 ECX=07fc0000 EDX=0000002c +ESI=00006f5c EDI=08000000 EBP=07fc0000 ESP=fffe0014 +EIP=1a0dff44 EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9b00 DPL=0 CS32 [-RA] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 000f6be8 00000037 +IDT= 000f6c26 00000000 +CR0=60000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=ADDB +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 +Aborted + +Hello, + + I too have the same results. + Below is an additional snippet where the call is made through valgrind. + + While valgrind grinds, the SDL window displays "Guest has not initialized the display (yet)." + +==16648== Memcheck, a memory error detector +==16648== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. +==16648== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info +==16648== Command: qemu-system-i386 -machine isapc -fda bootdisk.img +==16648== +qemu: fatal: Trying to execute code outside RAM or ROM at 0x1a0dff44 + +EAX=000f0f88 EBX=00100000 ECX=07fc0000 EDX=0000002c +ESI=00006f5c EDI=08000000 EBP=07fc0000 ESP=fffe0014 +EIP=1a0dff44 EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9b00 DPL=0 CS32 [-RA] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 000f6be8 00000037 +IDT= 000f6c26 00000000 +CR0=60000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000000 CCD=00000000 CCO=ADDB +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 +==16648== +==16648== HEAP SUMMARY: +==16648== in use at exit: 36,820,878 bytes in 32,195 blocks +==16648== total heap usage: 198,107 allocs, 165,912 frees, 1,828,399,692 bytes allocated +==16648== +==16648== LEAK SUMMARY: +==16648== definitely lost: 8,462 bytes in 29 blocks +==16648== indirectly lost: 55,605 bytes in 1,550 blocks +==16648== possibly lost: 316,286 bytes in 773 blocks +==16648== still reachable: 36,304,789 bytes in 29,208 blocks +==16648== suppressed: 0 bytes in 0 blocks +==16648== Rerun with --leak-check=full to see details of leaked memory +==16648== +==16648== For counts of detected and suppressed errors, rerun with: -v +==16648== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) +Killed + + + +Testing this with QEMU 2.5 (and also with today's head-of-git) "qemu-system_x86-64 -machine isapc" works for me (it boots the guest bios). So I'm going to close this bug as fixed; please open a fresh bug if you still have problems with a more recent QEMU version. + + diff --git a/results/classifier/zero-shot/108/all/1407454 b/results/classifier/zero-shot/108/all/1407454 new file mode 100644 index 000000000..6e574158d --- /dev/null +++ b/results/classifier/zero-shot/108/all/1407454 @@ -0,0 +1,103 @@ +other: 0.985 +debug: 0.979 +performance: 0.973 +semantic: 0.972 +permissions: 0.969 +PID: 0.968 +socket: 0.967 +graphic: 0.965 +boot: 0.963 +vnc: 0.960 +files: 0.959 +device: 0.958 +KVM: 0.957 +network: 0.956 + +assertion failed when using "-usb" option + +SUMMARY: +---------- +Description: Latest 'master' makes it impossible to use "-usb" command line on any target +Host platform: Linux x86-64 +Guest platform: probably all (at least x86-64, i386, arm and ppc) + +REPRODUCE: +---------- +How to reproduce: +1. Run the following command: +$ qemu-system-x86_64 -usb + +Expected result: +Starting virtual machine with empty configuration + +Actual result: +Qemu crashes with following message: + +qemu-system-x86_64: /home/mplucinski/Developer/Open_Source/qemu/qemu.git/util/qemu-option.c:387: qemu_opt_get_bool_helper: Assertion `opt->desc && opt->desc->type == QEMU_OPT_BOOL' failed. +Aborted + +MORE INFORMATION: +---------- +Same happens when trying to run other target, e.g. +$ qemu-system-i386 -usb +$ qemu-system-arm -machine kmz -usb + +First commit where the issue occurs (bisection result): 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 + +Also, very similar symptoms are described in #1406706, so it is possible that they are related. + +Could you test this? + +Signed-off-by: Tiejun Chen <email address hidden> +--- + util/qemu-option.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/util/qemu-option.c b/util/qemu-option.c +index a708241..7cb3601 100644 +--- a/util/qemu-option.c ++++ b/util/qemu-option.c +@@ -377,7 +377,7 @@ static bool qemu_opt_get_bool_helper(QemuOpts *opts, const char *name, + } + + opt = qemu_opt_find(opts, name); +- if (opt == NULL) { ++ if ((opt == NULL) || !opt->desc) { + const QemuOptDesc *desc = find_desc_by_name(opts->list->desc, name); + if (desc && desc->def_value_str) { + parse_option_bool(name, desc->def_value_str, &ret, &error_abort); +-- + +On Mon, Jan 5, 2015 at 5:48 AM, Tiejun Chen <email address hidden> wrote: +> Could you test this? +> +> Signed-off-by: Tiejun Chen <email address hidden> +> --- +> util/qemu-option.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/util/qemu-option.c b/util/qemu-option.c +> index a708241..7cb3601 100644 +> --- a/util/qemu-option.c +> +++ b/util/qemu-option.c +> @@ -377,7 +377,7 @@ static bool qemu_opt_get_bool_helper(QemuOpts *opts, const char *name, +> } +> +> opt = qemu_opt_find(opts, name); +> - if (opt == NULL) { +> + if ((opt == NULL) || !opt->desc) { +> const QemuOptDesc *desc = find_desc_by_name(opts->list->desc, name); +> if (desc && desc->def_value_str) { +> parse_option_bool(name, desc->def_value_str, &ret, &error_abort); + +This doesn't work because it discards the usb=on|off value that was +set on the command-line. + +I will send a fix. + +Stefan + + +This no longer asserts; I think Stefan fixed this and that fix is now in a release. + + diff --git a/results/classifier/zero-shot/108/all/1408 b/results/classifier/zero-shot/108/all/1408 new file mode 100644 index 000000000..f36e434b5 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1408 @@ -0,0 +1,102 @@ +other: 0.989 +permissions: 0.984 +device: 0.982 +debug: 0.981 +semantic: 0.981 +files: 0.980 +performance: 0.976 +boot: 0.976 +PID: 0.975 +socket: 0.975 +vnc: 0.973 +graphic: 0.971 +KVM: 0.967 +network: 0.960 + +Out of bounds in imx_usbphy_read() +Description of problem: +The size of the memory region of imx-usb-phy is 0x1000. + +``` +memory_region_init_io(&s->iomem, OBJECT(s), &imx_usbphy_ops, s, + "imx-usbphy", 0x1000); +``` + +A read to s->usbphy[33] will easily overflow. + +``` +static uint64_t imx_usbphy_read(void *opaque, hwaddr offset, unsigned size) +{ + // ... + default: + value = s->usbphy[index]; + break; + } +``` + +Maybe we should drop this read in default branch. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-arm + +cat << EOF | $QEMU \ +-machine sabrelite -monitor none -serial none \ +-display none -nodefaults -qtest stdio +readl 0x20c9870 +EOF +``` +Additional information: +``` ++ DEFAULT_INPUT_MAXSIZE=10000000 ++ ./qemu-videzzo-arm-target-videzzo-fuzz-imx-usb-phy -max_len=10000000 -detect_leaks=0 ./crash-2f5e9c8ec69dd69f8db69aaa84dde878482b8690.minimized +==14370==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x561837db1240). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 1679742864 +INFO: Loaded 1 modules (583356 inline 8-bit counters): 583356 [0x56183b151000, 0x56183b1df6bc), +INFO: Loaded 1 PC tables (583356 PCs): 583356 [0x56183a86a3b0,0x56183b150f70), +./qemu-videzzo-arm-target-videzzo-fuzz-imx-usb-phy: 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 , *imx-usbphy* +This process will fuzz the following MemoryRegions: + * imx-usbphy[0] (size 1000) + * imx-usbphy[0] (size 1000) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * imx-usbphy, EVENT_TYPE_MMIO_READ, 0x20c9000 +0x1000, 4,4 + * imx-usbphy, EVENT_TYPE_MMIO_WRITE, 0x20c9000 +0x1000, 4,4 + * imx-usbphy, EVENT_TYPE_MMIO_READ, 0x20ca000 +0x1000, 4,4 + * imx-usbphy, EVENT_TYPE_MMIO_WRITE, 0x20ca000 +0x1000, 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: 222Mb +Running: ./crash-2f5e9c8ec69dd69f8db69aaa84dde878482b8690.minimized +../hw/usb/imx-usb-phy.c:93:17: runtime error: index 540 out of bounds for type 'uint32_t [33]' + #0 0x5618357ddb2a in imx_usbphy_read /root/videzzo/videzzo_qemu/qemu/out-san/../hw/usb/imx-usb-phy.c:93:17 + #1 0x561836f07a0b in memory_region_read_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:441:11 + #2 0x561836ec6501 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18 + #3 0x561836ec38cc in memory_region_dispatch_read1 /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1425:16 + #4 0x561836ec3008 in memory_region_dispatch_read /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1458:9 + #5 0x561836f415ad in flatview_read_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2892:23 + #6 0x561836f42bb8 in flatview_read /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2934:12 + #7 0x561836f42678 in address_space_read_full /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2947:18 + #8 0x5618337f4b41 in address_space_read /root/videzzo/videzzo_qemu/qemu/include/exec/memory.h:2873:18 + #9 0x5618337f4b41 in qemu_readl /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1037:5 + #10 0x5618337f2c06 in dispatch_mmio_read /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1051:35 + #11 0x561837dac6bf in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5 + #12 0x561837da3a3d in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9 + #13 0x561837da37e4 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9 + #14 0x56183380a07c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12 + #15 0x561837db150b in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18 + #16 0x5618336ea806 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #17 0x5618336cd434 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #18 0x5618336d83de in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #19 0x5618336c49c6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #20 0x7f74d2914082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #21 0x5618336c4a1d in _start (/root/bugs/metadata/imx_usb_phy-00/qemu-videzzo-arm-target-videzzo-fuzz-imx-usb-phy+0x31cea1d) + +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/usb/imx-usb-phy.c:93:17 in +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +0x0,0x8,0x70,0x98,0xc,0x2,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0, +\x00\x08p\x98\x0c\x02\x00\x00\x00\x00\x04\x00\x00\x00 +``` diff --git a/results/classifier/zero-shot/108/all/1423124 b/results/classifier/zero-shot/108/all/1423124 new file mode 100644 index 000000000..33d254751 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1423124 @@ -0,0 +1,180 @@ +permissions: 0.980 +debug: 0.974 +PID: 0.968 +other: 0.964 +semantic: 0.963 +device: 0.963 +performance: 0.959 +graphic: 0.958 +socket: 0.957 +boot: 0.956 +vnc: 0.952 +network: 0.950 +files: 0.949 +KVM: 0.940 + +QEMU crash after sending data on host serial port + +Good morning, + +I'm using QEMU for Windows last version. +The host system is Windows 7 64bits. +I'm excuting the following statment : + +qemu-system-x86_64w.exe -hda debian.img -m 256 -net nic -net tap,ifname=TAP32 -soundhw all -serial COM9 + +Qemu starts the emulated Debian and it runs correctly. + +If I try to send data from Windows using COM9 to QEMU (both "real" or emulated by the COM0COM driver), QEMU crashes. Windows dump available if required. +If I try to send data to /dev/ttyS0 (that should be the Linux side of COM9) from Debian, again, the wirtual machine crashes. + +More details if necessary +Best regards +U.Poddine + +On Wed, Feb 18, 2015 at 11:29:58AM -0000, Ugo wrote: +> I'm using QEMU for Windows last version. +> The host system is Windows 7 64bits. +> I'm excuting the following statment : +> +> qemu-system-x86_64w.exe -hda debian.img -m 256 -net nic -net +> tap,ifname=TAP32 -soundhw all -serial COM9 +> +> Qemu starts the emulated Debian and it runs correctly. +> +> If I try to send data from Windows using COM9 to QEMU (both "real" or emulated by the COM0COM driver), QEMU crashes. Windows dump available if required. +> If I try to send data to /dev/ttyS0 (that should be the Linux side of COM9) from Debian, again, the wirtual machine crashes. + +Please post details of the crash including the backtrace. That might be +enough information for someone to figure out the problem and send a +patch to fix it. + + +Hello Stefan, + +the crash can be described better as a neverending loop started after having +received data on serial ports, infact for going out I'm forced to kill the QEMU +session from Windows. As result there is unfortunately no system dump in the +Windows dump folder. +I've tried to generate the backtrace with Windbg (attached), it shows +something before sending data to COM and after having killed the neverednding +loop, this in both cases : sending data from Windows to COM port (first +backtrace) and sending data from linux to /dev/pty port. +I'm afraid that the dumps are not so rich, due to the neverending loop problem +: I'm not able to debug better the situation. +Let me know if I can help more + +Regards +UP + + + +>----Messaggio originale---- +>Da: <email address hidden> +>Data: 23-feb-2015 11.32 +>A: <email address hidden> +>Ogg: Re: [Qemu-devel] [Bug 1423124] [NEW] QEMU crash after sending data on +host serial port +> +>On Wed, Feb 18, 2015 at 11:29:58AM -0000, Ugo wrote: +>> I'm using QEMU for Windows last version. +>> The host system is Windows 7 64bits. +>> I'm excuting the following statment : +>> +>> qemu-system-x86_64w.exe -hda debian.img -m 256 -net nic -net +>> tap,ifname=TAP32 -soundhw all -serial COM9 +>> +>> Qemu starts the emulated Debian and it runs correctly. +>> +>> If I try to send data from Windows using COM9 to QEMU (both "real" or +emulated by the COM0COM driver), QEMU crashes. Windows dump available if +required. +>> If I try to send data to /dev/ttyS0 (that should be the Linux side of COM9) +from Debian, again, the wirtual machine crashes. +> +>Please post details of the crash including the backtrace. That might be +>enough information for someone to figure out the problem and send a +>patch to fix it. +> +>-- +>You received this bug notification because you are subscribed to the bug +>report. +>https://bugs.launchpad.net/bugs/1423124 +> +>Title: +> QEMU crash after sending data on host serial port +> +>Status in QEMU: +> New +> +>Bug description: +> Good morning, +> +> I'm using QEMU for Windows last version. +> The host system is Windows 7 64bits. +> I'm excuting the following statment : +> +> qemu-system-x86_64w.exe -hda debian.img -m 256 -net nic -net +> tap,ifname=TAP32 -soundhw all -serial COM9 +> +> Qemu starts the emulated Debian and it runs correctly. +> +> If I try to send data from Windows using COM9 to QEMU (both "real" or +emulated by the COM0COM driver), QEMU crashes. Windows dump available if +required. +> If I try to send data to /dev/ttyS0 (that should be the Linux side of COM9) +from Debian, again, the wirtual machine crashes. +> +> More details if necessary +> Best regards +> U.Poddine +> +>To manage notifications about this bug go to: +>https://bugs.launchpad.net/qemu/+bug/1423124/+subscriptions +> + + +Hello, + +after having upgraded QEMU to the end-of-February release, the problem (still there) evolved. +Now there is no more a "nevereding loop", but QEMU crashes on stratup with the above described startup command : + +qemu-system-x86_64w.exe -hda debian.img -m 256 -net nic -net +> tap,ifname=TAP32 -soundhw all -serial COM9 + +Now it's easy to give you the Windows dump, attached. + +Regards +Ugo + +Hi All + +I also meet this issue. + I have two computer, one is Win7 32 another is Win7 64, Both computer meet this issue. +My QEMU version is qemu-w32-setup-20160215 + +I want used EDK2 OVMF with Intel UDK Debugger tools to do source level debug +I had install com0com Virtual Com Port, and set COM3 connect to COM4 + +Intel UDK Debugger tools used COM3 +QEMU run OVMF used COM4 + +First execute Intel UDK Debugger tools, then launch QEMU +C:\Program Files\qemu\qemu-system-x86_64.exe -bios "C:\EDK2\Build\OvmfX64\DEBUG_VS2010\FV\OVMF.fd" -serial COM4 +Then QEMU crashes on stratup + +I have do some experiment +Execute terminal tool Tera Term and used COM3 +launch QEMU and used COM4 +C:\Program Files\qemu\qemu-system-x86_64.exe -bios "C:\EDK2\Build\OvmfX64\DEBUG_VS2010\FV\OVMF.fd" -serial COM4 +This is fine and i can see OVMF trace log on terminal +But if i press "Down" key on terminal, then QEMU crashe +It's caused by terminal send data("Down" key) to QEMU + +Have somebody can share some information about this? + +Thanks a lot. +Sugar + +Looks like the bug still exists. Sending eg "CTRL+D" or Arrow up/down makes qemu hang indefinitely + diff --git a/results/classifier/zero-shot/108/all/1427 b/results/classifier/zero-shot/108/all/1427 new file mode 100644 index 000000000..f9d3177f2 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1427 @@ -0,0 +1,389 @@ +other: 0.991 +permissions: 0.986 +performance: 0.986 +debug: 0.984 +graphic: 0.983 +semantic: 0.981 +socket: 0.978 +files: 0.975 +PID: 0.975 +device: 0.975 +network: 0.971 +vnc: 0.969 +KVM: 0.967 +boot: 0.965 + +Fifo overflow in transfer_fifo() +Description of problem: +In transfer_fifo(), fifo32_push() fails since less than 32 bytes are free in the +fifo. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-aarch64 + +cat << EOF | $QEMU \ +-machine xlnx-zcu102 -monitor none -serial none \ +-display none -nodefaults -qtest stdio +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x554439e4 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x7439dad1 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x554439e4 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x7439dad1 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070030 0x5b33c2da +writel 0xff070004 0x6847773b +writel 0xff070030 0x5b33c2da +writel 0xff070000 0x7a9e77fa +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x0bbac0b1 +readl 0xff070054 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +writel 0xff070038 0x3730c1d8 +writel 0xff07003c 0x1f9c3bcd +EOF +``` +Additional information: +``` +==60953==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x55c4943a85f0). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 1771329340 +INFO: Loaded 1 modules (600781 inline 8-bit counters): 600781 [0x55c4979bb000, 0x55c497a4dacd), +INFO: Loaded 1 PC tables (600781 PCs): 600781 [0x55c49708fbf0,0x55c4979ba8c0), +./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can: 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 , *xlnx.zynqmp-can* +This process will fuzz the following MemoryRegions: + * xlnx.zynqmp-can[1] (size 84) + * xlnx.zynqmp-can[0] (size 84) + * xlnx.zynqmp-can[1] (size 84) + * xlnx.zynqmp-can[0] (size 84) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * xlnx.zynqmp-can, EVENT_TYPE_MMIO_READ, 0xff070000 +0x84, 4,4 + * xlnx.zynqmp-can, EVENT_TYPE_MMIO_WRITE, 0xff070000 +0x84, 4,4 + * xlnx.zynqmp-can, EVENT_TYPE_MMIO_READ, 0xff060000 +0x84, 4,4 + * xlnx.zynqmp-can, EVENT_TYPE_MMIO_WRITE, 0xff060000 +0x84, 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: 509Mb +Running: poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can-crash-8c83f08fb7643e6eb55af43e76de522c6f5fcef2.minimized.minimized +qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can: ../util/fifo8.c:34: void fifo8_push(Fifo8 *, uint8_t): Assertion `fifo->num < fifo->capacity' failed. +==60953== ERROR: libFuzzer: deadly signal + #0 0x55c48f86e0fe in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x55c48f7bcd71 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x55c48f795ca6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x55c48f795d72 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x55c48f795d72 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7fe36599541f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7fe3657a700a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7fe3657a700a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7fe365786858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7fe365786728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7fe365797fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x55c4941f98ef in fifo8_push /root/videzzo/videzzo_qemu/qemu/out-san/../util/fifo8.c:34:5 + #12 0x55c490d83bb0 in fifo32_push /root/videzzo/videzzo_qemu/qemu/include/qemu/fifo32.h:94:9 + #13 0x55c490d79d17 in transfer_fifo /root/videzzo/videzzo_qemu/qemu/out-san/../hw/net/can/xlnx-zynqmp-can.c:476:21 + #14 0x55c490d71a00 in can_tx_post_write /root/videzzo/videzzo_qemu/qemu/out-san/../hw/net/can/xlnx-zynqmp-can.c:836:9 + #15 0x55c48fdfaf9b in register_write /root/videzzo/videzzo_qemu/qemu/out-san/../hw/core/register.c:122:9 + #16 0x55c48fdfefb8 in register_write_memory /root/videzzo/videzzo_qemu/qemu/out-san/../hw/core/register.c:203:5 + #17 0x55c4934be1d3 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:493:5 + #18 0x55c4934bdb11 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18 + #19 0x55c4934bc436 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1515:16 + #20 0x55c49354cd0e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2825:23 + #21 0x55c49353aabb in flatview_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2867:12 + #22 0x55c49353a578 in address_space_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2963:18 + #23 0x55c48f8aed48 in qemu_writel /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1096:5 + #24 0x55c48f8ad0b3 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1245:28 + #25 0x55c4943a3a6f in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5 + #26 0x55c49439aded in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9 + #27 0x55c49439ab94 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9 + #28 0x55c48f8b608c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12 + #29 0x55c4943a88bb in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18 + #30 0x55c48f796816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #31 0x55c48f779444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #32 0x55c48f7843ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #33 0x55c48f7709d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #34 0x7fe365788082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #35 0x55c48f770a2d in _start (/root/bugs/metadata/xlnx_zynqmp_can-01/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can+0x3454a2d) + +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/zero-shot/108/all/1430 b/results/classifier/zero-shot/108/all/1430 new file mode 100644 index 000000000..131189157 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1430 @@ -0,0 +1,125 @@ +other: 0.972 +graphic: 0.961 +debug: 0.954 +device: 0.952 +permissions: 0.949 +performance: 0.946 +semantic: 0.943 +socket: 0.931 +PID: 0.931 +vnc: 0.930 +KVM: 0.928 +files: 0.925 +network: 0.922 +boot: 0.907 + +Underflow in xlnx_dp_aux_push_rx_fifo() +Description of problem: +Pop two times from s->tx_fifo[2] but there is one element left. Since the fifo +is not empty, the check at [1] will fail. + +``` +static void xilinx_spips_flush_txfifo(XilinxSPIPS *s) +{ + // ... + for (;;) { + // ... + if (fifo8_is_empty(&s->tx_fifo)) { // ---------------> [1] + xilinx_spips_update_ixr(s); + return; + } else if (s->snoop_state == SNOOP_STRIPING || + s->snoop_state == SNOOP_NONE) { + for (i = 0; i < num_effective_busses(s); ++i) { + tx_rx[i] = fifo8_pop(&s->tx_fifo); // ---------> [2] + } + stripe8(tx_rx, num_effective_busses(s), false); + } else if (s->snoop_state >= SNOOP_ADDR) { + // ... +``` +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-aarch64 + +cat << EOF | $QEMU \ +-machine xlnx-zcu102 -monitor none -serial none \ +-display none -nodefaults -qtest stdio +writel 0xff0f00a0 0x74b13699 +readl 0xc1af068c +EOF +``` +Additional information: +``` +==64457==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x55f8037f3440). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 1864808059 +INFO: Loaded 1 modules (600775 inline 8-bit counters): 600775 [0x55f806e06000, 0x55f806e98ac7), +INFO: Loaded 1 PC tables (600775 PCs): 600775 [0x55f8064dab90,0x55f806e05800), +/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-qspips: 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 , *spi*, *lqspi* +This process will fuzz the following MemoryRegions: + * spi[0] (size 200) + * spi[0] (size 200) + * lqspi[0] (size 2000000) + * spi[0] (size 200) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * spi, EVENT_TYPE_MMIO_READ, 0xff050000 +0x200, 1,4 + * spi, EVENT_TYPE_MMIO_WRITE, 0xff050000 +0x200, 1,4 + * spi, EVENT_TYPE_MMIO_READ, 0xff040000 +0x200, 1,4 + * spi, EVENT_TYPE_MMIO_WRITE, 0xff040000 +0x200, 1,4 + * spi, EVENT_TYPE_MMIO_READ, 0xff0f0000 +0x200, 1,4 + * spi, EVENT_TYPE_MMIO_WRITE, 0xff0f0000 +0x200, 1,4 + * lqspi, EVENT_TYPE_MMIO_READ, 0xc0000000 +0x2000000, 4,4 + * lqspi, EVENT_TYPE_MMIO_WRITE, 0xc0000000 +0x2000000, 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: 509Mb +Running: /root/videzzo/videzzo_qemu/out-san/poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-qspips-crash-a2dce6d03fde8dc9cb50fb0c8708f307ca93d7c2.minimized +qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-qspips: ../util/fifo8.c:62: uint8_t fifo8_pop(Fifo8 *): Assertion `fifo->num > 0' failed. +==64457== ERROR: libFuzzer: deadly signal + #0 0x55f7fecb90fe in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x55f7fec07d71 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x55f7febe0ca6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x55f7febe0d72 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x55f7febe0d72 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7f67ea63a41f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7f67ea44c00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7f67ea44c00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7f67ea42b858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7f67ea42b728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7f67ea43cfd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x55f803645699 in fifo8_pop /root/videzzo/videzzo_qemu/qemu/out-san/../util/fifo8.c:62:5 + #12 0x55f8009d1ded in xilinx_spips_flush_txfifo /root/videzzo/videzzo_qemu/qemu/out-san/../hw/ssi/xilinx_spips.c:623:28 + #13 0x55f8009dc092 in lqspi_load_cache /root/videzzo/videzzo_qemu/qemu/out-san/../hw/ssi/xilinx_spips.c:1194:9 + #14 0x55f8009da069 in lqspi_read /root/videzzo/videzzo_qemu/qemu/out-san/../hw/ssi/xilinx_spips.c:1231:5 + #15 0x55f80294a61a in memory_region_read_with_attrs_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:464:9 + #16 0x55f802908961 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18 + #17 0x55f8029060d8 in memory_region_dispatch_read1 /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1431:16 + #18 0x55f802905468 in memory_region_dispatch_read /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1458:9 + #19 0x55f802983a6d in flatview_read_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2892:23 + #20 0x55f802985078 in flatview_read /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2934:12 + #21 0x55f802984b38 in address_space_read_full /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2947:18 + #22 0x55f7fecebb51 in address_space_read /root/videzzo/videzzo_qemu/qemu/include/exec/memory.h:2873:18 + #23 0x55f7fecebb51 in qemu_readl /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1037:5 + #24 0x55f7fece9c16 in dispatch_mmio_read /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1051:35 + #25 0x55f8037ee8bf in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5 + #26 0x55f8037e5c3d in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9 + #27 0x55f8037e59e4 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9 + #28 0x55f7fed0108c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12 + #29 0x55f8037f370b in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18 + #30 0x55f7febe1816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #31 0x55f7febc4444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #32 0x55f7febcf3ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #33 0x55f7febbb9d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #34 0x7f67ea42d082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #35 0x55f7febbba2d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-qspips+0x3454a2d) + +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 +0x1,0xd,0xa0,0x0,0xf,0xff,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x99,0x36,0xb1,0x74,0x0,0x0,0x0,0x0,0x0,0xe,0x8c,0x6,0xaf,0xc1,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0, +\x01\x0d\xa0\x00\x0f\xff\x00\x00\x00\x00\x04\x00\x00\x00\x996\xb1t\x00\x00\x00\x00\x00\x0e\x8c\x06\xaf\xc1\x00\x00\x00\x00\x04\x00\x00\x00 +``` diff --git a/results/classifier/zero-shot/108/all/1434779 b/results/classifier/zero-shot/108/all/1434779 new file mode 100644 index 000000000..ef4631675 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1434779 @@ -0,0 +1,132 @@ +other: 0.980 +permissions: 0.977 +device: 0.972 +socket: 0.971 +semantic: 0.970 +debug: 0.970 +vnc: 0.969 +graphic: 0.968 +boot: 0.967 +performance: 0.964 +PID: 0.963 +files: 0.957 +network: 0.948 +KVM: 0.932 + +qemu hangs on live-migration with storage(virtual machine: windows Server 2008 with only one disk ) + +Hi, +We are using “Windows Server 2008” with qemu-kvm-2.0.1 (linux kernel:3.10.0) as a host of a VM. +Using drive_mirror to do live-migration on the same host for different disks +Local disk: /sf/data/local/ +Shared disk(iscsi): /sf/other/local/ --- the disk is busy, the IO rate is about 30MB/s +qemu-system-x86_64 -k en-us -m 2048 -smp 2 -vnc :3100 -usbdevice tablet -boot c -enable-kvm -drive file=/sf/data/local/vm-disk-1.qcow2,if=none,id=drive-ide0,cache=none,aio=native -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=100 + +Step 1: +Start migration: Drive_mirror -f drive-ide0 /sf/other/local/test.qcow2 + +Step 2: +When detect the migration has completed, then send cmd: block_job_complete -f drive-ide0 + +Step 3: +send cmd: info status +What surprised me is that the qemu monitor reports can’t be connected. + +Then find bellows: +The qemu process hangs on the mirror_run->bdrv_drain_all->aio_poll->qemu_poll_ns->ppoll (), +None events were received and poll forever. I don’t know why the aio can’t be responsed. This case is hardly to +be generated but it really happens sometimes . I’m looking forward to getting help from you . +The stack capture snapshot: + + +Thanks +MyAngle + + + +On Sat, Mar 21, 2015 at 07:44:37AM -0000, youyunyehe wrote: +> We are using “Windows Server 2008” with qemu-kvm-2.0.1 (linux kernel:3.10.0) as a host of a VM. + +Please give the exact qemu-kvm package version and Linux distro name. +The code in qemu.git/master is slightly different so maybe the issue no +longer happens, but it would be worth looking at the exact source code +your qemu-kvm is built from. + +I have CCed Jeff Cody, who maintains drive-mirror. + +> Using drive_mirror to do live-migration on the same host for different disks +> Local disk: /sf/data/local/ +> Shared disk(iscsi): /sf/other/local/ --- the disk is busy, the IO rate is about 30MB/s +> qemu-system-x86_64 -k en-us -m 2048 -smp 2 -vnc :3100 -usbdevice tablet -boot c -enable-kvm -drive file=/sf/data/local/vm-disk-1.qcow2,if=none,id=drive-ide0,cache=none,aio=native -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=100 +> +> Step 1: +> Start migration: Drive_mirror -f drive-ide0 /sf/other/local/test.qcow2 +> +> Step 2: +> When detect the migration has completed, then send cmd: block_job_complete -f drive-ide0 +> +> Step 3: +> send cmd: info status +> What surprised me is that the qemu monitor reports can’t be connected. +> +> Then find bellows: +> The qemu process hangs on the mirror_run->bdrv_drain_all->aio_poll->qemu_poll_ns->ppoll (), +> None events were received and poll forever. I don’t know why the aio can’t be responsed. This case is hardly to +> be generated but it really happens sometimes . I’m looking forward to getting help from you . +> The stack capture snapshot: + + +> -----Original Message----- +> From: <email address hidden> [mailto:<email address hidden>] +> On Behalf Of Stefan Hajnoczi +> Sent: 2015年3月23日 21:32 +> To: Bug 1434779 +> Cc: <email address hidden> +> Subject: Re: [Qemu-devel] [Bug 1434779] [NEW] qemu hangs on live-migration with storage(virtual machine: windows Server 2008 +> with only one disk ) +> +> On Sat, Mar 21, 2015 at 07:44:37AM -0000, youyunyehe wrote: +> > We are using “Windows Server 2008” with qemu-kvm-2.0.1 (linux kernel:3.10.0) as a host of a VM. +> +> Please give the exact qemu-kvm package version and Linux distro name. +> The code in qemu.git/master is slightly different so maybe the issue no longer happens, but it would be worth looking at the exact +> source code your qemu-kvm is built from. + +[Halsey] I also recreated this issue today, qemu hangs at bdrv_rw-co() -> bdrv_prwv_co() -> aio_poll(0 -> qemu_poll_ns() -> ppoll(). I'm just call bdrv_write to write data to qcow2 file. My qemu version is qemu-2.2.0. + +> I have CCed Jeff Cody, who maintains drive-mirror. +> +> > Using drive_mirror to do live-migration on the same host for +> > different disks Local disk: /sf/data/local/ +> > Shared disk(iscsi): /sf/other/local/ --- the disk is busy, the IO rate is about 30MB/s +> > qemu-system-x86_64 -k en-us -m 2048 -smp 2 -vnc :3100 -usbdevice +> > tablet -boot c -enable-kvm -drive +> > file=/sf/data/local/vm-disk-1.qcow2,if=none,id=drive-ide0,cache=none,a +> > io=native -device +> > ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=100 +> > +> > Step 1: +> > Start migration: Drive_mirror -f drive-ide0 +> > /sf/other/local/test.qcow2 +> > +> > Step 2: +> > When detect the migration has completed, then send cmd: +> > block_job_complete -f drive-ide0 +> > +> > Step 3: +> > send cmd: info status +> > What surprised me is that the qemu monitor reports can’t be connected. +> > +> > Then find bellows: +> > The qemu process hangs on the +> > mirror_run->bdrv_drain_all->aio_poll->qemu_poll_ns->ppoll (), None +> > events were received and poll forever. I don’t know why the aio can’t be responsed. This case is hardly to be generated but it really +> happens sometimes . I’m looking forward to getting help from you . +> > The stack capture snapshot: + + + +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/zero-shot/108/all/1452904 b/results/classifier/zero-shot/108/all/1452904 new file mode 100644 index 000000000..9bd56e4e0 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1452904 @@ -0,0 +1,228 @@ +permissions: 0.987 +performance: 0.983 +other: 0.980 +device: 0.979 +files: 0.978 +KVM: 0.977 +debug: 0.976 +graphic: 0.975 +boot: 0.975 +vnc: 0.974 +PID: 0.973 +network: 0.970 +socket: 0.970 +semantic: 0.970 + +High CPU in idle Windows guest + +Hi, + +I'm running a freshly installed Windows 7 domU on an up-to-date Debian +jessie machine running Xen 4.4.1-9. When the Windows machine is idle, +I'm seeing upwards of 10% CPU usage from the qemu-system-i386 instance. +Other Linux and FreeBSD machines register negligable CPU usage (<0.5%). +The server is an HP Proliant DL360 G7. + +Data from perf attacthed to the process might give the best clues. + +Any information as to why this processes is comsuming so much CPU would +be much appreciated. + +Regards, +Terry. + +# uname -a +Linux xen 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux + +# lsb_release -a +No LSB modules are available. +Distributor ID: Debian +Description: Debian GNU/Linux 8.0 (jessie) +Release: 8.0 +Codename: jessie + +# qemu-system-i386 --version +QEMU emulator version 2.1.2 (Debian 1:2.1+dfsg-11), Copyright (c) 2003-2008 Fabrice Bellard + +# cat win7.cfg +name = 'win7' +vcpus = '1' +memory = '4096' +builder = 'hvm' +disk = [ '/vms/xen/domains/desk_win7/disk1.img,qcow2,hda,rw', + '/vms/xen/domains/desk_win7/disk2.img,qcow2,hdb,rw' ] +vfb = [ 'vnc=1,vnclisten="0.0.0.0",sdl=0' ] +vif = [ 'mac=00:16:3E:FB:FC:39,bridge=xenbr0' ] +serial = 'pty' +vnc = 1 +vnclisten = '0.0.0.0' +sdl = 0 +usbdevice = 'mouse' +audio = 1 +soundhw = 'sb16,es1370' +on_poweroff = 'destroy' +on_reboot = 'restart' +on_crash = 'restart' + +# /usr/bin/qemu-system-i386 -nodefaults -name desk_win7 -boot order=cda -usb -usbdevice mouse -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:fb:fc:39 -netdev type=tap,id=net0,ifname=vif12.0-emu,script=no,downscript=no -m 4088 -drive file=/vms/xen/domains/desk_win7/disk1.img,if=ide,index=0,media=disk,format=qcow2,cache=writeback -drive file=/vms/xen/domains/desk_win7/disk2.img,if=ide,index=1,media=disk,format=qcow2,cache=writeback -vnc 0.0.0.0:0,to=99 -display none -device cirrus-vga -global vga.vram_size_mb=8 + +# top +Tasks: 134 total, 1 running, 133 sleeping, 0 stopped, 0 zombie +%Cpu(s): 16.6 us, 5.5 sy, 0.0 ni, 0.0 id, 77.9 wa, 0.0 hi, 0.0 si, 0.0 st +KiB Mem: 354420 total, 348884 used, 5536 free, 184 buffers +KiB Swap: 17575932 total, 2642868 used, 14933064 free. 4132 cached Mem + + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND +12297 root 20 0 6683864 192944 1140 S 20.6 54.4 2:25.51 qemu-syste+ + +# xen dmesg +(XEN) Xen version 4.4.1 (Debian 4.4.1-9) (<email address hidden>) (gcc (Debian 4.9.2-10) 4.9.2) debug=n Mon Apr 6 18:24:28 UTC 2015 +(XEN) Bootloader: GRUB 2.02~beta2-22 +(XEN) Command line: placeholder dom0_mem=512M dom0_max_vcpus=1 dom0_vcpus_pin radeon.modeset=0 iommu=no-intremap +(XEN) Video information: +(XEN) VGA is text mode 80x25, font 8x16 +(XEN) VBE/DDC methods: none; EDID transfer time: 2 seconds +(XEN) EDID info not retrieved because no DDC retrieval method detected +(XEN) Disc information: +(XEN) Found 1 MBR signatures +(XEN) Found 1 EDD information structures +(XEN) Xen-e820 RAM map: +(XEN) 0000000000000000 - 000000000009f400 (usable) +(XEN) 000000000009f400 - 00000000000a0000 (reserved) +(XEN) 00000000000f0000 - 0000000000100000 (reserved) +(XEN) 0000000000100000 - 00000000cf62f000 (usable) +(XEN) 00000000cf62f000 - 00000000cf63c000 (ACPI data) +(XEN) 00000000cf63c000 - 00000000cf63d000 (usable) +(XEN) 00000000cf63d000 - 00000000d4000000 (reserved) +(XEN) 00000000fec00000 - 00000000fee10000 (reserved) +(XEN) 00000000ff800000 - 0000000100000000 (reserved) +(XEN) 0000000100000000 - 00000004affff000 (usable) +(XEN) ACPI: RSDP 000F4F00, 0024 (r2 HP ) +(XEN) ACPI: XSDT CF630140, 00B4 (r1 HP ProLiant 2 Ò 162E) +(XEN) ACPI: FACP CF630240, 00F4 (r3 HP ProLiant 2 Ò 162E) +(XEN) ACPI: DSDT CF630340, 20BD (r1 HP DSDT 1 INTL 20030228) +(XEN) ACPI: FACS CF62F100, 0040 +(XEN) ACPI: SPCR CF62F140, 0050 (r1 HP SPCRRBSU 1 Ò 162E) +(XEN) ACPI: MCFG CF62F1C0, 003C (r1 HP ProLiant 1 0) +(XEN) ACPI: HPET CF62F200, 0038 (r1 HP ProLiant 2 Ò 162E) +(XEN) ACPI: FFFF CF62F240, 0064 (r2 HP ProLiant 2 Ò 162E) +(XEN) ACPI: SPMI CF62F2C0, 0040 (r5 HP ProLiant 1 Ò 162E) +(XEN) ACPI: ERST CF62F300, 01D0 (r1 HP ProLiant 1 Ò 162E) +(XEN) ACPI: APIC CF62F500, 015E (r1 HP ProLiant 2 0) +(XEN) ACPI: SRAT CF62F680, 0570 (r1 HP Proliant 1 Ò 162E) +(XEN) ACPI: FFFF CF62FC00, 0176 (r1 HP ProLiant 1 Ò 162E) +(XEN) ACPI: BERT CF62FD80, 0030 (r1 HP ProLiant 1 Ò 162E) +(XEN) ACPI: HEST CF62FDC0, 00BC (r1 HP ProLiant 1 Ò 162E) +(XEN) ACPI: DMAR CF62FE80, 0150 (r1 HP ProLiant 1 Ò 162E) +(XEN) ACPI: SSDT CF632400, 0125 (r3 HP CRSPCI0 2 HP 1) +(XEN) ACPI: SSDT CF632540, 01CF (r3 HP riser1a 2 INTL 20061109) +(XEN) ACPI: SSDT CF632740, 03BB (r1 HP pcc 1 INTL 20090625) +(XEN) ACPI: SSDT CF632B00, 0377 (r1 HP pmab 1 INTL 20090625) +(XEN) ACPI: SSDT CF632E80, 2094 (r1 INTEL PPM RCM 1 INTL 20061109) +(XEN) System RAM: 18421MB (18863928kB) +(XEN) Domain heap initialised +(XEN) Processor #0 6:12 APIC version 21 +(XEN) Processor #16 6:12 APIC version 21 +(XEN) Processor #4 6:12 APIC version 21 +(XEN) Processor #20 6:12 APIC version 21 +(XEN) Processor #2 6:12 APIC version 21 +(XEN) Processor #18 6:12 APIC version 21 +(XEN) Processor #1 6:12 APIC version 21 +(XEN) Processor #17 6:12 APIC version 21 +(XEN) Processor #5 6:12 APIC version 21 +(XEN) Processor #21 6:12 APIC version 21 +(XEN) Processor #3 6:12 APIC version 21 +(XEN) Processor #19 6:12 APIC version 21 +(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23 +(XEN) IOAPIC[1]: apic_id 0, version 32, address 0xfec80000, GSI 24-47 +(XEN) Enabling APIC mode: Phys. Using 2 I/O APICs +(XEN) Failed to get Error Log Address Range. +(XEN) Using scheduler: SMP Credit Scheduler (credit) +(XEN) Detected 2533.485 MHz processor. +(XEN) Initing memory sharing. +(XEN) Intel VT-d iommu 0 supported page sizes: 4kB. +(XEN) Intel VT-d Snoop Control not enabled. +(XEN) Intel VT-d Dom0 DMA Passthrough not enabled. +(XEN) Intel VT-d Queued Invalidation enabled. +(XEN) Intel VT-d Interrupt Remapping not enabled. +(XEN) Intel VT-d Shared EPT tables not enabled. +(XEN) I/O virtualisation enabled +(XEN) - Dom0 mode: Relaxed +(XEN) Interrupt remapping disabled +(XEN) Enabled directed EOI with ioapic_ack_old on! +(XEN) ENABLING IO-APIC IRQs +(XEN) -> Using old ACK method +(XEN) Platform timer is 14.318MHz HPET +(XEN) Allocated console ring of 32 KiB. +(XEN) VMX: Supported advanced features: +(XEN) - APIC MMIO access virtualisation +(XEN) - APIC TPR shadow +(XEN) - Extended Page Tables (EPT) +(XEN) - Virtual-Processor Identifiers (VPID) +(XEN) - Virtual NMI +(XEN) - MSR direct-access bitmap +(XEN) - Unrestricted Guest +(XEN) HVM: ASIDs enabled. +(XEN) HVM: VMX enabled +(XEN) HVM: Hardware Assisted Paging (HAP) detected +(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB +(XEN) Brought up 12 CPUs +(XEN) *** LOADING DOMAIN 0 *** +(XEN) Xen kernel: 64-bit, lsb, compat32 +(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1f18000 +(XEN) PHYSICAL MEMORY ARRANGEMENT: +(XEN) Dom0 alloc.: 000000049c000000->00000004a0000000 (110661 pages to be allocated) +(XEN) Init. ramdisk: 00000004aee45000->00000004afdff7d5 +(XEN) VIRTUAL MEMORY ARRANGEMENT: +(XEN) Loaded kernel: ffffffff81000000->ffffffff81f18000 +(XEN) Init. ramdisk: ffffffff81f18000->ffffffff82ed27d5 +(XEN) Phys-Mach map: ffffffff82ed3000->ffffffff82fd3000 +(XEN) Start info: ffffffff82fd3000->ffffffff82fd34b4 +(XEN) Page tables: ffffffff82fd4000->ffffffff82ff1000 +(XEN) Boot stack: ffffffff82ff1000->ffffffff82ff2000 +(XEN) TOTAL: ffffffff80000000->ffffffff83400000 +(XEN) ENTRY ADDRESS: ffffffff819021f0 +(XEN) Dom0 has maximum 1 VCPUs +(XEN) Scrubbing Free RAM: .................................................................................................................................................................................done. +(XEN) Initial low memory virq threshold set at 0x4000 pages. +(XEN) Std. Loglevel: Errors and warnings +(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) +(XEN) Xen is relinquishing VGA console. +(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) +(XEN) Freed 284kB init memory. + +# perf report +# To display the perf.data header info, please use --header/--header-only options. +# +# Samples: 6K of event 'cpu-clock' +# Event count (approx.): 1744250000 +# +# Overhead Command Shared Object Symbol +# ........ ............... ....................... .................................... +# + 8.69% qemu-system-i38 [kernel.kallsyms] [k] xen_hypercall_xen_version + 2.29% qemu-system-i38 qemu-system-i386 [.] 0x00000000000acac8 + 2.01% qemu-system-i38 qemu-system-i386 [.] 0x00000000000acad9 + 1.53% qemu-system-i38 qemu-system-i386 [.] 0x00000000000ac978 + 1.33% qemu-system-i38 qemu-system-i386 [.] 0x00000000000ac989 + 1.02% qemu-system-i38 qemu-system-i386 [.] 0x00000000000acaa4 + 0.93% qemu-system-i38 libc-2.19.so [.] memset + 0.70% qemu-system-i38 qemu-system-i386 [.] 0x00000000000e2814 + 0.69% qemu-system-i38 qemu-system-i386 [.] 0x00000000000e37f4 + 0.67% qemu-system-i38 qemu-system-i386 [.] 0x00000000000aca40 + 0.66% qemu-system-i38 qemu-system-i386 [.] 0x00000000000acadf + 0.60% qemu-system-i38 qemu-system-i386 [.] 0x00000000000acad7 + 0.59% qemu-system-i38 [vdso] [.] __vdso_clock_gettime + 0.59% qemu-system-i38 qemu-system-i386 [.] 0x0000000000342b88 + 0.57% qemu-system-i38 [vdso] [.] __vdso_gettimeofday + 0.52% qemu-system-i38 [kernel.kallsyms] [k] pvclock_clocksource_read + 0.49% qemu-system-i38 qemu-system-i386 [.] 0x00000000000a9e45 + 0.46% qemu-system-i38 [kernel.kallsyms] [k] do_sys_poll + 0.37% qemu-system-i38 [kernel.kallsyms] [k] hrtimer_init + 0.36% qemu-system-i38 [kernel.kallsyms] [k] __fget + 0.34% qemu-system-i38 [kernel.kallsyms] [k] ktime_get_ts + +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/zero-shot/108/all/1454 b/results/classifier/zero-shot/108/all/1454 new file mode 100644 index 000000000..f0db4df75 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1454 @@ -0,0 +1,77 @@ +semantic: 0.994 +vnc: 0.993 +debug: 0.993 +device: 0.993 +permissions: 0.993 +graphic: 0.992 +performance: 0.991 +other: 0.991 +KVM: 0.991 +boot: 0.990 +socket: 0.988 +PID: 0.988 +files: 0.985 +network: 0.983 + +QEMU TCG s390x fails an assertion while dispatching an FIXPT_DIVIDE exception on DR when compiled with LTO +Description of problem: +When running the attached minimal reproducer, with qemu-system-s390x version 7.2.0 compiled with LTO (`--enable-lto`) with GCC v12.2.1, QEMU fails an assertion and crashes: +``` +qemu-system-s390x: ../target/s390x/tcg/excp_helper.c:215: do_program_interrupt: Assertion `ilen == 2 || ilen == 4 || ilen == 6' failed. +Aborted (core dumped) +``` +Steps to reproduce: +1. Compile QEMU v7.2.0 for s390x with LTO enabled: + ``` + ../configure --target-list=s390x-softmmu --enable-lto + ``` +2. Compile the given reproducer assembler [lpswe-to-pgm.S](/uploads/200fb0e777ddd0ed26f51009e81c26ea/lpswe-to-pgm.S): + ``` + s390x-linux-gnu-gcc -march=z13 -m64 -nostdlib -nostartfiles -static -Wl,-Ttext=0 -Wl,--build-id=none lpswe-to-pgm.S -o lpswe-to-pgm + ``` +3. Execute QEMU on the reproducer: + ``` + ./qemu-system-s390x -kernel lpswe-to-pgm + ``` +Additional information: +I have debugged QEMU to try to find the root cause, and I believe I found it, but I'm not sure what the most appropriate way to fix it would be: + +QEMU executes the `DR` instruction by executing the `divs32` helper. + +When the helper sees that the final division result does not fit in 32 bits, it generates a program interrupt for fixed point divide by calling the `tcg_s390_program_interrupt` function, with the final parameter being the TCG host PC, which is found by calling `GETPC`. + +`tcg_s390_program_interrupt` then calls `cpu_restore_state`, and then as long as the host PC is valid, `cpu_restore_state` eventually calls `s390x_restore_state_to_opc` through a long chain of calls, which sets `CPUS390XState::int_pgm_ilen` to a valid value. + +Unfortunately when compiling with LTO, the host PC is not valid, which means we don't update `int_pgm_ilen`, resulting in the failed assertion. + +The reason the host PC is not valid when compiling with LTO, is that GCC decides to split `helper_divs32` into 2 parts, the actual div logic being the first part, and the call to `GETPC` & `tcg_s390_program_interrupt` being the second part. The way GCC implements it is by turning the second part into a separate function, which the first part calls - see disassembly below. (GCC then re-uses the second part in other similar TCG helpers) + +Because we now called the second part before calling `GETPC`, we have a new return address, and `GETPC` returns the address of the first part, instead of the TCG host PC. + +``` +000000000022c870 <helper_divs32>: + 22c870: 48 83 ec 08 sub rsp,0x8 + 22c874: 85 d2 test edx,edx + 22c876: 74 22 je 22c89a <helper_divs32+0x2a> + 22c878: 48 89 f0 mov rax,rsi + 22c87b: 48 63 ca movsxd rcx,edx + 22c87e: 48 99 cqo + 22c880: 48 f7 f9 idiv rcx + 22c883: 4c 63 c0 movsxd r8,eax + 22c886: 48 89 97 10 03 00 00 mov QWORD PTR [rdi+0x310],rdx + 22c88d: 49 39 c0 cmp r8,rax + 22c890: 75 17 jne 22c8a9 <helper_divs32+0x39> + 22c892: 4c 89 c0 mov rax,r8 + 22c895: 48 83 c4 08 add rsp,0x8 + 22c899: c3 ret + 22c89a: 48 8b 54 24 08 mov rdx,QWORD PTR [rsp+0x8] + 22c89f: be 09 00 00 00 mov esi,0x9 + 22c8a4: e8 47 e5 ff ff call 22adf0 <tcg_s390_program_interrupt> + 22c8a9: e8 b2 fe ff ff call 22c760 <helper_divs32.part.0> + +000000000022c760 <helper_divs32.part.0>: + 22c760: 48 83 ec 08 sub rsp,0x8 + 22c764: be 09 00 00 00 mov esi,0x9 + 22c769: 48 8b 54 24 08 mov rdx,QWORD PTR [rsp+0x8] + 22c76e: e8 7d e6 ff ff call 22adf0 <tcg_s390_program_interrupt> +``` diff --git a/results/classifier/zero-shot/108/all/1456819 b/results/classifier/zero-shot/108/all/1456819 new file mode 100644 index 000000000..2027f21b2 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1456819 @@ -0,0 +1,130 @@ +permissions: 0.970 +other: 0.964 +debug: 0.963 +device: 0.958 +boot: 0.954 +semantic: 0.948 +performance: 0.946 +vnc: 0.941 +socket: 0.940 +graphic: 0.939 +PID: 0.937 +files: 0.934 +network: 0.931 +KVM: 0.923 + +OVMF, Hyper-V, virtio, Win7 incompatibility + +Host kernel: v4.1-rc4 +QEMU: qemu.git tag v2.3.0 +OVMF: edk2.git-ovmf-x64-0-20150518.b1004.g54ae9c0.noarch +libvirt: 1.2.13.1-1.fc21.x86_64 +Guest: en_windows_7_professional_with_sp1_x64_dvd_u_676939.iso + +If I attempt to use the above software versions to start a VM install, I hit one of two problems: + +(a) If I use a virtio NIC, the VM aborts with an error similar to: + +qemu-system-x86_64: Guest moved used index from 22 to 0 + +(b) If I use an emulated (e1000) NIC, the VM switches to a black screen when I should have the dancing windows boot animation logo + +Both of these are resolved by switching off ALL Hyper-V enlightenments as shown in the below XML. Enabling any one of them results in the above behavior. + +This problem is only seen with OVMF, removing the loader and nvram directives below allows all Hyper-V enlightenments to be enabled, with or without a virtio NIC. + +<domain type='kvm'> + <name>win7-ovmf-demo</name> + <uuid>a42b96e9-e95d-42c6-9f4a-0236f3d38d95</uuid> + <memory unit='KiB'>4194304</memory> + <currentMemory unit='KiB'>4194304</currentMemory> + <vcpu placement='static'>2</vcpu> + <os> + <type arch='x86_64' machine='pc-i440fx-2.3'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> + <nvram>/var/lib/libvirt/qemu/nvram/win7-ovmf-demo_VARS.fd</nvram> + </os> + <features> + <acpi/> + <apic/> + <pae/> + <hyperv> + <relaxed state='off'/> + <vapic state='off'/> + <spinlocks state='off'/> + </hyperv> + </features> + <clock offset='localtime'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + <timer name='hypervclock' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/local/bin/qemu-system-x86_64</emulator> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/var/lib/libvirt/images/MSDN/en_windows_7_professional_with_sp1_x64_dvd_u_676939.iso'/> + <target dev='hdb' bus='ide'/> + <readonly/> + <boot order='1'/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <interface type='network'> + <mac address='52:54:00:9b:49:b9'/> + <source network='default'/> + <model type='e1000'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <input type='tablet' bus='usb'/> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='vnc' port='-1' autoport='yes'/> + <video> + <model type='vga' vram='16384' heads='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='none'/> + </devices> +</domain> + +The problem also does not occur using OVMF with Windows 8.1 install media: en_windows_8.1_n_with_update_x64_dvd_4065114.iso + +Please refer to + +https://bugzilla.redhat.com/show_bug.cgi?id=1185253 + +especially note (2) under "Additional info" in Comment #0. + +"Hyper-V extensions + UEFI guest firmware + Win7 guest + guest is multi-VCPU" is not a supported configuration, even in Microsoft's own stack. + +Virt-manager has been modified to avoid such a configuration (see comment #10). + +Is there still anything left to do here, or could we close this bug ticket nowadays? + diff --git a/results/classifier/zero-shot/108/all/1464611 b/results/classifier/zero-shot/108/all/1464611 new file mode 100644 index 000000000..5ef4e17f5 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1464611 @@ -0,0 +1,194 @@ +permissions: 0.974 +other: 0.943 +PID: 0.938 +performance: 0.933 +device: 0.932 +socket: 0.929 +files: 0.922 +KVM: 0.922 +graphic: 0.921 +debug: 0.917 +semantic: 0.916 +network: 0.910 +boot: 0.904 +vnc: 0.901 + +4 * redundant conditions + + +1. + +[qemu/hw/block/nvme.c:355]: (style) Redundant condition: sqid. 'A && (!A || B)' is equivalent to 'A || B' + + if (!sqid || (sqid && !nvme_check_sqid(n, sqid))) { + +2. + +[qemu/hw/block/nvme.c:429]: (style) Redundant condition: cqid. 'A && (!A || B)' is equivalent to 'A || B' + + if (!cqid || (cqid && !nvme_check_cqid(n, cqid))) { + +3. + +[qemu/hw/tpm/tpm_passthrough.c:157]: (style) Redundant condition: tpm_pt.tpm_op_canceled. 'A && (!A || B)' is equivalent to 'A || B' + + if (!tpm_pt->tpm_op_canceled || + (tpm_pt->tpm_op_canceled && errno != ECANCELED)) { + +4. + +[qemu/target-arm/translate-a64.c:5729]: (style) Redundant condition: size<3. 'A && (!A || B)' is equivalent to 'A || B' + + if (size > 3 + || (size < 3 && is_q) + || (size == 3 && !is_q)) { + +On 12 June 2015 at 11:38, dcb <email address hidden> wrote: +> Public bug reported: +> +> +> 1. +> +> [qemu/hw/block/nvme.c:355]: (style) Redundant condition: sqid. 'A && (!A +> || B)' is equivalent to 'A || B' +> +> if (!sqid || (sqid && !nvme_check_sqid(n, sqid))) { +> +> 2. +> +> [qemu/hw/block/nvme.c:429]: (style) Redundant condition: cqid. 'A && (!A +> || B)' is equivalent to 'A || B' +> +> if (!cqid || (cqid && !nvme_check_cqid(n, cqid))) { +> +> 3. +> +> [qemu/hw/tpm/tpm_passthrough.c:157]: (style) Redundant condition: +> tpm_pt.tpm_op_canceled. 'A && (!A || B)' is equivalent to 'A || B' +> +> if (!tpm_pt->tpm_op_canceled || +> (tpm_pt->tpm_op_canceled && errno != ECANCELED)) { + +These three are all straightforward and would look simpler +in their simplified versions... + +> 4. +> +> [qemu/target-arm/translate-a64.c:5729]: (style) Redundant condition: +> size<3. 'A && (!A || B)' is equivalent to 'A || B' +> +> if (size > 3 +> || (size < 3 && is_q) +> || (size == 3 && !is_q)) { + +...but I'm less sure about this one. I'm not even sure +what it's trying to suggest this should simplify to: +just dropping "size < 3" is obviously wrong, and the +condition format isn't "A && (!A || B)" either. + +thanks +-- PMM + + +On 06/12/2015 05:01 AM, Peter Maydell wrote: + +>> 4. +>> +>> [qemu/target-arm/translate-a64.c:5729]: (style) Redundant condition: +>> size<3. 'A && (!A || B)' is equivalent to 'A || B' +>> +>> if (size > 3 +>> || (size < 3 && is_q) +>> || (size == 3 && !is_q)) { +> +> ...but I'm less sure about this one. I'm not even sure +> what it's trying to suggest this should simplify to: +> just dropping "size < 3" is obviously wrong, and the +> condition format isn't "A && (!A || B)" either. + +Let's break it down into the 6 possibilities based on the binary * +ternary conditions being checked: + +> 3, is_q => accept +> 3, !is_q => accept +== 3, is_q => reject +== 3, !is_q => accept +< 3, is_q => accept +< 3, !is_q => reject + +Here's a shorter conditional with the same properties, but it's gross: + +if (size > 3 || (is_q != (size == 3))) { + +Too much mental thought to prove it accepts the same set of conditions. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +On 12 June 2015 at 14:03, Eric Blake <email address hidden> wrote: +> On 06/12/2015 05:01 AM, Peter Maydell wrote: +> +>>> 4. +>>> +>>> [qemu/target-arm/translate-a64.c:5729]: (style) Redundant condition: +>>> size<3. 'A && (!A || B)' is equivalent to 'A || B' +>>> +>>> if (size > 3 +>>> || (size < 3 && is_q) +>>> || (size == 3 && !is_q)) { +>> +>> ...but I'm less sure about this one. I'm not even sure +>> what it's trying to suggest this should simplify to: +>> just dropping "size < 3" is obviously wrong, and the +>> condition format isn't "A && (!A || B)" either. +> +> Let's break it down into the 6 possibilities based on the binary * +> ternary conditions being checked: +> +>> 3, is_q => accept +>> 3, !is_q => accept +> == 3, is_q => reject +> == 3, !is_q => accept +> < 3, is_q => accept +> < 3, !is_q => reject +> +> Here's a shorter conditional with the same properties, but it's gross: +> +> if (size > 3 || (is_q != (size == 3))) { +> +> Too much mental thought to prove it accepts the same set of conditions. + +Yeah, I think this is the kind of thing where I say "the compiler +should do this simplification if it cares enough" :-) + +-- PMM + + +>These three are all straightforward and would look simpler +>in their simplified versions... + +Agreed. The first 3 look valid candidates for simplification. + +> 4. +> +> [qemu/target-arm/translate-a64.c:5729]: (style) Redundant condition: +> size<3. 'A && (!A || B)' is equivalent to 'A || B' +> +> if (size > 3 +> || (size < 3 && is_q) +> || (size == 3 && !is_q)) { + +>...but I'm less sure about this one. + +Me too. Suggest regard as a false positive from the static analysis tool +and so leave the original code alone. + +Patches have been committed: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=f96fe6b5c27b9a66dba71 +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=5f333d79a4337b390fa41 + +Released with version 2.8 + diff --git a/results/classifier/zero-shot/108/all/1477538 b/results/classifier/zero-shot/108/all/1477538 new file mode 100644 index 000000000..c35338f99 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1477538 @@ -0,0 +1,157 @@ +device: 0.967 +other: 0.967 +semantic: 0.957 +network: 0.954 +permissions: 0.952 +graphic: 0.950 +PID: 0.949 +vnc: 0.946 +performance: 0.946 +socket: 0.941 +debug: 0.939 +files: 0.937 +KVM: 0.936 +boot: 0.912 + +Windows QEMU Guest Agent VSS Provider service stops during qemu backup + +I’m currently implementing the QEMU Guest Agent on all my KVM Windows guests. + +I’m using the stable VirtIO drivers and Guest agent from Fedora: https://fedoraproject.org/wiki/Windows_Virtio_Drivers + +Both the stable and latest release do provide Qemu Windows Guest agent 7.0.0.10. + +After the Guest agent installation I initially received VSS events with ID 8194: + + Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback interface. hr = 0x80070005, Access is denied. + +This is often caused by incorrect security settings in either the writer or requestor process. +Operation: + Gathering Writer Data +Context: + + Writer Class Id: {e8132975-6f93-4464-a53e-1050253ae220} + + Writer Name: System Writer + + Writer Instance ID: {6c777a34-53dd-4fb3-a4c9-b85d7e183e27} + + +I was able to fix this issue by adding local access permissions for the “Network Service” account at the Dcom security permissions: + +On the client computer from the Start Menu, select Run +The Run dialog opens. +In the Open field type dcomcnfg and click OK. +The Component Services dialog opens. +Expand Component Services, Computers, and My Computer. +Right-click My Computer and click Properties on the pop-up menu. +The My Computer Properties dialog opens. +Click the COM Security tab. +Under Access Permission click Edit Default. +The Access Permissions dialog opens. +From the Access Permissions dialog, add the "Network Service" account with Local Access allowed. +Close all open dialogs. + +Now an initial backup runs without any errors but this is causing the QEMU Guest Agent VSS Provider service to stop running without any error in the event log. + +As a result a second backup will cause an error: MSDTC Client 2 with event ID: 4879: + +MSDTC encountered an error (HR=0x80000171) while attempting to establish a secure connection with system SERVERNAME. + +This is probably caused because the QEMU Guest Agent VSS Provider service isn’t running anymore. + +I can manually start the QEMU Guest Agent VSS Provider service but every backup is causing the service to stop. + +I’m seeing this behavior at all my Windows based guests running both Windows Server 2012 R2 and Windows Server 2008 R2. + + Since I can’t find any logging or troubleshooting possibilities for this particular service I'm open for suggestions how to troubleshoot this issue to receive detailed information about the reason why this services stops running during a backup. + + +qemu-server 3.4-3 amd64 +Guest agent 7.0.0.10 + +After upgrading to QEMU guest agent 7.2.1 this issue disappeared. + +The only minor "issue" that remains is that the QEMU Guest Agent VSS Provider service is being installed with start-up type: Automatic. + +After a backup the service is automatically being stopped causing monitoring systems like the Windows server manager to complain about stopped services with start-up type automatic. + +Because the Qemu guest agent starts the VSS provider service automatically when a backup is being triggered this can easily be solved by changing the start-up type to: manual. + +I have now changed the start-up type to manual using GPO for all my Qemu Windows guests. + +I have filed a bug report at Redhat with the request to change the service start-up type to manual for the provided MSI install packages. +https://bugzilla.redhat.com/show_bug.cgi?id=1286672 + + + + + + + +Hi Joop, + +From where did you find QEMU guest agent 7.2.1 ? I am looking for one for RHEL 7. Any idea where can I find it ? + +Thanks, +Ravi + + + +Hello Ravi, + +You can find it at the Fedora Windows VirtIO Drivers wiki page that I provided in my first post. + +Here's a direct link to the latest 7.2.1 guest agent: +https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-qemu-ga/qemu-ga-win-7.2.1-1/ + +Hello Ravi, + +Just noticed that you are looking for a RHEL 7 guest agent instead of the Windows version. +Not sure what the latest Linux release is but the standard repos currently provide release 2.3.0. + +If you need a newer version you need to search for a 3th party rpm or compile it yourself from source. + + +Thanks Joop, I am looking for Windows 2012 guest agent only. Let me try the 7.2.1 guest agent. + +Well, I am still getting this error. +Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback interface. hr = 0x80070005, Access is denied. +. This is often caused by incorrect security settings in either the writer or requestor process. + +Operation: + Gathering Writer Data + +Context: + Writer Class Id: {e8132975-6f93-4464-a53e-1050253ae220} + Writer Name: System Writer + Writer Instance ID: {07dc130c-35da-4bd1-9948-2b4501249c3b} + + +Finally it worked. + +I had to carry out DCOM config that you suggested earlier in addition to installation of 7.2.1 + +Thanks, +Ravi + + + + +Have you tried my manual steps to fix this issue? + +On the client computer from the Start Menu, select Run +The Run dialog opens. +In the Open field type dcomcnfg and click OK. +The Component Services dialog opens. +Expand Component Services, Computers, and My Computer. +Right-click My Computer and click Properties on the pop-up menu. +The My Computer Properties dialog opens. +Click the COM Security tab. +Under Access Permission click Edit Default. +The Access Permissions dialog opens. +From the Access Permissions dialog, add the "Network Service" account with Local Access allowed. +Close all open dialogs. + +If the issue has not been fixed for you I suggest to reopen the bug (I'm the original bug reporter not the bug fixer) + diff --git a/results/classifier/zero-shot/108/all/1478360 b/results/classifier/zero-shot/108/all/1478360 new file mode 100644 index 000000000..85b402a40 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1478360 @@ -0,0 +1,193 @@ +permissions: 0.990 +other: 0.990 +graphic: 0.987 +debug: 0.986 +device: 0.985 +semantic: 0.985 +PID: 0.983 +performance: 0.982 +files: 0.979 +socket: 0.979 +network: 0.979 +boot: 0.976 +vnc: 0.973 +KVM: 0.973 + +Cant compile on ubuntu 14.04 x64 + +./configure --static +Install prefix /usr/local +BIOS directory /usr/local/share/qemu +binary directory /usr/local/bin +library directory /usr/local/lib +module directory /usr/local/lib/qemu +libexec directory /usr/local/libexec +include directory /usr/local/include +config directory /usr/local/etc +local state directory /usr/local/var +Manual directory /usr/local/share/man +ELF interp prefix /usr/gnemul/qemu-%M +Source path /home/slobodan/qemu +C compiler cc +Host C compiler cc +C++ compiler c++ +Objective-C compiler cc +ARFLAGS rv +CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g +QEMU_CFLAGS -I/usr/include/pixman-1 -Werror -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1 -I/usr/include/libpng12 +LDFLAGS -Wl,--warn-common -m64 -static -g +make make +install install +python python -B +smbd /usr/sbin/smbd +module support no +host CPU x86_64 +host big endian no +target list aarch64-softmmu alpha-softmmu arm-softmmu cris-softmmu i386-softmmu lm32-softmmu m68k-softmmu microblaze-softmmu microblazeel-softmmu mips-softmmu mips64-softmmu mips64el-softmmu mipsel-softmmu moxie-softmmu or32-softmmu ppc-softmmu ppc64-softmmu ppcemb-softmmu s390x-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu sparc64-softmmu tricore-softmmu unicore32-softmmu x86_64-softmmu xtensa-softmmu xtensaeb-softmmu aarch64-linux-user alpha-linux-user arm-linux-user armeb-linux-user cris-linux-user i386-linux-user m68k-linux-user microblaze-linux-user microblazeel-linux-user mips-linux-user mips64-linux-user mips64el-linux-user mipsel-linux-user mipsn32-linux-user mipsn32el-linux-user or32-linux-user ppc-linux-user ppc64-linux-user ppc64abi32-linux-user ppc64le-linux-user s390x-linux-user sh4-linux-user sh4eb-linux-user sparc-linux-user sparc32plus-linux-user sparc64-linux-user unicore32-linux-user x86_64-linux-user +tcg debug enabled no +gprof enabled no +sparse enabled no +strip binaries yes +profiler no +static build yes +pixman system +SDL support no +GTK support yes +GNUTLS support yes +GNUTLS hash yes +GNUTLS gcrypt yes +GNUTLS nettle no () +VTE support no +curses support no +curl support no +mingw32 support no +Audio drivers oss +Block whitelist (rw) +Block whitelist (ro) +VirtFS support no +VNC support yes +VNC TLS support no +VNC SASL support no +VNC JPEG support yes +VNC PNG support yes +xen support no +brlapi support no +bluez support yes +Documentation no +GUEST_BASE yes +PIE no +vde support no +netmap support no +Linux AIO support no +ATTR/XATTR support yes +Install blobs yes +KVM support yes +RDMA support no +TCG interpreter no +fdt support yes +preadv support yes +fdatasync yes +madvise yes +posix_madvise yes +sigev_thread_id yes +uuid support yes +libcap-ng support no +vhost-net support yes +vhost-scsi support yes +Trace backends nop +spice support no +rbd support no +xfsctl support no +nss used no +libusb no +usb net redir no +OpenGL support no +libiscsi support no +libnfs support no +build guest agent yes +QGA VSS support no +QGA w32 disk info no +seccomp support no +coroutine backend ucontext +coroutine pool yes +GlusterFS support no +Archipelago support no +gcov gcov +gcov enabled no +TPM support yes +libssh2 support no +TPM passthrough yes +QOM debugging yes +vhdx yes +lzo support no +snappy support no +bzip2 support no +NUMA host support no +tcmalloc support no + +:~/qemu$ make + GEN config-host.h + GEN qemu-options.def + GEN qmp-commands.h + GEN qapi-types.h + GEN qapi-visit.h + GEN qapi-event.h + GEN trace/generated-events.h + GEN trace/generated-tracers.h + GEN trace/generated-tcg-tracers.h + GEN trace/generated-helpers-wrappers.h + GEN trace/generated-helpers.h + GEN tests/test-qapi-types.h + GEN tests/test-qapi-visit.h + GEN tests/test-qmp-commands.h + GEN tests/test-qapi-event.h + CC tests/qemu-iotests/socket_scm_helper.o + LINK tests/qemu-iotests/socket_scm_helper +c++: error: unrecognized command line option ‘-R’ +make: *** [tests/qemu-iotests/socket_scm_helper] Error 1 + +On 26 July 2015 at 17:02, Vido <email address hidden> wrote: +> Public bug reported: +> +> ./configure --static + +> c++: error: unrecognized command line option ‘-R’ +> make: *** [tests/qemu-iotests/socket_scm_helper] Error 1 + +This is a bug in Ubuntu's gnutls package: +https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1478035 + +You can work around it by adding "--disable-gnutls" to +your configure arguments, or by applying this patch: +http://patchwork.ozlabs.org/patch/499821/ + +I would expect that patch to be applied for QEMU 2.4. + +thanks +-- PMM + + +Tnx Peter, just one quick question how should I configure qemu to disable threding I cant find any option with ./configure --help + +On 27 July 2015 at 21:09, Vido <email address hidden> wrote: +> Tnx Peter, just one quick question how should I configure qemu to +> disable threding I cant find any option with ./configure --help + +I'm not sure why you think that's related to this bug. +There's no option to disable threading because you never +want to do that; it's not optional. + +The fix for this bug went into git today, incidentally. +It will be in QEMU 2.4. + +thanks +-- PMM + + +chroot . ./qemu-mips-static ./cspd +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +and I come across solution that disabling threading will solve this issue + +Tnx for noticing about fix great news + diff --git a/results/classifier/zero-shot/108/all/1492 b/results/classifier/zero-shot/108/all/1492 new file mode 100644 index 000000000..ca61fecbb --- /dev/null +++ b/results/classifier/zero-shot/108/all/1492 @@ -0,0 +1,307 @@ +permissions: 0.986 +device: 0.984 +debug: 0.983 +performance: 0.982 +other: 0.982 +boot: 0.980 +graphic: 0.978 +semantic: 0.977 +PID: 0.977 +files: 0.976 +network: 0.974 +socket: 0.965 +vnc: 0.965 +KVM: 0.953 + +[coredump] [git master] qemu-x86_64 segfaults on ppc64le (4K page size) when trying to run android-studio inside chroot +Description of problem: +qemu-x86_64 segfaults when trying to run android-studio inside an Arch Linux x86_64 chroot from a Gentoo Linux ppc64le (4K page size) host. Hardware is a Raptor CS Talos 2 Power 9. +``` +[niko@talos2 ~]$ android-studio +/usr/bin/android-studio: line 200: 117922 Segmentation fault (core dumped) "$JAVA_BIN" -classpath "$CLASS_PATH" ${VM_OPTIONS} "-XX:ErrorFile=$HOME/java_error_in_studio_%p.log" "-XX:HeapDumpPath=$HOME/java_error_in_studio_.hprof" "-Djb.vmOptionsFile=${USER_VM_OPTIONS_FILE:-${VM_OPTIONS_FILE}}" ${IDE_PROPERTIES_PROPERTY} -Djava.system.class.loader=com.intellij.util.lang.PathClassLoader -Didea.strict.classpath=true -Didea.vendor.name=Google -Didea.paths.selector=AndroidStudio2022.1 -Didea.platform.prefix=AndroidStudio -Didea.jre.check=true -Dsplash=true com.intellij.idea.Main "$@" +``` +Steps to reproduce: +1. Create an Arch Linux chroot from a bootstrap tarball: https://wiki.archlinux.org/title/Install_Arch_Linux_from_existing_Linux#Method_A:_Using_the_bootstrap_tarball_(recommended) +2. Chroot into it using the following script: +``` +#!/bin/bash + +basedir="/home/niko/chroots/arch-x86_64" +cp /etc/resolv.conf ${basedir}/etc/ +cp /usr/bin/qemu-x86_64 ${basedir}/usr/bin/ +sed -i 's!#Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$arch!Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$a> +mount --make-slave --bind ${basedir} ${basedir} +mount -t proc none ${basedir}/proc +mount -t sysfs none ${basedir}/sys/ +mount --make-rslave --rbind /dev ${basedir}/dev +mount --make-rslave --rbind /run ${basedir}/run +chroot ${basedir} /bin/bash +sleep 3 +umount -R ${basedir}/run +umount -R ${basedir}/dev +umount ${basedir}/sys +umount ${basedir}/proc +umount ${basedir} +mount | grep chroots | grep arch-x86_64 | grep -v snap +``` +3. Initialize pacaman keyring and update system: +``` +# pacman-key --init +# pacman-key --populate +# pacman -Syu +``` +4. Install android-studio from the AUR (download `PKGBUILD` and run `makepkg -s`, finally install the package with `pacman -U <packagename>`): https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=android-studio +5. Create an unpriviledged account and run `android-studio` +6. Wait for the crash. +Additional information: +``` +Wed 2023-02-15 12:39:32 CET 117922 1000 1000 SIGSEGV present /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 > +talos2 ~ # coredumpctl gdb 117922 + PID: 117922 (java) + UID: 1000 (niko) + GID: 1000 (niko) + Signal: 11 (SEGV) + Timestamp: Wed 2023-02-15 12:39:25 CET (1min 47s ago) + Command Line: /usr/bin/qemu-x86_64 /opt/android-studio/jbr/bin/java -classpath /opt/android-studio/lib/util.jar:/opt/android-studio/lib/app.jar:/opt/android-studio/lib/3rd-party-rt.jar:/opt/android-studio/lib/jna.jar:/opt/android-studio/lib/platform-statistics-devkit.jar:/opt/android-studio/lib/jps-model.jar:/opt/android-studio/lib/rd-core.jar:/opt/android-studio/lib/rd-framework.jar:/opt/android-studio/lib/stats.jar:/opt/android-studio/lib/protobuf.jar:/opt/android-studio/lib/external-system-rt.jar:/opt/android-studio/lib/forms_rt.jar:/opt/android-studio/lib/intellij-test-discovery.jar:/opt/android-studio/lib/rd-swing.jar:/opt/android-studio/lib/annotations.jar:/opt/android-studio/lib/groovy.jar:/opt/android-studio/lib/annotations-java5.jar:/opt/android-studio/lib/byte-buddy-agent.jar:/opt/android-studio/lib/error-prone-annotations.jar:/opt/android-studio/lib/externalProcess-rt.jar:/opt/android-studio/lib/grpc-netty-shaded.jar:/opt/android-studio/lib/idea_rt.jar:/opt/android-studio/lib/intellij-coverage-agent-1.0.656.jar:/opt/android-studio/lib/junit.jar:/opt/android-studio/lib/junit4.jar:/opt/android-studio/lib/lz4-java.jar:/opt/android-studio/lib/platform-objectSerializer-annotations.jar:/opt/android-studio/lib/pty4j.jar:/opt/android-studio/lib/rd-text.jar:/opt/android-studio/lib/resources.jar:/opt/android-studio/lib/util_rt.jar:/opt/android-studio/lib/winp.jar:/opt/android-studio/lib/ant/lib/ant.jar:/opt/android-studio/lib/dbus-java-3.2.1.jar:/opt/android-studio/lib/java-utils-1.0.6.jar:/opt/android-studio/lib/jnr-unixsocket-0.23.jar:/opt/android-studio/lib/jnr-ffi-2.1.10.jar:/opt/android-studio/lib/jffi-1.2.19.jar:/opt/android-studio/lib/jffi-1.2.19-native.jar:/opt/android-studio/lib/asm-7.1.jar:/opt/android-studio/lib/asm-commons-7.1.jar:/opt/android-studio/lib/asm-analysis-7.1.jar:/opt/android-studio/lib/asm-tree-7.1.jar:/opt/android-studio/lib/asm-util-7.1.jar:/opt/android-studio/lib/jnr-a64asm-1.0.0.jar:/opt/android-studio/lib/jnr-x86asm-1.0.2.jar:/opt/android-studio/lib/jnr-constants-0.9.12.jar:/opt/android-studio/lib/jnr-enxio-0.21.jar:/opt/android-studio/lib/jnr-posix-3.0.50.jar -Xms256m -Xmx1280m -XX:ReservedCodeCacheSize=512m -XX:+IgnoreUnrecognizedVMOptions -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=50 -XX:CICompilerCount=2 -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow -ea -Dsun.io.useCanonCaches=false $'-Djdk.http.auth.tunneling.disabledSchemes=""' -Djdk.attach.allowAttachSelf=true -Djdk.module.illegalAccess.silent=true -Djna.nosys=true -Djna.boot.library.path= -Didea.vendor.name=Google -Dkotlinx.coroutines.debug=off -Dsun.tools.attach.tmp.only=true -XX:ErrorFile=/home/niko/java_error_in_studio_%p.log -XX:HeapDumpPath=/home/niko/java_error_in_studio_.hprof -Djb.vmOptionsFile=/opt/android-studio/bin/studio64.vmoptions -Djava.system.class.loader=com.intellij.util.lang.PathClassLoader -Didea.strict.classpath=true -Didea.vendor.name=Google -Didea.paths.selector=AndroidStudio2022.1 -Didea.platform.prefix=AndroidStudio -Didea.jre.check=true -Dsplash=true com.intellij.idea.Main + Executable: /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 + Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope + Unit: user@1000.service + User Unit: vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope + Slice: user-1000.slice + Owner UID: 1000 (niko) + Boot ID: 33cad872d21043ebbe3dd6581bdd28c6 + Machine ID: b3e834569b8ff461391f5ac061feb773 + Hostname: talos2 + Storage: /var/lib/systemd/coredump/core.java.1000.33cad872d21043ebbe3dd6581bdd28c6.117922.1676461165000000.zst (present) + Size on Disk: 226.7M + Message: Process 117922 (java) of user 1000 dumped core. + +GNU gdb (Gentoo 12.1 vanilla) 12.1 +Copyright (C) 2022 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "powerpc64le-unknown-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://bugs.gentoo.org/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64... +BFD: warning: /var/tmp/coredump-R9M5K3: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000002 +BFD: warning: /var/tmp/coredump-R9M5K3: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001 +BFD: warning: /var/tmp/coredump-R9M5K3: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002 + +warning: Can't open file /opt/android-studio/jbr/bin/java during file-backed mapping note processing + +warning: Can't open file /usr/lib/ld-linux-x86-64.so.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libpthread.so.0 during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/jli/libjli.so during file-backed mapping note processing + +warning: Can't open file /usr/lib/libdl.so.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libc.so.6 during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/server/libjvm.so during file-backed mapping note processing + +warning: Can't open file /usr/lib/libm.so.6 during file-backed mapping note processing + +warning: Can't open file /usr/lib/librt.so.1 during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libverify.so during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libjava.so during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libjimage.so during file-backed mapping note processing + +warning: Can't open file /tmp/hsperfdata_niko/117922 during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libzip.so during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/modules during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libnio.so during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libnet.so during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/util.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/app.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/3rd-party-rt.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/jna.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/platform-statistics-devkit.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/jps-model.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/rd-core.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/rd-framework.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/stats.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/protobuf.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/external-system-rt.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/forms_rt.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/intellij-test-discovery.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/rd-swing.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/annotations.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/groovy.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/annotations-java5.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/byte-buddy-agent.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/error-prone-annotations.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/externalProcess-rt.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/grpc-netty-shaded.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/idea_rt.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/intellij-coverage-agent-1.0.656.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/junit.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/junit4.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/lz4-java.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/platform-objectSerializer-annotations.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/pty4j.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/rd-text.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/resources.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/util_rt.jar during file-backed mapping note processing + +warning: core file may not match specified executable file. +[New LWP 117925] +[New LWP 117924] +[New LWP 117930] +[New LWP 117935] +[New LWP 117933] +[New LWP 117928] +[New LWP 117936] +[New LWP 117922] +[New LWP 117927] +[New LWP 117932] +[New LWP 117929] +[New LWP 117937] +[New LWP 117926] +[New LWP 117934] +[New LWP 117931] +[New LWP 117941] +[New LWP 117939] +[New LWP 117938] +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/usr/lib64/libthread_db.so.1". +Core was generated by `/usr/bin/qemu-x86_64 /opt/android-studio/jbr/bin/java -classpath /opt/android-s'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x00000000102e1c68 in sigsuspend () +[Current thread is 1 (Thread 0x3fffbab18360 (LWP 117925))] +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x3fffbab18360 (LWP 117925) 0x00000000102e1c68 in sigsuspend () + 2 Thread 0x3fffbb3cf360 (LWP 117924) 0x000000001033afec in syscall () + 3 Thread 0x3fffba9d3360 (LWP 117930) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () + 4 Thread 0x3fffba951360 (LWP 117935) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 5 Thread 0x3fffba850360 (LWP 117933) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 6 Thread 0x3fffbaa55360 (LWP 117928) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 7 Thread 0x3fffba910360 (LWP 117936) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () + 8 Thread 0x409e2000 (LWP 117922) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 9 Thread 0x3fffbaa96360 (LWP 117927) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 10 Thread 0x3fffba891360 (LWP 117932) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 11 Thread 0x3fffbaa14360 (LWP 117929) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 12 Thread 0x3fffba60e360 (LWP 117937) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () + 13 Thread 0x3fffbaad7360 (LWP 117926) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 14 Thread 0x3fffba992360 (LWP 117934) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 15 Thread 0x3fffbabce360 (LWP 117931) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () + 16 Thread 0x3fffba7ce360 (LWP 117941) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () + 17 Thread 0x3fffba80f360 (LWP 117939) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 18 Thread 0x3fffba5cd360 (LWP 117938) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +(gdb) thread 1 +[Switching to thread 1 (Thread 0x3fffbab18360 (LWP 117925))] +#0 0x00000000102e1c68 in sigsuspend () +(gdb) thread 2 +[Switching to thread 2 (Thread 0x3fffbb3cf360 (LWP 117924))] +#0 0x000000001033afec in syscall () +(gdb) thread 3 +[Switching to thread 3 (Thread 0x3fffba9d3360 (LWP 117930))] +#0 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () +(gdb) thread 4 +[Switching to thread 4 (Thread 0x3fffba951360 (LWP 117935))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 ../common-user/host/ppc64/safe-syscall.inc.S: No such file or directory. +(gdb) thread 5 +[Switching to thread 5 (Thread 0x3fffba850360 (LWP 117933))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 6 +[Switching to thread 6 (Thread 0x3fffbaa55360 (LWP 117928))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 7 +[Switching to thread 7 (Thread 0x3fffba910360 (LWP 117936))] +#0 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () +(gdb) thread 8 +[Switching to thread 8 (Thread 0x409e2000 (LWP 117922))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 9 +[Switching to thread 9 (Thread 0x3fffbaa96360 (LWP 117927))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 10 +[Switching to thread 10 (Thread 0x3fffba891360 (LWP 117932))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 11 +[Switching to thread 11 (Thread 0x3fffbaa14360 (LWP 117929))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 12 +[Switching to thread 12 (Thread 0x3fffba60e360 (LWP 117937))] +#0 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () +(gdb) thread 13 +[Switching to thread 13 (Thread 0x3fffbaad7360 (LWP 117926))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 14 +[Switching to thread 14 (Thread 0x3fffba992360 (LWP 117934))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 15 +[Switching to thread 15 (Thread 0x3fffbabce360 (LWP 117931))] +#0 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () +(gdb) thread 16 +[Switching to thread 16 (Thread 0x3fffba7ce360 (LWP 117941))] +#0 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () +(gdb) thread 17 +[Switching to thread 17 (Thread 0x3fffba80f360 (LWP 117939))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 18 +[Switching to thread 18 (Thread 0x3fffba5cd360 (LWP 117938))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +``` + +Download full coredump: https://drive.google.com/file/d/1t0Tm6-O6THrOFPp8uO-pbHqv8tZ6XWUe/view?usp=share_link diff --git a/results/classifier/zero-shot/108/all/1495380 b/results/classifier/zero-shot/108/all/1495380 new file mode 100644 index 000000000..07604a26c --- /dev/null +++ b/results/classifier/zero-shot/108/all/1495380 @@ -0,0 +1,30 @@ +other: 0.968 +debug: 0.966 +device: 0.962 +files: 0.958 +network: 0.957 +PID: 0.955 +performance: 0.955 +socket: 0.955 +permissions: 0.954 +graphic: 0.952 +boot: 0.951 +semantic: 0.945 +vnc: 0.944 +KVM: 0.912 + +Invalid parameter 'queues'. multi-queue vhost-user backends does not work. + +The command line which I use: +/usr/bin/qemu-system-x86_64 -name instance-00000006 -S -machine pc-i440fx-2.4,accel=kvm,usb=off -cpu Haswell-noTSX,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -object memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/hugepages/libvirt/qemu,share=yes,size=1073741824 -numa node,nodeid=0,cpus=0,memdev=ram-node0 -uuid 54d61ffc-c8cf-4227-9610-96bcf1590984 -smbios type=1,manufacturer=OpenStack,product=OpenStack,version=2014.1.3,serial=44454c4c-3300-1043-804c-b5c04f463532,uuid=54d61ffc-c8cf-4227-9610-96bcf1590984 -no-user-config -nodefaults -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/54d61ffc-c8cf-4227-9610-96bcf1590984/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -chardev socket,id=charnet0,path=/var/run/vrouter/uvh_vif_tap35abd3c0-4f -netdev type=vhost-user,id=hostnet0,chardev=charnet0,queues=5 -device virtio-net-pci,netdev=hostnet0,id=net0,mq=on,mac=02:35:ab:d3:c0:4f,bus=pci.0,mq=on,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/54d61ffc-c8cf-4227-9610-96bcf1590984/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 10.10.6.14:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on + +The error information : +2015-09-14T06:16:05.914264Z qemu-system-x86_64: -netdev type=vhost-user,id=hostnet0,chardev=charnet0,queues=5: Invalid parameter 'queues' + +You should use qemu 2.5.0. + +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/zero-shot/108/all/1505041 b/results/classifier/zero-shot/108/all/1505041 new file mode 100644 index 000000000..d3ae2451f --- /dev/null +++ b/results/classifier/zero-shot/108/all/1505041 @@ -0,0 +1,115 @@ +other: 0.968 +socket: 0.962 +performance: 0.958 +semantic: 0.957 +permissions: 0.956 +vnc: 0.954 +debug: 0.954 +PID: 0.952 +network: 0.951 +files: 0.949 +graphic: 0.949 +device: 0.949 +boot: 0.923 +KVM: 0.921 + +Live snapshot revert times increases linearly with snapshot age + +The WineTestBot (https://testbot.winehq.org/) uses QEmu live snapshots to ensure the Wine tests are always run in a pristine Windows environment. However the revert times keep increasing linearly with the age of the snapshot, going from tens of seconds to thousands. While the revert takes place the qemu process takes 100% of a core and there is no disk activity. Obviously waiting over 20 minutes before being able to run a 10 second test is not viable. + +Only some VMs are impacted. Based on libvirt's XML files the common point appears to be the presence of the following <timer> tags: + + <clock offset='localtime'> + <timer name='rtc' tickpolicy='delay'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + +Where the unaffected VMs have the following clock definition instead: + + <clock offset='localtime'/> + +Yet shutting down the affected VMs, changing the clock definition, creating a live snapshot and trying to revert to it 6 months later results in slow revert times (>400 seconds). + +Changing the tickpolicy to catchup for rtc and/or pit has no effect on the revert time (and unsurprisingly causes the clock to run fast in the guest). + + +To reproduce this problem do the following: +* Create a Windows VM (either 32 or 64 bits). This is known to happen with at least Windows 2000, XP, 2003, 2008 and 10. +* That VM will have the <timer> tags shown above, with the possible addition of an hypervclock timer. +* Shut down the VM. +* date -s "2014/04/01" +* Start the VM. +* Take a live snapshot. +* Shut down the VM. +* date -s "<your current date>" +* Revert to the live snapshot. + +If the revert takes more than 2 minutes then there is a problem. + + +A workaround is to set track='guest' on the rtc timer. This makes the revert fast and may even be the correct solution. But why is it not the default or better documented? + * It setting track='wall' or omitting track, then the revert is slow and the clock in the guest is not updated. + * It setting track='guest' the revert is fast and the clock in the guest is not updated. + + +I found three past mentions of this issue but as far as I can tell none of them got anywhere: + +* [Qemu-discuss] massive slowdown for reverts after given amount of time on any newer versions + https://lists.gnu.org/archive/html/qemu-discuss/2013-02/msg00000.html + +* The above post references another one from 2011 wrt qemu 0.14: + https://lists.gnu.org/archive/html/qemu-devel/2011-03/msg02645.html + +* Comment #9 of Launchpad bug 1174654 matches this slow revert issue. However + the bug was really about another issue so this was not followed on. + https://bugs.launchpad.net/qemu/+bug/1174654/comments/9 + + +I'm currently running into this issue with QEmu 2.1 but it looks like this bug has been there all along. +1:2.1+dfsg-12+deb8u2 qemu-kvm +1:2.1+dfsg-12+deb8u2 qemu-system-common +1:2.1+dfsg-12+deb8u2 qemu-system-x86 + +I'm unsure why clock time would affect snapshot revert, but one thing to note is that the general recommended timer settings for guest OS are different from what you have. virt-manager/oVirt/OpenStack would all set: + + <clock offset='localtime'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + +in general for all guest OS, and if they have new enough QEMU (>= 2.0.0) + libvirt (>= 1.2.2), they'd go further and for Windows guests would set this + + + <clock offset='localtime'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + <timer name='hypervclock' present='yes'/> + </clock> + + <features> + <hyperv> + <relaxed state='on'/> + <vapic state='on'/> + <spinlocks state='on' retries='8191'/> + </hyperv> + <features/> + +This is fairly important to ensure reliable guest OS clock operation. It also avoids random BSOD on SMP guests from Windows 7 onwards. + +The timer settings I showed were from a Windows XP VM but a Windows 10 VM I created recently (with qemu 2.1 and libvirt 1.2.9) does have the hypervclock timer and defaults to tickpolicy='catchup' for rtc but it is missing the hyperv features you mentioned. I'll investigate those. + +I'm wary of tickpolicy='catchup' though. My understanding is that it's needed for the guest's clock to remain accurate over time. However our VMs stay up at most 30 minutes before being reverted so I don't think the clock will have drifted by any amount we care about. Really it can be off by a few days without impacting the tests. + +One nasty effect of tickpolicy='catchup' is that when we revert to our live snapshot the clock runs 10 times as fast as it tries to catch up to the current date. That would definitely impact our tests, particularly around timing sound play times or checking serial baud rates. We normally manually reset the time from within the guest so maybe that would stop it from running fast. My other concern is that I'm not sure trying to compensate for missing ticks is better for our tests than maintaining the illusion that the VM is running at a normal speed even if it's in reality running at half real time speed. I feel that for our tests agreement between the audio, serial card and various timer devices is more important than staying in sync with the outside world. + +See also: +https://bugs.launchpad.net/qemu/+bug/1174654 + + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1505652 b/results/classifier/zero-shot/108/all/1505652 new file mode 100644 index 000000000..a150a1e5f --- /dev/null +++ b/results/classifier/zero-shot/108/all/1505652 @@ -0,0 +1,93 @@ +permissions: 0.993 +debug: 0.991 +semantic: 0.990 +device: 0.989 +other: 0.987 +performance: 0.985 +graphic: 0.982 +PID: 0.981 +files: 0.974 +socket: 0.971 +boot: 0.969 +network: 0.968 +vnc: 0.964 +KVM: 0.943 + +An IO error happen when qemu snapshot-create + +My qemu version is 1.7.1,but when I try to make live snapshot by libvirt,the libvirt sometimes report an error :qemuMonitorJSONCheckError:377 : internal error: unable to execute QEMU command 'transaction': An IO error has occurred. + +Here is the command being snpshot create by virsh: +virsh snapshot-create snapshot-test.vm snapshot.xml --no-metadata --disk-only --reuse-external +the snapshot.xml: +<domainsnapshot> + <description>test</description> + <disks> + <disk name='vda' snapshot="external"> + <source dev='/home/disk/sbd8' file='/home/disk/sdb8' type="block"/> + </disk> + </disks> +</domainsnapshot> + + +I have read the qemu code about the snapshot create, and I find the qemu when call the function handle_aiocb_rw_linear(): +static ssize_t handle_aiocb_rw_linear(RawPosixAIOData *aiocb, char *buf) +{ + ssize_t offset = 0; + ssize_t len; + + while (offset < aiocb->aio_nbytes) { + if (aiocb->aio_type & QEMU_AIO_WRITE) { + len = pwrite(aiocb->aio_fildes, + (const char *)buf + offset, + aiocb->aio_nbytes - offset, + aiocb->aio_offset + offset); + } else { + len = pread(aiocb->aio_fildes, + buf + offset, + aiocb->aio_nbytes - offset, + aiocb->aio_offset + offset); + } + if (len == -1 && errno == EINTR) { + continue; + } else if (len == -1) { + offset = -errno; + break; + } else if (len == 0) { + break; + } + offset += len; + } + + return offset; +} + +The function pwrite happen error,the errono is 1,and the error describe:"pwrite failed, Operation not permitted (1, EPERM) because the process does not have the appropriate privileges to use the pwrite system call". +The qemu call stack about is: +external_snapshot_prepare()->bdrv_flush()->...->paio_submit->...->handle_aiocb_rw_linear. + +Please ask the libvirt community for help. This issue is probably related to your libvirt storage setup. + +On Tue, Oct 13, 2015 at 11:52:26AM -0000, jiangchi68 wrote: +> My qemu version is 1.7.1,but when I try to make live snapshot by +> libvirt,the libvirt sometimes report an error +> :qemuMonitorJSONCheckError:377 : internal error: unable to execute QEMU +> command 'transaction': An IO error has occurred. +> +> Here is the command being snpshot create by virsh: +> virsh snapshot-create snapshot-test.vm snapshot.xml --no-metadata --disk-only --reuse-external +> the snapshot.xml: +> <domainsnapshot> +> <description>test</description> +> <disks> +> <disk name='vda' snapshot="external"> +> <source dev='/home/disk/sbd8' file='/home/disk/sdb8' type="block"/> +> </disk> +> </disks> +> </domainsnapshot> + +Please send your question to <email address hidden>. + +It could be related to /home/disk file permissions. + + diff --git a/results/classifier/zero-shot/108/all/1562 b/results/classifier/zero-shot/108/all/1562 new file mode 100644 index 000000000..27c504f64 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1562 @@ -0,0 +1,144 @@ +other: 0.985 +debug: 0.981 +permissions: 0.980 +semantic: 0.979 +graphic: 0.976 +performance: 0.975 +socket: 0.974 +PID: 0.973 +device: 0.973 +files: 0.970 +vnc: 0.962 +network: 0.960 +boot: 0.948 +KVM: 0.937 + +qemu live migration with compression ( zstd or zlib ) in same server always(100% reproduce) failed (recevied ram page flag 0x0) +Description of problem: + +Steps to reproduce: +1. live migration with compress mode in same server +2. src: qemu-system-x86_64 -cpu Cascadelake-Server-v4 -smp 10 -enable-kvm -m 50G -nographic -serial telnet:localhost:4321,server,nowait -nic tap,ifname=tap0,script=no,downscript=no CentOS-Stream-GenericCloud-9-20230123.0.x86_64_test_0.qcow2 + +``` + QEMU 7.2.91 monitor - type 'help' for more information +(qemu) migrate_set_capability compress on +(qemu) migrate_set_parameter multifd-compression zstd +(qemu) info migrate_capabilities +xbzrle: off +rdma-pin-all: off +auto-converge: off +zero-blocks: off +compress: on +events: off +postcopy-ram: off +x-colo: off +release-ram: off +block: off +return-path: off +pause-before-switchover: off +multifd: off +dirty-bitmaps: off +postcopy-blocktime: off +late-block-activate: off +x-ignore-shared: off +validate-uuid: off +background-snapshot: off +zero-copy-send: off +postcopy-preempt: off +(qemu) info migrate_parameters +announce-initial: 50 ms +announce-max: 550 ms +announce-rounds: 5 +announce-step: 100 ms +compress-level: 1 +compress-threads: 8 +compress-wait-thread: on +decompress-threads: 2 +throttle-trigger-threshold: 50 +cpu-throttle-initial: 20 +cpu-throttle-increment: 10 +cpu-throttle-tailslow: off +max-cpu-throttle: 99 +tls-creds: '' +tls-hostname: '' +max-bandwidth: 134217728 bytes/second +downtime-limit: 300 ms +x-checkpoint-delay: 20000 ms +block-incremental: off +multifd-channels: 2 +multifd-compression: zstd +xbzrle-cache-size: 67108864 bytes +max-postcopy-bandwidth: 0 +tls-authz: '' +(qemu) migrate -d tcp:localhost:4444 +(qemu) qemu-system-x86_64: failed to save SaveStateEntry with id(name): 2(ram): -5 +qemu-system-x86_64: Unable to write to socket: Connection reset by peer +``` + +3.dest(in same server): qemu-system-x86_64 -cpu Cascadelake-Server-v4 -smp 10 -enable-kvm -m 50G -nographic -serial telnet:localhost:4322,server,nowait -nic tap,ifname=tap1,script=no,downscript=no --incoming tcp:0:4444 CentOS-Stream-GenericCloud-9-20230123.0.x86_64_test_0.qcow2 + +``` + QEMU 7.2.91 monitor - type 'help' for more information +(qemu) migrate_set_capability compress on +(qemu) migrate_set_parameter multifd-compression zstd +(qemu) info mi +mice migrate migrate_capabilities +migrate_parameters +(qemu) info migrate_capabilities +xbzrle: off +rdma-pin-all: off +auto-converge: off +zero-blocks: off +compress: on +events: off +postcopy-ram: off +x-colo: off +release-ram: off +block: off +return-path: off +pause-before-switchover: off +multifd: off +dirty-bitmaps: off +postcopy-blocktime: off +late-block-activate: off +x-ignore-shared: off +validate-uuid: off +background-snapshot: off +zero-copy-send: off +postcopy-preempt: off +(qemu) info migr +migrate migrate_capabilities migrate_parameters +(qemu) info migrate_parameters +announce-initial: 50 ms +announce-max: 550 ms +announce-rounds: 5 +announce-step: 100 ms +compress-level: 1 +compress-threads: 8 +compress-wait-thread: on +decompress-threads: 2 +throttle-trigger-threshold: 50 +cpu-throttle-initial: 20 +cpu-throttle-increment: 10 +cpu-throttle-tailslow: off +max-cpu-throttle: 99 +tls-creds: '' +tls-hostname: '' +max-bandwidth: 134217728 bytes/second +downtime-limit: 300 ms +x-checkpoint-delay: 20000 ms +block-incremental: off +multifd-channels: 2 +multifd-compression: zstd +xbzrle-cache-size: 67108864 bytes +max-postcopy-bandwidth: 0 +tls-authz: '' +(qemu) info migrate_capabilitiesqemu-system-x86_64: Unknown combination of migration flags: 0x0 +qemu-system-x86_64: decompress data failed +qemu-system-x86_64: error while loading state section id 2(ram) +qemu-system-x86_64: load of migration failed: Operation not permitted +``` +Additional information: +$ zstd -V +*** zstd command line interface 64-bits v1.5.1, by Yann Collet *** diff --git a/results/classifier/zero-shot/108/all/1587065 b/results/classifier/zero-shot/108/all/1587065 new file mode 100644 index 000000000..c30fa9729 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1587065 @@ -0,0 +1,248 @@ +permissions: 0.973 +device: 0.972 +debug: 0.966 +performance: 0.965 +files: 0.964 +semantic: 0.962 +socket: 0.962 +other: 0.960 +PID: 0.957 +boot: 0.956 +graphic: 0.949 +vnc: 0.944 +KVM: 0.935 +network: 0.928 + +btrfs qemu-ga - multiple mounts block fsfreeze + +Having two mounts of the same device makes fsfreeze through qemu-ga impossible. +root@CmsrvMTA:/# mount -l | grep /dev/vda2 +/dev/vda2 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@) +/dev/vda2 on /home type btrfs (rw,relatime,space_cache,subvolid=258,subvol=/@home) + +Having two mounts is rather common with btrfs, so the feature fsfreeze is unusable on these systems. + + +Below more information about how we encountered this issue... + +Message send to <email address hidden>: + +Message 1: +---------- +I use external snapshots to backup my guests. I use the 'quiesce' option to flush and frees the guest file system with the qemu guest agent. + +With the exeption of one guest, this procedure works fine. On the 'unwilling' guest, I get this error message: +"ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze /: Device or resource busy" + +I don't think this is not some sort of time-out error, because activation of the fsfreeze and the error message happen immediately after each other: + +$ grep qemu-ga syslog.1 +May 25 00:51:19 CmsrvMTA qemu-ga: info: guest-fsfreeze called + +This is the only entry of the qemu guest agent in syslog. + +$ sudo virsh version +Compiled against library: libvirt 1.3.1 +Using library: libvirt 1.3.1 +Gebruikte API: QEMU 1.3.1 +Draaiende hypervisor: QEMU 2.5.0 + +$ virsh qemu-agent-command CmsrvMTA '{"execute": "guest-info"}' +{"return":{"version":"2.5.0", ... ,{"enabled":true,"name":"guest-fstrim","success-response":true},{"enabled":true,"name":"guest-fsfreeze-thaw","success-response":true},{"enabled":true,"name":"guest-fsfreeze-status","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze-list","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze","success-response":true}, ... } + +For making an external snapshot, I use this command: +$ virsh snapshot-create-as --domain CmsrvMTA sn1 --disk-only --atomic --quiesce --no-metadata --diskspec vda,file=/srv/poolVMS/CmsrvMTA.sn1 + +Piece of reply 1: +----------------- +I have encountered this before. Some operating systems + may have bind-mounts that let a device appear multiple times in the mount list. Unfortunately the guest agent is not smart enough to consider a device that has been frozen as succesfull and keep going. This causes this specific error. + +Piece of reply 2: +----------------- +Ok, that seems to be it. + +I’ve got the ‘/’ and ‘/home’ on the same device formatted as btrfs on two separate sub volumes. + +I'm the responder from the Qemu list. I reviewed that C code a while ago when I stumbled over it. If someone helps me through the Qemu patch acceptance process then I'm willing to provide a patch. + +I have a related Problem with a libvirt Guest running some Docker-Containers. + +root@docker1:~# df -h +Filesystem Size Used Avail Use% Mounted on +/dev/sda1 7.9G 2.9G 4.6G 39% / +udev 10M 0 10M 0% /dev +tmpfs 794M 8.6M 785M 2% /run +tmpfs 2.0G 672K 2.0G 1% /dev/shm +tmpfs 5.0M 0 5.0M 0% /run/lock +tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup +none 7.9G 2.9G 4.6G 39% /var/lib/docker/aufs/mnt/8b510e9eb71523cf9afc723e11831a169c822b7251049f95ebed5e978b22184b +shm 64M 0 64M 0% /var/lib/docker/containers/3d5542423739bc1a4467ce5e15a3b82224d2d1b315af75d7d91a0cc04e1e7b07/shm +none 7.9G 2.9G 4.6G 39% /var/lib/docker/aufs/mnt/5d186a68a1fca2b58a440e6dbdf293853011a9526b819ac1dbcba7f91272535f +shm 64M 0 64M 0% /var/lib/docker/containers/a4355f5e2a66b25a564c5027f818b4385cd417f85d8aaf79700ca4086fb86e63/shm +none 7.9G 2.9G 4.6G 39% /var/lib/docker/aufs/mnt/e972052c347006cd8c79dc5bf9aaba07fdba2edeadc01e18e903d04ca4b05a86 +none 7.9G 2.9G 4.6G 39% /var/lib/docker/aufs/mnt/e22995e962919ea50fcf7b4a5e52916e6839f76708d22e57e81de687af2f0dd0 +shm 64M 0 64M 0% /var/lib/docker/containers/00e3490e37ded90e7421eb19e650cc684dec2b65a848a203c21212a549bf9e0e/shm +shm 64M 0 64M 0% /var/lib/docker/containers/631b37644a0ac106b7d7403c2fcc3760d4647cb96141915b0aa7ae78f98e4e05/shm +root@docker1:~# mount -l | grep /dev/vda2 +root@docker1:~# mount -l | grep /dev/sda +/dev/sda1 on / type ext4 (rw,relatime,discard,errors=remount-ro,data=ordered) +/dev/sda1 on /var/lib/docker/aufs type ext4 (rw,relatime,discard,errors=remount-ro,data=ordered) + +I am not able to take snapshots: + +error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze /: Device or resource busy + +Thank you +Tim + +Strangely I've started having the same problem as Tim this week, beside regular upgrade I did reboot since last backup... (Ubuntu LTS 16.04) + +if I stop docker, the backup will proceed, otherwise i get the same failed to freeze / error message, even with no container running, just the daemon. That's both true with 1.11.2 and 1.12.1 docker dameon version. + +I also have a path mounted twice, but this time it's devicemapper and not AUFS like tim, so maybe not fs type related. + +virsh version: + Compiled against library: libvirt 1.3.1 + Using library: libvirt 1.3.1 + Using API: QEMU 1.3.1 + Running hypervisor: QEMU 2.5.0 + + +KVM/QEMU Host command: + virsh snapshot-create-as $VM_NAME \ + ${VM_NAME}_snapshot \ + "${VM_NAME} snapshot $(date +%Y-%m-%d-%H%M%S)" \ + --diskspec vda,file=${VM_QCOW_FILE}-snap.qcow2 \ + --disk-only \ + --atomic \ + --no-metadata \ + --quiesce + +VM similar mount source: + /dev/mapper/delve--vg-root on / type ext4 (rw,relatime,discard,errors=remount-ro,data=ordered) + /dev/mapper/delve--vg-root on /var/lib/docker/devicemapper type ext4 (rw,relatime,discard,errors=remount-ro,data=ordered) + + +In the VM logs: + Sep 8 12:48:45 xxxxxxxx qemu-ga: info: guest-fsfreeze called + +Same problem here ! More infos : https://forum.opennebula.org/t/backup-live-vms-with-snapshots-quiesce-atomic/4471 + +This has been merged in upstream Qemu a while ago. + +Was that this commit here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ce2eb6c4a044d809c +? +That was included in QEMU v2.9.0, so I think we can set the status to "Fix released" now? + +Any chance this will ever get backported to 2.5 on Xenial? +cheers! + +You've got to open this (or a new bug) against Ubuntu's qemu package to get it included there. So far, this bug here is only opened against the upstream QEMU project. + +This affects Ubuntu 16.04 as in #4 + + + + +Fix is known and seems backportable, marking as server-next and subscribing for somebody to take a look. +Also as mentioned it is in 2.9, so newer releases are already fixed. + +Steps to reproduce + +uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 release=xenial label=daily +uvt-kvm create --password ubuntu x-freeze arch=amd64 release=xenial label=daily + +Add this to the guest definition and restart it +<channel type='unix'> + <source mode='bind'/> + <target type='virtio' name='org.qemu.guest_agent.0'/> +</channel> + +From the host freeze and thaw it: +$ virsh domfsfreeze x-freeze +$ virsh domfsthaw x-freeze + +# The above works + +In the Guest then add a bind mount to trigger the issue +$ sudo mkdir /mnt/test +$ sudo mount -o bind / /mnt/test/ + +Then again try to freeze/unfreeze +$ virsh domfsfreeze x-freeze +error: Unable to freeze filesystems +error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze /: Device or resource busy + + +I installed a fix from my PPA [1] and with that it works just fine now. +Proposing an MP for review by the team, to afterwards move on into SRU processing. + +[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3310 + + +Tests are all ok, MP review was acked and case confirmed. +No Security Update since then in between, so sponsoring into SRU queue now ... + +Hello Dominique, or anyone else affected, + +Accepted qemu into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-5ubuntu10.31 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Prior to the update: + +$ virsh domfsfreeze x-freeze; virsh domfsthaw x-freeze +error: Unable to freeze filesystems +error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze /: Device or resource busy + +Thawed 0 filesystem(s) + + +$ sudo apt install qemu-guest-agent +Reading package lists... Done +Building dependency tree +Reading state information... Done +The following packages will be upgraded: + qemu-guest-agent +1 upgraded, 0 newly installed, 0 to remove and 27 not upgraded. +Need to get 132 kB of archives. +After this operation, 0 B of additional disk space will be used. +Get:1 http://archive.ubuntu.com/ubuntu xenial-proposed/universe amd64 qemu-guest-agent amd64 1:2.5+dfsg-5ubuntu10.31 [132 kB] +Fetched 132 kB in 0s (1.161 kB/s) +(Reading database ... 54125 files and directories currently installed.) +Preparing to unpack .../qemu-guest-agent_1%3a2.5+dfsg-5ubuntu10.31_amd64.deb ... +Unpacking qemu-guest-agent (1:2.5+dfsg-5ubuntu10.31) over (1:2.5+dfsg-5ubuntu10.30) ... +Processing triggers for man-db (2.7.5-1) ... +Processing triggers for systemd (229-4ubuntu21.2) ... +Processing triggers for ureadahead (0.100.0-19) ... +Setting up qemu-guest-agent (1:2.5+dfsg-5ubuntu10.31) ... + + +Retesting the above: +$ virsh domfsfreeze x-freeze; virsh domfsthaw x-freeze +Froze 1 filesystem(s) + +Thawed 1 filesystem(s) + + +Found no other hickups due to the update, setting verified. + +The verification of the Stable Release Update for qemu has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + +This bug was fixed in the package qemu - 1:2.5+dfsg-5ubuntu10.31 + +--------------- +qemu (1:2.5+dfsg-5ubuntu10.31) xenial; urgency=medium + + * d/p/ubuntu/lp-1587065-qga-ignore-EBUSY-when-freezing-a-filesystem.patch: + Fix qemu-guest-agent failing to freeze filesystems that were mounted + multiple times like bind mounts. (LP: #1587065). + + -- Christian Ehrhardt <email address hidden> Thu, 28 Jun 2018 11:35:05 +0200 + diff --git a/results/classifier/zero-shot/108/all/1588 b/results/classifier/zero-shot/108/all/1588 new file mode 100644 index 000000000..6194c7007 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1588 @@ -0,0 +1,184 @@ +permissions: 0.972 +debug: 0.971 +other: 0.969 +semantic: 0.961 +device: 0.958 +vnc: 0.957 +graphic: 0.955 +performance: 0.955 +PID: 0.950 +KVM: 0.941 +socket: 0.941 +network: 0.935 +files: 0.924 +boot: 0.916 + +virsh backup-begin crashes guest - qcow2_get_specific_info: Assertion `false' failed. +Description of problem: +I run a daily backup job of around 350 guests, scattered on different host machines. + +Each day around 1-2 guests crashes on virsh backup-begin with the following error in /var/log/libvirt/qemu/$GUEST.log: + +```qemu-system-x86_64: ../../block/qcow2.c:5175: qcow2_get_specific_info: Assertion `false' failed.``` (https://github.com/qemu/qemu/blob/0c8022876f2183f93e23a7314862140c94ee62e7/block/qcow2.c) + +Different guests every day, no patterns what I can see. + +I'm using a top and a base image with incremental backups, qcow2 compat 1.1, output of qemu-img info of the base and top image; + +``` +qemu-img info base.qcow2 +image: base.qcow2 +file format: qcow2 +virtual size: 5 GiB (5368709120 bytes) +disk size: 1.9 GiB +cluster_size: 65536 +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: false + refcount bits: 16 + corrupt: false + extended l2: false + +qemu-img info -U top.qcow2 +image: top.qcow2 +file format: qcow2 +virtual size: 60 GiB (64424509440 bytes) +disk size: 1.36 GiB +cluster_size: 65536 +backing file: base.qcow2 +backing file format: qcow2 +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: false + bitmaps: + [0]: + flags: + [0]: in-use + [1]: auto + name: 1680670811 + granularity: 65536 + refcount bits: 16 + corrupt: false + extended l2: false +``` + +I know I'm not be using the latest qemu and that this is difficult to reproduce. This bug happens in production and upgrading qemu would be a huge task, given that I would have to upgrade the entire production. Nevertheless I of course would be willing to do it if deemed necessary but at this point I'm just looking for directions on how to pin point this bug. + +A "guest-1" grepped version of libvirt debug logs during the seconds this happened: + +``` +2023-04-08 20:37:20.453+0000: 431153: debug : virDomainLookupByName:413 : conn=0x7fbff000ca30, name=guest-1 +2023-04-08 20:37:20.453+0000: 431153: debug : virDomainDispose:348 : release domain 0x7fc068021c60 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.454+0000: 431155: debug : virDomainGetState:2493 : dom=0x7fc068024330, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), state=0x7fc08c052cf0, reason=0x7fc08c052cf4, flags=0x0 +2023-04-08 20:37:20.454+0000: 431155: debug : virDomainDispose:348 : release domain 0x7fc068024330 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.483+0000: 431152: debug : virDomainLookupByName:413 : conn=0x7fc070014e90, name=guest-1 +2023-04-08 20:37:20.483+0000: 431152: debug : virDomainDispose:348 : release domain 0x7fc0500075f0 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.483+0000: 431148: debug : virDomainListAllCheckpoints:292 : dom=0x7fc0ac002380, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), checkpoints=0x7fc0b79018a8, flags=0x0 +2023-04-08 20:37:20.483+0000: 431148: debug : virDomainDispose:348 : release domain 0x7fc0ac002380 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.484+0000: 431151: debug : virDomainDispose:348 : release domain 0x7fc0b0006950 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.516+0000: 431150: debug : virDomainLookupByName:413 : conn=0x7fc0a80027a0, name=guest-1 +2023-04-08 20:37:20.516+0000: 431150: debug : virDomainDispose:348 : release domain 0x7fc08c007c60 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.516+0000: 431152: debug : virDomainGetState:2493 : dom=0x7fc068021e90, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), state=0x7fc0a47c64d0, reason=0x7fc0a47c64d4, flags=0x0 +2023-04-08 20:37:20.516+0000: 431152: debug : virDomainDispose:348 : release domain 0x7fc068021e90 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.544+0000: 431156: debug : virDomainLookupByName:413 : conn=0x7fc0a80025a0, name=guest-1 +2023-04-08 20:37:20.544+0000: 431156: debug : virDomainDispose:348 : release domain 0x7fc068029d00 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.544+0000: 431149: debug : virDomainSuspend:623 : dom=0x7fc050007500, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f) +2023-04-08 20:37:20.544+0000: 431149: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=suspend agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=none) +2023-04-08 20:37:20.544+0000: 431149: debug : qemuDomainObjBeginJobInternal:883 : Started job: suspend (async=none vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.544+0000: 431149: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.580+0000: 1882669: debug : qemuProcessHandleStop:660 : Transitioned guest guest-1 to paused state, reason user, event detail 0 +2023-04-08 20:37:20.580+0000: 1882669: debug : virLockManagerLogParams:90 : key=name type=string value=guest-1 +2023-04-08 20:37:20.580+0000: 1882669: debug : virDomainLockManagerAddImage:90 : Add disk /home/vm/domains/guest-1/disk.qcow2 +2023-04-08 20:37:20.580+0000: 1882669: debug : virLockManagerAddResource:325 : lock=0x7fbf8801fdc0 type=0 name=/home/vm/domains/guest-1/disk.qcow2 nparams=0 params=(nil) flags=0x0 +2023-04-08 20:37:20.581+0000: 431149: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.581+0000: 431149: debug : virLockManagerLogParams:90 : key=name type=string value=guest-1 +2023-04-08 20:37:20.581+0000: 431149: debug : virDomainLockManagerAddImage:90 : Add disk /home/vm/domains/guest-1/disk.qcow2 +2023-04-08 20:37:20.581+0000: 431149: debug : virLockManagerAddResource:325 : lock=0x7fc0a8968e60 type=0 name=/home/vm/domains/guest-1/disk.qcow2 nparams=0 params=(nil) flags=0x0 +2023-04-08 20:37:20.582+0000: 431149: debug : qemuDomainObjEndJob:1135 : Stopping job: suspend (async=none vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.582+0000: 431149: debug : virDomainDispose:348 : release domain 0x7fc050007500 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.608+0000: 431148: debug : virDomainLookupByName:413 : conn=0x7fbff000cc30, name=guest-1 +2023-04-08 20:37:20.608+0000: 431148: debug : virDomainDispose:348 : release domain 0x7fc07001e330 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.608+0000: 431151: debug : virDomainGetState:2493 : dom=0x7fc050007550, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), state=0x7fc0a003d640, reason=0x7fc0a003d644, flags=0x0 +2023-04-08 20:37:20.608+0000: 431151: debug : virDomainDispose:348 : release domain 0x7fc050007550 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.634+0000: 431150: debug : virDomainLookupByName:413 : conn=0x7fc0a8002ea0, name=guest-1 +2023-04-08 20:37:20.634+0000: 431150: debug : virDomainDispose:348 : release domain 0x7fbfc00072e0 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.634+0000: 431152: debug : virDomainBackupBegin:13040 : dom=0x7fc0500075f0, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), backupXML=<domainbackup><incremental>1680930625</incremental></domainbackup>, checkpointXML=<domaincheckpoint><name>1680986240</name></domaincheckpoint>, flags=0x0 +2023-04-08 20:37:20.667+0000: 431152: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=none agentJob=none asyncJob=backup (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=none) +2023-04-08 20:37:20.667+0000: 431152: debug : qemuDomainObjBeginJobInternal:892 : Started async job: backup (vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.668+0000: 431152: debug : virStringMatch:662 : match '/home/vm/domains/guest-1/qemu.agent' for '^/var/lib/libvirt/qemu/channel/target/([^/]+\.)|(domain-[^/]+/)org\.qemu\.guest_agent\.0$' +2023-04-08 20:37:20.669+0000: 431152: debug : virStringMatch:662 : match '/home/vm/domains/guest-1/qemu.agent' for '^/var/lib/libvirt/qemu/channel/target/([^/]+\.)|(domain-[^/]+/)org\.qemu\.guest_agent\.0$' +2023-04-08 20:37:20.670+0000: 431152: debug : virStringMatch:662 : match '/home/vm/domains/guest-1/qemu.agent' for '^/var/lib/libvirt/qemu/channel/target/([^/]+\.)|(domain-[^/]+/)org\.qemu\.guest_agent\.0$' +2023-04-08 20:37:20.670+0000: 431152: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=async nested agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=backup) +2023-04-08 20:37:20.670+0000: 431152: debug : qemuDomainObjBeginJobInternal:883 : Started job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.670+0000: 431152: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.671+0000: 1882669: debug : qemuMonitorJSONIOProcessLine:222 : Line [{"return": [{"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 32212254720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 7361290240, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-format", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "dirty-bitmaps": [{"name": "1680930625", "recording": true, "persistent": true, "busy": false, "granularity": 65536, "count": 458293248}], "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}, {"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 7882014720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "format": "file", "actual-size": 7361290240, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-storage", "backing_file_depth": 0, "drv": "file", "iops": 0, "bps_wr": 0, "write_threshold": 0, "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}], "id": "libvirt-39597736"}] +2023-04-08 20:37:20.671+0000: 1882669: debug : virJSONValueFromString:1691 : string={"return": [{"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 32212254720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 7361290240, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-format", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "dirty-bitmaps": [{"name": "1680930625", "recording": true, "persistent": true, "busy": false, "granularity": 65536, "count": 458293248}], "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}, {"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 7882014720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "format": "file", "actual-size": 7361290240, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-storage", "backing_file_depth": 0, "drv": "file", "iops": 0, "bps_wr": 0, "write_threshold": 0, "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}], "id": "libvirt-39597736"} +2023-04-08 20:37:20.672+0000: 1882669: info : qemuMonitorJSONIOProcessLine:241 : QEMU_MONITOR_RECV_REPLY: mon=0x7fc0480048b0 reply={"return": [{"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 32212254720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 7361290240, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-format", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "dirty-bitmaps": [{"name": "1680930625", "recording": true, "persistent": true, "busy": false, "granularity": 65536, "count": 458293248}], "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}, {"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 7882014720, "filename": "/home/vm/domains/guest-1/disk.qcow2", "format": "file", "actual-size": 7361290240, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "libvirt-1-storage", "backing_file_depth": 0, "drv": "file", "iops": 0, "bps_wr": 0, "write_threshold": 0, "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback": true}, "file": "/home/vm/domains/guest-1/disk.qcow2"}], "id": "libvirt-39597736"} +2023-04-08 20:37:20.672+0000: 431152: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.672+0000: 431152: debug : qemuDomainObjEndJob:1135 : Stopping job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.672+0000: 431152: debug : virStorageFileBackendFileInit:57 : initializing FS storage file 0x7fc0704b3740 (file:/home/vm/domains/guest-1/disk.qcow2.1680986240)[64055:108] +2023-04-08 20:37:20.672+0000: 431152: debug : qemuDomainStorageSourceAccessModify:7767 : src='/home/vm/domains/guest-1/disk.qcow2.1680986240' readonly=0 force_ro=0 force_rw=1 revoke=0 chain=0 +2023-04-08 20:37:20.672+0000: 431152: debug : virLockManagerLogParams:90 : key=name type=string value=guest-1 +2023-04-08 20:37:20.672+0000: 431152: debug : virDomainLockManagerAddImage:90 : Add disk /home/vm/domains/guest-1/disk.qcow2.1680986240 +2023-04-08 20:37:20.672+0000: 431152: debug : virLockManagerAddResource:325 : lock=0x7fc0a460ca40 type=0 name=/home/vm/domains/guest-1/disk.qcow2.1680986240 nparams=0 params=(nil) flags=0x0 +2023-04-08 20:37:20.683+0000: 431152: debug : virCommandRunAsync:2630 : About to run LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -r -u libvirt-29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f -F /home/vm/domains/guest-1/disk.qcow2.1680986240 +2023-04-08 20:37:20.796+0000: 431151: debug : virDomainLookupByName:413 : conn=0x7fc0a80020a0, name=guest-1 +2023-04-08 20:37:20.893+0000: 431152: debug : qemuSetupImagePathCgroup:74 : Allow path /home/vm/domains/guest-1/disk.qcow2.1680986240, perms: rw +2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=async nested agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=backup) +2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjBeginJobInternal:883 : Started job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjEndJob:1135 : Stopping job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=async nested agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=backup) +2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjBeginJobInternal:883 : Started job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.894+0000: 431152: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.894+0000: 431151: debug : virDomainDispose:348 : release domain 0x7fc014007240 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.894+0000: 431152: info : qemuMonitorSend:914 : QEMU_MONITOR_SEND_MSG: mon=0x7fc0480048b0 msg={"execute":"blockdev-add","arguments":{"driver":"file","filename":"/home/vm/domains/guest-1/disk.qcow2.1680986240","node-name":"libvirt-78-storage","auto-read-only":true,"discard":"unmap"},"id":"libvirt-39597737"} +2023-04-08 20:37:20.894+0000: 1882669: info : qemuMonitorIOWrite:402 : QEMU_MONITOR_IO_WRITE: mon=0x7fc0480048b0 buf={"execute":"blockdev-add","arguments":{"driver":"file","filename":"/home/vm/domains/guest-1/disk.qcow2.1680986240","node-name":"libvirt-78-storage","auto-read-only":true,"discard":"unmap"},"id":"libvirt-39597737"} +2023-04-08 20:37:20.895+0000: 1385058: debug : virDomainGetInfo:2444 : dom=0x7fc0ac001b80, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), info=0x7fc009ffa880 +2023-04-08 20:37:20.895+0000: 1385058: debug : virDomainDispose:348 : release domain 0x7fc0ac001b80 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:20.895+0000: 431149: debug : virDomainGetBlockInfo:6284 : dom=0x7fc068024100, (VM: name=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f), info=0x7fc0b7100890, flags=0x0 +2023-04-08 20:37:20.895+0000: 431149: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=query agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=async nested agentJob=none async=backup) +2023-04-08 20:37:20.895+0000: 431149: debug : qemuDomainObjBeginJobInternal:867 : Waiting for job (vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.895+0000: 431152: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.895+0000: 431152: debug : qemuDomainObjEndJob:1135 : Stopping job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.896+0000: 431152: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=async nested agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=backup) +2023-04-08 20:37:20.896+0000: 431152: debug : qemuDomainObjBeginJobInternal:883 : Started job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.896+0000: 431152: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.896+0000: 431149: debug : qemuDomainObjBeginJobInternal:867 : Waiting for job (vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.896+0000: 431152: info : qemuMonitorSend:914 : QEMU_MONITOR_SEND_MSG: mon=0x7fc0480048b0 msg={"execute":"blockdev-create","arguments":{"job-id":"create-libvirt-78-format","options":{"driver":"qcow2","file":"libvirt-78-storage","size":32212254720,"cluster-size":65536,"backing-file":"/home/vm/domains/guest-1/disk.qcow2","backing-fmt":"qcow2"}},"id":"libvirt-39597738"} +2023-04-08 20:37:20.896+0000: 1882669: info : qemuMonitorIOWrite:402 : QEMU_MONITOR_IO_WRITE: mon=0x7fc0480048b0 buf={"execute":"blockdev-create","arguments":{"job-id":"create-libvirt-78-format","options":{"driver":"qcow2","file":"libvirt-78-storage","size":32212254720,"cluster-size":65536,"backing-file":"/home/vm/domains/guest-1/disk.qcow2","backing-fmt":"qcow2"}},"id":"libvirt-39597738"} +2023-04-08 20:37:20.898+0000: 1882669: debug : qemuProcessHandleJobStatusChange:956 : job 'create-libvirt-78-format'(domain: 0x7fc0a4033a10,guest-1) state changed to 'created'(1) +2023-04-08 20:37:20.898+0000: 1882669: debug : qemuProcessHandleJobStatusChange:956 : job 'create-libvirt-78-format'(domain: 0x7fc0a4033a10,guest-1) state changed to 'running'(2) +2023-04-08 20:37:20.898+0000: 431152: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.898+0000: 431152: debug : qemuDomainObjEndJob:1135 : Stopping job: async nested (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.899+0000: 431149: debug : qemuDomainObjBeginJobInternal:883 : Started job: query (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:20.899+0000: 431149: debug : qemuDomainObjEnterMonitorInternal:5872 : Entering monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:21.432+0000: 1882669: debug : qemuProcessHandleAgentEOF:147 : Received EOF from agent on 0x7fc0a4033a10 'guest-1' +2023-04-08 20:37:21.432+0000: 1882669: debug : qemuMonitorIO:576 : Error on monitor Unable to read from monitor: Connection reset by peer mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1 +2023-04-08 20:37:21.432+0000: 1882669: debug : qemuMonitorIO:609 : Triggering error callback mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1 +2023-04-08 20:37:21.432+0000: 1882669: debug : qemuProcessHandleMonitorError:355 : Received error on 0x7fc0a4033a10 'guest-1' +2023-04-08 20:37:21.432+0000: 431149: debug : qemuMonitorSend:927 : Send command resulted in error Unable to read from monitor: Connection reset by peer mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1 +2023-04-08 20:37:21.433+0000: 431149: debug : qemuDomainObjExitMonitor:5902 : Exited monitor (mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:21.433+0000: 1882669: debug : qemuMonitorIO:576 : Error on monitor Unable to read from monitor: Connection reset by peer mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1 +2023-04-08 20:37:21.433+0000: 431149: debug : qemuDomainObjEndJob:1135 : Stopping job: query (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:21.433+0000: 1882669: debug : qemuMonitorIO:598 : Triggering EOF callback mon=0x7fc0480048b0 vm=0x7fc0a4033a10 name=guest-1 +2023-04-08 20:37:21.433+0000: 1882669: debug : qemuProcessHandleMonitorEOF:310 : Received EOF on 0x7fc0a4033a10 'guest-1' +2023-04-08 20:37:21.433+0000: 431149: debug : virDomainDispose:348 : release domain 0x7fc068024100 guest-1 29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f +2023-04-08 20:37:21.433+0000: 620333: debug : qemuProcessKill:7931 : vm=0x7fc0a4033a10 name=guest-1 pid=1882665 flags=0x1 +2023-04-08 20:37:21.633+0000: 620333: debug : qemuDomainObjBeginJobInternal:831 : Starting job: job=destroy agentJob=none asyncJob=none (vm=0x7fc0a4033a10 name=guest-1, current job=none agentJob=none async=backup) +2023-04-08 20:37:21.633+0000: 620333: debug : qemuDomainObjBeginJobInternal:883 : Started job: destroy (async=backup vm=0x7fc0a4033a10 name=guest-1) +2023-04-08 20:37:21.634+0000: 620333: debug : processMonitorEOFEvent:4025 : Monitor connection to 'guest-1' closed without SHUTDOWN event; assuming the domain crashed +2023-04-08 20:37:21.634+0000: 620333: debug : qemuProcessStop:8014 : Shutting down vm=0x7fc0a4033a10 name=guest-1 id=814 pid=1882665, reason=crashed, asyncJob=none, flags=0x0 +2023-04-08 20:37:21.634+0000: 620333: debug : qemuDomainLogAppendMessage:6740 : Append log message (vm='guest-1' message='2023-04-08 20:37:21.634+0000: shutting down, reason=crashed +2023-04-08 20:37:22.617+0000: 620333: debug : qemuProcessKill:7931 : vm=0x7fc0a4033a10 name=guest-1 pid=1882665 flags=0x5 +2023-04-08 20:37:22.617+0000: 620333: debug : qemuDomainCleanupRun:7321 : driver=0x7fc07015c730, vm=guest-1 +2023-04-08 20:37:22.617+0000: 620333: debug : qemuProcessAutoDestroyRemove:8416 : vm=guest-1 +2023-04-08 20:37:22.617+0000: 620333: debug : virCloseCallbacksUnset:145 : vm=guest-1, uuid=29ac5dd8-6eb9-4140-a9d1-cdcbae01ac0f, cb=0x7fc09e3f9ba0 +``` + +If you need any further information just let me know. As per request, ping @pipo.sk +Additional information: + diff --git a/results/classifier/zero-shot/108/all/1594239 b/results/classifier/zero-shot/108/all/1594239 new file mode 100644 index 000000000..dbddb0c7a --- /dev/null +++ b/results/classifier/zero-shot/108/all/1594239 @@ -0,0 +1,1703 @@ +PID: 0.980 +device: 0.980 +other: 0.978 +files: 0.978 +boot: 0.976 +graphic: 0.976 +performance: 0.967 +debug: 0.964 +permissions: 0.964 +network: 0.963 +semantic: 0.957 +socket: 0.956 +vnc: 0.938 +KVM: 0.937 + +After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error + +Description +=========== +Using virt-manager to create a VM in Aarch64, Ubuntu 16.04. +Add scsi disk to the VM. After add four or more scsi disks, start the VM and will got Qemu error. + +Steps to reproduce +================== +1.Use virt-manager to create a VM. +2.After the VM is started, add scsi disk to the VM. They will be allocated to "sdb,sdc,sdd....." . +3.If we got a disk name > sdg, virt-manager will also assign a virtio-scsi controller for this disk.And the VM will be shutdown. +4.Start the VM, will see the error log. + + +Expected result +=============== +Start the vm smoothly.The added disks can work. + +Actual result +============= +Got the error: +starting domain: internal error: process exited while connecting to monitor: qemu-system-aarch64: /build/qemu-zxCwKP/qemu-2.5+dfsg/migration/savevm.c:620: vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id == 0' failed. +details=Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 90, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 126, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/domain.py", line 1402, in startup + self._backend.create() + File "/usr/local/lib/python2.7/dist-packages/libvirt.py", line 1035, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirtError: internal error: process exited while connecting to monitor: qemu-system-aarch64: /build/qemu-zxCwKP/qemu-2.5+dfsg/migration/savevm.c:620: vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id == 0' failed. + + +Environment +=========== +1. virt-manager version is 1.3.2 + +2. Which hypervisor did you use? + Libvirt+KVM + $ kvm --version + QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.1), Copyright (c) 2003-2008 Fabrice Bellard + $ libvirtd --version + libvirtd (libvirt) 1.3.1 + +3. Which storage type did you use? + In the host file system,all in one physics machine. +stack@u202154:/opt/stack/nova$ df -hl +Filesystem Size Used Avail Use% Mounted on +udev 7.8G 0 7.8G 0% /dev +tmpfs 1.6G 61M 1.6G 4% /run +/dev/sda2 917G 41G 830G 5% / +tmpfs 7.9G 0 7.9G 0% /dev/shm +tmpfs 5.0M 0 5.0M 0% /run/lock +tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup +/dev/sda1 511M 888K 511M 1% /boot/efi +cgmfs 100K 0 100K 0% /run/cgmanager/fs +tmpfs 1.6G 0 1.6G 0% /run/user/1002 +tmpfs 1.6G 0 1.6G 0% /run/user/1000 +tmpfs 1.6G 0 1.6G 0% /run/user/0 + +4. Environment information: + Architecture : AARCH64 + OS: Ubuntu 16.04 + +The Qemu commmand of libvirt is : +2016-06-20 02:39:46.561+0000: starting up libvirt version: 1.3.1, package: 1ubuntu10 (William Grant <email address hidden> Fri, 15 Apr 2016 12:08:21 +1000), qemu version: 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.1), hostname: u202154 +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name cent7 -S -machine virt,accel=kvm,usb=off -cpu host -drive file=/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/cent7_VARS.fd,if=pflash,format=raw,unit=1 -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid d5462bb6-159e-4dbd-9266-bf8c07fa1695 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-cent7/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 -device virtio-scsi-device,id=scsi0 -device lsi,id=scsi1 -device lsi,id=scsi2 -device virtio-scsi-device,id=scsi3 -usb -drive file=/var/lib/libvirt/images/cent7-2.img,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -drive file=/var/lib/libvirt/images/cent7-10.img,format=qcow2,if=none,id=drive-scsi0-0-0-2 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-0-2,id=scsi0-0-0-2 -drive file=/var/lib/libvirt/images/cent7-11.img,format=qcow2,if=none,id=drive-scsi0-0-0-3 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=3,drive=drive-scsi0-0-0-3,id=scsi0-0-0-3 -drive file=/var/lib/libvirt/images/cent7-13.img,format=qcow2,if=none,id=drive-scsi3-0-0-0 -device scsi-hd,bus=scsi3.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi3-0-0-0,id=scsi3-0-0-0 -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=35 -device virtio-net-device,netdev=hostnet0,id=net0,mac=52:54:00:a1:6e:75 -serial pty -msg timestamp=on +Domain id=11 is tainted: host-cpu + +The libvirt xml is: +<domain type='kvm'> + <name>cent7</name> + <uuid>d5462bb6-159e-4dbd-9266-bf8c07fa1695</uuid> + <memory unit='KiB'>2097152</memory> + <currentMemory unit='KiB'>2097152</currentMemory> + <vcpu placement='static'>2</vcpu> + <os> + <type arch='aarch64' machine='virt'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw</loader> + <nvram>/var/lib/libvirt/qemu/nvram/cent7_VARS.fd</nvram> + <boot dev='hd'/> + </os> + <cpu mode='host-passthrough'/> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/cent7-2.img'/> + <target dev='sda' bus='scsi'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <target dev='sdb' bus='scsi'/> + <readonly/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/cent7-10.img'/> + <target dev='sdc' bus='scsi'/> + <address type='drive' controller='0' bus='0' target='0' unit='2'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/cent7-11.img'/> + <target dev='sdd' bus='scsi'/> + <address type='drive' controller='0' bus='0' target='0' unit='3'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/cent7-13.img'/> + <target dev='sdv' bus='scsi'/> + <address type='drive' controller='3' bus='0' target='0' unit='0'/> + </disk> + <controller type='scsi' index='0' model='virtio-scsi'> + <address type='virtio-mmio'/> + </controller> + <controller type='scsi' index='1'> + <address type='virtio-mmio'/> + </controller> + <controller type='scsi' index='2'> + <address type='virtio-mmio'/> + </controller> + <controller type='scsi' index='3' model='virtio-scsi'> + <address type='virtio-mmio'/> + </controller> + <controller type='pci' index='0' model='pcie-root'/> + <controller type='pci' index='1' model='dmi-to-pci-bridge'> + <model name='i82801b11-bridge'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> + </controller> + <controller type='pci' index='2' model='pci-bridge'> + <model name='pci-bridge'/> + <target chassisNr='2'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:a1:6e:75'/> + <source bridge='br0'/> + <model type='virtio'/> + <address type='virtio-mmio'/> + </interface> + <serial type='pty'> + <target port='0'/> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + </devices> +</domain> + +This turns out to be a bug in libvirt, fixed in 1.3.4 or later; see the discussion here: +https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07217.html +I'm going to close this as 'not a bug', since it's not a bug in QEMU proper. + + +Hi All, + Libvirt fixed in 1.3.4 is about setting machine arch for qemu-2.6, not fix this bug. I have also reproduce in the Qemu2.6 and newest version of libvirt. See procedure as below: +With the Qemu 2.6.50 and libvirt(commit 03ce1328086d6937d2647d616efff29941a3e80a): +I find that the problem that I have met before occurs again. I can reproduce it. + 1. After launching a VM with fedora23(for example), the xml is f23.xml in attachment. + 2. Then use qemu-img command to generate a qemu disk f23-2.qcow2 and f23-3.qcow2 + 3. Add f23-2.qcow2 as sdc. + $ ./virsh attach-device f23 /root/sdc.xml +sdc.xml : + <disk type="file" device="disk"> + <driver name="qemu" type="qcow2"/> + <source file="/var/lib/libvirt/images/f23-2.qcow2"/> + <target dev="sdc" bus="scsi"/> + </disk> + Then in the Guest f23, we can see it takes effect immediately. + + 4. Add f23-3.qcow2 as sdh , also add virtio-scsi controller for sdh. + $ ./virsh edit f23 + add this below + <controller type="scsi" index="1" model="virtio-scsi"/> + <disk type="file" device="disk"> + <driver name="qemu" type="qcow2"/> + <source file="/var/lib/libvirt/images/f23-4.qcow2"/> + <target dev="sdh" bus="scsi"/> + </disk> + $ ./virsh destory f23 && ./.virsh start f23 +Got the error: +2016-06-28 11:37:17.017+0000: 6329: warning : qemuDomainObjTaint:3227 : Domain id=15 name='f23' uuid=e2de65f4-5d9a-4b90-a56a-ae40f4763aec is tainted: high-privileges +2016-06-28 11:37:17.017+0000: 6329: warning : qemuDomainObjTaint:3227 : Domain id=15 name='f23' uuid=e2de65f4-5d9a-4b90-a56a-ae40f4763aec is tainted: host-cpu +2016-06-28 11:37:28.546+0000: 6313: error : qemuMonitorIORead:583 : Unable to read from monitor: Connection reset by peer +2016-06-28 11:37:28.546+0000: 6313: error : qemuProcessReportLogError:1815 : internal error: qemu unexpectedly closed the monitor: qemu-system-aarch64: /opt/stack/kevin/qemu/migration/savevm.c:615: vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id == 0' failed. + +So this bug seems exist with new qemu and new libvirt. + +This seems to be a minimal reproducer: + +qemu-system-aarch64 \ + -machine virt-2.6,accel=tcg \ + -nodefaults \ + -no-user-config \ + -nographic -monitor stdio \ + -device virtio-scsi-device,id=scsi0 \ + -device virtio-scsi-device,id=scsi1 \ + -drive file=foo.img,format=raw,if=none,id=d0 \ + -device scsi-hd,bus=scsi0.0,drive=d0 \ + -drive file=foo.img,format=raw,if=none,id=d1 \ + -device scsi-hd,bus=scsi1.0,drive=d1 + +I'm not 100% sure but I think the problem is we've got two devices with the same qdev path/name and we aren't expecting that when they're children of another device; here's some debug on the aarch64 version: + +(qemu) vmstate_register_with_alias_id: vmsd=cpu_common +vmstate_register_with_alias_id: se->compat=(nil) instance_id=0 +vmstate_register_with_alias_id: vmsd=cpu +vmstate_register_with_alias_id: se->compat=(nil) instance_id=0 +vmstate_register_with_alias_id: vmsd=pflash_cfi01 +vmstate_register_with_alias_id: se->compat=(nil) instance_id=0 +vmstate_register_with_alias_id: vmsd=pflash_cfi01 +vmstate_register_with_alias_id: se->compat=(nil) instance_id=1 +vmstate_register_with_alias_id: vmsd=arm_gic +vmstate_register_with_alias_id: se->compat=(nil) instance_id=0 +vmstate_register_with_alias_id: vmsd=pl011 +vmstate_register_with_alias_id: se->compat=(nil) instance_id=0 +vmstate_register_with_alias_id: vmsd=pl031 +vmstate_register_with_alias_id: se->compat=(nil) instance_id=0 +vmstate_register_with_alias_id: vmsd=gpex_root +vmstate_register_with_alias_id: dev/id case: 0000:00:00.0 +vmstate_register_with_alias_id: se->compat=0x55d911656fa0 instance_id=0 +vmstate_register_with_alias_id: vmsd=PCIBUS +vmstate_register_with_alias_id: se->compat=(nil) instance_id=0 +vmstate_register_with_alias_id: vmsd=pl061 +vmstate_register_with_alias_id: se->compat=(nil) instance_id=0 +vmstate_register_with_alias_id: vmsd=gpio-key +vmstate_register_with_alias_id: se->compat=(nil) instance_id=0 +vmstate_register_with_alias_id: vmsd=fw_cfg +vmstate_register_with_alias_id: se->compat=(nil) instance_id=0 +vmstate_register_with_alias_id: vmsd=scsi-disk +vmstate_register_with_alias_id: dev/id case: 0:0:0 +vmstate_register_with_alias_id: se->compat=0x55d912077020 instance_id=0 +vmstate_register_with_alias_id: vmsd=scsi-disk +vmstate_register_with_alias_id: dev/id case: 0:0:0 +vmstate_register_with_alias_id: se->compat=0x55d912078c90 instance_id=1 +qemu-system-aarch64: /home/dgilbert/git/qemu/migration/savevm.c:624: vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id == 0' failed. + +I think the problem is the names of the virtio-scsi devices - on pci I'd expect to have a PCI bus name for the name of the virtio interface, so that they're pci slot/scsi id; on x86 it won't let me instantiate a virtio-scsi-device - because I don't have a virtio bus, so I have to ask for a virtio-scsi-pci device and then I end up with unique names like: + +vmstate_register_with_alias_id: dev/id case: 0000:00:01.3 +vmstate_register_with_alias_id: se->compat=0x564cdb891a60 instance_id=0 +vmstate_register_with_alias_id: vmsd=scsi-disk +vmstate_register_with_alias_id: dev/id case: 0000:00:02.0/0:0:0 +vmstate_register_with_alias_id: se->compat=0x564cdb95ec30 instance_id=0 +vmstate_register_with_alias_id: vmsd=scsi-disk +vmstate_register_with_alias_id: dev/id case: 0000:00:03.0/0:0:0 + +going back to aarch64 and doing an info qtree we have: + + dev: virtio-mmio, id "" + gpio-out "sysbus-irq" 1 + mmio 000000000a000800/0000000000000200 + bus: virtio-mmio-bus.4 + type virtio-mmio-bus + dev: virtio-mmio, id "" + gpio-out "sysbus-irq" 1 + mmio 000000000a000600/0000000000000200 + bus: virtio-mmio-bus.3 + type virtio-mmio-bus + dev: virtio-mmio, id "" + gpio-out "sysbus-irq" 1 + mmio 000000000a000400/0000000000000200 + bus: virtio-mmio-bus.2 + type virtio-mmio-bus + dev: virtio-mmio, id "" + gpio-out "sysbus-irq" 1 + mmio 000000000a000200/0000000000000200 + bus: virtio-mmio-bus.1 + type virtio-mmio-bus + dev: virtio-mmio, id "" + gpio-out "sysbus-irq" 1 + mmio 000000000a000000/0000000000000200 + bus: virtio-mmio-bus.0 + type virtio-mmio-bus + +Dave + +Dave, + +How did you get the debug info in #4 above? + +I can now replicate the error, but can't get to the monitor. I'm new to qemu so it's probably one of those things I haven't learned yet. + +Thanks, +Tom + +Dave, + +Yeah, well, never mind. :-) + +If I'd looked at the code first I'd have seen the function name and thought about which data I'd want to dump and where, I'd have figured out where the debug data came from. + +-Tom + +Hi Tom, + Yeh it's just vmstate_register_with_alias_id printing vmsd->name at entry, +and then after the char *id = .... printing that as well (that's what I labelled as the dev/id case). +Then just before the assert I was printing the se->compat and se->instance_id values. + +I noticed this bug because one of our test team had hit the same assert a few weeks back on x86, but it was on a truly bizarre setup (~50 nested PCIe bridges) so I knew where to look for it. + +I think the idea is that if you have a se->compat string then it had better be unique (that is instance_id == 0); and the compat string is formed by concatenation of the qdev path and the name of this device. Then we have '0.0.0' as the name of this scsi device (i.e. local to this SCSI adapter) but no path that gives a unique string for the adapter like we do on the x86. + +Dave + +Thanks! That makes sense. But, off the cuff, it seems odd that there's an instance_id if it can only be zero. But then again, it may be overloaded or be applicable in other cases. I'll dig into the code today. + + + +On 07/01/2016 02:27 AM, Dr. David Alan Gilbert wrote: +> Hi Tom, +> Yeh it's just vmstate_register_with_alias_id printing vmsd->name at entry, +> and then after the char *id = .... printing that as well (that's what I labelled as the dev/id case). +> Then just before the assert I was printing the se->compat and se->instance_id values. +> +> I noticed this bug because one of our test team had hit the same assert +> a few weeks back on x86, but it was on a truly bizarre setup (~50 nested +> PCIe bridges) so I knew where to look for it. +> +> I think the idea is that if you have a se->compat string then it had +> better be unique (that is instance_id == 0); and the compat string is +> formed by concatenation of the qdev path and the name of this device. +> Then we have '0.0.0' as the name of this scsi device (i.e. local to this +> SCSI adapter) but no path that gives a unique string for the adapter +> like we do on the x86. +> +> Dave +> + + +Yeh I *think* the idea is that you either: + a) have an instance_id +or + b) have a unique name + in which case you're also allowed to have an old compatibility name/instance_id to work with old code that didn't have a unique name (that's in se->compat) + +so the assert is: + assert(!se->compat || se->instance_id == 0); + + The !se->compat corresponds to (a) + se->instance_id == 0 corresponds to (b) + +Having a unique name is a very good idea for hotplug - it lets you unplug the middle one and still receive a migration correctly. + +Dave + +We may be saying the same thing, but I'd word it differently. If a + "device" has a "path" then it gets a se->compat (compatibility?) record. + - Within that record each device gets an instance_id value based on its +name. Multiple IDs for the same name are allowed. + - At the "se" level each device also gets an instance id but now based +on path + name. There can only be one instance for that combination which +requires that the path must be unique for each device name. + +In this case both SCSI device have the path "0:0:0" (chan:id:lun) which +violates the above requirement. + +Looking at the debug info I noticed that for "virtio-net" the (PCI) path is +not all zeroes (0000:00:01.0). Makes me wonder if maybe something on the +SCSI side of things should be generating valid paths. + +Still digging. + +On 1 July 2016 at 09:08, Dr. David Alan Gilbert <email address hidden> wrote: + +> Yeh I *think* the idea is that you either: +> a) have an instance_id +> or +> b) have a unique name +> in which case you're also allowed to have an old compatibility +> name/instance_id to work with old code that didn't have a unique name +> (that's in se->compat) +> +> so the assert is: +> assert(!se->compat || se->instance_id == 0); +> +> The !se->compat corresponds to (a) +> se->instance_id == 0 corresponds to (b) +> +> Having a unique name is a very good idea for hotplug - it lets you +> unplug the middle one and still receive a migration correctly. +> +> Dave +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1594239 +> +> Title: +> After adding more scsi disks for Aarch64 virtual machine, start the VM +> and got Qemu Error +> +> Status in QEMU: +> Confirmed +> +> Bug description: +> Description +> =========== +> Using virt-manager to create a VM in Aarch64, Ubuntu 16.04. +> Add scsi disk to the VM. After add four or more scsi disks, start the VM +> and will got Qemu error. +> +> Steps to reproduce +> ================== +> 1.Use virt-manager to create a VM. +> 2.After the VM is started, add scsi disk to the VM. They will be +> allocated to "sdb,sdc,sdd....." . +> 3.If we got a disk name > sdg, virt-manager will also assign a +> virtio-scsi controller for this disk.And the VM will be shutdown. +> 4.Start the VM, will see the error log. +> +> +> Expected result +> =============== +> Start the vm smoothly.The added disks can work. +> +> Actual result +> ============= +> Got the error: +> starting domain: internal error: process exited while connecting to +> monitor: qemu-system-aarch64: +> /build/qemu-zxCwKP/qemu-2.5+dfsg/migration/savevm.c:620: +> vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id +> == 0' failed. +> details=Traceback (most recent call last): +> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 90, in +> cb_wrapper +> callback(asyncjob, *args, **kwargs) +> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 126, in +> tmpcb +> callback(*args, **kwargs) +> File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, +> in newfn +> ret = fn(self, *args, **kwargs) +> File "/usr/share/virt-manager/virtManager/domain.py", line 1402, in +> startup +> self._backend.create() +> File "/usr/local/lib/python2.7/dist-packages/libvirt.py", line 1035, +> in create +> if ret == -1: raise libvirtError ('virDomainCreate() failed', +> dom=self) +> libvirtError: internal error: process exited while connecting to +> monitor: qemu-system-aarch64: +> /build/qemu-zxCwKP/qemu-2.5+dfsg/migration/savevm.c:620: +> vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id +> == 0' failed. +> +> +> Environment +> =========== +> 1. virt-manager version is 1.3.2 +> +> 2. Which hypervisor did you use? +> Libvirt+KVM +> $ kvm --version +> QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.1), +> Copyright (c) 2003-2008 Fabrice Bellard +> $ libvirtd --version +> libvirtd (libvirt) 1.3.1 +> +> 3. Which storage type did you use? +> In the host file system,all in one physics machine. +> stack@u202154:/opt/stack/nova$ df -hl +> Filesystem Size Used Avail Use% Mounted on +> udev 7.8G 0 7.8G 0% /dev +> tmpfs 1.6G 61M 1.6G 4% /run +> /dev/sda2 917G 41G 830G 5% / +> tmpfs 7.9G 0 7.9G 0% /dev/shm +> tmpfs 5.0M 0 5.0M 0% /run/lock +> tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup +> /dev/sda1 511M 888K 511M 1% /boot/efi +> cgmfs 100K 0 100K 0% /run/cgmanager/fs +> tmpfs 1.6G 0 1.6G 0% /run/user/1002 +> tmpfs 1.6G 0 1.6G 0% /run/user/1000 +> tmpfs 1.6G 0 1.6G 0% /run/user/0 +> +> 4. Environment information: +> Architecture : AARCH64 +> OS: Ubuntu 16.04 +> +> The Qemu commmand of libvirt is : +> 2016-06-20 02:39:46.561+0000: starting up libvirt version: 1.3.1, +> package: 1ubuntu10 (William Grant <email address hidden> Fri, 15 Apr 2016 +> 12:08:21 +1000), qemu version: 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.1), +> hostname: u202154 +> LC_ALL=C +> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin +> QEMU_AUDIO_DRV=none /usr/bin/kvm -name cent7 -S -machine +> virt,accel=kvm,usb=off -cpu host -drive +> file=/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw,if=pflash,format=raw,unit=0,readonly=on +> -drive +> file=/var/lib/libvirt/qemu/nvram/cent7_VARS.fd,if=pflash,format=raw,unit=1 +> -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid +> d5462bb6-159e-4dbd-9266-bf8c07fa1695 -nographic -no-user-config -nodefaults +> -chardev +> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-cent7/monitor.sock,server,nowait +> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown +> -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 +> -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 -device +> virtio-scsi-device,id=scsi0 -device lsi,id=scsi1 -device lsi,id=scsi2 +> -device virtio-scsi-device,id=scsi3 -usb -drive +> file=/var/lib/libvirt/images/cent7-2.img,format=qcow2,if=none,id=drive-scsi0-0-0-0 +> -device +> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 +> -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device +> scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 +> -drive +> file=/var/lib/libvirt/images/cent7-10.img,format=qcow2,if=none,id=drive-scsi0-0-0-2 +> -device +> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-0-2,id=scsi0-0-0-2 +> -drive +> file=/var/lib/libvirt/images/cent7-11.img,format=qcow2,if=none,id=drive-scsi0-0-0-3 +> -device +> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=3,drive=drive-scsi0-0-0-3,id=scsi0-0-0-3 +> -drive +> file=/var/lib/libvirt/images/cent7-13.img,format=qcow2,if=none,id=drive-scsi3-0-0-0 +> -device +> scsi-hd,bus=scsi3.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi3-0-0-0,id=scsi3-0-0-0 +> -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=35 -device +> virtio-net-device,netdev=hostnet0,id=net0,mac=52:54:00:a1:6e:75 -serial pty +> -msg timestamp=on +> Domain id=11 is tainted: host-cpu +> +> The libvirt xml is: +> <domain type='kvm'> +> <name>cent7</name> +> <uuid>d5462bb6-159e-4dbd-9266-bf8c07fa1695</uuid> +> <memory unit='KiB'>2097152</memory> +> <currentMemory unit='KiB'>2097152</currentMemory> +> <vcpu placement='static'>2</vcpu> +> <os> +> <type arch='aarch64' machine='virt'>hvm</type> +> <loader readonly='yes' +> type='pflash'>/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw</loader> +> <nvram>/var/lib/libvirt/qemu/nvram/cent7_VARS.fd</nvram> +> <boot dev='hd'/> +> </os> +> <cpu mode='host-passthrough'/> +> <clock offset='utc'/> +> <on_poweroff>destroy</on_poweroff> +> <on_reboot>restart</on_reboot> +> <on_crash>restart</on_crash> +> <devices> +> <emulator>/usr/bin/kvm</emulator> +> <disk type='file' device='disk'> +> <driver name='qemu' type='qcow2'/> +> <source file='/var/lib/libvirt/images/cent7-2.img'/> +> <target dev='sda' bus='scsi'/> +> <address type='drive' controller='0' bus='0' target='0' unit='0'/> +> </disk> +> <disk type='file' device='cdrom'> +> <driver name='qemu' type='raw'/> +> <target dev='sdb' bus='scsi'/> +> <readonly/> +> <address type='drive' controller='0' bus='0' target='0' unit='1'/> +> </disk> +> <disk type='file' device='disk'> +> <driver name='qemu' type='qcow2'/> +> <source file='/var/lib/libvirt/images/cent7-10.img'/> +> <target dev='sdc' bus='scsi'/> +> <address type='drive' controller='0' bus='0' target='0' unit='2'/> +> </disk> +> <disk type='file' device='disk'> +> <driver name='qemu' type='qcow2'/> +> <source file='/var/lib/libvirt/images/cent7-11.img'/> +> <target dev='sdd' bus='scsi'/> +> <address type='drive' controller='0' bus='0' target='0' unit='3'/> +> </disk> +> <disk type='file' device='disk'> +> <driver name='qemu' type='qcow2'/> +> <source file='/var/lib/libvirt/images/cent7-13.img'/> +> <target dev='sdv' bus='scsi'/> +> <address type='drive' controller='3' bus='0' target='0' unit='0'/> +> </disk> +> <controller type='scsi' index='0' model='virtio-scsi'> +> <address type='virtio-mmio'/> +> </controller> +> <controller type='scsi' index='1'> +> <address type='virtio-mmio'/> +> </controller> +> <controller type='scsi' index='2'> +> <address type='virtio-mmio'/> +> </controller> +> <controller type='scsi' index='3' model='virtio-scsi'> +> <address type='virtio-mmio'/> +> </controller> +> <controller type='pci' index='0' model='pcie-root'/> +> <controller type='pci' index='1' model='dmi-to-pci-bridge'> +> <model name='i82801b11-bridge'/> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' +> function='0x0'/> +> </controller> +> <controller type='pci' index='2' model='pci-bridge'> +> <model name='pci-bridge'/> +> <target chassisNr='2'/> +> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' +> function='0x0'/> +> </controller> +> <interface type='bridge'> +> <mac address='52:54:00:a1:6e:75'/> +> <source bridge='br0'/> +> <model type='virtio'/> +> <address type='virtio-mmio'/> +> </interface> +> <serial type='pty'> +> <target port='0'/> +> </serial> +> <console type='pty'> +> <target type='serial' port='0'/> +> </console> +> </devices> +> </domain> +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1594239/+subscriptions +> + + +This looks like a command line / configuration issue which results in a name collision as Dave predicted above. + +I had to piece this together out of bits of information since documentation is a bit sparse but the following works. Note the explicit ID and LUN values on the -device declarations: +sudo qemu-system-aarch64 -enable-kvm -machine virt -cpu host -machine type=virt -nographic -smp 1 -m 2048 -kernel aarch64-linux-3.15rc2-buildroot.img --append "console=ttyAMA0" \ + -device virtio-scsi-device,id=scsi0 \ + -device virtio-scsi-device,id=scsi1 \ + -drive file=scsi_1.img,format=raw,if=none,id=d0 \ + -device scsi-hd,bus=scsi0.0,scsi-id=0,lun=0,drive=d0 \ + -drive file=scsi_2.img,format=raw,if=none,id=d1 \ + -device scsi-hd,bus=scsi1.0,scsi-id=0,lun=1,drive=d1 + +Added debug shows the following (Note the LUN value of 1 for the second drive): +calculate_compat_instance_id: For [scsi-disk], Init instance_id to [0] +calculate_new_instance_id: For [0:0:0/scsi-disk], Init instance_id to [0] +calculate_compat_instance_id: For [scsi-disk], Init instance_id to [0] +calculate_compat_instance_id: Found match for [scsi-disk], incrementing instance_id is now [1] +calculate_new_instance_id: For [0:0:1/scsi-disk], Init instance_id to [0] + +Note: even though it's on a different bus, specifying the same id & lun will cause a collision. + +If desired, the above can be simplified to use a single bus: +sudo qemu-system-aarch64 -enable-kvm -machine virt -cpu host -machine type=virt -nographic -smp 1 -m 2048 -kernel aarch64-linux-3.15rc2-buildroot.img --append "console=ttyAMA0" \ + -device virtio-scsi-device,id=scsi0 \ + -drive file=scsi_1.img,format=raw,if=none,id=d0 \ + -device scsi-hd,bus=scsi0.0,scsi-id=0,lun=0,drive=d0 \ + -drive file=scsi_2.img,format=raw,if=none,id=d1 \ + -device scsi-hd,bus=scsi0.0,scsi-id=0,lun=1,drive=d1 + +Searching the web, I saw this more commonly done with virtio-scsi-pci instead of virtio-scsi-device (but I can't tell you why): +sudo qemu-system-aarch64 -enable-kvm -machine virt -cpu host -machine type=virt -nographic -smp 1 -m 2048 -kernel aarch64-linux-3.15rc2-buildroot.img --append "console=ttyAMA0" \ + -device virtio-scsi-pci,id=scsi0 \ + -device virtio-scsi-pci,id=scsi1 \ + -drive file=scsi_1.img,format=raw,if=none,id=d0 \ + -device scsi-hd,bus=scsi0.0,scsi-id=0,lun=0,drive=d0 \ + -drive file=scsi_2.img,format=raw,if=none,id=d1 \ + -device scsi-hd,bus=scsi1.0,scsi-id=0,lun=1,drive=d1 + +Note that the name used internally now includes the bus id: +calculate_compat_instance_id: For [scsi-disk], Init instance_id to [0] +calculate_new_instance_id: For [0000:00:02.0/0:0:0/scsi-disk], Init instance_id to [0] +calculate_compat_instance_id: For [scsi-disk], Init instance_id to [0] +calculate_compat_instance_id: Found match for [scsi-disk], incrementing instance_id is now [1] +calculate_new_instance_id: For [0000:00:03.0/0:0:1/scsi-disk], Init instance_id to [0] + +This means that it is now possible to use the same LUN for the drives on the 2 different buses: +sudo qemu-system-aarch64 -enable-kvm -machine virt -cpu host -machine type=virt -nographic -smp 1 -m 2048 -kernel aarch64-linux-3.15rc2-buildroot.img --append "console=ttyAMA0" \ + -device virtio-scsi-pci,id=scsi0 \ + -device virtio-scsi-pci,id=scsi1 \ + -drive file=scsi_1.img,format=raw,if=none,id=d0 \ + -device scsi-hd,bus=scsi0.0,scsi-id=0,lun=0,drive=d0 \ + -drive file=scsi_2.img,format=raw,if=none,id=d1 \ + -device scsi-hd,bus=scsi1.0,scsi-id=0,lun=0,drive=d1 + +Internally: +calculate_compat_instance_id: For [scsi-disk], Init instance_id to [0] +calculate_new_instance_id: For [0000:00:02.0/0:0:0/scsi-disk], Init instance_id to [0] +calculate_compat_instance_id: For [scsi-disk], Init instance_id to [0] +calculate_compat_instance_id: Found match for [scsi-disk], incrementing instance_id is now [1] +calculate_new_instance_id: For [0000:00:03.0/0:0:0/scsi-disk], Init instance_id to [0] + +Here also, a single bus works fine as long as ID + LUN is unique: +sudo qemu-system-aarch64 -enable-kvm -machine virt -cpu host -machine type=virt -nographic -smp 1 -m 2048 -kernel aarch64-linux-3.15rc2-buildroot.img --append "console=ttyAMA0" \ + -device virtio-scsi-pci,id=scsi0 \ + -drive file=scsi_1.img,format=raw,if=none,id=d0 \ + -device scsi-hd,bus=scsi0.0,scsi-id=0,lun=1,drive=d0 \ + -drive file=scsi_2.img,format=raw,if=none,id=d1 \ + -device scsi-hd,bus=scsi0.0,scsi-id=0,lun=5,drive=d1 + +Internally: +calculate_new_instance_id: For [0000:00:02.0/virtio-scsi], Init instance_id to [0] +calculate_compat_instance_id: For [scsi-disk], Init instance_id to [0] +calculate_new_instance_id: For [0000:00:02.0/0:0:1/scsi-disk], Init instance_id to [0] +calculate_compat_instance_id: For [scsi-disk], Init instance_id to [0] +calculate_compat_instance_id: Found match for [scsi-disk], incrementing instance_id is now [1] +calculate_new_instance_id: For [0000:00:02.0/0:0:5/scsi-disk], Init instance_id to [0] + +The issue is that virtio-mmio devices don't distinguish themselves on the sysbus level. + +Using the small reproducer from Cole, and setting a breakpoint on virtio_bus_get_dev_path(), for the second virtio-scsi-device we get: + + ... + qdev_get_dev_path() + virtio_bus_get_dev_path() + qdev_get_dev_path() + +In virtio_bus_get_dev_path(), "bus" is set to "virtio-mmio-bus.30" ("name" field). "proxy" is set to the VirtIOMMIOProxy object that produces (owns) "virtio-mmio-bus.30" as its "bus" field. Finally virtio_bus_get_dev_path() forwards the "get dev path" request to this proxy object. + +In that second qdev_get_dev_path() call, the parent bus for the VirtIOMMIOProxy object is "main-system-bus" (proxy->parent_bus->name). + +The bus class for the main system bus is set up in system_bus_class_init(), and that function only sets the "print_dev" and "get_fw_dev_path" member functions. The "get_dev_path" member function is left NULL, hence qdev_get_dev_path() will return NULL ultimately. + +Thus, in the "dev/id" case, in your debug patch's terminology, "id" will be NULL, and the inner concatenation branch will not be taken. Only vmsd->name will be copied into se->idstr. + +This can be fixed in two ways, I believe. + +* First, we could implement sysbus_get_dev_path(), and set it in system_bus_class_init(). This function would closely follow sysbus_get_fw_dev_path(): format the address of the first MMIO or IO region of the device to a string. For virtio-mmio devices in particular, this would be suitable, because they have a single (0x200 size) memory region (see VirtIOMMIOProxy.iomem), and the base address of that memory region is precisely what distinguishes the virtio-mmio transports from each other. + +* Secondly, we could override virtio_bus_get_dev_path() in virtio_mmio_bus_class_init(), as the "get_dev_path" member function of the TYPE_VIRTIO_MMIO_BUS class. Implementing virtio_mmio_bus_get_dev_path() would result in the first qdev_get_dev_path() listed above to call our specialized code. + +In virtio_mmio_bus_get_dev_path(), we could open-code the first two steps of virtio_bus_get_dev_path(): + + BusState *bus = qdev_get_parent_bus(dev); + DeviceState *proxy = DEVICE(bus->parent); + +Here we'd know that "proxy" (a VirtIOMMIOProxy object) is actually derived from SysBusDevice, and we could dynamic-cast it accordingly. In the SysBusDevice, we could access mmio[0].addr directly (it's a "public" field, and we know virtio-mmio transports have exactly one MMIO region and no IO regions), and format that. + +The small issue with both alternatives is that they'd immediately break migration between pre-patch and post-patch, because (IIUC) these paths get formatted into migration section headers or some such. So either change would require introducing new machine type versions for *all* target arches and machine types that are currently versioned. This is the reason I'm not trying to prototype either idea above -- just gathering all those machine types looks daunting. + +As noted above, virtio-scsi-pci uses a bus address as part of the internal ID string while virtio-scsi-device does not. + + * Is this difference intentional? + + * Are they intended to support different use cases? If so, what? + +> As noted above, virtio-scsi-pci uses a bus address as part of the internal ID string while +> virtio-scsi-device does not. +> +> * Is this difference intentional? +> +> * Are they intended to support different use cases? If so, what? + +I don't think it is intentional; I think every SCSI device is expecting to have +a globally unique name; it's got a unique name on it's adapter (in terms of bus/id/lun triple - i.e. 0:0:0) and expecting it's adapter to have a unique name, which in the case of the PCI devices is the PCI bus name. + +Dave + +On 5 July 2016 at 15:41, Tom Hanson <email address hidden> wrote: +> As noted above, virtio-scsi-pci uses a bus address as part of the +> internal ID string while virtio-scsi-device does not. +> +> * Is this difference intentional? + +Probably not. + +> * Are they intended to support different use cases? If so, what? + +virtio-scsi-device is a "virtio backend" (other backends +include char, block and net devices), which plugs into a +"virtio bus". Virtio buses are provided by "virtio transports", +which can be PCI, s390 CCW, or virtio-mmio, and any particular +virtio bus has either 0 or 1 virtio backends on it. + +The general idea is that this is a clean-ish separation between +the "what is this virtio device doing" and "how exactly do you +access it". virtio-scsi-pci is one of the family of virtio-*-pci +devices which combine a virtio-pci transport and a virtio-foo +backend in one convenient package -- we provide these (a) for +backward compatibility with old command lines etc from before +we made the backend/transport split and (b) for convenience +since the command lines are shorter than if you specify +the transport and backend separately manually. + +(Note that a virtio-pci transport is a pci device, not a +pci bus -- it plugs into a pci bus on one and has a +virtio-bus on the other.) + +thanks +-- PMM + + +On 5 July 2016 at 16:02, Peter Maydell <email address hidden> wrote: +> (Note that a virtio-pci transport is a pci device, not a +> pci bus -- it plugs into a pci bus on one and has a +> virtio-bus on the other.) + +Should read "on one end". + +thanks +-- PMM + + +So, in the original minimal command line above (#3) is the transport/bus missing? Or is mmio implied? Or? + +I don't think this difference is intentional. I think we're seeing an interplay between the following two commits: + +* http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d2ffa08b601b +* http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7685ee6abcb93 + +Referring to the message of the second commit above, the problem is that sysbus doesn't implement get_dev_path, hence it doesn't support "creating unique savevm id strings". + +virtio_bus_get_dev_path() simply defers to the parent bus ("main-system-bus" in this case). + +I'll try to come up with a patch, if for nothing more than illustration. + +What would a device path look like for an MMIO backend? +On Jul 5, 2016 9:35 AM, "Laszlo Ersek (Red Hat)" <email address hidden> wrote: + +> I don't think this difference is intentional. I think we're seeing an +> interplay between the following two commits: +> +> * http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d2ffa08b601b +> * http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7685ee6abcb93 +> +> Referring to the message of the second commit above, the problem is that +> sysbus doesn't implement get_dev_path, hence it doesn't support +> "creating unique savevm id strings". +> +> virtio_bus_get_dev_path() simply defers to the parent bus ("main-system- +> bus" in this case). +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1594239 +> +> Title: +> After adding more scsi disks for Aarch64 virtual machine, start the VM +> and got Qemu Error +> +> Status in QEMU: +> Confirmed +> +> Bug description: +> Description +> =========== +> Using virt-manager to create a VM in Aarch64, Ubuntu 16.04. +> Add scsi disk to the VM. After add four or more scsi disks, start the VM +> and will got Qemu error. +> +> Steps to reproduce +> ================== +> 1.Use virt-manager to create a VM. +> 2.After the VM is started, add scsi disk to the VM. They will be +> allocated to "sdb,sdc,sdd....." . +> 3.If we got a disk name > sdg, virt-manager will also assign a +> virtio-scsi controller for this disk.And the VM will be shutdown. +> 4.Start the VM, will see the error log. +> +> +> Expected result +> =============== +> Start the vm smoothly.The added disks can work. +> +> Actual result +> ============= +> Got the error: +> starting domain: internal error: process exited while connecting to +> monitor: qemu-system-aarch64: +> /build/qemu-zxCwKP/qemu-2.5+dfsg/migration/savevm.c:620: +> vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id +> == 0' failed. +> details=Traceback (most recent call last): +> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 90, in +> cb_wrapper +> callback(asyncjob, *args, **kwargs) +> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 126, in +> tmpcb +> callback(*args, **kwargs) +> File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, +> in newfn +> ret = fn(self, *args, **kwargs) +> File "/usr/share/virt-manager/virtManager/domain.py", line 1402, in +> startup +> self._backend.create() +> File "/usr/local/lib/python2.7/dist-packages/libvirt.py", line 1035, +> in create +> if ret == -1: raise libvirtError ('virDomainCreate() failed', +> dom=self) +> libvirtError: internal error: process exited while connecting to +> monitor: qemu-system-aarch64: +> /build/qemu-zxCwKP/qemu-2.5+dfsg/migration/savevm.c:620: +> vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id +> == 0' failed. +> +> +> Environment +> =========== +> 1. virt-manager version is 1.3.2 +> +> 2. Which hypervisor did you use? +> Libvirt+KVM +> $ kvm --version +> QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.1), +> Copyright (c) 2003-2008 Fabrice Bellard +> $ libvirtd --version +> libvirtd (libvirt) 1.3.1 +> +> 3. Which storage type did you use? +> In the host file system,all in one physics machine. +> stack@u202154:/opt/stack/nova$ df -hl +> Filesystem Size Used Avail Use% Mounted on +> udev 7.8G 0 7.8G 0% /dev +> tmpfs 1.6G 61M 1.6G 4% /run +> /dev/sda2 917G 41G 830G 5% / +> tmpfs 7.9G 0 7.9G 0% /dev/shm +> tmpfs 5.0M 0 5.0M 0% /run/lock +> tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup +> /dev/sda1 511M 888K 511M 1% /boot/efi +> cgmfs 100K 0 100K 0% /run/cgmanager/fs +> tmpfs 1.6G 0 1.6G 0% /run/user/1002 +> tmpfs 1.6G 0 1.6G 0% /run/user/1000 +> tmpfs 1.6G 0 1.6G 0% /run/user/0 +> +> 4. Environment information: +> Architecture : AARCH64 +> OS: Ubuntu 16.04 +> +> The Qemu commmand of libvirt is : +> 2016-06-20 02:39:46.561+0000: starting up libvirt version: 1.3.1, +> package: 1ubuntu10 (William Grant <email address hidden> Fri, 15 Apr 2016 +> 12:08:21 +1000), qemu version: 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.1), +> hostname: u202154 +> LC_ALL=C +> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin +> QEMU_AUDIO_DRV=none /usr/bin/kvm -name cent7 -S -machine +> virt,accel=kvm,usb=off -cpu host -drive +> file=/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw,if=pflash,format=raw,unit=0,readonly=on +> -drive +> file=/var/lib/libvirt/qemu/nvram/cent7_VARS.fd,if=pflash,format=raw,unit=1 +> -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid +> d5462bb6-159e-4dbd-9266-bf8c07fa1695 -nographic -no-user-config -nodefaults +> -chardev +> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-cent7/monitor.sock,server,nowait +> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown +> -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 +> -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 -device +> virtio-scsi-device,id=scsi0 -device lsi,id=scsi1 -device lsi,id=scsi2 +> -device virtio-scsi-device,id=scsi3 -usb -drive +> file=/var/lib/libvirt/images/cent7-2.img,format=qcow2,if=none,id=drive-scsi0-0-0-0 +> -device +> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 +> -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device +> scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 +> -drive +> file=/var/lib/libvirt/images/cent7-10.img,format=qcow2,if=none,id=drive-scsi0-0-0-2 +> -device +> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-0-2,id=scsi0-0-0-2 +> -drive +> file=/var/lib/libvirt/images/cent7-11.img,format=qcow2,if=none,id=drive-scsi0-0-0-3 +> -device +> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=3,drive=drive-scsi0-0-0-3,id=scsi0-0-0-3 +> -drive +> file=/var/lib/libvirt/images/cent7-13.img,format=qcow2,if=none,id=drive-scsi3-0-0-0 +> -device +> scsi-hd,bus=scsi3.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi3-0-0-0,id=scsi3-0-0-0 +> -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=35 -device +> virtio-net-device,netdev=hostnet0,id=net0,mac=52:54:00:a1:6e:75 -serial pty +> -msg timestamp=on +> Domain id=11 is tainted: host-cpu +> +> The libvirt xml is: +> <domain type='kvm'> +> <name>cent7</name> +> <uuid>d5462bb6-159e-4dbd-9266-bf8c07fa1695</uuid> +> <memory unit='KiB'>2097152</memory> +> <currentMemory unit='KiB'>2097152</currentMemory> +> <vcpu placement='static'>2</vcpu> +> <os> +> <type arch='aarch64' machine='virt'>hvm</type> +> <loader readonly='yes' +> type='pflash'>/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw</loader> +> <nvram>/var/lib/libvirt/qemu/nvram/cent7_VARS.fd</nvram> +> <boot dev='hd'/> +> </os> +> <cpu mode='host-passthrough'/> +> <clock offset='utc'/> +> <on_poweroff>destroy</on_poweroff> +> <on_reboot>restart</on_reboot> +> <on_crash>restart</on_crash> +> <devices> +> <emulator>/usr/bin/kvm</emulator> +> <disk type='file' device='disk'> +> <driver name='qemu' type='qcow2'/> +> <source file='/var/lib/libvirt/images/cent7-2.img'/> +> <target dev='sda' bus='scsi'/> +> <address type='drive' controller='0' bus='0' target='0' unit='0'/> +> </disk> +> <disk type='file' device='cdrom'> +> <driver name='qemu' type='raw'/> +> <target dev='sdb' bus='scsi'/> +> <readonly/> +> <address type='drive' controller='0' bus='0' target='0' unit='1'/> +> </disk> +> <disk type='file' device='disk'> +> <driver name='qemu' type='qcow2'/> +> <source file='/var/lib/libvirt/images/cent7-10.img'/> +> <target dev='sdc' bus='scsi'/> +> <address type='drive' controller='0' bus='0' target='0' unit='2'/> +> </disk> +> <disk type='file' device='disk'> +> <driver name='qemu' type='qcow2'/> +> <source file='/var/lib/libvirt/images/cent7-11.img'/> +> <target dev='sdd' bus='scsi'/> +> <address type='drive' controller='0' bus='0' target='0' unit='3'/> +> </disk> +> <disk type='file' device='disk'> +> <driver name='qemu' type='qcow2'/> +> <source file='/var/lib/libvirt/images/cent7-13.img'/> +> <target dev='sdv' bus='scsi'/> +> <address type='drive' controller='3' bus='0' target='0' unit='0'/> +> </disk> +> <controller type='scsi' index='0' model='virtio-scsi'> +> <address type='virtio-mmio'/> +> </controller> +> <controller type='scsi' index='1'> +> <address type='virtio-mmio'/> +> </controller> +> <controller type='scsi' index='2'> +> <address type='virtio-mmio'/> +> </controller> +> <controller type='scsi' index='3' model='virtio-scsi'> +> <address type='virtio-mmio'/> +> </controller> +> <controller type='pci' index='0' model='pcie-root'/> +> <controller type='pci' index='1' model='dmi-to-pci-bridge'> +> <model name='i82801b11-bridge'/> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' +> function='0x0'/> +> </controller> +> <controller type='pci' index='2' model='pci-bridge'> +> <model name='pci-bridge'/> +> <target chassisNr='2'/> +> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' +> function='0x0'/> +> </controller> +> <interface type='bridge'> +> <mac address='52:54:00:a1:6e:75'/> +> <source bridge='br0'/> +> <model type='virtio'/> +> <address type='virtio-mmio'/> +> </interface> +> <serial type='pty'> +> <target port='0'/> +> </serial> +> <console type='pty'> +> <target type='serial' port='0'/> +> </console> +> </devices> +> </domain> +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1594239/+subscriptions +> + + +On 5 July 2016 at 16:20, Tom Hanson <email address hidden> wrote: +> So, in the original minimal command line above (#3) is the transport/bus +> missing? Or is mmio implied? Or? + +The virt board creates a collection of virtio-mmio transports, +so if you create just a backend on the command line (via +"-device virtio-scsi-device") it will be plugged into a +virtio-bus on a virtio-mmio transport. + +You almost certainly didn't want to do this -- virtio-mmio +is only there for legacy reasons [it predates pci support +in the 'virt' board and the device-tree-driven kernel and +for a time it was the only way to do virtio]. + +You want to use virtio-pci, which is more flexible and has more +features (so either use -device virtio-scsi-pci, or use -device +virtio-scsi-device with -device virtio-pci and suitable id/bus +options to explicitly wire them together). + +thanks +-- PMM + + +I haven't dug into the code for this particular aspect (yet) but it sounds like when a scsi-hd device is specified with a virtio backend but with no virtio bus specified, it is defaulting to an MMIO bus. Is this correct? + +A few questions: + +1) Is it valid for a SCSI drive to default to an MMIO bus/backend? Or should it have defaulted to PCI? + +2) Given that the 2 scsi-hd devices were specified with no bus, no ID, and no LUN was there anything incorrect in how QEMU handled them? (Other than a more verbose error message being desirable.) + +3) In the general case of a MMIO device, do they need to have a unique dev path? In the real world, there's no bus, no bus address, nothing that looks like a dev path. Just a memory address. + +4) Or is it the case that MMIO devices need to be unique based solely on the device characteristics? + +On 07/05/2016 10:29 AM, Peter Maydell wrote: +... +> The virt board creates a collection of virtio-mmio transports, +> so if you create just a backend on the command line (via +> "-device virtio-scsi-device") it will be plugged into a +> virtio-bus on a virtio-mmio transport. +> +> You almost certainly didn't want to do this -- virtio-mmio +> is only there for legacy reasons [it predates pci support +> in the 'virt' board and the device-tree-driven kernel and +> for a time it was the only way to do virtio]. + +Should this behavior be changed? Use PCI as a default instead? + + +Posted a patch: http://lists.nongnu.org/archive/html/qemu-devel/2016-07/msg01119.html + +I tested Laszlo's patch against this scenario and it eliminated the error. + +However, I'm still not convinced that it's needed. + +Let's start with a basic question: Does it make sense for there to be more than one MMIO "bus" on a system? + +After all, it's NOT a physical bus and there's only one set of physical memory (at least on anything we're currently modelling). + +Would it make as much sense to disallow a second virtio-mmio bus?? + +A virtio-mmio "bus" is a single-device transport. It has a fixed base address that is set at board creation time. The MMIO area is 0x200 bytes in size, and hosts the virtio registers for one device that can sit on this transport. Transports can be unused. + +The "virt" machtype creates 32 transports (= 32 virtio-mmio "buses" suitable for one virtio device each). This allows for 32 virtio devices exposed via virtio-mmio. The placement of the different virtio-mmio "buses" at specific addresses in MMIO space is board specific. + +So yes, it definitely makes sense to create several of these "buses". It's better to think of a single virtio-mmio "bus" as a virtio-mmio "transport" or "register block". The "bus" terminology is just an internal QEMU detail. (It is not enumerable in hardware, for example.) + +On 5 July 2016 at 17:43, Tom Hanson <email address hidden> wrote: +> On 07/05/2016 10:29 AM, Peter Maydell wrote: +> ... +>> The virt board creates a collection of virtio-mmio transports, +>> so if you create just a backend on the command line (via +>> "-device virtio-scsi-device") it will be plugged into a +>> virtio-bus on a virtio-mmio transport. +>> +>> You almost certainly didn't want to do this -- virtio-mmio +>> is only there for legacy reasons [it predates pci support +>> in the 'virt' board and the device-tree-driven kernel and +>> for a time it was the only way to do virtio]. +> +> Should this behavior be changed? Use PCI as a default instead? + +This would break command line compatibility, which is +something we generally try to avoid. If you want +pci, why not just use virtio-scsi-pci ? + +thanks +-- PMM + + +OK, that makes sense. I was thinking that the MMIO transport would/could +support multiple register blocks and thus multiple devices. + +On 5 July 2016 at 13:26, Laszlo Ersek (Red Hat) <email address hidden> wrote: + +> A virtio-mmio "bus" is a single-device transport. It has a fixed base +> address that is set at board creation time. The MMIO area is 0x200 bytes +> in size, and hosts the virtio registers for one device that can sit on +> this transport. Transports can be unused. +> +> The "virt" machtype creates 32 transports (= 32 virtio-mmio "buses" +> suitable for one virtio device each). This allows for 32 virtio devices +> exposed via virtio-mmio. The placement of the different virtio-mmio +> "buses" at specific addresses in MMIO space is board specific. +> +> So yes, it definitely makes sense to create several of these "buses". +> It's better to think of a single virtio-mmio "bus" as a virtio-mmio +> "transport" or "register block". The "bus" terminology is just an +> internal QEMU detail. (It is not enumerable in hardware, for example.) +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1594239 +> +> Title: +> After adding more scsi disks for Aarch64 virtual machine, start the VM +> and got Qemu Error +> +> Status in QEMU: +> Confirmed +> +> Bug description: +> Description +> =========== +> Using virt-manager to create a VM in Aarch64, Ubuntu 16.04. +> Add scsi disk to the VM. After add four or more scsi disks, start the VM +> and will got Qemu error. +> +> Steps to reproduce +> ================== +> 1.Use virt-manager to create a VM. +> 2.After the VM is started, add scsi disk to the VM. They will be +> allocated to "sdb,sdc,sdd....." . +> 3.If we got a disk name > sdg, virt-manager will also assign a +> virtio-scsi controller for this disk.And the VM will be shutdown. +> 4.Start the VM, will see the error log. +> +> +> Expected result +> =============== +> Start the vm smoothly.The added disks can work. +> +> Actual result +> ============= +> Got the error: +> starting domain: internal error: process exited while connecting to +> monitor: qemu-system-aarch64: +> /build/qemu-zxCwKP/qemu-2.5+dfsg/migration/savevm.c:620: +> vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id +> == 0' failed. +> details=Traceback (most recent call last): +> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 90, in +> cb_wrapper +> callback(asyncjob, *args, **kwargs) +> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 126, in +> tmpcb +> callback(*args, **kwargs) +> File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, +> in newfn +> ret = fn(self, *args, **kwargs) +> File "/usr/share/virt-manager/virtManager/domain.py", line 1402, in +> startup +> self._backend.create() +> File "/usr/local/lib/python2.7/dist-packages/libvirt.py", line 1035, +> in create +> if ret == -1: raise libvirtError ('virDomainCreate() failed', +> dom=self) +> libvirtError: internal error: process exited while connecting to +> monitor: qemu-system-aarch64: +> /build/qemu-zxCwKP/qemu-2.5+dfsg/migration/savevm.c:620: +> vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id +> == 0' failed. +> +> +> Environment +> =========== +> 1. virt-manager version is 1.3.2 +> +> 2. Which hypervisor did you use? +> Libvirt+KVM +> $ kvm --version +> QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.1), +> Copyright (c) 2003-2008 Fabrice Bellard +> $ libvirtd --version +> libvirtd (libvirt) 1.3.1 +> +> 3. Which storage type did you use? +> In the host file system,all in one physics machine. +> stack@u202154:/opt/stack/nova$ df -hl +> Filesystem Size Used Avail Use% Mounted on +> udev 7.8G 0 7.8G 0% /dev +> tmpfs 1.6G 61M 1.6G 4% /run +> /dev/sda2 917G 41G 830G 5% / +> tmpfs 7.9G 0 7.9G 0% /dev/shm +> tmpfs 5.0M 0 5.0M 0% /run/lock +> tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup +> /dev/sda1 511M 888K 511M 1% /boot/efi +> cgmfs 100K 0 100K 0% /run/cgmanager/fs +> tmpfs 1.6G 0 1.6G 0% /run/user/1002 +> tmpfs 1.6G 0 1.6G 0% /run/user/1000 +> tmpfs 1.6G 0 1.6G 0% /run/user/0 +> +> 4. Environment information: +> Architecture : AARCH64 +> OS: Ubuntu 16.04 +> +> The Qemu commmand of libvirt is : +> 2016-06-20 02:39:46.561+0000: starting up libvirt version: 1.3.1, +> package: 1ubuntu10 (William Grant <email address hidden> Fri, 15 Apr 2016 +> 12:08:21 +1000), qemu version: 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.1), +> hostname: u202154 +> LC_ALL=C +> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin +> QEMU_AUDIO_DRV=none /usr/bin/kvm -name cent7 -S -machine +> virt,accel=kvm,usb=off -cpu host -drive +> file=/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw,if=pflash,format=raw,unit=0,readonly=on +> -drive +> file=/var/lib/libvirt/qemu/nvram/cent7_VARS.fd,if=pflash,format=raw,unit=1 +> -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid +> d5462bb6-159e-4dbd-9266-bf8c07fa1695 -nographic -no-user-config -nodefaults +> -chardev +> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-cent7/monitor.sock,server,nowait +> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown +> -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 +> -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 -device +> virtio-scsi-device,id=scsi0 -device lsi,id=scsi1 -device lsi,id=scsi2 +> -device virtio-scsi-device,id=scsi3 -usb -drive +> file=/var/lib/libvirt/images/cent7-2.img,format=qcow2,if=none,id=drive-scsi0-0-0-0 +> -device +> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 +> -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device +> scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 +> -drive +> file=/var/lib/libvirt/images/cent7-10.img,format=qcow2,if=none,id=drive-scsi0-0-0-2 +> -device +> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-0-2,id=scsi0-0-0-2 +> -drive +> file=/var/lib/libvirt/images/cent7-11.img,format=qcow2,if=none,id=drive-scsi0-0-0-3 +> -device +> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=3,drive=drive-scsi0-0-0-3,id=scsi0-0-0-3 +> -drive +> file=/var/lib/libvirt/images/cent7-13.img,format=qcow2,if=none,id=drive-scsi3-0-0-0 +> -device +> scsi-hd,bus=scsi3.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi3-0-0-0,id=scsi3-0-0-0 +> -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=35 -device +> virtio-net-device,netdev=hostnet0,id=net0,mac=52:54:00:a1:6e:75 -serial pty +> -msg timestamp=on +> Domain id=11 is tainted: host-cpu +> +> The libvirt xml is: +> <domain type='kvm'> +> <name>cent7</name> +> <uuid>d5462bb6-159e-4dbd-9266-bf8c07fa1695</uuid> +> <memory unit='KiB'>2097152</memory> +> <currentMemory unit='KiB'>2097152</currentMemory> +> <vcpu placement='static'>2</vcpu> +> <os> +> <type arch='aarch64' machine='virt'>hvm</type> +> <loader readonly='yes' +> type='pflash'>/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw</loader> +> <nvram>/var/lib/libvirt/qemu/nvram/cent7_VARS.fd</nvram> +> <boot dev='hd'/> +> </os> +> <cpu mode='host-passthrough'/> +> <clock offset='utc'/> +> <on_poweroff>destroy</on_poweroff> +> <on_reboot>restart</on_reboot> +> <on_crash>restart</on_crash> +> <devices> +> <emulator>/usr/bin/kvm</emulator> +> <disk type='file' device='disk'> +> <driver name='qemu' type='qcow2'/> +> <source file='/var/lib/libvirt/images/cent7-2.img'/> +> <target dev='sda' bus='scsi'/> +> <address type='drive' controller='0' bus='0' target='0' unit='0'/> +> </disk> +> <disk type='file' device='cdrom'> +> <driver name='qemu' type='raw'/> +> <target dev='sdb' bus='scsi'/> +> <readonly/> +> <address type='drive' controller='0' bus='0' target='0' unit='1'/> +> </disk> +> <disk type='file' device='disk'> +> <driver name='qemu' type='qcow2'/> +> <source file='/var/lib/libvirt/images/cent7-10.img'/> +> <target dev='sdc' bus='scsi'/> +> <address type='drive' controller='0' bus='0' target='0' unit='2'/> +> </disk> +> <disk type='file' device='disk'> +> <driver name='qemu' type='qcow2'/> +> <source file='/var/lib/libvirt/images/cent7-11.img'/> +> <target dev='sdd' bus='scsi'/> +> <address type='drive' controller='0' bus='0' target='0' unit='3'/> +> </disk> +> <disk type='file' device='disk'> +> <driver name='qemu' type='qcow2'/> +> <source file='/var/lib/libvirt/images/cent7-13.img'/> +> <target dev='sdv' bus='scsi'/> +> <address type='drive' controller='3' bus='0' target='0' unit='0'/> +> </disk> +> <controller type='scsi' index='0' model='virtio-scsi'> +> <address type='virtio-mmio'/> +> </controller> +> <controller type='scsi' index='1'> +> <address type='virtio-mmio'/> +> </controller> +> <controller type='scsi' index='2'> +> <address type='virtio-mmio'/> +> </controller> +> <controller type='scsi' index='3' model='virtio-scsi'> +> <address type='virtio-mmio'/> +> </controller> +> <controller type='pci' index='0' model='pcie-root'/> +> <controller type='pci' index='1' model='dmi-to-pci-bridge'> +> <model name='i82801b11-bridge'/> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' +> function='0x0'/> +> </controller> +> <controller type='pci' index='2' model='pci-bridge'> +> <model name='pci-bridge'/> +> <target chassisNr='2'/> +> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' +> function='0x0'/> +> </controller> +> <interface type='bridge'> +> <mac address='52:54:00:a1:6e:75'/> +> <source bridge='br0'/> +> <model type='virtio'/> +> <address type='virtio-mmio'/> +> </interface> +> <serial type='pty'> +> <target port='0'/> +> </serial> +> <console type='pty'> +> <target type='serial' port='0'/> +> </console> +> </devices> +> </domain> +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1594239/+subscriptions +> + + +So, given the 1 register block per virt-mmio "bus" then I agree that we +need a "dev path" distinction between them. + +On 5 July 2016 at 14:22, Thomas Hanson <email address hidden> wrote: + +> OK, that makes sense. I was thinking that the MMIO transport would/could +> support multiple register blocks and thus multiple devices. +> +> On 5 July 2016 at 13:26, Laszlo Ersek (Red Hat) <email address hidden> wrote: +> +>> A virtio-mmio "bus" is a single-device transport. It has a fixed base +>> address that is set at board creation time. The MMIO area is 0x200 bytes +>> in size, and hosts the virtio registers for one device that can sit on +>> this transport. Transports can be unused. +>> +>> The "virt" machtype creates 32 transports (= 32 virtio-mmio "buses" +>> suitable for one virtio device each). This allows for 32 virtio devices +>> exposed via virtio-mmio. The placement of the different virtio-mmio +>> "buses" at specific addresses in MMIO space is board specific. +>> +>> So yes, it definitely makes sense to create several of these "buses". +>> It's better to think of a single virtio-mmio "bus" as a virtio-mmio +>> "transport" or "register block". The "bus" terminology is just an +>> internal QEMU detail. (It is not enumerable in hardware, for example.) +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/1594239 +>> +>> Title: +>> After adding more scsi disks for Aarch64 virtual machine, start the VM +>> and got Qemu Error +>> +>> Status in QEMU: +>> Confirmed +>> +>> Bug description: +>> Description +>> =========== +>> Using virt-manager to create a VM in Aarch64, Ubuntu 16.04. +>> Add scsi disk to the VM. After add four or more scsi disks, start the +>> VM and will got Qemu error. +>> +>> Steps to reproduce +>> ================== +>> 1.Use virt-manager to create a VM. +>> 2.After the VM is started, add scsi disk to the VM. They will be +>> allocated to "sdb,sdc,sdd....." . +>> 3.If we got a disk name > sdg, virt-manager will also assign a +>> virtio-scsi controller for this disk.And the VM will be shutdown. +>> 4.Start the VM, will see the error log. +>> +>> +>> Expected result +>> =============== +>> Start the vm smoothly.The added disks can work. +>> +>> Actual result +>> ============= +>> Got the error: +>> starting domain: internal error: process exited while connecting to +>> monitor: qemu-system-aarch64: +>> /build/qemu-zxCwKP/qemu-2.5+dfsg/migration/savevm.c:620: +>> vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id +>> == 0' failed. +>> details=Traceback (most recent call last): +>> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 90, in +>> cb_wrapper +>> callback(asyncjob, *args, **kwargs) +>> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 126, in +>> tmpcb +>> callback(*args, **kwargs) +>> File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, +>> in newfn +>> ret = fn(self, *args, **kwargs) +>> File "/usr/share/virt-manager/virtManager/domain.py", line 1402, in +>> startup +>> self._backend.create() +>> File "/usr/local/lib/python2.7/dist-packages/libvirt.py", line 1035, +>> in create +>> if ret == -1: raise libvirtError ('virDomainCreate() failed', +>> dom=self) +>> libvirtError: internal error: process exited while connecting to +>> monitor: qemu-system-aarch64: +>> /build/qemu-zxCwKP/qemu-2.5+dfsg/migration/savevm.c:620: +>> vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id +>> == 0' failed. +>> +>> +>> Environment +>> =========== +>> 1. virt-manager version is 1.3.2 +>> +>> 2. Which hypervisor did you use? +>> Libvirt+KVM +>> $ kvm --version +>> QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.1), +>> Copyright (c) 2003-2008 Fabrice Bellard +>> $ libvirtd --version +>> libvirtd (libvirt) 1.3.1 +>> +>> 3. Which storage type did you use? +>> In the host file system,all in one physics machine. +>> stack@u202154:/opt/stack/nova$ df -hl +>> Filesystem Size Used Avail Use% Mounted on +>> udev 7.8G 0 7.8G 0% /dev +>> tmpfs 1.6G 61M 1.6G 4% /run +>> /dev/sda2 917G 41G 830G 5% / +>> tmpfs 7.9G 0 7.9G 0% /dev/shm +>> tmpfs 5.0M 0 5.0M 0% /run/lock +>> tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup +>> /dev/sda1 511M 888K 511M 1% /boot/efi +>> cgmfs 100K 0 100K 0% /run/cgmanager/fs +>> tmpfs 1.6G 0 1.6G 0% /run/user/1002 +>> tmpfs 1.6G 0 1.6G 0% /run/user/1000 +>> tmpfs 1.6G 0 1.6G 0% /run/user/0 +>> +>> 4. Environment information: +>> Architecture : AARCH64 +>> OS: Ubuntu 16.04 +>> +>> The Qemu commmand of libvirt is : +>> 2016-06-20 02:39:46.561+0000: starting up libvirt version: 1.3.1, +>> package: 1ubuntu10 (William Grant <email address hidden> Fri, 15 Apr 2016 +>> 12:08:21 +1000), qemu version: 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.1), +>> hostname: u202154 +>> LC_ALL=C +>> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin +>> QEMU_AUDIO_DRV=none /usr/bin/kvm -name cent7 -S -machine +>> virt,accel=kvm,usb=off -cpu host -drive +>> file=/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw,if=pflash,format=raw,unit=0,readonly=on +>> -drive +>> file=/var/lib/libvirt/qemu/nvram/cent7_VARS.fd,if=pflash,format=raw,unit=1 +>> -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid +>> d5462bb6-159e-4dbd-9266-bf8c07fa1695 -nographic -no-user-config -nodefaults +>> -chardev +>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-cent7/monitor.sock,server,nowait +>> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown +>> -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 +>> -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 -device +>> virtio-scsi-device,id=scsi0 -device lsi,id=scsi1 -device lsi,id=scsi2 +>> -device virtio-scsi-device,id=scsi3 -usb -drive +>> file=/var/lib/libvirt/images/cent7-2.img,format=qcow2,if=none,id=drive-scsi0-0-0-0 +>> -device +>> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 +>> -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device +>> scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 +>> -drive +>> file=/var/lib/libvirt/images/cent7-10.img,format=qcow2,if=none,id=drive-scsi0-0-0-2 +>> -device +>> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-0-2,id=scsi0-0-0-2 +>> -drive +>> file=/var/lib/libvirt/images/cent7-11.img,format=qcow2,if=none,id=drive-scsi0-0-0-3 +>> -device +>> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=3,drive=drive-scsi0-0-0-3,id=scsi0-0-0-3 +>> -drive +>> file=/var/lib/libvirt/images/cent7-13.img,format=qcow2,if=none,id=drive-scsi3-0-0-0 +>> -device +>> scsi-hd,bus=scsi3.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi3-0-0-0,id=scsi3-0-0-0 +>> -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=35 -device +>> virtio-net-device,netdev=hostnet0,id=net0,mac=52:54:00:a1:6e:75 -serial pty +>> -msg timestamp=on +>> Domain id=11 is tainted: host-cpu +>> +>> The libvirt xml is: +>> <domain type='kvm'> +>> <name>cent7</name> +>> <uuid>d5462bb6-159e-4dbd-9266-bf8c07fa1695</uuid> +>> <memory unit='KiB'>2097152</memory> +>> <currentMemory unit='KiB'>2097152</currentMemory> +>> <vcpu placement='static'>2</vcpu> +>> <os> +>> <type arch='aarch64' machine='virt'>hvm</type> +>> <loader readonly='yes' +>> type='pflash'>/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw</loader> +>> <nvram>/var/lib/libvirt/qemu/nvram/cent7_VARS.fd</nvram> +>> <boot dev='hd'/> +>> </os> +>> <cpu mode='host-passthrough'/> +>> <clock offset='utc'/> +>> <on_poweroff>destroy</on_poweroff> +>> <on_reboot>restart</on_reboot> +>> <on_crash>restart</on_crash> +>> <devices> +>> <emulator>/usr/bin/kvm</emulator> +>> <disk type='file' device='disk'> +>> <driver name='qemu' type='qcow2'/> +>> <source file='/var/lib/libvirt/images/cent7-2.img'/> +>> <target dev='sda' bus='scsi'/> +>> <address type='drive' controller='0' bus='0' target='0' unit='0'/> +>> </disk> +>> <disk type='file' device='cdrom'> +>> <driver name='qemu' type='raw'/> +>> <target dev='sdb' bus='scsi'/> +>> <readonly/> +>> <address type='drive' controller='0' bus='0' target='0' unit='1'/> +>> </disk> +>> <disk type='file' device='disk'> +>> <driver name='qemu' type='qcow2'/> +>> <source file='/var/lib/libvirt/images/cent7-10.img'/> +>> <target dev='sdc' bus='scsi'/> +>> <address type='drive' controller='0' bus='0' target='0' unit='2'/> +>> </disk> +>> <disk type='file' device='disk'> +>> <driver name='qemu' type='qcow2'/> +>> <source file='/var/lib/libvirt/images/cent7-11.img'/> +>> <target dev='sdd' bus='scsi'/> +>> <address type='drive' controller='0' bus='0' target='0' unit='3'/> +>> </disk> +>> <disk type='file' device='disk'> +>> <driver name='qemu' type='qcow2'/> +>> <source file='/var/lib/libvirt/images/cent7-13.img'/> +>> <target dev='sdv' bus='scsi'/> +>> <address type='drive' controller='3' bus='0' target='0' unit='0'/> +>> </disk> +>> <controller type='scsi' index='0' model='virtio-scsi'> +>> <address type='virtio-mmio'/> +>> </controller> +>> <controller type='scsi' index='1'> +>> <address type='virtio-mmio'/> +>> </controller> +>> <controller type='scsi' index='2'> +>> <address type='virtio-mmio'/> +>> </controller> +>> <controller type='scsi' index='3' model='virtio-scsi'> +>> <address type='virtio-mmio'/> +>> </controller> +>> <controller type='pci' index='0' model='pcie-root'/> +>> <controller type='pci' index='1' model='dmi-to-pci-bridge'> +>> <model name='i82801b11-bridge'/> +>> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' +>> function='0x0'/> +>> </controller> +>> <controller type='pci' index='2' model='pci-bridge'> +>> <model name='pci-bridge'/> +>> <target chassisNr='2'/> +>> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' +>> function='0x0'/> +>> </controller> +>> <interface type='bridge'> +>> <mac address='52:54:00:a1:6e:75'/> +>> <source bridge='br0'/> +>> <model type='virtio'/> +>> <address type='virtio-mmio'/> +>> </interface> +>> <serial type='pty'> +>> <target port='0'/> +>> </serial> +>> <console type='pty'> +>> <target type='serial' port='0'/> +>> </console> +>> </devices> +>> </domain> +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1594239/+subscriptions +>> +> +> + + +Fixed in commit f58b39d2d5b6dea1a757e1dc7d67a44eac1c4f9c. + +Fix has been included in QEMU v2.7.0 --> changing status to Fix Released. + +I’m sorry to post as a newbie here. I just want to confirm the bug described above by Kevin Zhao. At least that’s what it sounds like to me. I had a perfectly working VM on Qemu/KVM, with the VirtManager hypervisor, which I have *only* to be able to access an Audigy pci card from Windows XP. After I added a /dev/sbd disk as a device, the VM wouldn’t boot and even froze my system. Then I disconnected the disk from the VM, and now, though it doesn’t crash or freeze, I still can’t get into the VM, and I get the error message below: + +«Error starting domain: internal error: process exited while connecting to monitor: 2016-11-18T22:45:31.643085Z qemu-system-x86_64: -drive file=/home/[folder]/[folder]/VWinXP.raw,format=raw,if=none,id=drive-ide0-0-0: Could not open '/home/[folder]/[folder]/VWinXP.raw': Permission denied» + +I have changing permissions for the .raw file, but −intriguinly, for a newbie like me− everytime I try to open the VM, the permissions are changed automatically back to: + +Owner = Libvirt Qemu +Group = kvm + +I know this is not a help forum, but I would be grateful for some feedback. Been trying to fix this non-stop for the last two days. + diff --git a/results/classifier/zero-shot/108/all/1596579 b/results/classifier/zero-shot/108/all/1596579 new file mode 100644 index 000000000..92ab0e983 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1596579 @@ -0,0 +1,115 @@ +debug: 0.972 +semantic: 0.965 +performance: 0.965 +device: 0.964 +other: 0.963 +graphic: 0.959 +boot: 0.957 +socket: 0.955 +permissions: 0.953 +PID: 0.947 +vnc: 0.943 +KVM: 0.942 +files: 0.932 +network: 0.930 + +segfault upon reboot + +[ 31.167946] VFIO - User Level meta-driver version: 0.3 +[ 34.969182] kvm: zapping shadow pages for mmio generation wraparound +[ 43.095077] vfio-pci 0000:1a:00.0: irq 50 for MSI/MSI-X +[166493.891331] perf interrupt took too long (2506 > 2500), lowering kernel.perf_event_max_sample_rate to 50000 +[315765.858431] qemu-kvm[1385]: segfault at 0 ip (null) sp 00007ffe5430db18 error 14 +[315782.002077] vfio-pci 0000:1a:00.0: transaction is not cleared; proceeding with reset anyway +[315782.910854] mptsas 0000:1a:00.0: Refused to change power state, currently in D3 +[315782.911236] mptbase: ioc1: Initiating bringup +[315782.911238] mptbase: ioc1: WARNING - Unexpected doorbell active! +[315842.957613] mptbase: ioc1: ERROR - Failed to come READY after reset! IocState=f0000000 +[315842.957670] mptbase: ioc1: WARNING - ResetHistory bit failed to clear! +[315842.957675] mptbase: ioc1: ERROR - Diagnostic reset FAILED! (ffffffffh) +[315842.957717] mptbase: ioc1: WARNING - NOT READY WARNING! +[315842.957720] mptbase: ioc1: ERROR - didn't initialize properly! (-1) +[315842.957890] mptsas: probe of 0000:1a:00.0 failed with error -1 + +The qemu-kvm segfault happens when I issue a reboot on the Windows VM. The card I have is: +1a:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS (rev ff) + +I have two of these cards (bought with many years difference), exact same model, and they fail the same way. I'm using PCI passthrough on this card for access to the tape drive. +This is very easy to reproduce, so feel free to let me know what to try. +Kernel 3.10.0-327.18.2.el7.x86_64 (Centos 7.2.1511). +qemu-kvm-1.5.3-105.el7_2.4.x86_64 +Reporting it here because of the segfault, but I guess I might have to open a bug report with mptbase as well? + +Running the debuginfo qemu-kvm rpm and attaching with gdb might be interesting to get a backtrace from that segfault. Otherwise devices getting stuck in D3 often mean they didn't return from a reset correctly. Are we to assume that the VM died between the vfio-pci line and the mptbase line and the device was set to managed='yes' and therefore libvirt returned the device to the host driver? Please document your VM config and provide lspci -vvv info for the assigned device. + +The VM is fine until I issue a reboot on the guest OS, in this case it happened right at [315765.858431]. That is, once I boot the host, the guest starts fine, I am able to use the tape drive fine, but when I reboot for whatever reason, I guess the segfault. + +Is this enough or do you want the full dumpxml ? + + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x1a' slot='0x00' function='0x0'/> + </source> + <alias name='hostdev0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </hostdev> + +Makes sense to me what you've explained about libvirt returning to the host driver, but unfortunately I don't have enough knowledge to comment, sorry. + +lspci -vvv: + +1a:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS (rev 08) + Subsystem: Hewlett-Packard Company SC44Ge Host Bus Adapter + Physical Slot: 3 + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin A routed to IRQ 27 + Region 0: I/O ports at 2000 [disabled] [size=256] + Region 1: Memory at 97a10000 (64-bit, non-prefetchable) [size=16K] + Region 3: Memory at 97a00000 (64-bit, non-prefetchable) [size=64K] + Expansion ROM at <ignored> [disabled] + Capabilities: [50] Power Management version 2 + Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [68] Express (v1) Endpoint, MSI 00 + DevCap: MaxPayload 4096 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us + ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset- + DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported- + RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ + MaxPayload 256 bytes, MaxReadReq 4096 bytes + DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- + LnkCap: Port #0, Speed 2.5GT/s, Width x8, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us + ClockPM- Surprise- LLActRep- BwNot- + LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk- + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s, Width x8, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- + Capabilities: [98] MSI: Enable- Count=1/1 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Capabilities: [b0] MSI-X: Enable+ Count=1 Masked- + Vector table: BAR=1 offset=00002000 + PBA: BAR=1 offset=00003000 + Capabilities: [100 v1] Advanced Error Reporting + UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol- + UESvrt: DLP+ SDES- TLP+ FCP+ CmpltTO+ CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC+ UnsupReq- ACSViol- + CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- + CEMsk: RxErr- BadTLP+ BadDLLP+ Rollover+ Timeout+ NonFatalErr- + AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- + Kernel driver in use: vfio-pci + +Installed debuginfo packages and abrt caught it. The coredump is 11G but tar.bz2 everything is at 367M. Anything in specific you'd like from all the debug info generated? + + + + + +By all means, feel free to provide me instructions on how to debug this myself, so I can help others in the future, although I understand that can be more time consuming. If anyone would rather prefer talking on IRC, just let me know the network and channel. Thanks + +Can you reproduce this problem with the latest upstream version of QEMU (currently version 4.1)? Or is it only reproducible in the qemu-kvm from your distribution? (In the latter case, please report this bug to your distro instead) + +I have no way of reproducing now, should be good by now, I wouldn't worry about it, just close this, thanks. + +Ok, thanks for the update + diff --git a/results/classifier/zero-shot/108/all/1601 b/results/classifier/zero-shot/108/all/1601 new file mode 100644 index 000000000..c265825d6 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1601 @@ -0,0 +1,95 @@ +permissions: 0.974 +device: 0.971 +semantic: 0.971 +socket: 0.969 +other: 0.969 +PID: 0.967 +graphic: 0.967 +debug: 0.966 +performance: 0.960 +KVM: 0.955 +network: 0.953 +vnc: 0.947 +files: 0.946 +boot: 0.916 + +QEMU Guest Agent (qga) high CPU usage (1 core at 100%). May happen with guest-network-get-interfaces. Strace says: EAGAIN (Resource temporarily unavailable) +Description of problem: +I have a VM that has the QEMU guest agent installed. I use the QGA to get information periodically about the network interfaces. Meaning, I execute the `guest-network-get-interfaces` in a period around 1-2 seconds each. + +After a while (maybe a day or so) the QGA seems to lock up with the CPU at 100% in 1 core. It does not reply to more commands, and restarting the service sometimes doesn't work, so a hard reboot it is. + +`dmesg` doesn't show anything useful/relevant. When attempting to edit the `qemu-guest-agent.service` and append `/usr/bin/strace` to it, I can get this in a loop: + +``` +strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable) +strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable) +strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable) +strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable) +strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable) +strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable) +strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable) +strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable) +``` + +I don't have more knowledge to debug this further. I can help to provide more info if some guidance is provided. + +**Don't know if it helps/affects**, but the guest VM is running Docker with around 10 containers or so, so when QGA works, I get around 18 network interfaces, counting loopback, docker `veth`s and `br` interfaces. +Steps to reproduce: +1. Create a VM with Fedora 37 +2. Install the QEMU Guest Agent +3. Call `guest-network-get-interfaces` in a loop every 1-2 seconds (after it finishes) through QGA using the unix socket using the provided python script, called as: `python qga.py --socket /run/test-vm-108.qga '{ "execute": "guest-network-get-interfaces" }'` +4. Eventually, the guest agent will lock up at 100% CPU usage on 1 core +Additional information: +Python script used to call QGA: +``` +import argparse +import socket +import sys + +def main(): + buf_size = 1024 + timeout_secs = .5 + + parser = argparse.ArgumentParser() + parser.add_argument('--socket', required=True, help='Path to Unix socket') + parser.add_argument('request', help='Request to send') + args = parser.parse_args() + + unix_socket_path = args.socket + request = args.request + + try: + with socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) as sock: + sock.settimeout(timeout_secs) + sock.connect(unix_socket_path) + + request_bytes = request.encode('utf-8') + sock.sendall(request_bytes) + + response_bytes = b'' + received_bytes = sock.recv(buf_size) + response_bytes += received_bytes + + sock.setblocking(False) + while True: + try: + received_bytes = sock.recv(buf_size) + if not received_bytes: + break + response_bytes += received_bytes + except (BlockingIOError, TimeoutError): + break + except (FileNotFoundError, ConnectionRefusedError): + sock.close() + sys.exit() + + response = response_bytes.decode('utf-8').strip() + print(response) + + except (TimeoutError, FileNotFoundError, BlockingIOError, ConnectionRefusedError): + sys.exit() + +if __name__ == "__main__": + main() +``` diff --git a/results/classifier/zero-shot/108/all/16056596 b/results/classifier/zero-shot/108/all/16056596 new file mode 100644 index 000000000..e6f8e1f9c --- /dev/null +++ b/results/classifier/zero-shot/108/all/16056596 @@ -0,0 +1,108 @@ +permissions: 0.985 +other: 0.980 +semantic: 0.979 +debug: 0.978 +files: 0.975 +device: 0.973 +boot: 0.971 +graphic: 0.970 +performance: 0.970 +PID: 0.961 +socket: 0.952 +vnc: 0.946 +network: 0.940 +KVM: 0.934 + +[BUG][powerpc] KVM Guest Boot Failure and Hang at "Booting Linux via __start()" + +Bug Description: +Encountering a boot failure when launching a KVM guest with +'qemu-system-ppc64'. The guest hangs at boot, and the QEMU monitor +crashes. +Reproduction Steps: +# qemu-system-ppc64 --version +QEMU emulator version 9.2.50 (v9.2.0-2799-g0462a32b4f) +Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers +# /usr/bin/qemu-system-ppc64 -name avocado-vt-vm1 -machine +pseries,accel=kvm \ +-m 32768 -smp 32,sockets=1,cores=32,threads=1 -nographic \ + -device virtio-scsi-pci,id=scsi \ +-drive +file=/home/kvmci/tests/data/avocado-vt/images/rhel8.0devel-ppc64le.qcow2,if=none,id=drive0,format=qcow2 +\ +-device scsi-hd,drive=drive0,bus=scsi.0 \ + -netdev bridge,id=net0,br=virbr0 \ + -device virtio-net-pci,netdev=net0 \ + -serial pty \ + -device virtio-balloon-pci \ + -cpu host +QEMU 9.2.50 monitor - type 'help' for more information +char device redirected to /dev/pts/2 (label serial0) +(qemu) +(qemu) qemu-system-ppc64: warning: kernel_irqchip allowed but +unavailable: IRQ_XIVE capability must be present for KVM +Falling back to kernel-irqchip=off +** Qemu Hang + +(In another ssh session) +# screen /dev/pts/2 +Preparing to boot Linux version 6.10.4-200.fc40.ppc64le +(mockbuild@c23cc4e677614c34bb22d54eeea4dc1f) (gcc (GCC) 14.2.1 20240801 +(Red Hat 14.2.1-1), GNU ld version 2.41-37.fc40) #1 SMP Sun Aug 11 +15:20:17 UTC 2024 +Detected machine type: 0000000000000101 +command line: +BOOT_IMAGE=(ieee1275/disk,msdos2)/vmlinuz-6.10.4-200.fc40.ppc64le +root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root crashkernel=1024M +Max number of cores passed to firmware: 2048 (NR_CPUS = 2048) +Calling ibm,client-architecture-support... done +memory layout at init: + memory_limit : 0000000000000000 (16 MB aligned) + alloc_bottom : 0000000008200000 + alloc_top : 0000000030000000 + alloc_top_hi : 0000000800000000 + rmo_top : 0000000030000000 + ram_top : 0000000800000000 +instantiating rtas at 0x000000002fff0000... done +prom_hold_cpus: skipped +copying OF device tree... +Building dt strings... +Building dt structure... +Device tree strings 0x0000000008210000 -> 0x0000000008210bd0 +Device tree struct 0x0000000008220000 -> 0x0000000008230000 +Quiescing Open Firmware ... +Booting Linux via __start() @ 0x0000000000440000 ... +** Guest Console Hang + + +Git Bisect: +Performing git bisect points to the following patch: +# git bisect bad +e8291ec16da80566c121c68d9112be458954d90b is the first bad commit +commit e8291ec16da80566c121c68d9112be458954d90b (HEAD) +Author: Nicholas Piggin <npiggin@gmail.com> +Date: Thu Dec 19 13:40:31 2024 +1000 + + target/ppc: fix timebase register reset state +(H)DEC and PURR get reset before icount does, which causes them to +be +skewed and not match the init state. This can cause replay to not +match the recorded trace exactly. For DEC and HDEC this is usually +not +noticable since they tend to get programmed before affecting the + target machine. PURR has been observed to cause replay bugs when + running Linux. + + Fix this by resetting using a time of 0. + + Message-ID: <20241219034035.1826173-2-npiggin@gmail.com> + Signed-off-by: Nicholas Piggin <npiggin@gmail.com> + + hw/ppc/ppc.c | 11 ++++++++--- + 1 file changed, 8 insertions(+), 3 deletions(-) + + +Reverting the patch helps boot the guest. +Thanks, +Misbah Anjum N + diff --git a/results/classifier/zero-shot/108/all/1622547 b/results/classifier/zero-shot/108/all/1622547 new file mode 100644 index 000000000..c7266f5d1 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1622547 @@ -0,0 +1,411 @@ +other: 0.966 +boot: 0.958 +vnc: 0.955 +permissions: 0.954 +PID: 0.947 +socket: 0.945 +network: 0.937 +debug: 0.935 +files: 0.933 +performance: 0.931 +semantic: 0.930 +device: 0.930 +KVM: 0.919 +graphic: 0.916 + +qemu-system-sparc fatal error Trap 0x29 on Solaris 2.6 + +When trying to install Solaris 2.6 from original CDROM, qemu fail with the following error : + +qemu: fatal: Trap 0x29 while interrupts disabled, Error state +pc: f0041280 npc: f0041284 +%g0-7: 00000000 f0281800 08000000 ffffffff 00000000 f0243b88 00000001 f0244020 +%o0-7: 40400ce2 40400ce2 00000000 404000e2 f0243b88 00000000 f023ffd8 f0057914 +%l0-7: 40000cc2 f009645c f0096460 00000002 00000209 00000004 00000007 f023ff90 +%i0-7: 00000042 404000e3 00000000 404000e3 e0000000 f028192a f0240038 f0096448 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +psr: 40400cc2 (icc: -Z-- SPE: SP-) wim: 00000002 +fsr: 00000000 y: 00000000 + +The command line was : + +qemu-system-sparc -nographic -bios ./openbios-sparc32 -M SS-20 -hda ./36G.disk -m 512 -cdrom Solaris_2.6_Software_05_98.img -boot d -serial telnet:0.0.0.0:3000,server -smp 2,cores=2 -monitor null + +It fails with a similar output when using bios ss20_v2.25_rom. + +▶ qemu-system-sparc --version +QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers + +▶ uname -a +Linux xxx 4.7.1-1-ARCH #1 SMP PREEMPT Wed Aug 17 08:13:35 CEST 2016 x86_64 GNU/Linux + +On Mon, Sep 12, 2016 at 12:13 PM, Mathieu Clabaut +<email address hidden> wrote: +> Public bug reported: +> +> When trying to install Solaris 2.6 from original CDROM, qemu fail with +> the following error : +> +> qemu: fatal: Trap 0x29 while interrupts disabled, Error state +> pc: f0041280 npc: f0041284 +> %g0-7: 00000000 f0281800 08000000 ffffffff 00000000 f0243b88 00000001 f0244020 +> %o0-7: 40400ce2 40400ce2 00000000 404000e2 f0243b88 00000000 f023ffd8 f0057914 +> %l0-7: 40000cc2 f009645c f0096460 00000002 00000209 00000004 00000007 f023ff90 +> %i0-7: 00000042 404000e3 00000000 404000e3 e0000000 f028192a f0240038 f0096448 +> %f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> psr: 40400cc2 (icc: -Z-- SPE: SP-) wim: 00000002 +> fsr: 00000000 y: 00000000 +> +> The command line was : +> +> qemu-system-sparc -nographic -bios ./openbios-sparc32 -M SS-20 -hda +> ./36G.disk -m 512 -cdrom Solaris_2.6_Software_05_98.img -boot d -serial +> telnet:0.0.0.0:3000,server -smp 2,cores=2 -monitor null +> +> It fails with a similar output when using bios ss20_v2.25_rom. +> +> ▶ qemu-system-sparc --version +> QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +> +> ▶ uname -a +> Linux xxx 4.7.1-1-ARCH #1 SMP PREEMPT Wed Aug 17 08:13:35 CEST 2016 x86_64 GNU/Linux +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1622547 +> +> Title: +> qemu-system-sparc fatal error Trap 0x29 on Solaris 2.6 +> +> Status in QEMU: +> New +> +> Bug description: +> When trying to install Solaris 2.6 from original CDROM, qemu fail with +> the following error : +> +> qemu: fatal: Trap 0x29 while interrupts disabled, Error state +> pc: f0041280 npc: f0041284 +> %g0-7: 00000000 f0281800 08000000 ffffffff 00000000 f0243b88 00000001 f0244020 +> %o0-7: 40400ce2 40400ce2 00000000 404000e2 f0243b88 00000000 f023ffd8 f0057914 +> %l0-7: 40000cc2 f009645c f0096460 00000002 00000209 00000004 00000007 f023ff90 +> %i0-7: 00000042 404000e3 00000000 404000e3 e0000000 f028192a f0240038 f0096448 +> %f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> psr: 40400cc2 (icc: -Z-- SPE: SP-) wim: 00000002 +> fsr: 00000000 y: 00000000 +> +> The command line was : +> +> qemu-system-sparc -nographic -bios ./openbios-sparc32 -M SS-20 -hda +> ./36G.disk -m 512 -cdrom Solaris_2.6_Software_05_98.img -boot d +> -serial telnet:0.0.0.0:3000,server -smp 2,cores=2 -monitor null +> +> It fails with a similar output when using bios ss20_v2.25_rom. + +AFAIR [1] SS-20 requires another CPU. Can you try the following options? +-cpu "TI SuperSparc 50" +or +-cpu "TI SuperSparc 60" +or +-cpu "Ross RT620" + +(can't remember whether the latter was still supported in 2.6 though) + +Artyom + +1. http://tyom.blogspot.de/2010/05/sx-framebuffer-emulation.html + +> +> ▶ qemu-system-sparc --version +> QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +> +> ▶ uname -a +> Linux xxx 4.7.1-1-ARCH #1 SMP PREEMPT Wed Aug 17 08:13:35 CEST 2016 x86_64 GNU/Linux +> + + + +-- +Regards, +Artyom Tarasenko + +SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu + + +Thanks a lot Artyom. +-cpu "TI SuperSparc 50" does the job… + +This bug can be closed (sorry for the noise). + +This still fails for me even when using that CPU option. But it only fails with my just-compiled QEMU 2.8.0, NOT my distribution-provided QEMU 2.6.1. + +mike@ossy ~/qemu> sudo /usr/local/bin/qemu-system-sparc -bios ./ss20_v2.25_rom -M SS-20 -nographic -boot d -hda ./sol26_36G.disk -m 512 -cdrom /mymedia/Disk\ Sets/Solaris_2.6_SPARC/Solaris_2.6_Software_05_98.iso -serial telnet:0.0.0.0:3000,server -smp 2,cores=2 -cpu "TI SuperSparc 60" -net nic -net bridge,br=br0 +QEMU 2.8.0 monitor - type 'help' for more information +(qemu) QEMU waiting for connection on: disconnected:telnet:0.0.0.0:3000,server +qemu: fatal: Trap 0x29 while interrupts disabled, Error state +pc: 0000e754 npc: 0000e758 +%g0-7: 00000000 00010d88 00000000 00000000 00000000 00000000 00000000 00000000 +%o0-7: f1201e20 ffffffff 00000000 ffffffff ffffffff ffffffff ffffffff 00011a38 +%l0-7: f1201e20 0000e754 0000e758 00000029 00000300 00003c1c 00000000 ffffffff +%i0-7: 00013848 00000029 00000099 00000000 0edfe200 ffffffff ffffff40 00011a38 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +psr: 404010c5 (icc: -Z-- SPE: SP-) wim: 00000000 +fsr: 00000000 y: 00000000 + +fish: “sudo /usr/local/bin/qemu-system…” terminated by signal SIGABRT (Abort) + + +In the other window: +mike@ossy ~/qemu> telnet localhost 3000 +Trying 127.0.0.1... +Connected to localhost. +Escape character is '^]'. + +Power-ON Reset +Connection closed by foreign host. + + + + +Just confirmed that it works in QEMU 2.7.1, which is strange, since 2.8.0 does not list any SPARC changes! + +There were some improvements to TCG which I tested locally with quite a range of images (although I don't specifically have Solaris 2.6), and didn't see any regressions at the time. + +Does dropping the -smp argument help at all? Otherwise are you able to attempt a git bisect or send me a link to the image privately to test? + + +Dropping SMP doesn't make a difference (I dropped it anyway since it doesn't make a second processor appear in the guest, and as I've learned it's currently emulated in one thread anyway). You don't need an image, just the SPARCstation-20 ROM file which can be had from a variety of sources: +910bd7306fcec38361fc4c3a2be50fa0 ss20_v2.25_rom +and with no images listed: +sudo /usr/src/qemu-2.8.0/build/sparc-softmmu/qemu-system-sparc -bios ./ss20_v2.25_rom -M SS-20 -nographic -m 512 -cpu "TI SuperSparc 60" -net nic -net bridge,br=br0 +still get the error. I've never done a git bisect before but I've always wanted to, so I will try. :) + +That was fun! And we have a result: + +fbb4bbb62e5603c991b880e25dc4bb30d342b944 is the first bad commit +commit fbb4bbb62e5603c991b880e25dc4bb30d342b944 +Author: Richard Henderson <email address hidden> +Date: Tue Jul 12 15:38:13 2016 -0700 + + target-sparc: Implement ldstub_asi inline + + Tested-by: Mark Cave-Ayland <email address hidden> + Signed-off-by: Richard Henderson <email address hidden> + +:040000 040000 670db498d49d38bc878efccd55e39d03f074cadf 5052ce1f32ddf00646aaa9e37bb73e38b4e750f1 M target-sparc + + +I verified that the last good commit not only boots the BIOS but also boots the OS properly (and faster than 2.7.1). + +Richard, can you please look at it? + +The test case: + +qemu-system-sparc -bios ./ss20_v2.25_rom -M SS-20 -nographic -m 512 +-cpu "TI SuperSparc 60" + +Kind regards, +Artyom + +On Wed, Jan 25, 2017 at 5:16 PM, <email address hidden> +<email address hidden> wrote: +> That was fun! And we have a result: +> +> fbb4bbb62e5603c991b880e25dc4bb30d342b944 is the first bad commit +> commit fbb4bbb62e5603c991b880e25dc4bb30d342b944 +> Author: Richard Henderson <email address hidden> +> Date: Tue Jul 12 15:38:13 2016 -0700 +> +> target-sparc: Implement ldstub_asi inline +> +> Tested-by: Mark Cave-Ayland <email address hidden> +> Signed-off-by: Richard Henderson <email address hidden> +> +> :040000 040000 670db498d49d38bc878efccd55e39d03f074cadf +> 5052ce1f32ddf00646aaa9e37bb73e38b4e750f1 M target-sparc +> +> +> I verified that the last good commit not only boots the BIOS but also boots the OS properly (and faster than 2.7.1). +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1622547 +> +> Title: +> qemu-system-sparc fatal error Trap 0x29 on Solaris 2.6 +> +> Status in QEMU: +> New +> +> Bug description: +> When trying to install Solaris 2.6 from original CDROM, qemu fail with +> the following error : +> +> qemu: fatal: Trap 0x29 while interrupts disabled, Error state +> pc: f0041280 npc: f0041284 +> %g0-7: 00000000 f0281800 08000000 ffffffff 00000000 f0243b88 00000001 f0244020 +> %o0-7: 40400ce2 40400ce2 00000000 404000e2 f0243b88 00000000 f023ffd8 f0057914 +> %l0-7: 40000cc2 f009645c f0096460 00000002 00000209 00000004 00000007 f023ff90 +> %i0-7: 00000042 404000e3 00000000 404000e3 e0000000 f028192a f0240038 f0096448 +> %f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> psr: 40400cc2 (icc: -Z-- SPE: SP-) wim: 00000002 +> fsr: 00000000 y: 00000000 +> +> The command line was : +> +> qemu-system-sparc -nographic -bios ./openbios-sparc32 -M SS-20 -hda +> ./36G.disk -m 512 -cdrom Solaris_2.6_Software_05_98.img -boot d +> -serial telnet:0.0.0.0:3000,server -smp 2,cores=2 -monitor null +> +> It fails with a similar output when using bios ss20_v2.25_rom. +> +> ▶ qemu-system-sparc --version +> QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +> +> ▶ uname -a +> Linux xxx 4.7.1-1-ARCH #1 SMP PREEMPT Wed Aug 17 08:13:35 CEST 2016 x86_64 GNU/Linux +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1622547/+subscriptions +> + + + +-- +Regards, +Artyom Tarasenko + +SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu + + +On Fri, Jan 27, 2017 at 9:15 AM, Richard Henderson <email address hidden> wrote: +> Fixes the booting of ss20 roms. + +Mike, can you please test this fix? + +> Reported-by: Mark Cave-Ayland <email address hidden> + +Initially Reported-by: Michael Russo <email address hidden> + +> Signed-off-by: Richard Henderson <email address hidden> +> --- +> target/sparc/translate.c | 27 +++++++++++++++++++++++++-- +> 1 file changed, 25 insertions(+), 2 deletions(-) +> +> diff --git a/target/sparc/translate.c b/target/sparc/translate.c +> index 655060c..aa6734d 100644 +> --- a/target/sparc/translate.c +> +++ b/target/sparc/translate.c +> @@ -2448,8 +2448,31 @@ static void gen_ldstub_asi(DisasContext *dc, TCGv dst, TCGv addr, int insn) +> gen_ldstub(dc, dst, addr, da.mem_idx); +> break; +> default: +> - /* ??? Should be DAE_invalid_asi. */ +> - gen_exception(dc, TT_DATA_ACCESS); +> + /* ??? In theory, this should be raise DAE_invalid_asi. +> + But the SS-20 roms do ldstuba [%l0] #ASI_M_CTL, %o1. */ +> + if (parallel_cpus) { +> + gen_helper_exit_atomic(cpu_env); +> + } else { +> + TCGv_i32 r_asi = tcg_const_i32(da.asi); +> + TCGv_i32 r_mop = tcg_const_i32(MO_UB); +> + TCGv_i64 s64, t64; +> + +> + save_state(dc); +> + t64 = tcg_temp_new_i64(); +> + gen_helper_ld_asi(t64, cpu_env, addr, r_asi, r_mop); +> + +> + s64 = tcg_const_i64(0xff); +> + gen_helper_st_asi(cpu_env, addr, s64, r_asi, r_mop); +> + tcg_temp_free_i64(s64); +> + tcg_temp_free_i32(r_mop); +> + tcg_temp_free_i32(r_asi); +> + +> + tcg_gen_trunc_i64_tl(dst, t64); +> + tcg_temp_free_i64(t64); +> + +> + /* End the TB. */ +> + dc->npc = DYNAMIC_PC; +> + } +> break; +> } +> } +> -- +> 2.9.3 +> + + + +-- +Regards, +Artyom Tarasenko + +SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu + + +Yep, this works great for the SS-20 ROM (tested with SS-5 ROM also). Boots all the way to OS (have to use -nographic but that's fine). Thanks! + +On 27/01/17 12:57, Artyom Tarasenko wrote: + +> On Fri, Jan 27, 2017 at 9:15 AM, Richard Henderson <email address hidden> wrote: +>> Fixes the booting of ss20 roms. +> +> Mike, can you please test this fix? +> +>> Reported-by: Mark Cave-Ayland <email address hidden> +> +> Initially Reported-by: Michael Russo <email address hidden> +> +>> Signed-off-by: Richard Henderson <email address hidden> + +Thanks Richard. + +I've given this a quick spin around my various SPARC images and it looks +good with no regressions, so: + +Tested-by: Mark Cave-Ayland <email address hidden> + +Also when resubmitting with the updated Reported-by above, can we also +CC qemu-stable to get this into the next 2.8 release? + + +ATB, + +Mark. + + + +Hi everyone, +Thanks for your hard work on SPARC emulation. Almost feels like I got my old SS5 and SS20 back. +What commit (if any) might I find the fix for SS20 in? +Thanks, +Vincent + +BTW, the patch posted in comment #9 works for me as well on qemu 2.8.0. +Thanks + +The fix has now been applied to git master (with a CC to qemu-stable) and so should appear in the upcoming 2.9.0 release as well as the stable 2.8.1 release. + +Commit 3db010c3398d03646 has been released with 2.9.0, so setting the status to "Fix released" + diff --git a/results/classifier/zero-shot/108/all/1630723 b/results/classifier/zero-shot/108/all/1630723 new file mode 100644 index 000000000..2605e5047 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1630723 @@ -0,0 +1,536 @@ +permissions: 0.978 +PID: 0.967 +semantic: 0.956 +device: 0.953 +files: 0.950 +graphic: 0.949 +socket: 0.940 +performance: 0.939 +boot: 0.928 +other: 0.927 +network: 0.924 +vnc: 0.914 +KVM: 0.903 +debug: 0.901 + +UART writes to netduino2/stm32f205-soc disappear + +Writes to UART 2 and 3 disappear. As a sanity check I put printf statements in the function stm32f2xx_usart_write in qemu/hw/char/stm32f2xx_usart.c and recompiled qemu. The result confirmed text sent to UART1 and UART4 are sent to that function while text sent to UART 2 and 3 are not. I assume writes to all 4 need to make it to that function for emulations to operate correctly. + +Example code that writes to all 4 UARTs/USARTs (does not contain the printf statements mention above): +https://github.com/skintigh/baremetal_netduino2 + +The only machine I saw listed in the help output is "netduino2." I pulled +QEMU from github, was that the right thing to do? + +I found the specifications for the stm32f2xx and some similar chips and +verified the addresses and interrupts are correct. + +The stm32f205 should support 6 UARTs, and the 6 addresses and IRQs are +coded correctly. However there is a hard-coded value MAX_SERIAL_PORTS limiting +serial_hds to 4, and I don't know why. I am considering submitting a patch. + +If I increase MAX_SERIAL_PORTS I can write to UARTs 1, 4, 5, and 6 and +output them to sockets. However writes to UARTs 2 and 3 just disappear. +They don't even trigger my printf in stm32f2xx_usart_write. It seems like +they are being intercepted somewhere, and unfortunately my knowledge of +QEMU is too low to know where to look. Any pointers would be greatly +appreciated. + +Thanks again for all your help + +On Thu, Oct 6, 2016 at 8:18 PM, Alistair Francis <email address hidden> +wrote: + +> QEMU only supports the Netduino (not Netduino 2) it is possible that +> the base addresses are different and that is why you aren't seeing the +> serial output. +> +> Thanks, +> +> Alistair +> +> +> On Wed, Oct 5, 2016 at 11:56 AM, Seth <email address hidden> wrote: +> > Public bug reported: +> > +> > Writes to UART 2 and 3 disappear. As a sanity check I put printf +> > statements in the function stm32f2xx_usart_write in +> > qemu/hw/char/stm32f2xx_usart.c and recompiled qemu. The result confirmed +> > text sent to UART1 and UART4 are sent to that function while text sent +> > to UART 2 and 3 are not. I assume writes to all 4 need to make it to +> > that function for emulations to operate correctly. +> > +> > Example code that writes to all 4 UARTs/USARTs (does not contain the +> printf statements mention above): +> > https://github.com/skintigh/baremetal_netduino2 +> > +> > ** Affects: qemu +> > Importance: Undecided +> > Status: New +> > +> > -- +> > You received this bug notification because you are a member of qemu- +> > devel-ml, which is subscribed to QEMU. +> > https://bugs.launchpad.net/bugs/1630723 +> > +> > Title: +> > UART writes to netduino2/stm32f205-soc disappear +> > +> > Status in QEMU: +> > New +> > +> > Bug description: +> > Writes to UART 2 and 3 disappear. As a sanity check I put printf +> > statements in the function stm32f2xx_usart_write in +> > qemu/hw/char/stm32f2xx_usart.c and recompiled qemu. The result +> > confirmed text sent to UART1 and UART4 are sent to that function while +> > text sent to UART 2 and 3 are not. I assume writes to all 4 need to +> > make it to that function for emulations to operate correctly. +> > +> > Example code that writes to all 4 UARTs/USARTs (does not contain the +> printf statements mention above): +> > https://github.com/skintigh/baremetal_netduino2 +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/1630723/+subscriptions +> > +> + + +On 7 October 2016 at 17:03, Alistair Francis <email address hidden> wrote: +> On Fri, Oct 7, 2016 at 8:59 AM, Seth K <email address hidden> wrote: +>> The stm32f205 should support 6 UARTs, and the 6 addresses and IRQs are coded +>> correctly. However there is a hard-coded value MAX_SERIAL_PORTS limiting +>> serial_hds to 4, and I don't know why. I am considering submitting a patch. +> +> I'm not sure why we have that limit, you can submit a patch and see +> what everyone says. + +Almost certainly purely historical reasons. MAX_SERIAL_PORTS has +been 4 since it was introduced in commit 8d11df9e5aa584 in 2004, +because the x86 PC has 4 serial ports. Presumably nobody since +has found the limit annoying enough to adjust. + +thanks +-- PMM + + +I applied that patch, made qemu and ran my code, I didn't see a change. + +According to the STM32F20xxx memory map, the memory range seems to be 0x400 +-- UART 1 is listed as 0x40010000 - 0x400103FF. Should that memory region +be set to 0x400? + +I tried that too, no change yet, but maybe I should look at the other +memory settings. + +I also tried making these changes in another branch where I made this chip +have 8 UARTS. That was unchanged: I can only output UARTS 1,4,5,6. + +On Fri, Oct 7, 2016 at 12:10 PM, Alistair Francis <email address hidden> +wrote: + +> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis <email address hidden> +> wrote: +> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K <email address hidden> wrote: +> >> The only machine I saw listed in the help output is "netduino2." I +> pulled +> >> QEMU from github, was that the right thing to do? +> >> +> >> I found the specifications for the stm32f2xx and some similar chips and +> >> verified the addresses and interrupts are correct. +> > +> > Sorry my mistake. It is a the Netduino 2 Plus that we don't support. +> > +> > I think we should move this conversation to the bug report as well, I +> > was hoping that replying to the email would update the bug report but +> > it doesn't look like it. +> > +> >> +> >> The stm32f205 should support 6 UARTs, and the 6 addresses and IRQs are +> coded +> >> correctly. However there is a hard-coded value MAX_SERIAL_PORTS limiting +> >> serial_hds to 4, and I don't know why. I am considering submitting a +> patch. +> > +> > I'm not sure why we have that limit, you can submit a patch and see +> > what everyone says. +> > +> >> +> >> If I increase MAX_SERIAL_PORTS I can write to UARTs 1, 4, 5, and 6 and +> >> output them to sockets. However writes to UARTs 2 and 3 just disappear. +> They +> >> don't even trigger my printf in stm32f2xx_usart_write. It seems like +> they +> >> are being intercepted somewhere, and unfortunately my knowledge of QEMU +> is +> >> too low to know where to look. Any pointers would be greatly +> appreciated. +> > +> > Strange. There could be something else addressed there. If you run +> > 'info mtree' at the QEMU prompt (Ctrl-a + c) you should be able to see +> > the memory map of the system. +> +> Hey Seth, +> +> What if you try this diff? Does that help? +> +> diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c +> index 4c6640d..b07c67b 100644 +> --- a/hw/char/stm32f2xx_usart.c +> +++ b/hw/char/stm32f2xx_usart.c +> @@ -204,7 +204,7 @@ static void stm32f2xx_usart_init(Object *obj) +> sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->irq); +> +> memory_region_init_io(&s->mmio, obj, &stm32f2xx_usart_ops, s, +> - TYPE_STM32F2XX_USART, 0x2000); +> + TYPE_STM32F2XX_USART, 0x200); +> sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio); +> } +> +> Thanks, +> +> Alistair +> + + +It's a bare metal program so I don't really have anywhere to print to, +other than my custom function to output to the uart. I did double check all +the address to make sure they agreed with the documentation and the Qemu +source code. I tried changing around the destinations of the output just to +verify the order of the write or the destination somehow affected the +output. I tried being tricky, like instead of writing to usart 3 I wrote to +uart 4 - 0x400 (the same address, it didn't work). The code should be +simple enough that I don't have room for any crazy mistakes: + +volatile unsigned char * const USART1_PTR = (unsigned char *)0x40011000; +volatile unsigned char * const USART2_PTR = (unsigned char *)0x40004400; +volatile unsigned char * const USART3_PTR = (unsigned char *)0x40004800; +volatile unsigned char * const UART4_PTR = (unsigned char *)0x40004c00; + +void display(const char *string, volatile unsigned char * uart_addr){ + while(*string != '\0'){ + *(uart_addr+4) = *string; + string++; + } +} + +int my_init(){ + display("Test 1/4\n", USART1_PTR); + display("Test 2/4\n", USART2_PTR); + display("Test 3/4\n", USART3_PTR); + display("Test 4/4\n", UART4_PTR); +} + + +In the past I ran a really long test where I wrote to every possible +address just to see what happens. No unexpected output occurred. I can do +that test again, but it takes hours. I could also write code to convert the +address to something printable to verify the address isn't being changed, +but that seems unlikely. + +Another thought I had is maybe there is some sort of interaction between +where I am setting the stack top - 0x20001000 - but that doesn't seem like +it should interfere. Maybe the linker or objcopy are doing something crazy? + +I don't understand Qemu enough to know what should be calling the functions +that handle UART read/write. Is there something I should look at in Qemu +and try to intercept? + +On Fri, Oct 7, 2016 at 6:27 PM, Alistair Francis <email address hidden> +wrote: + +> On Fri, Oct 7, 2016 at 1:04 PM, Seth K <email address hidden> wrote: +> > I applied that patch, made qemu and ran my code, I didn't see a change. +> > +> > According to the STM32F20xxx memory map, the memory range seems to be +> 0x400 +> > -- UART 1 is listed as 0x40010000 - 0x400103FF. Should that memory +> region be +> > set to 0x400? +> +> I was hoping that would have fixed it. +> +> It sounds like it should be 0x400 then, although it doesn't sound like +> this is causing this issue. +> +> > +> > I tried that too, no change yet, but maybe I should look at the other +> memory +> > settings. +> +> Maybe, it is very strange that it's not reaching the read/write functions. +> +> Can you try putting print statements in the guest software to make +> sure it is writing to the locations you expect and then make sure +> there are no conditionals in QEMU that cause the print statements to +> not be printed. See what that uncovers. +> +> Thanks, +> +> Alistair +> +> > +> > I also tried making these changes in another branch where I made this +> chip +> > have 8 UARTS. That was unchanged: I can only output UARTS 1,4,5,6. +> > +> > On Fri, Oct 7, 2016 at 12:10 PM, Alistair Francis <email address hidden> +> > wrote: +> >> +> >> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis <email address hidden> +> >> wrote: +> >> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K <email address hidden> wrote: +> >> >> The only machine I saw listed in the help output is "netduino2." I +> >> >> pulled +> >> >> QEMU from github, was that the right thing to do? +> >> >> +> >> >> I found the specifications for the stm32f2xx and some similar chips +> and +> >> >> verified the addresses and interrupts are correct. +> >> > +> >> > Sorry my mistake. It is a the Netduino 2 Plus that we don't support. +> >> > +> >> > I think we should move this conversation to the bug report as well, I +> >> > was hoping that replying to the email would update the bug report but +> >> > it doesn't look like it. +> >> > +> >> >> +> >> >> The stm32f205 should support 6 UARTs, and the 6 addresses and IRQs +> are +> >> >> coded +> >> >> correctly. However there is a hard-coded value MAX_SERIAL_PORTS +> >> >> limiting +> >> >> serial_hds to 4, and I don't know why. I am considering submitting a +> >> >> patch. +> >> > +> >> > I'm not sure why we have that limit, you can submit a patch and see +> >> > what everyone says. +> >> > +> >> >> +> >> >> If I increase MAX_SERIAL_PORTS I can write to UARTs 1, 4, 5, and 6 +> and +> >> >> output them to sockets. However writes to UARTs 2 and 3 just +> disappear. +> >> >> They +> >> >> don't even trigger my printf in stm32f2xx_usart_write. It seems like +> >> >> they +> >> >> are being intercepted somewhere, and unfortunately my knowledge of +> QEMU +> >> >> is +> >> >> too low to know where to look. Any pointers would be greatly +> >> >> appreciated. +> >> > +> >> > Strange. There could be something else addressed there. If you run +> >> > 'info mtree' at the QEMU prompt (Ctrl-a + c) you should be able to see +> >> > the memory map of the system. +> >> +> >> Hey Seth, +> >> +> >> What if you try this diff? Does that help? +> >> +> >> diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c +> >> index 4c6640d..b07c67b 100644 +> >> --- a/hw/char/stm32f2xx_usart.c +> >> +++ b/hw/char/stm32f2xx_usart.c +> >> @@ -204,7 +204,7 @@ static void stm32f2xx_usart_init(Object *obj) +> >> sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->irq); +> >> +> >> memory_region_init_io(&s->mmio, obj, &stm32f2xx_usart_ops, s, +> >> - TYPE_STM32F2XX_USART, 0x2000); +> >> + TYPE_STM32F2XX_USART, 0x200); +> >> sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio); +> >> } +> >> +> >> Thanks, +> >> +> >> Alistair +> > +> > +> + + +I've narrowed this down. In exec.c the address is reduced by +section->offset_within_address_space. However, half the time that seems to +be wrong. + +For usart1 at 40011004 it is 40011000, a difference of 4 which signals a +usart write. + +For usart2 at 40004404 it is 40000c00, a difference of 3804 which means +nothing. + +On Wed, Oct 12, 2016 at 6:25 PM, Seth K <email address hidden> wrote: + +> It's a bare metal program so I don't really have anywhere to print to, +> other than my custom function to output to the uart. I did double check all +> the address to make sure they agreed with the documentation and the Qemu +> source code. I tried changing around the destinations of the output just to +> verify the order of the write or the destination somehow affected the +> output. I tried being tricky, like instead of writing to usart 3 I wrote to +> uart 4 - 0x400 (the same address, it didn't work). The code should be +> simple enough that I don't have room for any crazy mistakes: +> +> volatile unsigned char * const USART1_PTR = (unsigned char *)0x40011000; +> volatile unsigned char * const USART2_PTR = (unsigned char *)0x40004400; +> volatile unsigned char * const USART3_PTR = (unsigned char *)0x40004800; +> volatile unsigned char * const UART4_PTR = (unsigned char *)0x40004c00; +> +> void display(const char *string, volatile unsigned char * uart_addr){ +> while(*string != '\0'){ +> *(uart_addr+4) = *string; +> string++; +> } +> } +> +> int my_init(){ +> display("Test 1/4\n", USART1_PTR); +> display("Test 2/4\n", USART2_PTR); +> display("Test 3/4\n", USART3_PTR); +> display("Test 4/4\n", UART4_PTR); +> } +> +> +> In the past I ran a really long test where I wrote to every possible +> address just to see what happens. No unexpected output occurred. I can do +> that test again, but it takes hours. I could also write code to convert the +> address to something printable to verify the address isn't being changed, +> but that seems unlikely. +> +> Another thought I had is maybe there is some sort of interaction between +> where I am setting the stack top - 0x20001000 - but that doesn't seem like +> it should interfere. Maybe the linker or objcopy are doing something crazy? +> +> I don't understand Qemu enough to know what should be calling the +> functions that handle UART read/write. Is there something I should look at +> in Qemu and try to intercept? +> +> On Fri, Oct 7, 2016 at 6:27 PM, Alistair Francis <email address hidden> +> wrote: +> +>> On Fri, Oct 7, 2016 at 1:04 PM, Seth K <email address hidden> wrote: +>> > I applied that patch, made qemu and ran my code, I didn't see a change. +>> > +>> > According to the STM32F20xxx memory map, the memory range seems to be +>> 0x400 +>> > -- UART 1 is listed as 0x40010000 - 0x400103FF. Should that memory +>> region be +>> > set to 0x400? +>> +>> I was hoping that would have fixed it. +>> +>> It sounds like it should be 0x400 then, although it doesn't sound like +>> this is causing this issue. +>> +>> > +>> > I tried that too, no change yet, but maybe I should look at the other +>> memory +>> > settings. +>> +>> Maybe, it is very strange that it's not reaching the read/write functions. +>> +>> Can you try putting print statements in the guest software to make +>> sure it is writing to the locations you expect and then make sure +>> there are no conditionals in QEMU that cause the print statements to +>> not be printed. See what that uncovers. +>> +>> Thanks, +>> +>> Alistair +>> +>> > +>> > I also tried making these changes in another branch where I made this +>> chip +>> > have 8 UARTS. That was unchanged: I can only output UARTS 1,4,5,6. +>> > +>> > On Fri, Oct 7, 2016 at 12:10 PM, Alistair Francis <<email address hidden> +>> > +>> > wrote: +>> >> +>> >> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis <<email address hidden> +>> > +>> >> wrote: +>> >> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K <email address hidden> wrote: +>> >> >> The only machine I saw listed in the help output is "netduino2." I +>> >> >> pulled +>> >> >> QEMU from github, was that the right thing to do? +>> >> >> +>> >> >> I found the specifications for the stm32f2xx and some similar chips +>> and +>> >> >> verified the addresses and interrupts are correct. +>> >> > +>> >> > Sorry my mistake. It is a the Netduino 2 Plus that we don't support. +>> >> > +>> >> > I think we should move this conversation to the bug report as well, I +>> >> > was hoping that replying to the email would update the bug report but +>> >> > it doesn't look like it. +>> >> > +>> >> >> +>> >> >> The stm32f205 should support 6 UARTs, and the 6 addresses and IRQs +>> are +>> >> >> coded +>> >> >> correctly. However there is a hard-coded value MAX_SERIAL_PORTS +>> >> >> limiting +>> >> >> serial_hds to 4, and I don't know why. I am considering submitting a +>> >> >> patch. +>> >> > +>> >> > I'm not sure why we have that limit, you can submit a patch and see +>> >> > what everyone says. +>> >> > +>> >> >> +>> >> >> If I increase MAX_SERIAL_PORTS I can write to UARTs 1, 4, 5, and 6 +>> and +>> >> >> output them to sockets. However writes to UARTs 2 and 3 just +>> disappear. +>> >> >> They +>> >> >> don't even trigger my printf in stm32f2xx_usart_write. It seems like +>> >> >> they +>> >> >> are being intercepted somewhere, and unfortunately my knowledge of +>> QEMU +>> >> >> is +>> >> >> too low to know where to look. Any pointers would be greatly +>> >> >> appreciated. +>> >> > +>> >> > Strange. There could be something else addressed there. If you run +>> >> > 'info mtree' at the QEMU prompt (Ctrl-a + c) you should be able to +>> see +>> >> > the memory map of the system. +>> >> +>> >> Hey Seth, +>> >> +>> >> What if you try this diff? Does that help? +>> >> +>> >> diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c +>> >> index 4c6640d..b07c67b 100644 +>> >> --- a/hw/char/stm32f2xx_usart.c +>> >> +++ b/hw/char/stm32f2xx_usart.c +>> >> @@ -204,7 +204,7 @@ static void stm32f2xx_usart_init(Object *obj) +>> >> sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->irq); +>> >> +>> >> memory_region_init_io(&s->mmio, obj, &stm32f2xx_usart_ops, s, +>> >> - TYPE_STM32F2XX_USART, 0x2000); +>> >> + TYPE_STM32F2XX_USART, 0x200); +>> >> sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio); +>> >> } +>> >> +>> >> Thanks, +>> >> +>> >> Alistair +>> > +>> > +>> +> +> + + +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 all 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". Thank you and sorry for the inconvenience. + + +Example program tested successfully on commit 3493c36f037. + +Eventually fixed by fc38a1120c2 ("Remove checks on MAX_SERIAL_PORTS that are just bounds checks"). + + diff --git a/results/classifier/zero-shot/108/all/1640073 b/results/classifier/zero-shot/108/all/1640073 new file mode 100644 index 000000000..d61b6cda5 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1640073 @@ -0,0 +1,98 @@ +other: 0.981 +vnc: 0.940 +semantic: 0.939 +permissions: 0.932 +debug: 0.930 +graphic: 0.930 +performance: 0.928 +PID: 0.920 +socket: 0.919 +device: 0.919 +files: 0.918 +KVM: 0.916 +network: 0.914 +boot: 0.902 + +Guest pause because VMPTRLD failed in KVM + +1) Qemu command: +/usr/bin/qemu-kvm -name omu1 -S -machine pc-i440fx-2.3,accel=kvm,usb=off -cpu host -m 15625 -realtime mlock=off -smp 8,sockets=1,cores=8,threads=1 -uuid a2aacfff-6583-48b4-b6a4-e6830e519931 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/omu1.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/env/guest1.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/home/env/guest_300G.img,if=none,id=drive-virtio-disk1,format=raw,cache=none,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:80:05:00:00,bus=pci.0,addr=0x3 -netdev tap,fd=27,id=hostnet1,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=00:00:80:05:00:01,bus=pci.0,addr=0x4 -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,vgamem_mb=16,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on + +2) Qemu log: +KVM: entry failed, hardware error 0x4 +RAX=00000000ffffffed RBX=ffff8803fa2d7fd8 RCX=0100000000000000 RDX=0000000000000000 +RSI=0000000000000000 RDI=0000000000000046 RBP=ffff8803fa2d7e90 RSP=ffff8803fa2efe90 +R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=000000000000b69a +R12=0000000000000001 R13=ffffffff81a25b40 R14=0000000000000000 R15=ffff8803fa2d7fd8 +RIP=ffffffff81053e16 RFL=00000286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 ffffffff 00c00000 +CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0000 0000000000000000 ffffffff 00c00000 +FS =0000 0000000000000000 ffffffff 00c00000 +GS =0000 ffff88040f540000 ffffffff 00c00000 +LDT=0000 0000000000000000 ffffffff 00c00000 +TR =0040 ffff88040f550a40 00002087 00008b00 DPL=0 TSS64-busy +GDT= ffff88040f549000 0000007f +IDT= ffffffffff529000 00000fff +CR0=80050033 CR2=00007f81ca0c5000 CR3=00000003f5081000 CR4=000407e0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +Code=?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? <??> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? + +3) Demsg +[347315.028339] kvm: vmptrld ffff8817ec5f0000/17ec5f0000 failed +klogd 1.4.1, ---------- state change ---------- +[347315.039506] kvm: vmptrld ffff8817ec5f0000/17ec5f0000 failed +[347315.051728] kvm: vmptrld ffff8817ec5f0000/17ec5f0000 failed +[347315.057472] vmwrite error: reg 6c0a value ffff88307e66e480 (err 2120672384) +[347315.064567] Pid: 69523, comm: qemu-kvm Tainted: GF X 3.0.93-0.8-default #1 +[347315.064569] Call Trace: +[347315.064587] [<ffffffff810049d5>] dump_trace+0x75/0x300 +[347315.064595] [<ffffffff8145e3e3>] dump_stack+0x69/0x6f +[347315.064617] [<ffffffffa03738de>] vmx_vcpu_load+0x11e/0x1d0 [kvm_intel] +[347315.064647] [<ffffffffa029a204>] kvm_arch_vcpu_load+0x44/0x1d0 [kvm] +[347315.064669] [<ffffffff81054ee1>] finish_task_switch+0x81/0xe0 +[347315.064676] [<ffffffff8145f0b4>] thread_return+0x3b/0x2a7 +[347315.064687] [<ffffffffa028d9b5>] kvm_vcpu_block+0x65/0xa0 [kvm] +[347315.064703] [<ffffffffa02a16d1>] __vcpu_run+0xd1/0x260 [kvm] +[347315.064732] [<ffffffffa02a2418>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm] +[347315.064759] [<ffffffffa028ecee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm] +[347315.064771] [<ffffffff8116bdfb>] do_vfs_ioctl+0x8b/0x3b0 +[347315.064776] [<ffffffff8116c1c1>] sys_ioctl+0xa1/0xb0 +[347315.064783] [<ffffffff81469272>] system_call_fastpath+0x16/0x1b +[347315.064797] [<00007fee51969ce7>] 0x7fee51969ce6 +[347315.064799] vmwrite error: reg 6c0c value ffff88307e664000 (err 2120630272) +[347315.064802] Pid: 69523, comm: qemu-kvm Tainted: GF X 3.0.93-0.8-default #1 +[347315.064803] Call Trace: +[347315.064807] [<ffffffff810049d5>] dump_trace+0x75/0x300 +[347315.064811] [<ffffffff8145e3e3>] dump_stack+0x69/0x6f +[347315.064817] [<ffffffffa03738ec>] vmx_vcpu_load+0x12c/0x1d0 [kvm_intel] +[347315.064832] [<ffffffffa029a204>] kvm_arch_vcpu_load+0x44/0x1d0 [kvm] +[347315.064851] [<ffffffff81054ee1>] finish_task_switch+0x81/0xe0 +[347315.064855] [<ffffffff8145f0b4>] thread_return+0x3b/0x2a7 +[347315.064865] [<ffffffffa028d9b5>] kvm_vcpu_block+0x65/0xa0 [kvm] +[347315.064880] [<ffffffffa02a16d1>] __vcpu_run+0xd1/0x260 [kvm] +[347315.064907] [<ffffffffa02a2418>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm] +[347315.064933] [<ffffffffa028ecee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm] +[347315.064943] [<ffffffff8116bdfb>] do_vfs_ioctl+0x8b/0x3b0 +[347315.064947] [<ffffffff8116c1c1>] sys_ioctl+0xa1/0xb0 +[347315.064951] [<ffffffff81469272>] system_call_fastpath+0x16/0x1b +[347315.064957] [<00007fee51969ce7>] 0x7fee51969ce6 +[347315.064959] vmwrite error: reg 6c10 value 0 (err 0) + +4) The isssue can't be reporduced. I search the Intel VMX sepc about reaseons of vmptrld failure: +The instruction fails if its operand is not properly aligned, sets unsupported physical-address bits, or is equal to the VMXON +pointer. In addition, the instruction fails if the 32 bits in memory referenced by the operand do not match the VMCS +revision identifier supported by this processor. + +But I can't find any cues from the KVM source code. It seems each error condition is impossible. :( + +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 all 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". Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1642421 b/results/classifier/zero-shot/108/all/1642421 new file mode 100644 index 000000000..7b2df6a21 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1642421 @@ -0,0 +1,108 @@ +permissions: 0.982 +other: 0.979 +files: 0.974 +device: 0.969 +debug: 0.969 +performance: 0.967 +semantic: 0.966 +graphic: 0.964 +socket: 0.953 +boot: 0.951 +PID: 0.951 +network: 0.951 +vnc: 0.935 +KVM: 0.922 + +qemu-system-x86_64: ipv6 and dns is broken with netdev user + +Hi, + +dhcp inside qemu returns an ipv6 address as dns-server. However this is not +working. If i replace it with the ipv4 address '10.0.0.2' dns is working +again. I would expect that the qemu emulated dhcp server responds either an +ipv4 configuration that is working or its dns server/forwarder listens on the +ipv6 address returned by the emulated dhcp server. + +I used latest qemu from git ( b0bcc86d2a87456f5a276f941dc775b265b309cf) and used the following commands: + +$ ./qemu-system-x86_64 -enable-kvm -M pc -device virtio-rng-pci -device +virtio-net-pci,netdev=user.0 -drive file=buildenv.img,if=virtio,bus=1,unit=0 +-no-reboot -netdev user,id=user.0,hostfwd=tcp::5022-:22,hostfwd=tcp::7587-:7588 +-m 1024 -usb -nographic -smp 4 + +buildenv.img is a debian jessie amd64 installation. + +Inside qemu the network is configured to use dhcp: + +$ cat /etc/network/interfaces +allow-hotplug eth0 +iface eth0 inet dhcp + +$ ifconfig eth0 +eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 + inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 + inet6 addr: fe80::5054:ff:fe12:3456/64 Scope:Link + inet6 addr: fec0::5054:ff:fe12:3456/64 Scope:Site + UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 + RX packets:10 errors:0 dropped:0 overruns:0 frame:0 + TX packets:28 errors:0 dropped:0 overruns:0 carrier:0 + collisions:0 txqueuelen:1000 + RX bytes:3215 (3.1 KiB) TX bytes:3638 (3.5 KiB) + +$ cat /etc/resolv.conf +nameserver fec0::3 + +$ arp google.de +google.de: Host name lookup failure + +$ strace -f arp google.de +... +socket(PF_INET6, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4 +connect(4, {sa_family=AF_INET6, sin6_port=htons(53), inet_pton(AF_INET6, "fec0::3", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 +poll([{fd=4, events=POLLOUT}], 1, 0) = 1 ([{fd=4, revents=POLLOUT}]) +sendto(4, "\17\320\1\0\0\1\0\0\0\0\0\0\6google\2de\0\0\1\0\1", 27, MSG_NOSIGNAL, NULL, 0) = 27 +poll([{fd=4, events=POLLIN}], 1, 5000) = 0 (Timeout) +poll([{fd=4, events=POLLOUT}], 1, 0) = 1 ([{fd=4, revents=POLLOUT}]) +sendto(4, "\17\320\1\0\0\1\0\0\0\0\0\0\6google\2de\0\0\1\0\1", 27, MSG_NOSIGNAL, NULL, 0) = 27 +poll([{fd=4, events=POLLIN}], 1, 5000) = 0 (Timeout) +close(4) = 0 +... + +$ echo nameserver 10.0.0.2 > /etc/resolv.conf + +$ arp google.de +google.de (216.58.208.35) -- no entry + +Note: I reported this bug also to debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844566 + +Regards, + + Manuel + +I have a similar issue with qemu 2.7 from current Debian amd64 unstable/sid. Starting qemu with: + +kvm -m 640 -hda debian-8-amd64.qcow2 -net nic,model=rtl8139 -net user,hostfwd=tcp:127.0.0.1:5005-:22 + +I tested DNS resolution in the host and in the guest. + +The conclusions are: + +When the host's /etc/resolv.conf has, as the only line, a ipv6 nameserver like fd2d:[...]::1 or a ipv6 link-local address with a scope like fe80::[...]%wlan0 then: + + In the host, DNS resolution works ok in Debian sid. In Debian 8 'host' and 'dig' fail in the case of link-local address and work otherwise, and 'ping' works anyway. + In the guest, DNS resolution does not work at all (but access to IPv4 addresses directly works). + +In this case there is not global ipv6 connectivity, but some combinations of routers and network managers in the host lead to /etc/resolv.conf with only nameserver line a ipv6 or ipv6 link-local with scope address. This breaks DNS resolution in the guests. In this same configuration VirtualBox works ok. + +An old (2007) patch from glibc for the ipv6 link-local with scope case is at: + +https://sourceware.org/bugzilla/show_bug.cgi?id=5475 + + +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 all 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". Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1649040 b/results/classifier/zero-shot/108/all/1649040 new file mode 100644 index 000000000..4fb0256bd --- /dev/null +++ b/results/classifier/zero-shot/108/all/1649040 @@ -0,0 +1,144 @@ +permissions: 0.968 +device: 0.961 +files: 0.958 +other: 0.958 +performance: 0.958 +graphic: 0.955 +semantic: 0.953 +debug: 0.953 +boot: 0.949 +vnc: 0.949 +PID: 0.946 +socket: 0.942 +KVM: 0.941 +network: 0.921 + +Ubuntu 16.04.1 Grub Splash Doesn't Appear + +My Specs: + +Slackware 14.2 x86_64 > Host +QEMU 2.7.0 + +Ubuntu 16.04.1 > Guest + +Start options for Ubuntu: + +qemu-system-x86_64 -drive format=raw,file=ubuntu.img \ +-cpu host \ +--enable-kvm \ +-smp 2 \ +-m 4096 \ +-vga vmware \ +-soundhw ac97 \ +-usbdevice tablet \ +-rtc base=localtime \ +-usbdevice host:0781:5575 + + + +I've started Ubuntu around 6-8 times, and I have only see the Grub Boot Splash appear twice, so pretty much without fail it typically boots past the grub splash and automatically boots... + + +These are the /etc/default/grub settings; (I only changed these options GRUB_TIMEOUT=15 and GRUB_GFXMODE=1440x900) + + +# If you change this file, run 'update-grub' afterwards to update +# /boot/grub/grub.cfg. +# For full documentation of the options in this file, see: +# info -f grub -n 'Simple configuration' + +GRUB_DEFAULT=0 +GRUB_HIDDEN_TIMEOUT=0 +GRUB_HIDDEN_TIMEOUT_QUIET=true +GRUB_TIMEOUT=15 +GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` +GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" +GRUB_CMDLINE_LINUX="" + +# Uncomment to enable BadRAM filtering, modify to suit your needs +# This works with Linux (no patch required) and with any kernel that obtains +# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...) +#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef" + +# Uncomment to disable graphical terminal (grub-pc only) +#GRUB_TERMINAL=console + +# The resolution used on graphical terminal +# note that you can use only modes which your graphic card supports via VBE +# you can see them in real GRUB with the command `vbeinfo' +GRUB_GFXMODE=1440x900 + +# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux +#GRUB_DISABLE_LINUX_UUID=true + +# Uncomment to disable generation of recovery mode menu entries +#GRUB_DISABLE_RECOVERY="true" + +# Uncomment to get a beep at grub start +#GRUB_INIT_TUNE="480 440 1" + +Why are you using "-vga vmware" ? Can't you use "-vga std" instead? Also, now that QEMU 2.8 has been released, could you please test again with this latest version? Thanks! + +It's the same in 2.8.0 but I will test it again when I get some time for vmware. + +I used vmware because it offers better resolution. + +After posting this issue I have learned a little about virtio and for a few times I was able to boot it with -vag virtio and this was really nice. I was able to resize and qemu will fill the screen to fit. + +But now when I boot with -vga virtio it just sits there and won't start Ubuntu. + +These are the options I'm using; + +qemu-system-x86_64 -drive if=none,id=drive0,cache=none,aio=threads,format=raw,file=ubuntu.img,index=0 \ +-object iothread,id=iothread0 \ +-machine type=q35,accel=kvm,kernel_irqchip=on \ +-device virtio-blk-pci,drive=drive0,scsi=off,config-wce=off,iothread=iothread0 \ +-cpu host \ +--enable-kvm \ +-smp 2 \ +-m 4096 \ +-vga virtio \ +-soundhw ac97 \ +-usbdevice tablet \ +-rtc base=localtime + +I do not understand how QEMU boots options just fine for a few times, then another time you go back and try and nothing works... + +I switched to boot scsi and when I start it, the screen is just blank... + + + +qemu-system-x86_64 -drive if=none,id=hd,cache=none,aio=threads,format=raw,file=ubuntu.img,index=0 \ +-object iothread,id=iothread0 \ +-machine type=q35,accel=kvm,kernel_irqchip=on \ +-device virtio-scsi-pci,iothread=iothread0,id=scsi -device scsi-hd,drive=hd \ +-cpu host \ +--enable-kvm \ +-smp 2 \ +-m 4096 \ +-vga virtio \ +-soundhw hda \ +-usbdevice tablet \ +-rtc base=localtime + +Sometimes when I restart it, I'll get the grub menu and I boot it, then it just sits at the console login, for me to log in with a username and pass, it doesn't go to the DM. + +I get this message, not sure if it's related; + +intel_rapl no valid rapl domains found in package 0 + +-vga virtio is working, I finally figured out my image was corrupted, I realized you have to be careful shutting the guest down correctly, or you could corrupt the image/system... + +So now, back to the same issue, even using 2.8.0 and virtio the grub splash doesn't always appears. + +So this is random, one time I start the Guest, the boot splash appears, the next time I start the guest it doesn't... + +Grub boot splash doesn't appear consistent... + +It's the same with std too... + +Does this still happen with a newer version of Ubuntu and the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1652 b/results/classifier/zero-shot/108/all/1652 new file mode 100644 index 000000000..07bdb6830 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1652 @@ -0,0 +1,47 @@ +KVM: 0.981 +vnc: 0.981 +performance: 0.978 +permissions: 0.976 +debug: 0.976 +files: 0.976 +semantic: 0.976 +network: 0.975 +device: 0.975 +other: 0.975 +socket: 0.974 +graphic: 0.974 +PID: 0.973 +boot: 0.972 + +make check failed about qemu@master on debian10_aarch64 +Description of problem: +make check failed about qemu@master on debian10_aarch64 +Steps to reproduce: +1../configure +2.make -j16 +3.make -j16 check +Additional information: +error: +>>> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_IMG=./qemu-img G_TEST_DBUS_DAEMON=/home/stage/root/spack-stage-qemu-master-d6wsqaf6ydt7c6frhxqd3nyqhh72vz7v/spack-src/tests/dbus-vmstate-daemon.sh MALLOC_PERTURB_=105 QTEST_QEMU_BINARY=./qemu-system-aarch64 /home/stage/root/spack-stage-qemu-master-d6wsqaf6ydt7c6frhxqd3nyqhh72vz7v/spack-src/build/tests/qtest/migration-test --tap -k +――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +stderr: +Broken pipe +../tests/qtest/libqtest.c:184: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0) + + +TAP parsing error: Too few tests run (expected 18, got 0) +(test program exited with status code -6) +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― + +190/627 qemu:qtest+qtest-aarch64 / qtest-aarch64/arm-cpu-features ERROR 0.34s killed by signal 6 SIGABRT +>>> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_IMG=./qemu-img G_TEST_DBUS_DAEMON=/home/stage/root/spack-stage-qemu-master-d6wsqaf6ydt7c6frhxqd3nyqhh72vz7v/spack-src/tests/dbus-vmstate-daemon.sh MALLOC_PERTURB_=115 QTEST_QEMU_BINARY=./qemu-system-aarch64 /home/stage/root/spack-stage-qemu-master-d6wsqaf6ydt7c6frhxqd3nyqhh72vz7v/spack-src/build/tests/qtest/arm-cpu-features --tap -k +――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +stderr: +qemu-system-aarch64: Failed to retrieve host CPU features +Broken pipe +../tests/qtest/libqtest.c:184: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0) + + +TAP parsing error: Too few tests run (expected 5, got 1) +(test program exited with status code -6) +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― diff --git a/results/classifier/zero-shot/108/all/1654137 b/results/classifier/zero-shot/108/all/1654137 new file mode 100644 index 000000000..367029e98 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1654137 @@ -0,0 +1,228 @@ +permissions: 0.988 +debug: 0.979 +PID: 0.972 +device: 0.970 +semantic: 0.967 +other: 0.967 +network: 0.967 +graphic: 0.965 +files: 0.960 +socket: 0.960 +performance: 0.955 +KVM: 0.941 +vnc: 0.935 +boot: 0.906 + +Ctrl-A b not working in 2.8.0 + +With a recent update from 2.7.0 to 2.8.0 I have discovered that I can no longer send a "break" to the VM. Ctrl-A b is simply ignored. Other Ctrl-A sequences seem to work correctly. + +This is on a NetBSD amd64 system, version 7.99.53, and qemu was installed on this system from source. + +Reverting to the previous install restores "break" capability. + +I am also seeing this problem. In case it was not clear from Paul's original report, it affects guests using a serial console. + +Also, it is not specific to NetBSD. I can reproduce it using a Linux guest on a Linux host, by running the following on a Debian 8 system: + + wget http://landley.net/aboriginal/downloads/old/binaries/1.4.5/system-image-i686.tar.gz + tar xfz system-image-i686.tar.gz + cd system-image-i686 + sh run-emulator.sh + +and typing Control-A b m once the guest has started. + +Using qemu 2.1.2, this successfully causes the guest to print a memory usage summary. Using current qemu sources from git (dbe2b65566e76d3c3a0c3358285c0336ac61e757), nothing happens. + + +Hi + +On Fri, Jan 6, 2017 at 2:46 PM Andreas Gustafsson <email address hidden> wrote: + +> I am also seeing this problem. In case it was not clear from Paul's +> original report, it affects guests using a serial console. +> +> Also, it is not specific to NetBSD. I can reproduce it using a Linux +> guest on a Linux host, by running the following on a Debian 8 system: +> +> wget +> http://landley.net/aboriginal/downloads/old/binaries/1.4.5/system-image-i686.tar.gz +> tar xfz system-image-i686.tar.gz +> cd system-image-i686 +> sh run-emulator.sh +> +> and typing Control-A b m once the guest has started. +> +> Using qemu 2.1.2, this successfully causes the guest to print a memory +> usage summary. Using current qemu sources from git +> (dbe2b65566e76d3c3a0c3358285c0336ac61e757), nothing happens. +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1654137 +> +> Title: +> Ctrl-A b not working in 2.8.0 +> +> Status in QEMU: +> New +> +> Bug description: +> With a recent update from 2.7.0 to 2.8.0 I have discovered that I can +> no longer send a "break" to the VM. Ctrl-A b is simply ignored. +> Other Ctrl-A sequences seem to work correctly. +> + +It could be related to the chardev changes in 2.8, I am bisecting and +looking at it. + +thanks + + +> This is on a NetBSD amd64 system, version 7.99.53, and qemu was +> installed on this system from source. +> +> Reverting to the previous install restores "break" capability. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1654137/+subscriptions +> +> -- +Marc-André Lureau + + +Hi + +On Mon, Jan 9, 2017 at 4:39 PM Marc-André Lureau <email address hidden> +wrote: + +> Hi +> +> On Fri, Jan 6, 2017 at 2:46 PM Andreas Gustafsson <email address hidden> wrote: +> +> I am also seeing this problem. In case it was not clear from Paul's +> original report, it affects guests using a serial console. +> +> Also, it is not specific to NetBSD. I can reproduce it using a Linux +> guest on a Linux host, by running the following on a Debian 8 system: +> +> wget +> http://landley.net/aboriginal/downloads/old/binaries/1.4.5/system-image-i686.tar.gz +> tar xfz system-image-i686.tar.gz +> cd system-image-i686 +> sh run-emulator.sh +> +> and typing Control-A b m once the guest has started. +> +> Using qemu 2.1.2, this successfully causes the guest to print a memory +> usage summary. Using current qemu sources from git +> (dbe2b65566e76d3c3a0c3358285c0336ac61e757), nothing happens. +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1654137 +> +> Title: +> Ctrl-A b not working in 2.8.0 +> +> Status in QEMU: +> New +> +> Bug description: +> With a recent update from 2.7.0 to 2.8.0 I have discovered that I can +> no longer send a "break" to the VM. Ctrl-A b is simply ignored. +> Other Ctrl-A sequences seem to work correctly. +> +> +> It could be related to the chardev changes in 2.8, I am bisecting and +> looking at it. +> +> +it's a regression from commit a4afa548fc6dd9842ed866, I will send a fix +asap. + + +> thanks +> +> +> This is on a NetBSD amd64 system, version 7.99.53, and qemu was +> installed on this system from source. +> +> Reverting to the previous install restores "break" capability. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1654137/+subscriptions +> +> -- +> Marc-André Lureau +> +-- +Marc-André Lureau + + +On Tue, Jan 10, 2017 at 12:23 PM Paolo Bonzini <email address hidden> wrote: + + + +On 10/01/2017 12:06, Marc-André Lureau wrote: +> CharDriverState.be should be updated to point to the current +> associated backend. +> +> Fix the regression introduced in the "mux" chardev from commit +> a4afa548fc6dd9842ed86639b4d37d4d1c4ad480. +> +> https://bugs.launchpad.net/bugs/1654137 + +Queued. + +However, can you also simplify mux_chr_accept_input, mux_chr_can_read +and mux_chr_read to use d->be directly, with this change? + + +Yes, not a big improvement though. I'll consider it in the reactoring +series (https://github.com/elmarco/qemu/commits/chrfe) +-- +Marc-André Lureau + + +I can confirm that this bug is fixed in qemu 2.8.1 + +Thanks! + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=fb5e19d2e1472e96d + +This is broken again as of revision 7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac. + +Bisection shows it was broken by commit df85a78bf83d85627de27f492e78e73bbbd3df4a, +"char: move mux to its own file". Somewhat confusingly, this commit predates the fix +(fb5e19d2e1472e96d72d5e4d89c20033f8ab345c), but it is part of a branch that was merged +after the fix, in merge commit 2d6752d38d8acda6aae674a72b72be05482a58eb. Apparently +this caused a reversion to an old version of the mux code that still has the bug. + +Credit for discovering the regression goes to Paul Goyette. + + +This bug is no longer fixed. See also bug #1743191 + +This regression is still unfixed three months after being reported, and it's rendering qemu 2.11.1 unusable for my present use case, so I just reverted my system to the ever reliable qemu 0.15.1. + + + +@elmarco could you take a look at this possible regression since bisect claims it was due to the mux refactor + +Fixed on qemu mainline in 1b2503fcf7b5932c5a3779ca2ceb92bd403c4ee7 - thanks. I have backported the fix to pkgsrc as qemu-2.11.1nb3. + + +Hi Andreas, beware... while 1b2503fcf7b5 fixes this bug, it introduces another regression. +I suggest waiting for the release tag before cherry-picking it. + +Commit 1b2503fcf7b5932c reverted by commit 6f660996f1623034. We'll release 2.12 without a fix for this bug, and look at it for 2.13 and 2.12.1. + +https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg02505.html and followups describe the regression that 1b2503fcf7b5932c caused. + + +... and it has been fixed again for 3.0: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=eeaa6715050ed3f9cbedd32 + diff --git a/results/classifier/zero-shot/108/all/1656234 b/results/classifier/zero-shot/108/all/1656234 new file mode 100644 index 000000000..90eb8fb5f --- /dev/null +++ b/results/classifier/zero-shot/108/all/1656234 @@ -0,0 +1,90 @@ +permissions: 0.993 +other: 0.992 +graphic: 0.991 +debug: 0.991 +semantic: 0.990 +PID: 0.988 +files: 0.987 +performance: 0.985 +socket: 0.984 +network: 0.974 +vnc: 0.973 +boot: 0.973 +device: 0.972 +KVM: 0.969 + +Qemu core dumped if using virtio-net + +System Environment +======= +Qemu commit/branch: e92fbc75 +Host OS: RHEL7.2 ia32e +Host Kernel: 4.9.0 +Guest OS: RHEL7.2 ia32e +Guest Kernel: 4.9.0 + +Bug detailed description +======= +While create a kvm guest using virtio-net, the qemu will core dump with showing "Aborted (core dumped)". +Reproduce Steps +============== +create a guest: +qemu-system-x86_64 -enable-kvm -m 4096 -smp 4 -device virtio-net-pci,netdev=nic0,mac=00:16:3e:49:be:24 -netdev tap,id=nic0,script=/etc/kvm/qemu-ifup -drive file=/ia32e_rhel7u2_kvm.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 -serial file:serial.log + +Current Result: +============== + +qemu-system-x86_64: /workspace/ia32e/nightly/kvm-next-20170105-ef85b6-e92fbc/kvm/qemu/hw/virtio/virtio.c:214: virtio_queue_set_notification: Assertion `vq->notification_disabled > 0' failed. +Aborted (core dumped) + +add info +======== +[root@hsw-ep2 Desktop]# dmesg |grep -v virbr0 |tail -n 10 +[ 1760.265000] device tap0 left promiscuous mode +[ 1879.148642] device tap0 entered promiscuous mode +[ 1885.213702] kvm [14186]: vcpu0, guest rIP: 0xffffffff81066784 disabled perfctr wrmsr: 0xc2 data 0xffff +[ 1912.258783] device tap0 left promiscuous mode +[ 1995.972267] device tap0 entered promiscuous mode +[ 2001.990207] kvm [14335]: vcpu0, guest rIP: 0xffffffff81066784 disabled perfctr wrmsr: 0xc2 data 0xffff +[ 2024.703072] device tap0 left promiscuous mode +[ 2145.374239] device tap0 entered promiscuous mode +[ 2151.409948] kvm [14541]: vcpu0, guest rIP: 0xffffffff81066784 disabled perfctr wrmsr: 0xc2 data 0xffff +[ 2178.281446] device tap0 left promiscuous mode + + + +On Fri, Jan 13, 2017 at 08:40:22AM -0000, Robert Hu wrote: +> Public bug reported: +> +> System Environment +> ======= +> Qemu commit/branch: e92fbc75 +> Host OS: RHEL7.2 ia32e +> Host Kernel: 4.9.0 +> Guest OS: RHEL7.2 ia32e +> Guest Kernel: 4.9.0 +> +> Bug detailed description +> ======= +> While create a kvm guest using virtio-net, the qemu will core dump with showing "Aborted (core dumped)". +> Reproduce Steps +> ============== +> create a guest: +> qemu-system-x86_64 -enable-kvm -m 4096 -smp 4 -device virtio-net-pci,netdev=nic0,mac=00:16:3e:49:be:24 -netdev tap,id=nic0,script=/etc/kvm/qemu-ifup -drive file=/ia32e_rhel7u2_kvm.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 -serial file:serial.log +> +> Current Result: +> ============== +> +> qemu-system-x86_64: /workspace/ia32e/nightly/kvm-next-20170105-ef85b6-e92fbc/kvm/qemu/hw/virtio/virtio.c:214: virtio_queue_set_notification: Assertion `vq->notification_disabled > 0' failed. +> Aborted (core dumped) + +Thanks for reporting this assertion failure. A patch is queued and will +be merged soon: +https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg02277.html + +Stefan + + +Fix had been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=332fa82d0963409 + diff --git a/results/classifier/zero-shot/108/all/1670170 b/results/classifier/zero-shot/108/all/1670170 new file mode 100644 index 000000000..e040dde0c --- /dev/null +++ b/results/classifier/zero-shot/108/all/1670170 @@ -0,0 +1,293 @@ +permissions: 0.993 +debug: 0.993 +other: 0.992 +graphic: 0.990 +performance: 0.990 +semantic: 0.990 +device: 0.987 +PID: 0.986 +files: 0.985 +boot: 0.985 +network: 0.985 +socket: 0.982 +vnc: 0.968 +KVM: 0.958 + +`qemu-system-sparc64 -M Niagara` Aborted (core dumped) + +> qemu-system-sparc64 -M Niagara +qemu: fatal: Trap 0x0064 while trap level (6) >= MAXTL (6), Error state +pc: 0000000000004c80 npc: 0000000000004c84 +%g0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%o0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%o4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%l0-3: 0000000007f00000 000001ff00000000 000001fff0080000 0000000000000000 +%l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%i0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +pstate: 00000414 ccr: 44 (icc: -Z-- xcc: -Z--) asi: 00 tl: 6 pil: 0 +cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 7 +fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 + +Aborted (core dumped) + +> qemu-system-sparc64 -M help +Supported machines are: +Niagara Sun4v platform, Niagara +none empty machine +sun4u Sun4u platform (default) +sun4v Sun4v platform + +> qemu-system-sparc64 -version +QEMU emulator version 2.8.0(Virtualization:Staging / SLE_12_SP2) + +from https://build.opensuse.org/package/show/Virtualization:Staging/qemu on openSUSE Leap 42.2. + + + +There was a major rework of the Niagara platform in the upcoming 2.9 release. +Please use the new version. + +On Sun, Mar 5, 2017 at 7:18 PM, Michal Nowak <email address hidden> wrote: +> Public bug reported: +> +>> qemu-system-sparc64 -M Niagara +> qemu: fatal: Trap 0x0064 while trap level (6) >= MAXTL (6), Error state +> pc: 0000000000004c80 npc: 0000000000004c84 +> %g0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %o0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %o4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %l0-3: 0000000007f00000 000001ff00000000 000001fff0080000 0000000000000000 +> %l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %i0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> pstate: 00000414 ccr: 44 (icc: -Z-- xcc: -Z--) asi: 00 tl: 6 pil: 0 +> cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 7 +> fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 +> +> Aborted (core dumped) +> +>> qemu-system-sparc64 -M help +> Supported machines are: +> Niagara Sun4v platform, Niagara +> none empty machine +> sun4u Sun4u platform (default) +> sun4v Sun4v platform +> +>> qemu-system-sparc64 -version +> QEMU emulator version 2.8.0(Virtualization:Staging / SLE_12_SP2) +> +> from https://build.opensuse.org/package/show/Virtualization:Staging/qemu +> on openSUSE Leap 42.2. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> +> ** Tags: sparc +> +> ** Attachment added: "coredumpctl core dump" +> https://bugs.launchpad.net/bugs/1670170/+attachment/4831907/+files/core.qemu-system-spa.1000.79fef1d6233b4b989c19ea5c5c809627.451.1488737426000000.xz +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1670170 +> +> Title: +> `qemu-system-sparc64 -M Niagara` Aborted (core dumped) +> +> Status in QEMU: +> New +> +> Bug description: +> > qemu-system-sparc64 -M Niagara +> qemu: fatal: Trap 0x0064 while trap level (6) >= MAXTL (6), Error state +> pc: 0000000000004c80 npc: 0000000000004c84 +> %g0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %o0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %o4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %l0-3: 0000000007f00000 000001ff00000000 000001fff0080000 0000000000000000 +> %l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %i0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> pstate: 00000414 ccr: 44 (icc: -Z-- xcc: -Z--) asi: 00 tl: 6 pil: 0 +> cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 7 +> fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 +> +> Aborted (core dumped) +> +> > qemu-system-sparc64 -M help +> Supported machines are: +> Niagara Sun4v platform, Niagara +> none empty machine +> sun4u Sun4u platform (default) +> sun4v Sun4v platform +> +> > qemu-system-sparc64 -version +> QEMU emulator version 2.8.0(Virtualization:Staging / SLE_12_SP2) +> +> from +> https://build.opensuse.org/package/show/Virtualization:Staging/qemu on +> openSUSE Leap 42.2. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1670170/+subscriptions +> + + + +-- +Regards, +Artyom Tarasenko + +SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu + + +Retested with QEMU 2.8.90: + +15:03 $ qemu-system-sparc64 -M Niagara +qemu-system-sparc64: -M Niagara: unsupported machine type +Use -machine help to list supported machines + +15:03 $ qemu-system-sparc64 -M help +Supported machines are: +niagara Sun4v platform, Niagara +none empty machine +sun4u Sun4u platform (default) +sun4v Sun4v platform + +15:03 $ qemu-system-sparc64 -M niagara +Could not open option rom 'nvram1': No such file or directory +qemu-system-sparc64: Unable to load a firmware for -M niagara + +Fixed in version 2.8.90. + +not to pester anyone but it's back. + + +moo-PowerEdge-R710 Downloads # qemu-system-sparc64 -version +QEMU emulator version 4.0.91 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +moo-PowerEdge-R710 Downloads # qemu-system-sparc64 -machine niagara +Could not open option rom 'nvram1': No such file or directory +qemu-system-sparc64: Unable to load a firmware for -M niagara + +moo-PowerEdge-R710 Downloads # strace qemu-system-sparc64 -machine niagara +... ... ... +access("nvram1", R_OK) = -1 ENOENT (No such file or directory) +access("/usr/local/share/qemu-firmware/nvram1", R_OK) = -1 ENOENT (No such file or directory) +access("/usr/local/share/qemu/nvram1", R_OK) = -1 ENOENT (No such file or directory) +open("nvram1", O_RDONLY) = -1 ENOENT (No such file or directory) +fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 +write(2, "Could not open option rom 'nvram"..., 62Could not open option rom 'nvram1': No such file or directory +) = 62 +write(2, "qemu-system-sparc64: Unable to l"..., 62qemu-system-sparc64: Unable to load a firmware for -M niagara +) = 62 +exit_group(1) = ? ++++ exited with 1 +++ + + +nvram1 isnt on my system, but i can do this to see what else isnt there: + +moo-PowerEdge-R710 Downloads # touch /usr/local/share/qemu/nvram1 +moo-PowerEdge-R710 Downloads # qemu-system-sparc64 -machine niagara +Could not open option rom '1up-md.bin': No such file or directory +qemu-system-sparc64: Unable to load a firmware for -M niagara +moo-PowerEdge-R710 Downloads # touch /usr/local/share/qemu/1up-md.bin +moo-PowerEdge-R710 Downloads # qemu-system-sparc64 -machine niagara +Could not open option rom '1up-hv.bin': No such file or directory +qemu-system-sparc64: Unable to load a firmware for -M niagara +moo-PowerEdge-R710 Downloads # touch /usr/local/share/qemu/1up-hv.bin +moo-PowerEdge-R710 Downloads # qemu-system-sparc64 -machine niagara +Could not open option rom 'reset.bin': No such file or directory +qemu-system-sparc64: Unable to load a firmware for -M niagara +moo-PowerEdge-R710 Downloads # touch /usr/local/share/qemu/reset.bin +moo-PowerEdge-R710 Downloads # qemu-system-sparc64 -machine niagara +Could not open option rom 'q.bin': No such file or directory +qemu-system-sparc64: Unable to load a firmware for -M niagara +moo-PowerEdge-R710 Downloads # touch /usr/local/share/qemu/q.bin +moo-PowerEdge-R710 Downloads # qemu-system-sparc64 -machine niagara +Could not open option rom 'openboot.bin': No such file or directory +qemu-system-sparc64: Unable to load a firmware for -M niagara +moo-PowerEdge-R710 Downloads # touch /usr/local/share/qemu/openboot.bin +moo-PowerEdge-R710 Downloads # qemu-system-sparc64 -machine niagara +qemu: fatal: Trap 0x0010 while trap level (6) >= MAXTL (6), Error state +pc: 000000fff0000020 npc: 000000fff0000024 +%g0-3: 0000000000000000 0000000000000000 0000000008000000 0000000000000000 +%g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%o0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%o4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%l0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%i0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +pstate: 00000034 ccr: 00 (icc: ---- xcc: ----) asi: 00 tl: 6 pil: 0 gl: 2 +tbr: 0000000000000000 hpstate: 0000000000000004 htba: 0000000000000000 +cansave: 0 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 0 cwp: 7 +fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 + +Aborted +moo-PowerEdge-R710 Downloads # + + +S10image directory in this archive holds the rom images in case anyone is looking.... + +http://download.oracle.com/technetwork/systems/opensparc/OpenSPARCT1_Arch.1.5.tar.bz2 + +not that it really helps for qemu-4.1.0-rc1 + +moo-PowerEdge-R710 qemu-4.1.0-rc1 # qemu-system-sparc64 -machine niagara +qemu: fatal: Trap 0x0032 while trap level (6) >= MAXTL (6), Error state + + + + +It's difficult to tell as you haven't posted your complete command line, however it looks as if you're missing the path to the rom images: + +https://qemu.weilnetz.de/doc/qemu-doc.html#Sparc64-System-emulator +https://wiki.qemu.org/Documentation/Platforms/SPARC#Compatibility + + +ATB, + +Mark. + + diff --git a/results/classifier/zero-shot/108/all/1670175 b/results/classifier/zero-shot/108/all/1670175 new file mode 100644 index 000000000..b0e206ea0 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1670175 @@ -0,0 +1,306 @@ +permissions: 0.985 +other: 0.976 +debug: 0.968 +device: 0.963 +boot: 0.958 +socket: 0.955 +semantic: 0.955 +performance: 0.954 +files: 0.950 +PID: 0.949 +graphic: 0.946 +network: 0.945 +vnc: 0.944 +KVM: 0.901 + +qemu-system-sparc64 with tribblix-sparc-0m16.iso ends with "panic - kernel: no nucleus hblk8 to allocate" + +> qemu-system-sparc64 -m 1024 -cdrom Downloads/tribblix-sparc-0m16.iso -boot d -nographic +OpenBIOS for Sparc64 +Configuration device id QEMU version 1 machine id 0 +kernel cmdline +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Nov 24 2016 21:23 + Type 'help' for detailed information +Trying cdrom:f... +Not a bootable ELF image +Not a bootable a.out image + +Loading FCode image... +Loaded 7120 bytes +entry point is 0x4000 +Evaluating FCode... +Evaluating FCode... +Ignoring failed claim for va 10a96a0 memsz 19! +Ignoring failed claim for va 1000000 memsz d1fb6! +Ignoring failed claim for va 1402000 memsz 32518! +Ignoring failed claim for va 1800000 memsz 52ac8! +SunOS Release 5.11 Version tribblix-m16 64-bit +Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved. +could not find debugger-vocabulary-hook>threads:interpret: exception -13 caught +interpret \ ident "%Z%%M% %I% %E% SMI" +\ Copyright 2005 Sun Microsystems, Inc. All rights reserved. +\ Use is subject to license terms. +\ +\ CDDL HEADER START +\ +\ The contents of this file are subject to the terms of the +\ Common Development and Distribution License, Version 1.0 only +\ (the "License"). You may not use this file except in compliance +\ with the License. +\ +\ You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE +\ or http://www.opensolaris.org/os/licensing. +\ See the License for +WARNING: add_spec: No major number for sf +panic - kernel: no nucleus hblk8 to allocate +EXIT + +QEMU keeps running (CPU is on 100 % all the time), I can interact with the prompt: + +0 > boot +Not a Linux kernel image +Not a bootable ELF image +Not a bootable a.out image + +Loading FCode image... +Unhandled Exception 0x0000000000000018 +PC = 0x00000000ffd25310 NPC = 0x00000000ffd25314 +Stopping execution + +> qemu-system-sparc64 -version +QEMU emulator version 2.8.0(Virtualization:Staging / SLE_12_SP2) + +from https://build.opensuse.org/package/show/Virtualization:Staging/qemu on openSUSE Leap 42.2. + +ISO: http://pkgs.tribblix.org/iso/tribblix-sparc-0m16.iso. + +This is how it ends with 2048 MB of memory instead of 1024: + +> qemu-system-sparc64 -m 2048 -cdrom Downloads/tmp/tribblix-sparc-0m16.iso -boot d -nographic +OpenBIOS for Sparc64 +Configuration device id QEMU version 1 machine id 0 +kernel cmdline +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Nov 24 2016 21:23 + Type 'help' for detailed information +Trying cdrom:f... +Not a bootable ELF image +Not a bootable a.out image + +Loading FCode image... +Loaded 7120 bytes +entry point is 0x4000 +Evaluating FCode... +Evaluating FCode... +Ignoring failed claim for va 10a96a0 memsz 19! +Ignoring failed claim for va 1000000 memsz d1fb6! +Ignoring failed claim for va 1402000 memsz 32518! +Ignoring failed claim for va 1800000 memsz 52ac8! +SunOS Release 5.11 Version tribblix-m16 64-bit +Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved. +could not find debugger-vocabulary-hook>threads:interpret: exception -13 caught +interpret \ ident "%Z%%M% %I% %E% SMI" +\ Copyright 2005 Sun Microsystems, Inc. All rights reserved. +\ Use is subject to license terms. +\ +\ CDDL HEADER START +\ +\ The contents of this file are subject to the terms of the +\ Common Development and Distribution License, Version 1.0 only +\ (the "License"). You may not use this file except in compliance +\ with the License. +\ +\ You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE +\ or http://www.opensolaris.org/os/licensing. +\ See the License for WARNING: add_spec: No major number for sf +unix-tte:interpret: exception -13 caught +interpret ' unix-tte is va>tte-data failed with error ffffffffffffffed +WARNING: consconfig: cannot find driver for screen device /pci@1fe,0/QEMU,VGA@2 +Hostname: tribblix +Remounting root read/write +Probing for device nodes ... +WARNING: pcipsy0: unable to map reg entry 1 + +Preparing image for use +Requesting System Maintenance Mode +(See /lib/svc/share/README for more information.) +Console login service(s) cannot run + + +QEMU 2.8.90 gets a bit further with Tribblix: + +$ qemu-system-sparc64 -m 2048 -cdrom ~/Downloads/tmp/tribblix-sparc-0m16.iso -boot d -M sun4u -nographic +OpenBIOS for Sparc64 +Configuration device id QEMU version 1 machine id 0 +kernel cmdline +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Feb 28 2017 21:38 + Type 'help' for detailed information +Trying cdrom:f... +Not a bootable ELF image +Not a bootable a.out image + +Loading FCode image... +Loaded 7120 bytes +entry point is 0x4000 +Evaluating FCode... +Evaluating FCode... +Ignoring failed claim for va 10a96a0 memsz 19! +Ignoring failed claim for va 1000000 memsz d1fb6! +Ignoring failed claim for va 1402000 memsz 32518! +Ignoring failed claim for va 1800000 memsz 52ac8! +SunOS Release 5.11 Version tribblix-m16 64-bit +Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved. +could not find debugger-vocabulary-hook>threads:interpret: exception -13 caught +interpret \ ident "%Z%%M% %I% %E% SMI" +\ Copyright 2005 Sun Microsystems, Inc. All rights reserved. +\ Use is subject to license terms. +\ +\ CDDL HEADER START +\ +\ The contents of this file are subject to the terms of the +\ Common Development and Distribution License, Version 1.0 only +\ (the "License"). You may not use this file except in compliance +\ with the License. +\ +\ You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE +\ or http://www.opensolaris.org/os/licensing. +\ See the License for WARNING: add_spec: No major number for sf +unix-tte:interpret: exception -13 caught +interpret ' unix-tte is va>tte-data failed with error ffffffffffffffed +WARNING: consconfig: cannot find driver for screen device /pci@1fe,0/QEMU,VGA@2 +Hostname: tribblix +Remounting root read/write +Probing for device nodes ... +WARNING: pcipsy0: unable to map reg entry 1 + +Preparing image for use +Requesting System Maintenance Mode +(See /lib/svc/share/README for more information.) +Console login service(s) cannot run + +Enter user name for system maintenance (control-d to bypass): + + +*** +Prompt is unusable, CPU at 100 %. + +Looks like tribblix is an OpenSolaris variant from the above output (I normally tend to test with Milax but it's good to have another reference around). + +I spent a lot of time during the 2.8 cycle fixing up the context switch code in OpenBIOS which gets OpenSolaris most of the way. AFAICT the 2 main missing items are: + + +1) Wiring up the ebus interrupts + +I have patches for this, but they cause Linux to panic on startup, presumably because of 2) below. + +2) Fix up the /pci nodes, adding 2 PCI bridges to the DT + +This will take some thought since OpenBIOS needs to be modified to handle multiple PCI buses and has know bugs with PCI bridges. + + +The CPU for sun4u machines will always be at 100% because the USIIi processor doesn't have a HLT or equivalent instruction that can be used by the guest to enable QEMU to pause the vCPU whilst idle. + +Note that I work on this as time allows, so progress isn't particularly rapid. Offers of sponsorship to enable me to spend more time on this would be gratefully received :) + +Hi Mark, thank you for your effort on SPARC64 emulation in QEMU! + +Thanks for the explanation on what might be wrong. Is there a way to workaround the PCI problems? + +Tribblix is indeed an illumos (a community fork of OpenSolaris) distribution. Contrary to Milax, which looks abandoned to me as OpenSolaris is, Tribblix and DilOS reflect recent illumos development and until OpenIndiana SPARC edition materialize, probably should be a reference solarish (sic) platforms. + +As I hope to use qemu-system-sparc64 for automated validation of illumos distributions, currently I am unable to provide anything but testing/QA :). + +Let me know should there be anything to test. + +With QEMU 2.11 there are two new warnings I haven't seen before (execution was still the same): + +... +unix-tte:interpret: exception -13 caught +interpret ' unix-tte is va>tte-data failed with error ffffffffffffffed +WARNING: consconfig: cannot find driver for screen device /pci@1fe,0/pci@1,1/QEMU,VGA@2 +Hostname: tribblix +Remounting root read/write +Probing for device nodes ... +WARNING: ata_controller[0] - Unsupported Controller + Vendor 0x9510, Device 0x4606, Revision 0x7 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +... + +Then it hangs the same way it did with older QEMUs. + +qemu sparc64 also failed to boot Oracle Linux + +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 all 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". Thank you and sorry for the inconvenience. + + +This is still valid, setting to Confirmed. With the latest qemu as of today, it fails in a slightly different way, but still does not accept any keyboard input: + +\ +\ You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE +\ or http://www.opensolaris.org/os/licensing. +\ See the License for WARNING: add_spec: No major number for sf +unix-tte:interpret: exception -13 caught +interpret ' unix-tte is va>tte-data failed with error ffffffffffffffed +WARNING: consconfig: cannot find driver for screen device /pci@1fe,0/pci@1,1/QEMU,VGA@2 +Hostname: tribblix +Remounting root read/write +Probing for device nodes ... +WARNING: Interrupt not seen after set_features +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +WARNING: ebus0 assigning default interrupt level 1 for device i80420 +Preparing image for use +Done mounting /usr filesystem +USB keyboard + 1. Albanian 25. Latin-American + 2. Arabic 26. Lithuanian + 3. Belarusian 27. Latvian + 4. Belgian 28. Macedonian + 5. Brazilian 29. Malta_UK + 6. Bulgarian 30. Malta_US + 7. Canadian-Bilingual 31. Norwegian + 8. Croatian 32. Polish + 9. Czech 33. Portuguese +10. Danish 34. Romanian +11. Dutch 35. Russian +12. Dvorak 36. Serbia-And-Montenegro +13. Estonian 37. Slovak +14. Finnish 38. Slovenian +15. French 39. Spanish +16. French-Canadian 40. Swedish +17. Hungarian 41. Swiss-French +18. German 42. Swiss-German +19. Greek 43. Traditional-Chinese +20. Icelandic 44. TurkishF +21. Italian 45. TurkishQ +22. Japanese-type6 46. UK-English +23. Japanese 47. US-English +24. Korean +To select the keyboard layout, enter a number [default 47]: + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/216 + + diff --git a/results/classifier/zero-shot/108/all/1687309 b/results/classifier/zero-shot/108/all/1687309 new file mode 100644 index 000000000..b0931a2ba --- /dev/null +++ b/results/classifier/zero-shot/108/all/1687309 @@ -0,0 +1,190 @@ +device: 0.968 +other: 0.955 +permissions: 0.954 +performance: 0.950 +graphic: 0.948 +debug: 0.943 +vnc: 0.941 +PID: 0.933 +socket: 0.932 +network: 0.932 +boot: 0.928 +semantic: 0.926 +files: 0.918 +KVM: 0.908 + +Assertion !usb_packet_is_inflight(p) fails in OHCI + +I'm trying to get a USB web camera working in Qemu & Raspbian. USB works and V4L shows device info correctly and capturing frames from the camera works sometimes, but mostly it crashes with error message: + +qemu-system-arm: hw/usb/core.c:558: usb_packet_setup: Assertion `!usb_packet_is_inflight(p)' failed. + +This looks similar to the previous bug which also caused a crash on the same kind of assertion but the culprit was XHCI: https://bugs.launchpad.net/qemu/+bug/1653384 + + +== Versions == + +QEMU emulator version 2.9.50 (v2.9.0-303-g81b2d5c-dirty), +configured with +./configure --target-list=arm-softmmu,arm-linux-user,armeb-linux-user --enable-libusb --enable-libssh2 --enable-debug + +libusb: 1.0.21 + +Guest: 2017-04-10-raspbian-jessie-lite.img with kernel 4.4.34 for Raspbian on Qemu + +Command: /usr/local/bin/qemu-system-arm -kernel qemu-rpi-kernel/kernel-qemu-4.4.34-v4lm-jessie -cpu arm1176 -m 256 -M versatilepb -no-reboot -append "root=/dev/sda2 panic=1" -drive format=raw,file=2017-04-10-raspbian-jessie-lite.img -usb -usbdevice host:046d:0928 -net nic,model=virtio -net user,hostfwd=tcp::2222-:22 + +Web camera is an old Logitech QuickCam Express Etch2 (046d:0928). It works otherwise without problems. + + +== GDB Backtrace == + +qemu-system-arm: hw/usb/core.c:558: usb_packet_setup: Assertion `!usb_packet_is_inflight(p)' failed. + +Thread 1 "qemu-system-arm" received signal SIGABRT, Aborted. +0x00007fffdea6f428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 +54 ../sysdeps/unix/sysv/linux/raise.c: Tiedostoa tai hakemistoa ei ole. +(gdb) bt full +#0 0x00007fffdea6f428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 + resultvar = 0 + pid = 16526 + selftid = 16526 +#1 0x00007fffdea7102a in __GI_abort () at abort.c:89 + save_stage = 2 + act = {__sigaction_handler = {sa_handler = 0x4, sa_sigaction = 0x4}, sa_mask = {__val = {140737488345776, + 140737488351076, 140737488345856, 48702688480, 140737352876032, 93825001457954, 558, 93825001458576, 0, 0, + 140736929192332, 140736930289240, 140736930302896, 260615966, 140736930289240, 93825001457954}}, + sa_flags = -135479296, sa_restorer = 0x555555e20922} + sigs = {__val = {32, 0 <repeats 15 times>}} +#2 0x00007fffdea67bd7 in __assert_fail_base (fmt=<optimized out>, + assertion=assertion@entry=0x555555e20922 "!usb_packet_is_inflight(p)", + file=file@entry=0x555555e20686 "hw/usb/core.c", line=line@entry=558, + function=function@entry=0x555555e20b90 <__PRETTY_FUNCTION__.27044> "usb_packet_setup") at assert.c:92 + str = 0x5555573e0800 "" + total = 4096 +#3 0x00007fffdea67c82 in __GI___assert_fail (assertion=0x555555e20922 "!usb_packet_is_inflight(p)", + file=0x555555e20686 "hw/usb/core.c", line=558, + function=0x555555e20b90 <__PRETTY_FUNCTION__.27044> "usb_packet_setup") at assert.c:101 +No locals. +#4 0x0000555555b4015a in usb_packet_setup (p=0x555556e81bc8, pid=105, ep=0x55555733e180, stream=0, id=260615936, + short_not_ok=false, int_req=false) at hw/usb/core.c:558 + __PRETTY_FUNCTION__ = "usb_packet_setup" +#5 0x0000555555b4f2ee in ohci_service_iso_td (ohci=0x555556e814c0, ed=0x7fffffffdda0, completion=0) + at hw/usb/hcd-ohci.c:852 + int_req = false + dir = 2 + len = 1023 + str = 0x555555e233cf "in" + pid = 105 + ret = -8788 + i = -8912 + dev = 0x55555733d070 + ep = 0x55555733e180 + iso_td = {flags = 4039218540, bp = 251170816, next = 260615872, be = 251173880, offset = {59386, 0, 6, 0, 53328, + 53376, 0, 0}} + addr = 260615936 + starting_frame = 38252 + relative_frame_number = 0 + frame_count = 0 + start_offset = 59386 + next_offset = 0 + end_offset = 0 + start_addr = 251172858 + end_addr = 251173880 +#6 0x0000555555b5055c in ohci_service_ed_list (ohci=0x555556e814c0, head=260608080, completion=0) + at hw/usb/hcd-ohci.c:1239 + ed = {flags = 67080322, tail = 260614272, head = 260615936, next = 0} + next_ed = 0 + cur = 260608080 + active = 1 + link_cnt = 1 +#7 0x0000555555b50857 in ohci_frame_boundary (opaque=0x555556e814c0) at hw/usb/hcd-ohci.c:1304 + n = 12 + ohci = 0x555556e814c0 + hcca = {intr = {260608080 <repeats 32 times>}, frame = 38252, pad = 0, done = 0} +#8 0x0000555555d12050 in timerlist_run_timers (timer_list=0x555556939600) at util/qemu-timer.c:536 + ts = 0x555556ebc9b0 + current_time = 224991592167 + progress = false + cb = 0x555555b50778 <ohci_frame_boundary> + opaque = 0x555556e814c0 +#9 0x0000555555d1209c in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at util/qemu-timer.c:547 +No locals. +#10 0x0000555555d1244e in qemu_clock_run_all_timers () at util/qemu-timer.c:662 + progress = false + type = QEMU_CLOCK_VIRTUAL +#11 0x0000555555d12bf9 in main_loop_wait (nonblocking=0) at util/main-loop.c:525 + ret = 0 + timeout = 499 + timeout_ns = 977642 +#12 0x0000555555969440 in main_loop () at vl.c:1899 +No locals. +#13 0x0000555555971229 in main (argc=21, argv=0x7fffffffe358, envp=0x7fffffffe408) at vl.c:4717 + i = 0 + snapshot = 0 + linux_boot = 1 + initrd_filename = 0x0 + kernel_filename = 0x5555568d78c0 "qemu-rpi-kernel/kernel-qemu-4.4.34-v4lm-jessie" + kernel_cmdline = 0x5555568d8c80 "root=/dev/sda2 panic=1 " + boot_order = 0x0 + boot_once = 0x0 + ds = 0x55555718f750 + cyls = 0 + heads = 0 + secs = 0 + translation = 0 + opts = 0x0 + machine_opts = 0x5555568d8b20 + hda_opts = 0x0 + icount_opts = 0x0 + accel_opts = 0x0 + olist = 0x55555629fc80 <qemu_machine_opts> + optind = 21 + optarg = 0x7fffffffe780 "user,hostfwd=tcp::2222-:22" + loadvm = 0x0 + machine_class = 0x5555568eff50 + cpu_model = 0x7fffffffe6c2 "arm1176" + vga_model = 0x555555d8d8c4 "std" + qtest_chrdev = 0x0 + qtest_log = 0x0 + pid_file = 0x0 + incoming = 0x0 + defconfig = true + userconfig = true + nographic = false + display_type = DT_GTK + display_remote = 0 + log_mask = 0x0 + log_file = 0x0 + trace_file = 0x0 + maxram_size = 268435456 + ram_slots = 0 + vmstate_dump_file = 0x0 + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = false + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7fffffffe140} + __func__ = "main" + + +(P.S. Tiedostoa tai hakemistoa ei ole = file or directory doesn't exist.) + +The attached ZIP file contains USB packet capture file made with Wireshark on host OS side during crash. + +What happens in the capture: + +- packets 1-202: starting Qemu + +- running lsusb and v4l-info -> no packets produced + +- packets 203-268: fswebcam testpic05.jpg -> OK + +- packets 269-320: fswebcam testpic05b.jpg -> crash as described in the bug report + +For your reference, testpic05.jpg is attached, too. + +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". Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1701821 b/results/classifier/zero-shot/108/all/1701821 new file mode 100644 index 000000000..e7a2e9a81 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1701821 @@ -0,0 +1,239 @@ +other: 0.946 +socket: 0.946 +semantic: 0.945 +network: 0.942 +permissions: 0.942 +debug: 0.940 +performance: 0.939 +vnc: 0.938 +PID: 0.938 +device: 0.938 +files: 0.935 +graphic: 0.924 +boot: 0.920 +KVM: 0.919 + +floating-point operation bugs in qemu-sh4 + +When running the gnulib testsuite, I'm seeing test failures in the tests for libm functions + asinf + cbrtf + copysignf + coshf + expm1f + fabsf + floor + fmaf + ldexpf + logbf + round + roundf + sinhf + tanhf + +How to reproduce: +- Using gnulib, run ./gnulib-tool --create-testdir --dir=../testdir-math --single-configure asinf cbrtf copysignf coshf expm1f fabsf floor fma fmaf fmal ldexpf logbf round roundf sinhf tanhf +- Set environment variables for using qemu-sh4. +- cd testdir-math; mkdir build-sh4; cd build-sh4; ./configure --host=sh4-linux; make; make check + +Here are the failures (from the file testdir-math/build-sh4/gltests/test-suite.log): + + +FAIL: test-asinf +================ + +pc=0xf6751cdc sr=0x00000101 pr=0xf6758e86 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6751cd6 fpul=0x3f19999a +r0=0xf6751d88 r1=0x00000000 r2=0x00080000 r3=0x00000000 +r4=0xf6ffe21c r5=0xf6ffe230 r6=0xf6ffe2fc r7=0x00000000 +r8=0x3f19999a r9=0x3f19999a r10=0x00000000 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe230 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-asinf (exit status: 1) + +FAIL: test-cbrtf +================ + +pc=0x00400980 sr=0x00000001 pr=0x00400684 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x00400960 fpul=0x00000000 +r0=0x00400ae8 r1=0x00412070 r2=0x3f19999a r3=0xf6ffe2c0 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x00412064 r9=0x00400960 r10=0x00000000 r11=0x00000000 +r12=0xf671dc58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe21c +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-cbrtf (exit status: 1) + +FAIL: test-copysignf +==================== + +pc=0x004004ce sr=0x00000001 pr=0xf668d28c fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf6674678 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x004004d2 fpul=0x00000000 +r0=0x80000000 r1=0x3f4ccccd r2=0xf6674284 r3=0xf6ffe2b0 +r4=0x00000001 r5=0xf6ffe2e4 r6=0xf6ffe2ec r7=0x00000000 +r8=0x00411088 r9=0x00411084 r10=0x00000000 r11=0x00000000 +r12=0xf67a8c58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe240 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +in conditional delay slot (delayed_pc=0x004004d2) +Unhandled trap: 0x1a0 +FAIL test-copysignf (exit status: 1) + +FAIL: test-coshf +================ + +pc=0xf675223a sr=0x00000101 pr=0xf675223c fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf675231c fpul=0x3f19999a +r0=0x3f19999a r1=0x3f19999a r2=0x000000e0 r3=0xf6ffe2c0 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x00400734 r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe240 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +in delay slot (delayed_pc=0xf675231c) +Unhandled trap: 0x1a0 +FAIL test-coshf (exit status: 1) + +FAIL: test-expm1f +================= + +pc=0xf6757e08 sr=0x00000000 pr=0x004005ce fpscr=0x00081000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6757dfe fpul=0x00000000 +r0=0xf6757fb0 r1=0x00001000 r2=0x00080000 r3=0x3eb17218 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x00400514 r9=0x00000064 r10=0x00400514 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe234 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-expm1f (exit status: 1) + +FAIL: test-fabsf +================ + +pc=0x00400504 sr=0x00000001 pr=0xf660228c fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x004004ec fpul=0x00000000 +r0=0x00400640 r1=0x00412074 r2=0x00000000 r3=0x00412078 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00080000 +r8=0x004007ac r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0xf671dc58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe260 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-fabsf (exit status: 1) + +FAIL: test-floor2 +================= + +../../gltests/test-floor2.c:130: assertion 'correct_result_p (x, reference)' failed +qemu: uncaught target signal 6 (Aborted) - core dumped +FAIL test-floor2 (exit status: 134) + +FAIL: test-fmaf2 +================ + +pc=0xf675f5ac sr=0x00000101 pr=0xf675f5a6 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf675f5a6 fpul=0x01800000 +r0=0xf675f4a4 r1=0x000065b0 r2=0x00080000 r3=0x3f800000 +r4=0x01800000 r5=0x00000000 r6=0xffffffe9 r7=0x7f800000 +r8=0xffffff6b r9=0xf6ffe1e4 r10=0xf6ffe1e8 r11=0xffffff6b +r12=0xf67ab008 r13=0xf6ffe1d8 r14=0x004004dc r15=0xf6ffe18c +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-fmaf2 (exit status: 1) + +FAIL: test-ldexpf +================= + +pc=0xf669efa0 sr=0x00000001 pr=0xf669ef9a fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf6674678 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf669ef9a fpul=0x3f99999a +r0=0xfffffdc6 r1=0x000c9d70 r2=0x00080000 r3=0x3f19999a +r4=0x0019999a r5=0x3f19999a r6=0xffffffe9 r7=0x7f800000 +r8=0x00000001 r9=0x0040041c r10=0xf6ffe23c r11=0x00000000 +r12=0xf67a8c58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe218 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-ldexpf (exit status: 1) + +FAIL: test-logbf +================ + +pc=0xf675842c sr=0x00000001 pr=0x00400664 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6758422 fpul=0x00000000 +r0=0xf6758480 r1=0x00000000 r2=0x00080000 r3=0x00080000 +r4=0x00000000 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0xf6ffe24c r9=0x0040054c r10=0x00000000 r11=0x00000000 +r12=0xf671dc58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe244 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-logbf (exit status: 1) + +FAIL: test-round2 +================= + +FAIL test-round2 (exit status: 1) + +FAIL: test-roundf2 +================== + +FAIL test-roundf2 (exit status: 1) + +FAIL: test-sinhf +================ + +pc=0xf675581c sr=0x00000101 pr=0xf675a784 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6755858 fpul=0x3f19999a +r0=0xf6755930 r1=0x317fffff r2=0x3f19999a r3=0xf6ffe2c0 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x3f19999a r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe238 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +in conditional delay slot (delayed_pc=0xf6755858) +Unhandled trap: 0x1a0 +FAIL test-sinhf (exit status: 1) + +FAIL: test-tanhf +================ + +pc=0xf6758ca4 sr=0x00000100 pr=0x0040057c fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6758c9a fpul=0x3f19999a +r0=0xf6758d00 r1=0x00000000 r2=0x00080000 r3=0xf6ffe2c0 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x3f19999a r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe254 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-tanhf (exit status: 1) + + +I don't have access to sh4 hardware, so I cannot provide this as a comparison point. +But most of the test failures don't look like "merely" a wrong computation by glibc. + + + +Seems like two patches for this have been included in QEMU v2.10: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=57f5c1b093e1c3ec +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=fea7d77d3ea287d3 +Can we close this ticket now, or is there something left to do here? + +With qemu-2.10, all of these tests now pass. Great! + diff --git a/results/classifier/zero-shot/108/all/1715700 b/results/classifier/zero-shot/108/all/1715700 new file mode 100644 index 000000000..5f30ebaa9 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1715700 @@ -0,0 +1,554 @@ +other: 0.980 +permissions: 0.977 +files: 0.975 +device: 0.972 +debug: 0.970 +boot: 0.969 +performance: 0.966 +graphic: 0.965 +semantic: 0.965 +PID: 0.964 +vnc: 0.963 +KVM: 0.960 +socket: 0.958 +network: 0.954 + +Windows 7 guest won't boot on qemu 2.10 (works on 2.9) + +Qemu version: 2.10 stable. +Guest: Windows 7 SP1 x64, virtio drivers are already installed in the guest. +Command line: +qemu-system-x86_64 \ + -nodefaults \ + -nodefconfig \ + -machine type=q35,accel=kvm \ + -enable-kvm \ + -cpu host \ + -m 2048 \ + -vga virtio \ + -boot menu=on \ + -smbios file=/path/dmidecode_BIOS.bin \ + -acpitable file=/path/acpi_slic.bin \ + -bios /path/OVMF_CODE.fd \ + -net none \ + -drive if=virtio,media=disk,file=/media/win7.qcow2 \ + -device pcie-root-port \ + -device ich9-usb-ehci1 \ + -device ich9-usb-uhci1 \ + -device ich9-usb-uhci2 \ + -device ich9-usb-uhci3 + +Windows hangs at boot with waving flag screen (flag doesn't freeze, keeps waving indefinitely). Same command line boots fine with Qemu 2.9. I tried changing machine type to pc-q35-2.9 - same result. + +Hi, + There's a good chance this is the same as lp 1714331 - fixed by a newer OVMF. + + +Compiled latest OVMF from git (ea21f1d), used it in "-bios" line - same result. What else can I try? + +On Thu, 07 Sep 2017 19:34:37 -0000 +Aleksei Kovura <email address hidden> wrote: + +> Compiled latest OVMF from git (ea21f1d), used it in "-bios" line - same +> result. What else can I try? +Bisecting 2.9 -> 2.10 might point out offending commit + + +Ok, so I cloned from github and am bisecting like this (it's been a while, correct me if I'm wrong): +$ git bisect start +$ git bisect bad 1ab5eb4efb91a3d4569b0df6e824cc08ab4bd8ec # 2.10.0 stable commit +$ git bisect good 359c41abe32638adad503e386969fa428cecff52 # 2.9.0 stable commit +Bisecting: 1426 revisions left to test after this (roughly 11 steps) +[269c20b2bbd2aa8531e0cdc741fb166f290d7a2b] tests/qdict: check more get_try_int() cases +$ mkdir -p bin/269c20b2bbd2aa8531e0cdc741fb166f290d7a2b +$ cd bin/269c20b2bbd2aa8531e0cdc741fb166f290d7a2b +$ ../../configure --target-list=x86_64-softmmu --python=/usr/bin/python2 --enable-debug + +Compilation fails with this (full log here https://pastebin.com/aUYyE6Bb): + + CC block/block-backend.o +/media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c: In function ‘blkdebug_refresh_filename’: +/media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c:843:31: error: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4086 [-Werror=format-truncation=] + "blkdebug:%s:%s", s->config_file ?: "", + ^~ +/media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c:842:9: note: ‘snprintf’ output 11 or more bytes (assuming 4106) into a destination of size 4096 + snprintf(bs->exact_filename, sizeof(bs->exact_filename), + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + "blkdebug:%s:%s", s->config_file ?: "", + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + bs->file->bs->exact_filename); + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +cc1: all warnings being treated as errors +make: *** [/media/usb465gb_232gb_NTFS/compile/qemu/rules.mak:66: block/blkdebug.o] Error 1 +make: *** Waiting for unfinished jobs.... +/media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c: In function ‘blkverify_refresh_filename’: +/media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c:305:29: error: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4086 [-Werror=format-truncation=] + "blkverify:%s:%s", + ^~ +/media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c:304:9: note: ‘snprintf’ output between 12 and 8202 bytes into a destination of size 4096 + snprintf(bs->exact_filename, sizeof(bs->exact_filename), + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + "blkverify:%s:%s", + ~~~~~~~~~~~~~~~~~~ + bs->file->bs->exact_filename, + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + s->test_file->bs->exact_filename); + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +cc1: all warnings being treated as errors +make: *** [/media/usb465gb_232gb_NTFS/compile/qemu/rules.mak:66: block/blkverify.o] Error 1 + +Did I hit a commit with a broken build or something? What to do next? + +* Aleksei Kovura (<email address hidden>) wrote: +> Ok, so I cloned from github and am bisecting like this (it's been a while, correct me if I'm wrong): +> $ git bisect start +> $ git bisect bad 1ab5eb4efb91a3d4569b0df6e824cc08ab4bd8ec # 2.10.0 stable commit +> $ git bisect good 359c41abe32638adad503e386969fa428cecff52 # 2.9.0 stable commit +> Bisecting: 1426 revisions left to test after this (roughly 11 steps) +> [269c20b2bbd2aa8531e0cdc741fb166f290d7a2b] tests/qdict: check more get_try_int() cases +> $ mkdir -p bin/269c20b2bbd2aa8531e0cdc741fb166f290d7a2b +> $ cd bin/269c20b2bbd2aa8531e0cdc741fb166f290d7a2b +> $ ../../configure --target-list=x86_64-softmmu --python=/usr/bin/python2 --enable-debug +> +> Compilation fails with this (full log here +> https://pastebin.com/aUYyE6Bb): +> +> CC block/block-backend.o +> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c: In function ‘blkdebug_refresh_filename’: +> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c:843:31: error: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4086 [-Werror=format-truncation=] +> "blkdebug:%s:%s", s->config_file ?: "", +> ^~ +> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkdebug.c:842:9: note: ‘snprintf’ output 11 or more bytes (assuming 4106) into a destination of size 4096 +> snprintf(bs->exact_filename, sizeof(bs->exact_filename), +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> "blkdebug:%s:%s", s->config_file ?: "", +> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> bs->file->bs->exact_filename); +> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> cc1: all warnings being treated as errors +> make: *** [/media/usb465gb_232gb_NTFS/compile/qemu/rules.mak:66: block/blkdebug.o] Error 1 +> make: *** Waiting for unfinished jobs.... +> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c: In function ‘blkverify_refresh_filename’: +> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c:305:29: error: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4086 [-Werror=format-truncation=] +> "blkverify:%s:%s", +> ^~ +> /media/usb465gb_232gb_NTFS/compile/qemu/block/blkverify.c:304:9: note: ‘snprintf’ output between 12 and 8202 bytes into a destination of size 4096 +> snprintf(bs->exact_filename, sizeof(bs->exact_filename), +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> "blkverify:%s:%s", +> ~~~~~~~~~~~~~~~~~~ +> bs->file->bs->exact_filename, +> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> s->test_file->bs->exact_filename); +> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> cc1: all warnings being treated as errors +> make: *** [/media/usb465gb_232gb_NTFS/compile/qemu/rules.mak:66: block/blkverify.o] Error 1 +> +> Did I hit a commit with a broken build or something? What to do next? + +It's just the newer compiler is more fussy than the old one so when you +bisect you're not getting fixes for newer compilers. You can pass +flags to the configure to use extra clfgas to turn this particular +warning off. + +Dave + +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1715700 +> +> Title: +> Windows 7 guest won't boot on qemu 2.10 (works on 2.9) +> +> Status in QEMU: +> New +> +> Bug description: +> Qemu version: 2.10 stable. +> Guest: Windows 7 SP1 x64, virtio drivers are already installed in the guest. +> Command line: +> qemu-system-x86_64 \ +> -nodefaults \ +> -nodefconfig \ +> -machine type=q35,accel=kvm \ +> -enable-kvm \ +> -cpu host \ +> -m 2048 \ +> -vga virtio \ +> -boot menu=on \ +> -smbios file=/path/dmidecode_BIOS.bin \ +> -acpitable file=/path/acpi_slic.bin \ +> -bios /path/OVMF_CODE.fd \ +> -net none \ +> -drive if=virtio,media=disk,file=/media/win7.qcow2 \ +> -device pcie-root-port \ +> -device ich9-usb-ehci1 \ +> -device ich9-usb-uhci1 \ +> -device ich9-usb-uhci2 \ +> -device ich9-usb-uhci3 +> +> Windows hangs at boot with waving flag screen (flag doesn't freeze, +> keeps waving indefinitely). Same command line boots fine with Qemu +> 2.9. I tried changing machine type to pc-q35-2.9 - same result. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1715700/+subscriptions +> +-- +Dr. David Alan Gilbert / <email address hidden> / Manchester, UK + + +The newer GCC compilers are more fussy - just add '--disable-werror' when running 'configure' to make it ignore the warning + +Bisected. Good thing Igor is already here :) + +208fa0e43645edd0b0d8f838857dfc79daff40a8 is the first bad commit +commit 208fa0e43645edd0b0d8f838857dfc79daff40a8 +Author: Igor Mammedov <email address hidden> +Date: Fri Jul 28 11:09:05 2017 +0200 + + pc: make 'pc.rom' readonly when machine has PCI enabled + + +Just did a test to be sure: pulled latest git (a9158a5cba955b79d580a252cc58ff44d154e370) - guest didn't launch. Reverted 208fa0e43645edd0b0d8f838857dfc79daff40a8 - guest launched successfully. + +Can someone please take a look at this? I don't want to get stuck at 2.9.0 :) + +Added Imammedo to this lp. + +Igor asked to add Gerd. + +could be this commit breaks vbeshim ... + +Thanks, Gerd, for the CC -- I agree, this commit (208fa0e43645) almost certainly breaks the VBE Shim. Displaying the patch with a bit larger context, + +> diff --git a/hw/i386/pc.c b/hw/i386/pc.c +> index 22e16031b03b..59435390ba62 100644 +> --- a/hw/i386/pc.c +> +++ b/hw/i386/pc.c +> @@ -1442,8 +1442,11 @@ void pc_memory_init(PCMachineState *pcms, +> +> option_rom_mr = g_malloc(sizeof(*option_rom_mr)); +> memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE, +> &error_fatal); +> + if (pcmc->pci_enabled) { +> + memory_region_set_readonly(option_rom_mr, true); +> + } +> memory_region_add_subregion_overlap(rom_memory, +> PC_ROM_MIN_VGA, +> option_rom_mr, +> 1); + +and PC_ROM_MIN_VGA is #defined as 0xc0000 in "include/hw/loader.h". + +OVMF places the VBE Shim into the C segment, and points the 0x10 interrupt vector at it. See "OvmfPkg/QemuVideoDxe/VbeShim.c", function InstallVbeShim(): + +> SegmentC = 0xC0000; +> +> [...] +> +> // +> // Put the shim in place first. +> // +> Pam1Address = PCI_LIB_ADDRESS (0, 0, 0, 0x5A); +> // +> // low nibble covers 0xC0000 to 0xC3FFF +> // high nibble covers 0xC4000 to 0xC7FFF +> // bit1 in each nibble is Write Enable +> // bit0 in each nibble is Read Enable +> // +> Pam1 = PciRead8 (Pam1Address); +> PciWrite8 (Pam1Address, Pam1 | (BIT1 | BIT0)); +> +> // +> // We never added memory space during PEI or DXE for the C segment, so we +> // don't need to (and can't) allocate from there. Also, guest operating +> // systems will see a hole in the UEFI memory map there. +> // +> SegmentCPages = 4; +> +> ASSERT (sizeof mVbeShim <= EFI_PAGES_TO_SIZE (SegmentCPages)); +> CopyMem ((VOID *)(UINTN)SegmentC, mVbeShim, sizeof mVbeShim); +> +> [...] +> +> // +> // Clear Write Enable (bit1), keep Read Enable (bit0) set +> // +> PciWrite8 (Pam1Address, (Pam1 & ~BIT1) | BIT0); +> +> // +> // Second, point the Int10h vector at the shim. +> // +> Int0x10->Segment = (UINT16) ((UINT32)SegmentC >> 4); +> Int0x10->Offset = (UINT16) ((UINTN) (VbeModeInfo + 1) - SegmentC); + + +I'm not sure if I mentioned this before, but launchpad is an *abomination*. + +On Tue, 19 Sep 2017 10:39:00 -0000 +Gerd Hoffmann <email address hidden> wrote: + +> could be this commit breaks vbeshim ... +> + +is there a way to fix vbeshim instead of reverting RO limitation that commit introduced? + + +I'd also like to mention that, when we originally worked on the VBE Shim, I tried to put it elsewhere. Obviously it has to be pointed-to by a real mode interrupt vector, which limits quite a bit where it can go at all; the point is that I tried to put it into low *RAM* (under 640KB). + +It didn't work. Windows 7 would only accept the VBE Shim when it existed in the C segment, i.e. where a VGA option ROM would normally be located. + +This is just to say that moving the VBE Shim out of the C segment (into real-mode addressible RAM) will not work. + +The symptom described in the original report is likely due to + +- Windows following the 0x10 interrupt vector (from page 0) to the C segment, + +- copying a bunch of zeros into its real mode emulator from the C segment (where now no actual VBE code can be found), + +- and then seeing no results when the real mode emulator executes the zeros. + +On Tue, 19 Sep 2017 10:39:00 -0000 +Gerd Hoffmann <email address hidden> wrote: + +> could be this commit breaks vbeshim ... +> + +Did a bit of testing: w7 iso boots to install screen with seabios but +stuck at win boot logo with ovmf. + +I've heard (maybe wrongly) that seabios would also break in that case. + + + +What I mentioned earlier was not that SeaBIOS would break. + +Instead, I said that building OVMF, with the SeaBIOS CSM (Compatibility Support Module) embedded into it, would break, exactly the same way as the VBE Shim. + +Quoting the CSM Spec from Intel: "The CSM provides compatibility support between the Framework and traditional, legacy BIOS code and allows booting a traditional OS or booting an EFI OS off a device that requires a traditional option ROM (OpROM)." + +https://github.com/tianocore/tianocore.github.io/wiki/Compatibility-Support-Module + +Upstream edk2 contains no such module out of the box. However, SeaBIOS has been extended with a build target (CONFIG_CSM) that produces such a binary. This binary can be then embedded in the edk2 source tree (see "OvmfPkg/Csm/Csm16/ReadMe.txt"), and then OVMF can be built with -D CSM_ENABLE. + +This will allow OVMF to boot legacy OSes, and those OSes will think they are being booted on a legacy BIOS machine. + +While the SeaBIOS CSM itself is provided by the SeaBIOS project, the infrastructure that sets it up under UEFI comes from edk2. The two important drivers are -- built into OVMF only with -D CSM_ENABLE --: + +- IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf + +- IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf + +The former driver (LegacyBiosDxe) needs write access to the memory area at 0xc0000, so that it can install legacy PCI option ROMs. The service it provides is called "EFI_LEGACY_BIOS_PROTOCOL.InstallPciRom"; it loads a traditional OpROM into traditional OpROM address space (0xC0000 to 0xFFFFF region). + +The latter driver (VideoDxe) asks the former driver to install such an option ROM (for video services) from the PCI ROM BAR. + +Therefore, if the area at 0xc0000 is unwriteable for the guest, then neither the VBE Shim, nor its alternative -- namely the full-blown SeaBIOS CSM -- can function in OVMF. + +On Tue, 19 Sep 2017 10:59:51 -0000 +"Laszlo Ersek \(Red Hat\)" <email address hidden> wrote: + +> Thanks, Gerd, for the CC -- I agree, this commit (208fa0e43645) almost +> certainly breaks the VBE Shim. Displaying the patch with a bit larger +> context, +> +> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c +> > index 22e16031b03b..59435390ba62 100644 +> > --- a/hw/i386/pc.c +> > +++ b/hw/i386/pc.c +> > @@ -1442,8 +1442,11 @@ void pc_memory_init(PCMachineState *pcms, +> > +> > option_rom_mr = g_malloc(sizeof(*option_rom_mr)); +> > memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE, +> > &error_fatal); +> > + if (pcmc->pci_enabled) { +> > + memory_region_set_readonly(option_rom_mr, true); +> > + } +> > memory_region_add_subregion_overlap(rom_memory, +> > PC_ROM_MIN_VGA, +> > option_rom_mr, +> > 1); +looking at it more, question is why do we have a separate +piece of ram mapped here that overlays system ram. +Can we remove this memory region and let guest use +underling initial memory? + + +> +> and PC_ROM_MIN_VGA is #defined as 0xc0000 in "include/hw/loader.h". +> +> OVMF places the VBE Shim into the C segment, and points the 0x10 +> interrupt vector at it. See "OvmfPkg/QemuVideoDxe/VbeShim.c", function +> InstallVbeShim(): +> +> > SegmentC = 0xC0000; +> > +> > [...] +> > +> > // +> > // Put the shim in place first. +> > // +> > Pam1Address = PCI_LIB_ADDRESS (0, 0, 0, 0x5A); +> > // +> > // low nibble covers 0xC0000 to 0xC3FFF +> > // high nibble covers 0xC4000 to 0xC7FFF +> > // bit1 in each nibble is Write Enable +> > // bit0 in each nibble is Read Enable +> > // +> > Pam1 = PciRead8 (Pam1Address); +> > PciWrite8 (Pam1Address, Pam1 | (BIT1 | BIT0)); +> > +> > // +> > // We never added memory space during PEI or DXE for the C segment, so we +> > // don't need to (and can't) allocate from there. Also, guest operating +> > // systems will see a hole in the UEFI memory map there. +> > // +> > SegmentCPages = 4; +> > +> > ASSERT (sizeof mVbeShim <= EFI_PAGES_TO_SIZE (SegmentCPages)); +> > CopyMem ((VOID *)(UINTN)SegmentC, mVbeShim, sizeof mVbeShim); +> > +> > [...] +> > +> > // +> > // Clear Write Enable (bit1), keep Read Enable (bit0) set +> > // +> > PciWrite8 (Pam1Address, (Pam1 & ~BIT1) | BIT0); +> > +> > // +> > // Second, point the Int10h vector at the shim. +> > // +> > Int0x10->Segment = (UINT16) ((UINT32)SegmentC >> 4); +> > Int0x10->Offset = (UINT16) ((UINTN) (VbeModeInfo + 1) - SegmentC); +> + + + +ovmf seems to not touch pam configuration, so rom remains mapped. +seabios in contrast maps the address range to ram instead. +IIRC ovmf does that too in CSM mode. +So, yes, probably this is fixable in ovmf. + +Re: comment 14, "is there a way to fix vbeshim instead of reverting RO limitation that commit introduced?": + +I don't think so; please see my earlier comments 15 and 17. To elaborate: + +If a user wants to boot Windows 7 on OVMF, they have *three* options: + +(1) Build the SeaBIOS CSM (CONFIG_CSM=y), and embed it into OVMF, like described above. Then, boot Windows 7 in *Legacy Mode*. + +--> Windows 7 will think that it runs on a plain BIOS machine. The VBE Services will be provided to Windows 7 by (a) the edk2 CSM infrastructure, (b) the SeaBIOS CSM, and (c) the VGABIOS PCI oprom together. + +(2) Build the SeaBIOS CSM (CONFIG_CSM=y), and embed it into OVMF, like described above. Then, boot Windows 7 in *UEFI Mode*. + +--> Windows 7 will think that it runs on a UEFI machine, *but* because Windows 7 has a bug, it will want to invoke VBE services nonetheless. The VBE Services will be provided to Windows 7 by (a) the edk2 CSM infrastructure, (b) the SeaBIOS CSM, and (c) the VGABIOS PCI oprom together. + +(3) Build OVMF without the SeaBIOS CSM, then boot Windows 7 in UEFI Mode. + +--> Windows 7 will think that it runs on a UEFI machine, *but* because Windows 7 has a bug, it will want to invoke VBE services nonetheless. The VBE Services will be provided to Windows 7 by the VBE Shim that OVMF installs during boot. + + +Option #1 and option #2 no longer work because the CSM infrastructure in edk2 needs to be able to write 0xc0000. + +Option #3 no longer works because OVMF needs to put the VBE Shim into place at 0xc0000. + + +Basically, Windows 7 wants to find the VBE services at 0xc0000, regardless of the method that it is booted with, ie. Legacy or UEFI. (As I said, this is a Windows 7 bug.) If that memory area is not writeable to the guest, then OVMF cannot satisfy the (buggy) Windows 7 requirement, using either of options #1, #2 or #3. + +On 09/19/17 13:49, Gerd Hoffmann wrote: +> ovmf seems to not touch pam configuration, so rom remains mapped. + +I don't understand; the code that I quoted above -- and that LaunchPad +messed up -- explicitly changes the PAM registers: + + // + // Put the shim in place first. + // + Pam1Address = PCI_LIB_ADDRESS (0, 0, 0, 0x5A); + // + // low nibble covers 0xC0000 to 0xC3FFF + // high nibble covers 0xC4000 to 0xC7FFF + // bit1 in each nibble is Write Enable + // bit0 in each nibble is Read Enable + // + Pam1 = PciRead8 (Pam1Address); + PciWrite8 (Pam1Address, Pam1 | (BIT1 | BIT0)); + +... + + // + // Clear Write Enable (bit1), keep Read Enable (bit0) set + // + PciWrite8 (Pam1Address, (Pam1 & ~BIT1) | BIT0); + +> seabios in contrast maps the address range to ram instead. +> IIRC ovmf does that too in CSM mode. +> So, yes, probably this is fixable in ovmf. + +I don't see how. + +Thanks +Laszlo + + +Ahh, wait, now I remember something -- the PAM registers are at a different location on Q35!!! + +If that's what's wrong, then it is indeed an OVMF bug. Let me see if I can write a patch. + + + +Indeed the CSM platform support had the same error one and half years ago, see: + +https://github.com/tianocore/edk2/commit/db27e9f3d8f0 + +Thank you, Gerd, for the hint! + +> (2) Build the SeaBIOS CSM (CONFIG_CSM=y), and embed it into OVMF, +> like described above. Then, boot Windows 7 in *UEFI Mode*. + +> Option #1 and option #2 no longer work because the CSM infrastructure +> in edk2 needs to be able to write 0xc0000. + +Well, option #2 works for me. + + + +On 09/19/17 14:38, Gerd Hoffmann wrote: +>> (2) Build the SeaBIOS CSM (CONFIG_CSM=y), and embed it into OVMF, +>> like described above. Then, boot Windows 7 in *UEFI Mode*. +> +>> Option #1 and option #2 no longer work because the CSM infrastructure +>> in edk2 needs to be able to write 0xc0000. +> +> Well, option #2 works for me. +> + +Correct, and that's because edk2 commit db27e9f3d8f0 fixed the PAM +register offsets for Q35, in the CSM platform support. At that time we +missed that the same should be done in the VBE Shim as well. + +I'm going to do it for the VBE Shim now. + +(I'm pretty sure UEFI Windows 7 boots fine with the VBE Shim right now, +on QEMU 2.10, if the machine type is i440fx, not q35.) + +Thanks for the help! +Laszlo + + +Posted: + +[edk2] [PATCH 0/3] OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly + +https://lists.01.org/pipermail/edk2-devel/2017-September/014898.html + +I CC'd Aleksei on the series, but testing is welcome from anyone. (The cover letter at the link contains a git fetch URL.) + +edk2 commit range: b68c793144e8..947f3737abf6. + +See also LP#1725560. + +I assume this has been completely fixed in edk2, so I'm closing this QEMU bug now. + diff --git a/results/classifier/zero-shot/108/all/1716767 b/results/classifier/zero-shot/108/all/1716767 new file mode 100644 index 000000000..4be0b7d2a --- /dev/null +++ b/results/classifier/zero-shot/108/all/1716767 @@ -0,0 +1,125 @@ +debug: 0.978 +semantic: 0.977 +graphic: 0.976 +permissions: 0.976 +performance: 0.970 +other: 0.961 +device: 0.960 +vnc: 0.957 +PID: 0.946 +socket: 0.935 +network: 0.929 +KVM: 0.925 +files: 0.925 +boot: 0.919 + +file(1) fails with "Invalid argument" on qemu-sh4-user + +We recently discovered that file(1) fails on qemu-sh4-user when running on an ELF file: + +(sid_sh4)root@vs94:/# file /bin/bash +/bin/bash: ERROR: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV) error reading (Invalid argument) +(sid_sh4)root@vs94:/# + +Running with "-d" yields more output: + +(sid_sh4)root@vs94:/# file -d /bin/bash 2>&1 | tail +322: >> 7 byte&,=97,"(ARM)"] +0 == 97 = 0 +mget(type=1, flag=0, offset=7, o=0, nbytes=863324, il=0, nc=1) +mget/96 @7: \000\000\000\000\000\000\000\000\000\002\000*\000\001\000\000\000\250\317A\0004\000\000\000L(\r\000\027\000\000\0004\000 \000\n\000(\000\032\000\031\000\006\000\000\0004\000\000\0004\000@\0004\000@\000@\001\000\000@\001\000\000\005\000\000\000\004\000\000\000\003\000\000\000t\001\000\000t\001@\000t\001@\000\023\000\000 + +323: >> 7 byte&,=-1,"(embedded)"] +0 == 18446744073709551615 = 0 +[try softmagic 1] +[try elf -1] +/bin/bash: ERROR: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV) error reading (Invalid argument) +(sid_sh4)root@vs94:/# + +It seems that the comparison above has a bogus (overflown?) value. + +On actual hardware, it works: + +root@tirpitz:~> file /bin/bash +/bin/bash: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=4dd0e4281755827d8bb6686fd481f8c80ea73e9a, for GNU/Linux 3.2.0, stripped +root@tirpitz:~> + +I have uploaded a chroot with Debian unstable which allows to reproduce the issue: + +> https://people.debian.org/~glaubitz/sid-sh4-sbuild.tar.gz + +The "0 == 18446744073709551615 = 0" is actually fine, it's just printing "-1" as a 64-bit unsigned integer. Could you please upload the fill output of `file -d /bin/bash 2>&1`? + +On 09/12/2017 11:18 PM, James Clarke wrote: +> The "0 == 18446744073709551615 = 0" is actually fine, it's just printing +> "-1" as a 64-bit unsigned integer. + +Yeah, I noticed that output was the same on amd64. + +> Could you please upload the fill +> output of `file -d /bin/bash 2>&1`? + +> https://people.debian.org/~glaubitz/file-sh4-qemu.txt + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + +I just ran it myself inside and outside the sh4 chroot. The logging output is the same, with the exception of the final line. Something is happening once it's decided it's elf; looking at file_tryelf, my guess is the fstat call is failing[0]. + +[0] http://sources.debian.net/src/file/1:5.31-1/src/readelf.c/#L1609 + +On 12 September 2017 at 22:47, James Clarke <email address hidden> wrote: +> I just ran it myself inside and outside the sh4 chroot. The logging +> output is the same, with the exception of the final line. Something is +> happening once it's decided it's elf; looking at file_tryelf, my guess +> is the fstat call is failing[0]. + +strace could probably confirm or deny that. I would be unsurprised +if the linux-user definitions for the structure layouts for the +various stat structs were wrong for sh4. + +thanks +-- PMM + + +Ok, I was wrong, there's a whole load of code being included inside the function from a header. The issue seems to be the pread: + +20771@1505254578.940000:guest_user_syscall cpu=0x62850620 num=0x00000000000000b4 arg1=0x0000000000000003 arg2=0xfffffffff6fe6798 arg3=0x0000000000000020 arg4=0x0000000000000000 arg5=0x0000000000000034 arg6=0x0000000000000000 arg7=0x0000000000000000 arg8=0x0000000000000000 +20771@1505254578.940005:guest_user_syscall_ret cpu=0x62850620 num=0x00000000000000b4 ret=0x0000000000000000 + +0xb4 (180) is pread(64) on SH, which goes via a special wrapper[0] with a dummy argument that gets stripped. This dummy argument ensures that the 64-bit offset is aligned. However, linux-user doesn't know about this, and so takes (arg4, arg5) as the 64-bit value, rather than (arg5, arg6), leading to the host kernel trying to read 0x340000000000000000 bytes (and rightly returning 0 for EOF). + +[0] https://github.com/torvalds/linux/blob/e0d072250a54669dce876d8ade70e417356aae74/arch/sh/kernel/sys_sh32.c#L38 + +(Currently regpairs_aligned gets checked, but this, rightly, returns false for SH; alignment is not a requirement of the SH ABI, but p{read,write}64 are an exception for it.) + +Bah, and that's "read *from an offset of* 0x340000000000000000 bytes"; I got confused between count and pos midway through that paragraph. + +With the attached patch, qemu-sh4-static now works for file: + +root@debian:/# /usr/bin/qemu-sh4-static.new2 /usr/bin/file /bin/bash +/bin/bash: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=579b7ca73585e30c022e6dec83666ecc746f7499, for GNU/Linux 3.2.0, stripped + +On 09/13/2017 08:37 PM, James Clarke wrote: +> With the attached patch, qemu-sh4-static now works for file: + +I can also confirm that the patch fixes the problem for me. + +Would be great if it could get merged in one form or another. + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + +Please post patches to the qemu-devel mailing list for discussion instead of attaching them to the bugtracker. Thanks! + +Fix has been released with QEMU 2.11: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8bf8e9df4a7d82c7a47cc9 + diff --git a/results/classifier/zero-shot/108/all/1727 b/results/classifier/zero-shot/108/all/1727 new file mode 100644 index 000000000..c4d3bae45 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1727 @@ -0,0 +1,96 @@ +other: 0.981 +vnc: 0.973 +semantic: 0.970 +performance: 0.969 +graphic: 0.969 +PID: 0.968 +device: 0.966 +debug: 0.964 +permissions: 0.963 +KVM: 0.963 +socket: 0.959 +boot: 0.952 +network: 0.947 +files: 0.946 + +virtio-gpu-gl-pci console tries to make GL context before widget is realized leading to crash +Description of problem: +When `-vga none` is added to the command line, there is no crash. + +When it is not, two `GtkGLArea` widgets are created: one for VGA and one for `virtio-gpu-gl-pci`. Only the first one is realized, but the virgl code tries to create a GL context for the second. In `gd_gl_area_create_context`, `gtk_widget_get_window(vc->gfx.drawing_area)` evaluates to NULL a crash follows: + +``` +qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed +qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed +qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed +qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed +qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed +qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed +qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed +qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed +qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed +qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed +qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed +qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed +qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed +qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed +qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed +qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed +qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed +qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed +qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed +qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed +qemu: Gdk: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed +qemu: Gdk: gdk_gl_context_set_required_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_realize: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gdk: gdk_gl_context_get_version: assertion 'GDK_IS_GL_CONTEXT (context)' failed +qemu: Gtk: gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed +qemu: Gdk: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed +gl_version 0 - compat profile +WARNING: running without ARB/KHR robustness in place may crash +qemu-system-x86_64: ../libepoxy/src/dispatch_common.c:872: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed. +``` +Steps to reproduce: +1. Get OVMF. On Arch Linux, you can install the `edk2-ovmf` package. On other distros, find a similar package and modify the path in the command accordingly. +2. Run the command above. diff --git a/results/classifier/zero-shot/108/all/1727250 b/results/classifier/zero-shot/108/all/1727250 new file mode 100644 index 000000000..86c472f1c --- /dev/null +++ b/results/classifier/zero-shot/108/all/1727250 @@ -0,0 +1,496 @@ +permissions: 0.998 +other: 0.998 +device: 0.998 +semantic: 0.998 +socket: 0.997 +debug: 0.997 +network: 0.997 +performance: 0.997 +PID: 0.997 +graphic: 0.997 +vnc: 0.997 +files: 0.997 +KVM: 0.995 +boot: 0.995 + +qemu-io-test 147 segfaults when configured with gcov + +Head is at 3d7196d43bfe12efe98568cb60057e273652b99b + +Steps to re-produce: +1. git clone +./configure --enable-gcov --target-list=ppc64-softmmu +make +cd tests/qemu-iotests + +2. export qemu binary, in my environment +export QEMU_PROG=/home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 + +3. Run test 147 with format qcow2 +./check -qcow2 147 + +QEMU -- "/home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64" -nodefaults -machine accel=qtest +QEMU_IMG -- "/home/nasastry/qemu/qemu-img" +QEMU_IO -- "/home/nasastry/qemu/qemu-io" --cache writeback -f qcow2 +QEMU_NBD -- "/home/nasastry/qemu/qemu-nbd" +IMGFMT -- qcow2 (compat=1.1) +IMGPROTO -- file +PLATFORM -- Linux/ppc64le zzfp365-lp1 4.13.0-4.rel.git49564cb.el7.centos.ppc64le +TEST_DIR -- /home/nasastry/qemu/tests/qemu-iotests/scratch +SOCKET_SCM_HELPER -- /home/nasastry/qemu/tests/qemu-iotests/socket_scm_helper + +147 0s ... [failed, exit status 1] - output mismatch (see 147.out.bad) +--- /home/nasastry/qemu/tests/qemu-iotests/147.out 2017-10-25 14:04:54.978600753 +0530 ++++ /home/nasastry/qemu/tests/qemu-iotests/147.out.bad 2017-10-25 14:09:53.769783770 +0530 +@@ -1,5 +1,95 @@ +-...... ++WARNING:qemu:qemu received signal -11: /home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-monitor.sock -mon chardev=mon,mode=control -display none -vga none -qtest unix:path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-qtest.sock -machine accel=qtest -nodefaults -machine accel=qtest ++WARNING:qemu:qemu received signal -11: /home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-monitor.sock -mon chardev=mon,mode=control -display none -vga none -qtest unix:path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-qtest.sock -machine accel=qtest -nodefaults -machine accel=qtest ++WARNING:qemu:qemu received signal -11: /home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-monitor.sock -mon chardev=mon,mode=control -display none -vga none -qtest unix:path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-qtest.sock -machine accel=qtest -nodefaults -machine accel=qtest ++WARNING:qemu:qemu received signal -11: /home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-monitor.sock -mon chardev=mon,mode=control -display none -vga none -qtest unix:path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-qtest.sock -machine accel=qtest -nodefaults -machine accel=qtest ++WARNING:qemu:qemu received signal -11: /home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-monitor.sock -mon chardev=mon,mode=control -display none -vga none -qtest unix:path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-qtest.sock -machine accel=qtest -nodefaults -machine accel=qtest ++WARNING:qemu:qemu received signal -11: /home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-monitor.sock -mon chardev=mon,mode=control -display none -vga none -qtest unix:path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-28636-qtest.sock -machine accel=qtest -nodefaults -machine accel=qtest ++FFFFFF ++====================================================================== ++FAIL: test_fd (__main__.BuiltinNBD) ++---------------------------------------------------------------------- ++Traceback (most recent call last): ++ File "147", line 203, in test_fd ++ self.client_test(filename, flatten_sock_addr(address), 'nbd-export') ++ File "147", line 55, in client_test ++ self.assert_qmp(result, 'return', {}) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 315, in assert_qmp ++ result = self.dictpath(d, path) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 274, in dictpath ++ self.fail('failed path traversal for "%s" in "%s"' % (path, str(d))) ++AssertionError: failed path traversal for "return" in "None" ++ ++====================================================================== ++FAIL: test_inet (__main__.BuiltinNBD) ++---------------------------------------------------------------------- ++Traceback (most recent call last): ++ File "147", line 146, in test_inet ++ flatten_sock_addr(address), 'nbd-export') ++ File "147", line 55, in client_test ++ self.assert_qmp(result, 'return', {}) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 315, in assert_qmp ++ result = self.dictpath(d, path) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 274, in dictpath ++ self.fail('failed path traversal for "%s" in "%s"' % (path, str(d))) ++AssertionError: failed path traversal for "return" in "None" ++ ++====================================================================== ++FAIL: test_inet6 (__main__.BuiltinNBD) ++---------------------------------------------------------------------- ++Traceback (most recent call last): ++ File "147", line 171, in test_inet6 ++ self.client_test(filename, flatten_sock_addr(address), 'nbd-export') ++ File "147", line 55, in client_test ++ self.assert_qmp(result, 'return', {}) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 315, in assert_qmp ++ result = self.dictpath(d, path) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 274, in dictpath ++ self.fail('failed path traversal for "%s" in "%s"' % (path, str(d))) ++AssertionError: failed path traversal for "return" in "None" ++ ++====================================================================== ++FAIL: test_unix (__main__.BuiltinNBD) ++---------------------------------------------------------------------- ++Traceback (most recent call last): ++ File "147", line 179, in test_unix ++ flatten_sock_addr(address), 'nbd-export') ++ File "147", line 55, in client_test ++ self.assert_qmp(result, 'return', {}) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 315, in assert_qmp ++ result = self.dictpath(d, path) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 274, in dictpath ++ self.fail('failed path traversal for "%s" in "%s"' % (path, str(d))) ++AssertionError: failed path traversal for "return" in "None" ++ ++====================================================================== ++FAIL: test_inet (__main__.QemuNBD) ++---------------------------------------------------------------------- ++Traceback (most recent call last): ++ File "147", line 96, in test_inet ++ flatten_sock_addr(address)) ++ File "147", line 55, in client_test ++ self.assert_qmp(result, 'return', {}) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 315, in assert_qmp ++ result = self.dictpath(d, path) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 274, in dictpath ++ self.fail('failed path traversal for "%s" in "%s"' % (path, str(d))) ++AssertionError: failed path traversal for "return" in "None" ++ ++====================================================================== ++FAIL: test_unix (__main__.QemuNBD) ++---------------------------------------------------------------------- ++Traceback (most recent call last): ++ File "147", line 103, in test_unix ++ flatten_sock_addr(address)) ++ File "147", line 55, in client_test ++ self.assert_qmp(result, 'return', {}) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 315, in assert_qmp ++ result = self.dictpath(d, path) ++ File "/home/nasastry/qemu/tests/qemu-iotests/iotests.py", line 274, in dictpath ++ self.fail('failed path traversal for "%s" in "%s"' % (path, str(d))) ++AssertionError: failed path traversal for "return" in "None" ++ + ---------------------------------------------------------------------- + Ran 6 tests + +-OK ++FAILED (failures=6) +Failures: 147 +Failed 1 of 1 tests + +With out gcov configured, the above test get pass. +export QEMU_PROG=/home/nasastry/qemu/ppc64-softmmu/qemu-system-ppc64 +./check -qcow2 147 +QEMU -- "/home/nasastry/qemu/ppc64-softmmu/qemu-system-ppc64" -nodefaults -machine accel=qtest +QEMU_IMG -- "/home/nasastry/qemu/qemu-img" +QEMU_IO -- "/home/nasastry/qemu/qemu-io" --cache writeback -f qcow2 +QEMU_NBD -- "/home/nasastry/qemu/qemu-nbd" +IMGFMT -- qcow2 (compat=1.1) +IMGPROTO -- file +PLATFORM -- Linux/ppc64le zzfp365-lp1 4.13.0-4.rel.git49564cb.el7.centos.ppc64le +TEST_DIR -- /home/nasastry/qemu/tests/qemu-iotests/scratch +SOCKET_SCM_HELPER -- /home/nasastry/qemu/tests/qemu-iotests/socket_scm_helper + +147 +Passed all 1 tests + +from dmesg: +[81791.481930] qemu-system-ppc[28640]: unhandled signal 11 at 0000000000000004 nip 00007fff9f82f7d4 lr 0000000010e182fc code 30001 +[81791.649081] qemu-system-ppc[28651]: unhandled signal 11 at 0000000000000004 nip 00007fffbd94f7d4 lr 0000000010e182fc code 30001 +[81791.817591] qemu-system-ppc[28660]: unhandled signal 11 at 0000000000000004 nip 00007fff8c1ff7d4 lr 0000000010e182fc code 30001 +[81791.994442] qemu-system-ppc[28669]: unhandled signal 11 at 0000000000000004 nip 00007fffa6f1f7d4 lr 0000000010e182fc code 30001 +[81792.121339] qemu-system-ppc[28678]: unhandled signal 11 at 0000000000000004 nip 00007fffb9abf7d4 lr 0000000010e182fc code 30001 +[81792.205728] qemu-system-ppc[28687]: unhandled signal 11 at 0000000000000004 nip 00007fff8dccf7d4 lr 0000000010e182fc code 30001 + + +from gdb: +(gdb) bt +#0 0x00007fffa4a3f7d4 in __strcmp_power9 () from /lib64/libc.so.6 +#1 0x0000000010e182fc in find_desc_by_name (desc=0x11304690, name=0x3dfce1b0 "server.str") at util/qemu-option.c:166 +#2 0x0000000010e1d814 in qemu_opts_absorb_qdict (opts=0x3e25b1c0, qdict=0x3e0bbd40, errp=0x7fffd055c678) at util/qemu-option.c:1026 +#3 0x0000000010c5b2d0 in nbd_open (bs=0x3dfcaee0, options=0x3e0bbd40, flags=24578, errp=0x7fffd055c760) at block/nbd.c:406 +#4 0x0000000010b454d4 in bdrv_open_driver (bs=0x3dfcaee0, drv=0x11305010 <bdrv_nbd_unix>, node_name=0x0, options=0x3e0bbd40, open_flags=24578, errp=0x7fffd055c930) at block.c:1135 +#5 0x0000000010b46af0 in bdrv_open_common (bs=0x3dfcaee0, file=0x0, options=0x3e0bbd40, errp=0x7fffd055c930) at block.c:1395 +#6 0x0000000010b4ced4 in bdrv_open_inherit (filename=0x0, reference=0x0, options=0x3e0bbd40, flags=40962, parent=0x3dfc4be0, child_role=0x11004bd8 <child_file>, errp=0x7fffd055cb30) at block.c:2615 +#7 0x0000000010b4b60c in bdrv_open_child_bs (filename=0x0, options=0x3dfc8ea0, bdref_key=0x11005870 "file", parent=0x3dfc4be0, child_role=0x11004bd8 <child_file>, allow_none=true, errp=0x7fffd055cb30) at block.c:2314 +#8 0x0000000010b4c9ac in bdrv_open_inherit (filename=0x0, reference=0x0, options=0x3dfc8ea0, flags=8194, parent=0x0, child_role=0x0, errp=0x7fffd055cd48) at block.c:2566 +#9 0x0000000010b4d6f8 in bdrv_open (filename=0x0, reference=0x0, options=0x3e261380, flags=0, errp=0x7fffd055cd48) at block.c:2697 +#10 0x00000000105a4684 in bds_tree_init (bs_opts=0x3e261380, errp=0x7fffd055cd48) at blockdev.c:652 +#11 0x00000000105b5c9c in qmp_blockdev_add (options=0x7fffd055cd58, errp=0x7fffd055cd48) at blockdev.c:3920 +#12 0x00000000105eea88 in qmp_marshal_blockdev_add (args=0x3e25e320, ret=0x7fffd055cec0, errp=0x7fffd055ceb8) at qmp-marshal.c:616 +#13 0x0000000010db4de0 in do_qmp_dispatch (cmds=0x1136b198 <qmp_commands>, request=0x3e25d300, errp=0x7fffd055cf30) at qapi/qmp-dispatch.c:104 +#14 0x0000000010db518c in qmp_dispatch (cmds=0x1136b198 <qmp_commands>, request=0x3e25d300) at qapi/qmp-dispatch.c:131 +#15 0x00000000100c9470 in handle_qmp_command (parser=0x3dfd3350, tokens=0x3dfbef40) at /home/nasastry/qemu/monitor.c:3854 +#16 0x0000000010dc8bcc in json_message_process_token (lexer=0x3dfd3358, input=0x3dfbdc80, type=JSON_RCURLY, x=273, y=0) at qobject/json-streamer.c:105 +#17 0x0000000010e3dc98 in json_lexer_feed_char (lexer=0x3dfd3358, ch=125 '}', flush=false) at qobject/json-lexer.c:323 +#18 0x0000000010e3dfe0 in json_lexer_feed (lexer=0x3dfd3358, buffer=0x7fffd055d2f8 "}", size=1) at qobject/json-lexer.c:373 +#19 0x0000000010dc8d6c in json_message_parser_feed (parser=0x3dfd3350, buffer=0x7fffd055d2f8 "}", size=1) at qobject/json-streamer.c:124 +#20 0x00000000100c99ac in monitor_qmp_read (opaque=0x3dfd32c0, buf=0x7fffd055d2f8 "}", size=1) at /home/nasastry/qemu/monitor.c:3896 +#21 0x0000000010ca9430 in qemu_chr_be_write_impl (s=0x3dfce650, buf=0x7fffd055d2f8 "}", len=1) at chardev/char.c:167 +#22 0x0000000010ca9594 in qemu_chr_be_write (s=0x3dfce650, buf=0x7fffd055d2f8 "}", len=1) at chardev/char.c:179 +#23 0x0000000010cbf154 in tcp_chr_read (chan=0x3dfd2190, cond=G_IO_IN, opaque=0x3dfce650) at chardev/char-socket.c:440 +#24 0x0000000010cf9b1c in qio_channel_fd_source_dispatch (source=0x3e259470, callback=0x10cbee50 <tcp_chr_read>, user_data=0x3dfce650) at io/channel-watch.c:84 +#25 0x00007fffa4f13ab0 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 +#26 0x0000000010ddf918 in glib_pollfds_poll () at util/main-loop.c:214 +#27 0x0000000010ddfcc8 in os_host_main_loop_wait (timeout=-1) at util/main-loop.c:261 +#28 0x0000000010ddfeec in main_loop_wait (nonblocking=0) at util/main-loop.c:515 +#29 0x00000000105d0afc in main_loop () at vl.c:1995 +#30 0x00000000105e5cc4 in main (argc=16, argv=0x7fffd055ed08, envp=0x7fffd055ed90) at vl.c:4899 +(gdb) bt full +#0 0x00007fffa4a3f7d4 in __strcmp_power9 () from /lib64/libc.so.6 +No symbol table info available. +#1 0x0000000010e182fc in find_desc_by_name (desc=0x11304690, name=0x3dfce1b0 "server.str") at util/qemu-option.c:166 + i = 7 +#2 0x0000000010e1d814 in qemu_opts_absorb_qdict (opts=0x3e25b1c0, qdict=0x3e0bbd40, errp=0x7fffd055c678) at util/qemu-option.c:1026 + local_err = 0x0 + state = {opts = 0x3e25b1c0, errp = 0x7fffd055c5b0} + entry = 0x3dfce180 + next = 0x3dfce220 +#3 0x0000000010c5b2d0 in nbd_open (bs=0x3dfcaee0, options=0x3e0bbd40, flags=24578, errp=0x7fffd055c760) at block/nbd.c:406 + s = 0x3e262d70 + opts = 0x3e25b1c0 + local_err = 0x0 + sioc = 0x0 + tlscreds = 0x0 + hostname = 0x0 + ret = -22 + __func__ = "nbd_open" +#4 0x0000000010b454d4 in bdrv_open_driver (bs=0x3dfcaee0, drv=0x11305010 <bdrv_nbd_unix>, node_name=0x0, options=0x3e0bbd40, open_flags=24578, errp=0x7fffd055c930) at block.c:1135 + local_err = 0x0 + ret = 0 + __PRETTY_FUNCTION__ = "bdrv_open_driver" + __func__ = "bdrv_open_driver" +#5 0x0000000010b46af0 in bdrv_open_common (bs=0x3dfcaee0, file=0x0, options=0x3e0bbd40, errp=0x7fffd055c930) at block.c:1395 + ret = 0 + open_flags = 24578 + filename = 0x0 + driver_name = 0x3e25b340 "nbd" + node_name = 0x0 + discard = 0x3e25b460 "unmap" + detect_zeroes = 0x0 + opts = 0x3e25b210 + drv = 0x11305010 <bdrv_nbd_unix> + local_err = 0x0 + __PRETTY_FUNCTION__ = "bdrv_open_common" + __func__ = "bdrv_open_common" +#6 0x0000000010b4ced4 in bdrv_open_inherit (filename=0x0, reference=0x0, options=0x3e0bbd40, flags=40962, parent=0x3dfc4be0, child_role=0x11004bd8 <child_file>, errp=0x7fffd055cb30) at block.c:2615 + ret = 0 + file = 0x0 + bs = 0x3dfcaee0 + drv = 0x11305010 <bdrv_nbd_unix> + drvname = 0x3e0e28c0 "nbd" + backing = 0x0 + local_err = 0x0 + snapshot_options = 0x0 + snapshot_flags = 0 + __PRETTY_FUNCTION__ = "bdrv_open_inherit" + __func__ = "bdrv_open_inherit" +#7 0x0000000010b4b60c in bdrv_open_child_bs (filename=0x0, options=0x3dfc8ea0, bdref_key=0x11005870 "file", parent=0x3dfc4be0, child_role=0x11004bd8 <child_file>, allow_none=true, errp=0x7fffd055cb30) at block.c:2314 + bs = 0x0 + image_options = 0x3dfc9ec0 + bdref_key_dot = 0x3e25ae10 "\220\065\036>" + reference = 0x0 + __PRETTY_FUNCTION__ = "bdrv_open_child_bs" + __func__ = "bdrv_open_child_bs" +#8 0x0000000010b4c9ac in bdrv_open_inherit (filename=0x0, reference=0x0, options=0x3dfc8ea0, flags=8194, parent=0x0, child_role=0x0, errp=0x7fffd055cd48) at block.c:2566 + file_bs = 0x7fffd055cba0 + ret = 0 + file = 0x0 + bs = 0x3dfc4be0 + drv = 0x112ebae0 <bdrv_raw> + drvname = 0x3e0a78b0 "raw" + backing = 0x0 + local_err = 0x0 + snapshot_options = 0x0 + snapshot_flags = 0 + __PRETTY_FUNCTION__ = "bdrv_open_inherit" + __func__ = "bdrv_open_inherit" +---Type <return> to continue, or q <return> to quit--- +#9 0x0000000010b4d6f8 in bdrv_open (filename=0x0, reference=0x0, options=0x3e261380, flags=0, errp=0x7fffd055cd48) at block.c:2697 +No locals. +#10 0x00000000105a4684 in bds_tree_init (bs_opts=0x3e261380, errp=0x7fffd055cd48) at blockdev.c:652 + bdrv_flags = 0 +#11 0x00000000105b5c9c in qmp_blockdev_add (options=0x7fffd055cd58, errp=0x7fffd055cd48) at blockdev.c:3920 + bs = 0x0 + obj = 0x3e261380 + v = 0x3e25a2d0 + qdict = 0x3e261380 + ent = 0x0 + local_err = 0x0 + __func__ = "qmp_blockdev_add" +#12 0x00000000105eea88 in qmp_marshal_blockdev_add (args=0x3e25e320, ret=0x7fffd055cec0, errp=0x7fffd055ceb8) at qmp-marshal.c:616 + err = 0x0 + v = 0x3e0a6e40 + arg = {driver = BLOCKDEV_DRIVER_RAW, has_node_name = true, node_name = 0x3e25a930 "nbd-blockdev", has_discard = false, discard = BLOCKDEV_DISCARD_OPTIONS_IGNORE, has_cache = false, cache = 0x0, has_read_only = false, + read_only = false, has_force_share = false, force_share = false, has_detect_zeroes = false, detect_zeroes = BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF, u = {blkdebug = {image = 0x3e200a70, has_config = false, config = 0x0, + has_align = false, align = 0, has_max_transfer = false, max_transfer = 0, has_opt_write_zero = false, opt_write_zero = 0, has_max_write_zero = false, max_write_zero = 0, has_opt_discard = false, + opt_discard = 0, has_max_discard = false, max_discard = 0, has_inject_error = false, inject_error = 0x0, has_set_state = false, set_state = 0x0}, blkverify = {test = 0x3e200a70, raw = 0x0}, bochs = { + file = 0x3e200a70}, cloop = {file = 0x3e200a70}, dmg = {file = 0x3e200a70}, file = {filename = 0x3e200a70 "\004", has_pr_manager = false, pr_manager = 0x0, has_locking = false, locking = ON_OFF_AUTO_AUTO, + has_aio = false, aio = BLOCKDEV_AIO_OPTIONS_THREADS}, ftp = {url = 0x3e200a70 "\004", has_readahead = false, readahead = 0, has_timeout = false, timeout = 0, has_username = false, username = 0x0, + has_password_secret = false, password_secret = 0x0, has_proxy_username = false, proxy_username = 0x0, has_proxy_password_secret = false, proxy_password_secret = 0x0}, ftps = {url = 0x3e200a70 "\004", + has_readahead = false, readahead = 0, has_timeout = false, timeout = 0, has_username = false, username = 0x0, has_password_secret = false, password_secret = 0x0, has_proxy_username = false, + proxy_username = 0x0, has_proxy_password_secret = false, proxy_password_secret = 0x0, has_sslverify = false, sslverify = false}, gluster = {volume = 0x3e200a70 "\004", path = 0x0, server = 0x0, + has_debug = false, debug = 0, has_logfile = false, logfile = 0x0}, host_cdrom = {filename = 0x3e200a70 "\004", has_pr_manager = false, pr_manager = 0x0, has_locking = false, locking = ON_OFF_AUTO_AUTO, + has_aio = false, aio = BLOCKDEV_AIO_OPTIONS_THREADS}, host_device = {filename = 0x3e200a70 "\004", has_pr_manager = false, pr_manager = 0x0, has_locking = false, locking = ON_OFF_AUTO_AUTO, has_aio = false, + aio = BLOCKDEV_AIO_OPTIONS_THREADS}, http = {url = 0x3e200a70 "\004", has_readahead = false, readahead = 0, has_timeout = false, timeout = 0, has_username = false, username = 0x0, has_password_secret = false, + password_secret = 0x0, has_proxy_username = false, proxy_username = 0x0, has_proxy_password_secret = false, proxy_password_secret = 0x0, has_cookie = false, cookie = 0x0, has_cookie_secret = false, + cookie_secret = 0x0}, https = {url = 0x3e200a70 "\004", has_readahead = false, readahead = 0, has_timeout = false, timeout = 0, has_username = false, username = 0x0, has_password_secret = false, + password_secret = 0x0, has_proxy_username = false, proxy_username = 0x0, has_proxy_password_secret = false, proxy_password_secret = 0x0, has_cookie = false, cookie = 0x0, has_sslverify = false, + sslverify = false, has_cookie_secret = false, cookie_secret = 0x0}, iscsi = {transport = (unknown: 1042287216), portal = 0x0, target = 0x0, has_lun = false, lun = 0, has_user = false, user = 0x0, + has_password_secret = false, password_secret = 0x0, has_initiator_name = false, initiator_name = 0x0, has_header_digest = false, header_digest = QAPI_ISCSI_HEADER_DIGEST_CRC32C, has_timeout = false, + timeout = 0}, luks = {file = 0x3e200a70, has_key_secret = false, key_secret = 0x0}, nbd = {server = 0x3e200a70, has_export = false, export = 0x0, has_tls_creds = false, tls_creds = 0x0}, nfs = { + server = 0x3e200a70, path = 0x0, has_user = false, user = 0, has_group = false, group = 0, has_tcp_syn_count = false, tcp_syn_count = 0, has_readahead_size = false, readahead_size = 0, + has_page_cache_size = false, page_cache_size = 0, has_debug = false, debug = 0}, null_aio = {has_size = 112, size = 0, has_latency_ns = false, latency_ns = 0}, null_co = {has_size = 112, size = 0, + has_latency_ns = false, latency_ns = 0}, parallels = {file = 0x3e200a70}, qcow2 = {file = 0x3e200a70, has_backing = false, backing = 0x0, has_lazy_refcounts = false, lazy_refcounts = false, + has_pass_discard_request = false, pass_discard_request = false, has_pass_discard_snapshot = false, pass_discard_snapshot = false, has_pass_discard_other = false, pass_discard_other = false, + has_overlap_check = false, overlap_check = 0x0, has_cache_size = false, cache_size = 0, has_l2_cache_size = false, l2_cache_size = 0, has_refcount_cache_size = false, refcount_cache_size = 0, + has_cache_clean_interval = false, cache_clean_interval = 0, has_encrypt = false, encrypt = 0x0}, qcow = {file = 0x3e200a70, has_backing = false, backing = 0x0, has_encrypt = false, encrypt = 0x0}, qed = { + file = 0x3e200a70, has_backing = false, backing = 0x0}, quorum = {has_blkverify = 112, blkverify = 10, children = 0x0, vote_threshold = 0, has_rewrite_corrupted = false, rewrite_corrupted = false, + has_read_pattern = false, read_pattern = QUORUM_READ_PATTERN_QUORUM}, raw = {file = 0x3e200a70, has_offset = false, offset = 0, has_size = false, size = 0}, rbd = {pool = 0x3e200a70 "\004", image = 0x0, + has_conf = false, conf = 0x0, has_snapshot = false, snapshot = 0x0, has_user = false, user = 0x0, has_server = false, server = 0x0}, replication = {file = 0x3e200a70, mode = REPLICATION_MODE_PRIMARY, + has_top_id = false, top_id = 0x0}, sheepdog = {server = 0x3e200a70, vdi = 0x0, has_snap_id = false, snap_id = 0, has_tag = false, tag = 0x0}, ssh = {server = 0x3e200a70, path = 0x0, has_user = false, + user = 0x0}, throttle = {throttle_group = 0x3e200a70 "\004", file = 0x0}, vdi = {file = 0x3e200a70}, vhdx = {file = 0x3e200a70}, vmdk = {file = 0x3e200a70, has_backing = false, backing = 0x0}, vpc = { + file = 0x3e200a70}, vvfat = {dir = 0x3e200a70 "\004", has_fat_type = false, fat_type = 0, has_floppy = false, floppy = false, has_label = false, label = 0x0, has_rw = false, rw = false}, vxhs = { + vdisk_id = 0x3e200a70 "\004", server = 0x0, has_tls_creds = false, tls_creds = 0x0}}} +#13 0x0000000010db4de0 in do_qmp_dispatch (cmds=0x1136b198 <qmp_commands>, request=0x3e25d300, errp=0x7fffd055cf30) at qapi/qmp-dispatch.c:104 + local_err = 0x0 + command = 0x3e25b660 "blockdev-add" + args = 0x3e25e320 + dict = 0x3e25d300 + cmd = 0x3def3920 + ret = 0x0 + __func__ = "do_qmp_dispatch" + __FUNCTION__ = "do_qmp_dispatch" +#14 0x0000000010db518c in qmp_dispatch (cmds=0x1136b198 <qmp_commands>, request=0x3e25d300) at qapi/qmp-dispatch.c:131 + err = 0x0 + ret = 0x3e25d300 + rsp = 0x3e25a950 +#15 0x00000000100c9470 in handle_qmp_command (parser=0x3dfd3350, tokens=0x3dfbef40) at /home/nasastry/qemu/monitor.c:3854 + req = 0x3e25d300 + rsp = 0x0 + id = 0x0 + qdict = 0x3e25d300 + mon = 0x3dfd32c0 + err = 0x0 + __func__ = "handle_qmp_command" +#16 0x0000000010dc8bcc in json_message_process_token (lexer=0x3dfd3358, input=0x3dfbdc80, type=JSON_RCURLY, x=273, y=0) at qobject/json-streamer.c:105 +---Type <return> to continue, or q <return> to quit--- + parser = 0x3dfd3350 + token = 0x3e25a930 + tokens = 0x3dfbef40 +#17 0x0000000010e3dc98 in json_lexer_feed_char (lexer=0x3dfd3358, ch=125 '}', flush=false) at qobject/json-lexer.c:323 + char_consumed = 1 + new_state = 101 + __PRETTY_FUNCTION__ = "json_lexer_feed_char" +#18 0x0000000010e3dfe0 in json_lexer_feed (lexer=0x3dfd3358, buffer=0x7fffd055d2f8 "}", size=1) at qobject/json-lexer.c:373 + err = 0 + i = 0 +#19 0x0000000010dc8d6c in json_message_parser_feed (parser=0x3dfd3350, buffer=0x7fffd055d2f8 "}", size=1) at qobject/json-streamer.c:124 +No locals. +#20 0x00000000100c99ac in monitor_qmp_read (opaque=0x3dfd32c0, buf=0x7fffd055d2f8 "}", size=1) at /home/nasastry/qemu/monitor.c:3896 + old_mon = 0x0 +#21 0x0000000010ca9430 in qemu_chr_be_write_impl (s=0x3dfce650, buf=0x7fffd055d2f8 "}", len=1) at chardev/char.c:167 + be = 0x3dfd32c0 +#22 0x0000000010ca9594 in qemu_chr_be_write (s=0x3dfce650, buf=0x7fffd055d2f8 "}", len=1) at chardev/char.c:179 +No locals. +#23 0x0000000010cbf154 in tcp_chr_read (chan=0x3dfd2190, cond=G_IO_IN, opaque=0x3dfce650) at chardev/char-socket.c:440 + chr = 0x3dfce650 + __func__ = "tcp_chr_read" + s = 0x3dfce650 + buf = "}\000ʁ\377\177\000\000@\000\000\t\377\377\377\377\000\001\000\000\000\000\000\000\240\334\373=\000\000\000\000\300\334\373=\000\000\000\000`\234\364=\000\000\000\000\220\234\364=\000\000\000\000\340\201\375=", '\000' <repeats 12 times>, "pk\020>\000\000\000\000pk\020>\000\000\000\000\240\036\362=", '\000' <repeats 12 times>, "\300l\346=\000\000\000\000\360R\n>\000\000\000\000\370\324U\320\377\177\000\000\b", '\000' <repeats 16 times>, "\355\035\362M=\223~d\343U\320\377\177\000\000\240\323U\320\377\177\000\000\200\343U\320\377\177\000\000\000\251\065\021\002\000\000\000\340\252*\020\000\000\000\000\000\251\065\021\000\000\000\000\060"... + len = 1 + size = 1 +#24 0x0000000010cf9b1c in qio_channel_fd_source_dispatch (source=0x3e259470, callback=0x10cbee50 <tcp_chr_read>, user_data=0x3dfce650) at io/channel-watch.c:84 + func = 0x10cbee50 <tcp_chr_read> + ssource = 0x3e259470 +#25 0x00007fffa4f13ab0 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 +No symbol table info available. +#26 0x0000000010ddf918 in glib_pollfds_poll () at util/main-loop.c:214 + context = 0x3dfc1a50 + pfds = 0x3e25bdf0 +#27 0x0000000010ddfcc8 in os_host_main_loop_wait (timeout=-1) at util/main-loop.c:261 + context = 0x3dfc1a50 + ret = 1 + spin_counter = 0 +#28 0x0000000010ddfeec in main_loop_wait (nonblocking=0) at util/main-loop.c:515 + ret = 1 + timeout = 4294967295 + timeout_ns = -1 +#29 0x00000000105d0afc in main_loop () at vl.c:1995 +No locals. +#30 0x00000000105e5cc4 in main (argc=16, argv=0x7fffd055ed08, envp=0x7fffd055ed90) at vl.c:4899 + i = 1 + snapshot = 0 + linux_boot = 0 + initrd_filename = 0x0 + kernel_filename = 0x0 + kernel_cmdline = 0x10eb5c88 "" + boot_order = 0x10e75568 "" + boot_once = 0x0 + ds = 0x3e21dba0 + cyls = 0 + heads = 0 + secs = 0 + translation = 0 + opts = 0x0 + machine_opts = 0x3defabe0 + hda_opts = 0x0 + icount_opts = 0x0 + accel_opts = 0x0 + olist = 0x1112b3d8 <qemu_machine_opts> + optind = 16 + optarg = 0x7fffd055f359 "accel=qtest" + loadvm = 0x0 +---Type <return> to continue, or q <return> to quit--- + machine_class = 0x3df4fd00 + cpu_model = 0x0 + vga_model = 0x7fffd055f2d4 "none" + qtest_chrdev = 0x7fffd055f2e0 "unix:path=/home/nasastry/qemu/tests/qemu-iotests/scratch/qemu-32241-qtest.sock" + qtest_log = 0x0 + pid_file = 0x0 + incoming = 0x0 + userconfig = true + nographic = false + display_type = DT_NONE + display_remote = 0 + log_mask = 0x0 + log_file = 0x0 + trace_file = 0x0 + maxram_size = 536870912 + ram_slots = 0 + vmstate_dump_file = 0x0 + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = false + dirs = 0x3dfc4b20 + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7fffd055e7d8} + __func__ = "main" + __FUNCTION__ = "main" + +qemu-iotest 194 also fails in the similar stack trace. + +# ./check -qcow2 194 +QEMU -- "/home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64" -nodefaults -machine accel=qtest +QEMU_IMG -- "/home/nasastry/qemu_gcov/qemu-img" +QEMU_IO -- "/home/nasastry/qemu_gcov/qemu-io" --cache writeback -f qcow2 +QEMU_NBD -- "/home/nasastry/qemu_gcov/qemu-nbd" +IMGFMT -- qcow2 (compat=1.1) +IMGPROTO -- file +PLATFORM -- Linux/ppc64le zzfp365-lp1 4.13.0-4.rel.git49564cb.el7.centos.ppc64le +TEST_DIR -- /home/nasastry/qemu_gcov/tests/qemu-iotests/scratch +SOCKET_SCM_HELPER -- /home/nasastry/qemu_gcov/tests/qemu-iotests/socket_scm_helper + +194 1s ... [failed, exit status 1] - output mismatch (see 194.out.bad) +--- /home/nasastry/qemu_gcov/tests/qemu-iotests/194.out 2017-10-09 14:09:04.272726282 +0530 ++++ /home/nasastry/qemu_gcov/tests/qemu-iotests/194.out.bad 2017-10-25 15:13:26.630139740 +0530 +@@ -1,18 +1,18 @@ ++WARNING:qemu:qemu received signal -11: /home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/home/nasastry/qemu_gcov/tests/qemu-iotests/scratch/qemusource-38326-monitor.sock -mon chardev=mon,mode=control -display none -vga none -qtest unix:path=/home/nasastry/qemu_gcov/tests/qemu-iotests/scratch/qemusource-38326-qtest.sock -machine accel=qtest -nodefaults -machine accel=qtest -drive if=virtio,id=drive0,file=/home/nasastry/qemu_gcov/tests/qemu-iotests/scratch/38326-source.img,format=qcow2,cache=writeback + Launching VMs... + Launching NBD server on destination... + {u'return': {}} + {u'return': {}} + Starting `drive-mirror` on source... +-{u'return': {}} ++None + Waiting for `drive-mirror` to complete... +-{u'timestamp': {u'seconds': 'SECS', u'microseconds': 'USECS'}, u'data': {u'device': u'mirror-job0', u'type': u'mirror', u'speed': 0, u'len': 1073741824, u'offset': 1073741824}, u'event': u'BLOCK_JOB_READY'} +-Starting migration... +-{u'return': {}} +-{u'timestamp': {u'seconds': 'SECS', u'microseconds': 'USECS'}, u'data': {u'status': u'setup'}, u'event': u'MIGRATION'} +-{u'timestamp': {u'seconds': 'SECS', u'microseconds': 'USECS'}, u'data': {u'status': u'active'}, u'event': u'MIGRATION'} +-{u'timestamp': {u'seconds': 'SECS', u'microseconds': 'USECS'}, u'data': {u'status': u'completed'}, u'event': u'MIGRATION'} +-Gracefully ending the `drive-mirror` job on source... +-{u'return': {}} +-{u'timestamp': {u'seconds': 'SECS', u'microseconds': 'USECS'}, u'data': {u'device': u'mirror-job0', u'type': u'mirror', u'speed': 0, u'len': 1073741824, u'offset': 1073741824}, u'event': u'BLOCK_JOB_COMPLETED'} +-Stopping the NBD server on destination... +-{u'return': {}} ++Traceback (most recent call last): ++ File "194", line 60, in <module> ++ iotests.log(source_vm.event_wait('BLOCK_JOB_READY'), ++ File "/home/nasastry/qemu_gcov/tests/qemu-iotests/../../scripts/qemu.py", line 319, in event_wait ++ event = self._qmp.pull_event(wait=timeout) ++ File "/home/nasastry/qemu_gcov/tests/qemu-iotests/../../scripts/qmp/qmp.py", line 216, in pull_event ++ self.__get_events(wait) ++ File "/home/nasastry/qemu_gcov/tests/qemu-iotests/../../scripts/qmp/qmp.py", line 128, in __get_events ++ raise QMPConnectError("Error while reading from socket") ++qmp.qmp.QMPConnectError: Error while reading from socket +Failures: 194 +Failed 1 of 1 tests + +I confirmed that my patch http://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg00883.html fixes this bug too. + +The fix was committed: + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=c4365735a7d38f4355c6f77e6670d3972315f7c2 + +commit c4365735a7d38f4355c6f77e6670d3972315f7c2 +Author: Murilo Opsfelder Araujo <email address hidden> +Date: Fri Jan 5 11:32:41 2018 -0200 + + block/nbd: fix segmentation fault when .desc is not null-terminated + diff --git a/results/classifier/zero-shot/108/all/1729623 b/results/classifier/zero-shot/108/all/1729623 new file mode 100644 index 000000000..de22bf456 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1729623 @@ -0,0 +1,326 @@ +debug: 0.988 +graphic: 0.985 +performance: 0.982 +semantic: 0.981 +device: 0.980 +other: 0.978 +vnc: 0.978 +permissions: 0.976 +PID: 0.975 +files: 0.973 +socket: 0.972 +boot: 0.967 +KVM: 0.959 +network: 0.926 + +test-aio-multithread fails with 'Co-routine re-entered recursively' + +git head is at fa73e146250181852c0915aa65df8d54d35485fa + +configure with the following + +./configure --enable-attr --enable-bsd-user --enable-cap-ng\ + --enable-coroutine-pool --enable-crypto-afalg --enable-curl\ + --enable-curses --enable-debug --enable-debug-info\ + --enable-debug-tcg --enable-fdt --enable-gcrypt \ + --enable-gnutls --enable-gprof --enable-gtk \ + --enable-guest-agent --enable-kvm --enable-libiscsi \ + --enable-libssh2 --enable-linux-aio --enable-linux-user \ + --enable-live-block-migration --enable-modules \ + --enable-numa --enable-pie --enable-profiler \ + --enable-qom-cast-debug --enable-rbd --enable-replication \ + --enable-seccomp --enable-smartcard --enable-stack-protector \ + --enable-system --enable-tcg --enable-tcg-interpreter \ + --enable-tools --enable-tpm --enable-trace-backend=ftrace \ + --enable-user --enable-vhost-net --enable-vhost-scsi \ + --enable-vhost-user --enable-vhost-vsock --enable-virtfs \ + --enable-vnc --enable-tpm --enable-vnc-png \ + --enable-vnc-sasl --enable-werror --enable-xfsctl \ + --enable-gcov --enable-debug-stack-usage + +make -j 32 + +make test-aio-multithread V=1 + +... +File '/home/nasastry/qemu/include/qapi/qmp/qobject.h' +No executable lines + +MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} gtester -k --verbose -m=quick tests/test-aio-multithread +TEST: tests/test-aio-multithread... (pid=86877) + /aio/multi/lifecycle: OK + /aio/multi/schedule: Co-routine re-entered recursively +FAIL +GTester: last random seed: R02S681209ce87fc22715b41223212d9f6f0 +(pid=86891) + /aio/multi/mutex/contended: OK + /aio/multi/mutex/handoff: OK + /aio/multi/mutex/mcs: OK + /aio/multi/mutex/pthread: OK +FAIL: tests/test-aio-multithread +make: *** [check-tests/test-aio-multithread] Error 1 + +Full log will be attached. + + + +This try is inspiration from tests/docker/test-full. + +On Thu, Nov 02, 2017 at 03:11:30PM -0000, R.Nageswara Sastry wrote: +> Public bug reported: +> +> git head is at fa73e146250181852c0915aa65df8d54d35485fa +> +> configure with the following +> +> ./configure --enable-attr --enable-bsd-user --enable-cap-ng\ +> --enable-coroutine-pool --enable-crypto-afalg --enable-curl\ +> --enable-curses --enable-debug --enable-debug-info\ +> --enable-debug-tcg --enable-fdt --enable-gcrypt \ +> --enable-gnutls --enable-gprof --enable-gtk \ +> --enable-guest-agent --enable-kvm --enable-libiscsi \ +> --enable-libssh2 --enable-linux-aio --enable-linux-user \ +> --enable-live-block-migration --enable-modules \ +> --enable-numa --enable-pie --enable-profiler \ +> --enable-qom-cast-debug --enable-rbd --enable-replication \ +> --enable-seccomp --enable-smartcard --enable-stack-protector \ +> --enable-system --enable-tcg --enable-tcg-interpreter \ +> --enable-tools --enable-tpm --enable-trace-backend=ftrace \ +> --enable-user --enable-vhost-net --enable-vhost-scsi \ +> --enable-vhost-user --enable-vhost-vsock --enable-virtfs \ +> --enable-vnc --enable-tpm --enable-vnc-png \ +> --enable-vnc-sasl --enable-werror --enable-xfsctl \ +> --enable-gcov --enable-debug-stack-usage +> +> make -j 32 +> +> make test-aio-multithread V=1 +> +> ... +> File '/home/nasastry/qemu/include/qapi/qmp/qobject.h' +> No executable lines +> +> MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} gtester -k --verbose -m=quick tests/test-aio-multithread +> TEST: tests/test-aio-multithread... (pid=86877) +> /aio/multi/lifecycle: OK +> /aio/multi/schedule: Co-routine re-entered recursively +> FAIL + +I cannot reproduce it locally. + +Please run with gdb tests/test-aio-multithread and post the backtrace +when the "Co-routine re-entered recursively" message is printed using +the "thread apply all bt" gdb command. + +Stefan + + +I could re-produce using the following command, + +# MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} gtester -k --verbose -m=quick tests/test-aio-multithread +TEST: tests/test-aio-multithread... (pid=116074) + /aio/multi/lifecycle: OK + /aio/multi/schedule: Co-routine re-entered recursively +FAIL +GTester: last random seed: R02Seb8ebc3a9c10406e7725cdff556c14e4 +(pid=116088) + /aio/multi/mutex/contended: OK + /aio/multi/mutex/handoff: OK + /aio/multi/mutex/mcs: OK + /aio/multi/mutex/pthread: OK +FAIL: tests/test-aio-multithread +[root@zzfp365-lp1 qemu]# echo $? +1 + +No important dmesg messages. + +Trying with gdb + +When I ran only the test case seeing a segfault. +[root@zzfp365-lp1 qemu]# tests/test-aio-multithread +/aio/multi/lifecycle: OK +/aio/multi/schedule: Segmentation fault + +from dmesg: +test-aio-multit[117118]: unhandled signal 11 at 00007fff88a2fe88 nip 00007fff8c08ed24 lr 00007fff8c08ebb0 code 30001 + +from gdb: +# gdb tests/test-aio-multithread core.117109 +GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7 +Copyright (C) 2013 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "ppc64le-redhat-linux-gnu". +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>... +Reading symbols from /home/nasastry/qemu/tests/test-aio-multithread...done. + +warning: core file may not match specified executable file. +[New LWP 117118] +[New LWP 117116] +[New LWP 117109] +[New LWP 117120] +[New LWP 117119] +[New LWP 117117] +[New LWP 117110] +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +Core was generated by `tests/test-aio-multithread '. +Program terminated with signal 11, Segmentation fault. +#0 0x00007fff8c08ed24 in __vmx__longjmp () from /lib64/libc.so.6 +warning: File "/home/nasastry/qemu/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py:/usr/lib/golang/src/pkg/runtime/runtime-gdb.py". +To enable execution of this file add + add-auto-load-safe-path /home/nasastry/qemu/.gdbinit +line to your configuration file "/root/.gdbinit". +To completely disable this security protection add + set auto-load safe-path / +line to your configuration file "/root/.gdbinit". +For more information about this security protection see the +"Auto-loading safe path" section in the GDB manual. E.g., run from the shell: + info "(gdb)Auto-loading safe path" +Missing separate debuginfos, use: debuginfo-install glib2-2.50.3-3.el7.ppc64le glibc-2.17-196.el7.ppc64le gmp-6.0.0-15.el7.ppc64le gnutls-3.3.26-9.el7.ppc64le libaio-0.3.109-13.el7.ppc64le libcap-ng-0.7.5-4.el7.ppc64le libffi-3.0.13-18.el7.ppc64le libgcrypt-1.5.3-14.el7.ppc64le libgpg-error-1.12-3.el7.ppc64le libtasn1-4.10-1.el7.ppc64le nettle-2.7.1-8.el7.ppc64le p11-kit-0.23.5-3.el7.ppc64le pcre-8.32-17.el7.ppc64le zlib-1.2.7-17.el7.ppc64le +(gdb) bt +#0 0x00007fff8c08ed24 in __vmx__longjmp () from /lib64/libc.so.6 +#1 0x00007fff8c08ebb0 in siglongjmp@@GLIBC_2.17 () from /lib64/libc.so.6 +Cannot access memory at address 0x7fff88a2feb0 +(gdb) bt full +#0 0x00007fff8c08ed24 in __vmx__longjmp () from /lib64/libc.so.6 +No symbol table info available. +#1 0x00007fff8c08ebb0 in siglongjmp@@GLIBC_2.17 () from /lib64/libc.so.6 +No symbol table info available. +(gdb) thread apply all bt + +Thread 7 (Thread 0x7fff8bc4edc0 (LWP 117110)): +#0 0x00007fff8c16cdd4 in syscall () from /lib64/libc.so.6 +#1 0x00000001121f2868 in qemu_futex_wait (f=0x11273d74c <rcu_call_ready_event>, val=4294967295) at /home/nasastry/qemu/include/qemu/futex.h:29 +#2 0x00000001121f2e60 in qemu_event_wait (ev=0x11273d74c <rcu_call_ready_event>) at util/qemu-thread-posix.c:442 +#3 0x0000000112229a98 in call_rcu_thread (opaque=0x0) at util/rcu.c:249 +#4 0x00007fff8c248af4 in start_thread () from /lib64/libpthread.so.0 +#5 0x00007fff8c174ef4 in clone () from /lib64/libc.so.6 + +Thread 6 (Thread 0x7fff89c4edc0 (LWP 117117)): +#0 0x00007fff8c1644b0 in ppoll () from /lib64/libc.so.6 +#1 0x00000001121e3414 in qemu_poll_ns (fds=0x7fff7400a850, nfds=1, timeout=-1) at util/qemu-timer.c:322 +#2 0x00000001121eb5f8 in aio_poll (ctx=0x7fff740008c0, blocking=true) at util/aio-posix.c:629 +#3 0x000000011210efa0 in iothread_run (opaque=0x125335600) at tests/iothread.c:51 +#4 0x00007fff8c248af4 in start_thread () from /lib64/libpthread.so.0 +#5 0x00007fff8c174ef4 in clone () from /lib64/libc.so.6 + +Thread 5 (Thread 0x7fff8ac4edc0 (LWP 117119)): +#0 0x00000001121f01a0 in qemu_free_stack (stack=0x7fff88810000, sz=1114112) at util/oslib-posix.c:574 +#1 0x000000011222f738 in qemu_coroutine_delete (co_=0x125336e30) at util/coroutine-ucontext.c:153 +#2 0x000000011222b04c in coroutine_delete (co=0x125336e30) at util/qemu-coroutine.c:102 +#3 0x000000011222b310 in qemu_aio_coroutine_enter (ctx=0x7fff7c0008c0, co=0x125336e30) at util/qemu-coroutine.c:140 +#4 0x000000011222b3ec in qemu_coroutine_enter (co=0x125336e30) at util/qemu-coroutine.c:149 +#5 0x00000001121df09c in co_schedule_bh_cb (opaque=0x7fff7c0008c0) at util/async.c:391 +#6 0x00000001121dd7c8 in aio_bh_call (bh=0x7fff7c008400) at util/async.c:90 +#7 0x00000001121dd990 in aio_bh_poll (ctx=0x7fff7c0008c0) at util/async.c:118 +#8 0x00000001121eba60 in aio_poll (ctx=0x7fff7c0008c0, blocking=true) at util/aio-posix.c:689 +#9 0x000000011210efa0 in iothread_run (opaque=0x125335c00) at tests/iothread.c:51 +#10 0x00007fff8c248af4 in start_thread () from /lib64/libpthread.so.0 +#11 0x00007fff8c174ef4 in clone () from /lib64/libc.so.6 + +Thread 4 (Thread 0x7fff8b44edc0 (LWP 117120)): +#0 0x00000001121f01e0 in qemu_free_stack (stack=0x7fff88700000, sz=1114112) at util/oslib-posix.c:573 +#1 0x000000011222f738 in qemu_coroutine_delete (co_=0x125337130) at util/coroutine-ucontext.c:153 +#2 0x000000011222b04c in coroutine_delete (co=0x125337130) at util/qemu-coroutine.c:102 +#3 0x000000011222b310 in qemu_aio_coroutine_enter (ctx=0x7fff840008c0, co=0x125337130) at util/qemu-coroutine.c:140 +#4 0x000000011222b3ec in qemu_coroutine_enter (co=0x125337130) at util/qemu-coroutine.c:149 +#5 0x00000001121df09c in co_schedule_bh_cb (opaque=0x7fff840008c0) at util/async.c:391 +#6 0x00000001121dd7c8 in aio_bh_call (bh=0x7fff84008400) at util/async.c:90 +#7 0x00000001121dd990 in aio_bh_poll (ctx=0x7fff840008c0) at util/async.c:118 +#8 0x00000001121eba60 in aio_poll (ctx=0x7fff840008c0, blocking=true) at util/aio-posix.c:689 +#9 0x000000011210efa0 in iothread_run (opaque=0x125335f00) at tests/iothread.c:51 +#10 0x00007fff8c248af4 in start_thread () from /lib64/libpthread.so.0 +#11 0x00007fff8c174ef4 in clone () from /lib64/libc.so.6 + +Thread 3 (Thread 0x7fff8cb4b8b0 (LWP 117109)): +#0 0x00007fff8c24a074 in pthread_join () from /lib64/libpthread.so.0 +#1 0x00000001121f3898 in qemu_thread_join (thread=0x125336208) at util/qemu-thread-posix.c:547 +#2 0x000000011210f0ac in iothread_join (iothread=0x125336200) at tests/iothread.c:62 +#3 0x0000000111f5a408 in join_aio_contexts () at tests/test-aio-multithread.c:93 +#4 0x0000000111f5adc0 in test_multi_co_schedule (seconds=1) at tests/test-aio-multithread.c:183 +#5 0x0000000111f5aee8 in test_multi_co_schedule_1 () at tests/test-aio-multithread.c:191 +#6 0x00007fff8c94a3d4 in g_test_run_suite_internal () from /lib64/libglib-2.0.so.0 +#7 0x00007fff8c94a1a8 in g_test_run_suite_internal () from /lib64/libglib-2.0.so.0 +#8 0x00007fff8c94a1a8 in g_test_run_suite_internal () from /lib64/libglib-2.0.so.0 +#9 0x00007fff8c94a788 in g_test_run_suite () from /lib64/libglib-2.0.so.0 +#10 0x00007fff8c94a7c0 in g_test_run () from /lib64/libglib-2.0.so.0 +#11 0x0000000111f5ceb0 in main (argc=1, argv=0x7ffff82b45a8) at tests/test-aio-multithread.c:462 + +Thread 2 (Thread 0x7fff8944edc0 (LWP 117116)): +#0 0x00007fff8c977bb8 in g_mutex_lock () from /lib64/libglib-2.0.so.0 +#1 0x00007fff8c93c090 in private_thread_memory_cleanup () from /lib64/libglib-2.0.so.0 +#2 0x00007fff8c248924 in __nptl_deallocate_tsd () from /lib64/libpthread.so.0 +#3 0x00007fff8c248b00 in start_thread () from /lib64/libpthread.so.0 +#4 0x00007fff8c174ef4 in clone () from /lib64/libc.so.6 + +Thread 1 (Thread 0x7fff8a44edc0 (LWP 117118)): +#0 0x00007fff8c08ed24 in __vmx__longjmp () from /lib64/libc.so.6 +---Type <return> to continue, or q <return> to quit--- +#1 0x00007fff8c08ebb0 in siglongjmp@@GLIBC_2.17 () from /lib64/libc.so.6 +Cannot access memory at address 0x7fff88a2feb0 + + +So the following thread crashed with segfault: As the core file extension matching with this thread -- core.117109 + +Thread 3 (Thread 0x7fff8cb4b8b0 (LWP 117109)): +#0 0x00007fff8c24a074 in pthread_join () from /lib64/libpthread.so.0 +#1 0x00000001121f3898 in qemu_thread_join (thread=0x125336208) at util/qemu-thread-posix.c:547 +#2 0x000000011210f0ac in iothread_join (iothread=0x125336200) at tests/iothread.c:62 +#3 0x0000000111f5a408 in join_aio_contexts () at tests/test-aio-multithread.c:93 +#4 0x0000000111f5adc0 in test_multi_co_schedule (seconds=1) at tests/test-aio-multithread.c:183 +#5 0x0000000111f5aee8 in test_multi_co_schedule_1 () at tests/test-aio-multithread.c:191 +#6 0x00007fff8c94a3d4 in g_test_run_suite_internal () from /lib64/libglib-2.0.so.0 +#7 0x00007fff8c94a1a8 in g_test_run_suite_internal () from /lib64/libglib-2.0.so.0 +#8 0x00007fff8c94a1a8 in g_test_run_suite_internal () from /lib64/libglib-2.0.so.0 +#9 0x00007fff8c94a788 in g_test_run_suite () from /lib64/libglib-2.0.so.0 +#10 0x00007fff8c94a7c0 in g_test_run () from /lib64/libglib-2.0.so.0 +#11 0x0000000111f5ceb0 in main (argc=1, argv=0x7ffff82b45a8) at tests/test-aio-multithread.c:462 + + +But can't run: +gdb --args MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} gtester -k --verbose -m=quick tests/test-aio-multithread +... +gdb) r +Starting program: gtester -k --verbose -m=quick tests/test-aio-multithread +No executable file specified. +Use the "file" or "exec-file" command. + +On Mon, Nov 06, 2017 at 04:57:13AM -0000, R.Nageswara Sastry wrote: +> I could re-produce using the following command, +> +> # MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} gtester -k --verbose -m=quick tests/test-aio-multithread +> TEST: tests/test-aio-multithread... (pid=116074) +> /aio/multi/lifecycle: OK +> /aio/multi/schedule: Co-routine re-entered recursively +> FAIL +> GTester: last random seed: R02Seb8ebc3a9c10406e7725cdff556c14e4 +> (pid=116088) +> /aio/multi/mutex/contended: OK +> /aio/multi/mutex/handoff: OK +> /aio/multi/mutex/mcs: OK +> /aio/multi/mutex/pthread: OK +> FAIL: tests/test-aio-multithread +> [root@zzfp365-lp1 qemu]# echo $? +> 1 +> +> No important dmesg messages. +> +> Trying with gdb + +Thanks, the backtrace was useful. I have sent a patch and CCed you. + +Stefan + + +I confirmed with Stefan and this bug was fixed by https://git.qemu.org/?p=qemu.git;a=commitdiff;h=fb0c43f34eed8b18678c6e1f481d8564b35c99ed + +commit fb0c43f34eed8b18678c6e1f481d8564b35c99ed +Author: Stefan Hajnoczi <email address hidden> +Date: Mon Nov 6 19:02:33 2017 +0000 + + tests-aio-multithread: fix /aio/multi/schedule race condition + diff --git a/results/classifier/zero-shot/108/all/1735384 b/results/classifier/zero-shot/108/all/1735384 new file mode 100644 index 000000000..665a2ba9d --- /dev/null +++ b/results/classifier/zero-shot/108/all/1735384 @@ -0,0 +1,598 @@ +device: 0.973 +permissions: 0.970 +debug: 0.966 +files: 0.963 +other: 0.963 +PID: 0.959 +boot: 0.958 +performance: 0.958 +graphic: 0.956 +semantic: 0.956 +KVM: 0.954 +socket: 0.953 +vnc: 0.941 +network: 0.940 + +OpenJDK JVM segfaults on qemu-sh4 (regression) + +Some of the recent changes introduced a regression which makes the OpenJDK JVM crash on qemu-sh4: + +(sid-sh4-sbuild)root@nofan:/# java -version +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +(sid-sh4-sbuild)root@nofan:/# + +An older version works fine: + +(sid-sh4-sbuild)root@nofan:/# java -version +openjdk version "9.0.1" +OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) +OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) +(sid-sh4-sbuild)root@nofan:/# + +Haven't had time for bisecting this yet. + +Adrian + +This sounds like it may be the bug fixed by this patchset: https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg05067.html + + +On 11/30/2017 01:19 PM, Peter Maydell wrote: +> This sounds like it may be the bug fixed by this patchset: +> https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg05067.html + +Unfortunately not. I will upload a prepared chroot for testing later +and link it in this bug report. + +Adrian + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + +The offending commit is: + +d25f2a72272b9ffe0d06710d6217d1169bc2cc7d is the first bad commit +commit d25f2a72272b9ffe0d06710d6217d1169bc2cc7d +Author: Alex Bennée <email address hidden> +Date: Mon Nov 13 13:55:27 2017 +0000 + + accel/tcg/translate-all: expand cpu_restore_state addr check + + We are still seeing signals during translation time when we walk over + a page protection boundary. This expands the check to ensure the host + PC is inside the code generation buffer. The original suggestion was + to check versus tcg_ctx.code_gen_ptr but as we now segment the + translation buffer we have to settle for just a general check for + being inside. + + I've also fixed up the declaration to make it clear it can deal with + invalid addresses. A later patch will fix up the call sites. + + Signed-off-by: Alex Bennée <email address hidden> + Reported-by: Peter Maydell <email address hidden> + Reviewed-by: Laurent Vivier <email address hidden> + Reviewed-by: Richard Henderson <email address hidden> + Message-id: <email address hidden> + Suggested-by: Paolo Bonzini <email address hidden> + Cc: Richard Henderson <email address hidden> + Tested-by: Peter Maydell <email address hidden> + Signed-off-by: Peter Maydell <email address hidden> + +:040000 040000 da50c4c43089d3ee7d1e9ad50d3c9036114e5f11 cd6a0dcaa1d284fe5439f6f3b61547d4b0662768 M accel +:040000 040000 c294a7c102d27295f8d81cc06b5d4d17357440ad 5a1268b7634f69f0806f22161ec7d6a1a26c8812 M include + +Reverting the commit resolves the issue. + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + + +Thomas Huth <email address hidden> writes: + +> On 01.12.2017 00:25, John Paul Adrian Glaubitz wrote: +>> The offending commit is: +>> +>> d25f2a72272b9ffe0d06710d6217d1169bc2cc7d is the first bad commit +>> commit d25f2a72272b9ffe0d06710d6217d1169bc2cc7d +>> Author: Alex Bennée <email address hidden> +>> Date: Mon Nov 13 13:55:27 2017 +0000 +>> +>> accel/tcg/translate-all: expand cpu_restore_state addr check +>> +>> We are still seeing signals during translation time when we walk over +>> a page protection boundary. This expands the check to ensure the host +>> PC is inside the code generation buffer. The original suggestion was +>> to check versus tcg_ctx.code_gen_ptr but as we now segment the +>> translation buffer we have to settle for just a general check for +>> being inside. +>> +>> I've also fixed up the declaration to make it clear it can deal with +>> invalid addresses. A later patch will fix up the call sites. +>> +>> Signed-off-by: Alex Bennée <email address hidden> +>> Reported-by: Peter Maydell <email address hidden> +>> Reviewed-by: Laurent Vivier <email address hidden> +>> Reviewed-by: Richard Henderson <email address hidden> +>> Message-id: <email address hidden> +>> Suggested-by: Paolo Bonzini <email address hidden> +>> Cc: Richard Henderson <email address hidden> +>> Tested-by: Peter Maydell <email address hidden> +>> Signed-off-by: Peter Maydell <email address hidden> +>> +>> :040000 040000 da50c4c43089d3ee7d1e9ad50d3c9036114e5f11 cd6a0dcaa1d284fe5439f6f3b61547d4b0662768 M accel +>> :040000 040000 c294a7c102d27295f8d81cc06b5d4d17357440ad 5a1268b7634f69f0806f22161ec7d6a1a26c8812 M include +>> +>> Reverting the commit resolves the issue. +>> +> +> Alex, any ideas what might be wrong here? + +It's hard to imagine a scenario where taking the tb_lock() for resolving +something that will fail is going to be an improvement. However maybe +there is a subtle difference with sh4's javavm implementation. + +A backtrace QEMU after the segv would be useful here. + +-- +Alex Bennée + + +On 12/04/2017 10:29 AM, Alex Bennée wrote: +> It's hard to imagine a scenario where taking the tb_lock() for resolving +> something that will fail is going to be an improvement. However maybe +> there is a subtle difference with sh4's javavm implementation. + +So, OpenJDK doesn't have a SH-specific implementation of the JVM, it just +uses the Zero variant, which is a pure C++ implementation of the JVM. + +The same implementation is used on any other architecture like older ARM +(< ARMv7). I just tested it on ARMv4T and it doesn't crash there on +qemu-user. + +However, SH4 is special due to its implementation of atomics in user +space called gUSA for which support to qemu-user has been recently +added by Richard Hendersson. Maybe the problem lies there. + +> A backtrace QEMU after the segv would be useful here. + +I forgot what the proper procedure is for running qemu-user inside +GDB. Could you help me with that? + +The strace looks like this in any case: + +28856 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) +28856 open("/lib/sh4-linux-gnu/libgcc_s.so.1",O_RDONLY|O_CLOEXEC) = 3 +28856 read(3,0x7fffacd4,512) = 512 +28856 fstat64(3,0x7fffabe8) = 0 +28856 mmap(NULL,189084,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7ee27000 +28856 mprotect(0x7ee45000,61440,PROT_NONE) = 0 +28856 mmap(0x7ee54000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1d000) = 0x7ee54000 +28856 close(3) = 0 +28856 mprotect(0x7ee54000,4096,PROT_READ) = 0 +28856 mprotect(0x7eee8000,4096,PROT_READ) = 0 +28856 mprotect(0x7f05c000,20480,PROT_READ) = 0 +28856 mprotect(0x7f5c8000,53248,PROT_READ) = 0 +28856 getpid() = 28856 +28856 munmap(0x7f065000,50134) = 0 +28856 getpid() = 28856 +28856 mmap(NULL,1572864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7eca7000 +28856 mprotect(0x7eca7000,4096,PROT_NONE) = 0 +28856 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7ee26048,parent_tidptr=0x7ee26528,tls=0x7ee26930,child_tidptr=0x7ee26528) = 28860 +28856 futex(0x7ee26528,FUTEX_WAIT,28860,NULL,0x7f77c6e8,2138556136)28856 set_robust_list(2128766256,12,-1,2128766652,-1,2128764832) = -1 errno=38 (Function not implemented) +--- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0x289da000} --- +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +(sid-sh4-sbuild)root@nofan:/local_scratch/sid-sh4-sbuild# + +Adrian + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + + +John Paul Adrian Glaubitz <email address hidden> writes: + +> On 12/04/2017 10:29 AM, Alex Bennée wrote: +>> It's hard to imagine a scenario where taking the tb_lock() for resolving +>> something that will fail is going to be an improvement. However maybe +>> there is a subtle difference with sh4's javavm implementation. +> +> So, OpenJDK doesn't have a SH-specific implementation of the JVM, it just +> uses the Zero variant, which is a pure C++ implementation of the JVM. +> +> The same implementation is used on any other architecture like older ARM +> (< ARMv7). I just tested it on ARMv4T and it doesn't crash there on +> qemu-user. +> +> However, SH4 is special due to its implementation of atomics in user +> space called gUSA for which support to qemu-user has been recently +> added by Richard Hendersson. Maybe the problem lies there. +> +>> A backtrace QEMU after the segv would be useful here. +> +> I forgot what the proper procedure is for running qemu-user inside +> GDB. Could you help me with that? + +Either call directly: + + gdb --args qemu-foo <userspace args> + +Or alternatively: + + qemu-foo -g 1234 <userspace args> + +And then: + + gdb qemu-foo -p <pid of qemu-foo> + +And finally attaching to the gdbstub: + + gdb-multiarch -ex "target remote localhost:1234" + c + +Or just make sure your environment is generating core dumps you can +backtrace at leisure: + + gdb qemu-foo core + bt + + +> +> The strace looks like this in any case: +> +> 28856 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) +> 28856 open("/lib/sh4-linux-gnu/libgcc_s.so.1",O_RDONLY|O_CLOEXEC) = 3 +> 28856 read(3,0x7fffacd4,512) = 512 +> 28856 fstat64(3,0x7fffabe8) = 0 +> 28856 mmap(NULL,189084,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7ee27000 +> 28856 mprotect(0x7ee45000,61440,PROT_NONE) = 0 +> 28856 mmap(0x7ee54000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1d000) = 0x7ee54000 +> 28856 close(3) = 0 +> 28856 mprotect(0x7ee54000,4096,PROT_READ) = 0 +> 28856 mprotect(0x7eee8000,4096,PROT_READ) = 0 +> 28856 mprotect(0x7f05c000,20480,PROT_READ) = 0 +> 28856 mprotect(0x7f5c8000,53248,PROT_READ) = 0 +> 28856 getpid() = 28856 +> 28856 munmap(0x7f065000,50134) = 0 +> 28856 getpid() = 28856 +> 28856 mmap(NULL,1572864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7eca7000 +> 28856 mprotect(0x7eca7000,4096,PROT_NONE) = 0 +> 28856 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7ee26048,parent_tidptr=0x7ee26528,tls=0x7ee26930,child_tidptr=0x7ee26528) = 28860 +> 28856 futex(0x7ee26528,FUTEX_WAIT,28860,NULL,0x7f77c6e8,2138556136)28856 set_robust_list(2128766256,12,-1,2128766652,-1,2128764832) = -1 errno=38 (Function not implemented) +> --- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0x289da000} --- +> qemu: uncaught target signal 11 (Segmentation fault) - core dumped +> Segmentation fault +> (sid-sh4-sbuild)root@nofan:/local_scratch/sid-sh4-sbuild# +> +> Adrian +> +> -- +> .''`. John Paul Adrian Glaubitz +> : :' : Debian Developer - <email address hidden> +> `. `' Freie Universitaet Berlin - <email address hidden> +> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + +-- +Alex Bennée + + + +John Paul Adrian Glaubitz <email address hidden> writes: + +> Public bug reported: +> +> Some of the recent changes introduced a regression which makes the +> OpenJDK JVM crash on qemu-sh4: +> +> (sid-sh4-sbuild)root@nofan:/# java -version +> qemu: uncaught target signal 11 (Segmentation fault) - core dumped +> Segmentation fault +> (sid-sh4-sbuild)root@nofan:/# + +With an --enable-debug build I managed to replicate: + + root@6e10336e48ac:/etc/apt# java --version + qemu-sh4: /home/alex/lsrc/qemu/qemu.git/tcg/tcg.h:703: temp_idx: Assertion `n >= 0 && n < tcg_ctx->nb_temps' failed. + qemu: uncaught target signal 11 (Segmentation fault) - core dumped + Segmentation fault (core dumped) + +Which implies the front end has gotten something wrong. Maybe this +somehow tripped up the fault resolution in the end? Can you try with an +--enable-debug build? + +> +> An older version works fine: +> +> (sid-sh4-sbuild)root@nofan:/# java -version +> openjdk version "9.0.1" +> OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) +> OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) +> (sid-sh4-sbuild)root@nofan:/# +> +> Haven't had time for bisecting this yet. +> +> Adrian +> +> ** Affects: qemu +> Importance: Undecided +> Status: New + + +-- +Alex Bennée + + +On 12/05/2017 04:02 PM, Alex Bennée wrote: +> With an --enable-debug build I managed to replicate: +> +> root@6e10336e48ac:/etc/apt# java --version +> qemu-sh4: /home/alex/lsrc/qemu/qemu.git/tcg/tcg.h:703: temp_idx: Assertion `n >= 0 && n < tcg_ctx->nb_temps' failed. +> qemu: uncaught target signal 11 (Segmentation fault) - core dumped +> Segmentation fault (core dumped) +> +> Which implies the front end has gotten something wrong. Maybe this +> somehow tripped up the fault resolution in the end? Can you try with an +> --enable-debug build? +Will do. Thank you for giving me a heads-up! + +Adrian + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + +This fixes bug #1735384 while running java under qemu-sh4. When debug +was enabled it showed a problem with TCG temps. Once fixed I was able +to run java -version normally. + +Reported-by: John Paul Adrian Glaubitz <email address hidden> +Suggested-by: Richard Henderson <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +--- + target/sh4/translate.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/target/sh4/translate.c b/target/sh4/translate.c +index 703020fe87..b4b5c822d0 100644 +--- a/target/sh4/translate.c ++++ b/target/sh4/translate.c +@@ -2189,7 +2189,7 @@ static int decode_gusa(DisasContext *ctx, CPUSH4State *env, int *pmax_insns) + } + + /* If op_src is not a valid register, then op_arg was a constant. */ +- if (op_src < 0) { ++ if (op_src < 0 && !TCGV_IS_UNUSED(op_arg)) { + tcg_temp_free_i32(op_arg); + } + +-- +2.15.1 + + + +Hi Alex! + +Wow, thanks! I wanted to run your suggested test today as I ran out of time yesterday and now you already fixed it :-). + +Thanks a lot! + +Adrian + +> On Dec 6, 2017, at 10:30 AM, Alex Bennée <email address hidden> wrote: +> +> This fixes bug #1735384 while running java under qemu-sh4. When debug +> was enabled it showed a problem with TCG temps. Once fixed I was able +> to run java -version normally. +> +> Reported-by: John Paul Adrian Glaubitz <email address hidden> +> Suggested-by: Richard Henderson <email address hidden> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> target/sh4/translate.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/target/sh4/translate.c b/target/sh4/translate.c +> index 703020fe87..b4b5c822d0 100644 +> --- a/target/sh4/translate.c +> +++ b/target/sh4/translate.c +> @@ -2189,7 +2189,7 @@ static int decode_gusa(DisasContext *ctx, CPUSH4State *env, int *pmax_insns) +> } +> +> /* If op_src is not a valid register, then op_arg was a constant. */ +> - if (op_src < 0) { +> + if (op_src < 0 && !TCGV_IS_UNUSED(op_arg)) { +> tcg_temp_free_i32(op_arg); +> } +> +> -- +> 2.15.1 +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1735384 +> +> Title: +> OpenJDK JVM segfaults on qemu-sh4 (regression) +> +> Status in QEMU: +> New +> +> Bug description: +> Some of the recent changes introduced a regression which makes the +> OpenJDK JVM crash on qemu-sh4: +> +> (sid-sh4-sbuild)root@nofan:/# java -version +> qemu: uncaught target signal 11 (Segmentation fault) - core dumped +> Segmentation fault +> (sid-sh4-sbuild)root@nofan:/# +> +> An older version works fine: +> +> (sid-sh4-sbuild)root@nofan:/# java -version +> openjdk version "9.0.1" +> OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) +> OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) +> (sid-sh4-sbuild)root@nofan:/# +> +> Haven't had time for bisecting this yet. +> +> Adrian +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1735384/+subscriptions + + + +On 12/06/2017 10:30 AM, Alex Bennée wrote: +> This fixes bug #1735384 while running java under qemu-sh4. When debug +> was enabled it showed a problem with TCG temps. Once fixed I was able +> to run java -version normally. +> +> Reported-by: John Paul Adrian Glaubitz <email address hidden> +> Suggested-by: Richard Henderson <email address hidden> +> Signed-off-by: Alex Bennée <email address hidden> + +I can confirm that this fixes the issue for me, too. + +So, just in case: + +Tested-by: John Paul Adrian Glaubitz <email address hidden> + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + + +John Paul Adrian Glaubitz <email address hidden> writes: + +> Hi Alex! +> +> Wow, thanks! I wanted to run your suggested test today as I ran out of +> time yesterday and now you already fixed it :-). + +Can you confirm you've tested it and your happy it works? + +> +> Thanks a lot! +> +> Adrian +> +>> On Dec 6, 2017, at 10:30 AM, Alex Bennée <email address hidden> wrote: +>> +>> This fixes bug #1735384 while running java under qemu-sh4. When debug +>> was enabled it showed a problem with TCG temps. Once fixed I was able +>> to run java -version normally. +>> +>> Reported-by: John Paul Adrian Glaubitz <email address hidden> +>> Suggested-by: Richard Henderson <email address hidden> +>> Signed-off-by: Alex Bennée <email address hidden> +>> --- +>> target/sh4/translate.c | 2 +- +>> 1 file changed, 1 insertion(+), 1 deletion(-) +>> +>> diff --git a/target/sh4/translate.c b/target/sh4/translate.c +>> index 703020fe87..b4b5c822d0 100644 +>> --- a/target/sh4/translate.c +>> +++ b/target/sh4/translate.c +>> @@ -2189,7 +2189,7 @@ static int decode_gusa(DisasContext *ctx, CPUSH4State *env, int *pmax_insns) +>> } +>> +>> /* If op_src is not a valid register, then op_arg was a constant. */ +>> - if (op_src < 0) { +>> + if (op_src < 0 && !TCGV_IS_UNUSED(op_arg)) { +>> tcg_temp_free_i32(op_arg); +>> } +>> +>> -- +>> 2.15.1 +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/1735384 +>> +>> Title: +>> OpenJDK JVM segfaults on qemu-sh4 (regression) +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> Some of the recent changes introduced a regression which makes the +>> OpenJDK JVM crash on qemu-sh4: +>> +>> (sid-sh4-sbuild)root@nofan:/# java -version +>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped +>> Segmentation fault +>> (sid-sh4-sbuild)root@nofan:/# +>> +>> An older version works fine: +>> +>> (sid-sh4-sbuild)root@nofan:/# java -version +>> openjdk version "9.0.1" +>> OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) +>> OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) +>> (sid-sh4-sbuild)root@nofan:/# +>> +>> Haven't had time for bisecting this yet. +>> +>> Adrian +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1735384/+subscriptions + + +-- +Alex Bennée + + +On 12/06/2017 11:52 AM, Alex Bennée wrote: +>> Wow, thanks! I wanted to run your suggested test today as I ran out of +>> time yesterday and now you already fixed it :-). +> +> Can you confirm you've tested it and your happy it works? + +I already confirmed it, but in case my previous mail got lost: + +Tested-by: John Paul Adrian Glaubitz <email address hidden> + +And, yes, I'm happy it works :-). Can now switch back to using the latest +qemu snapshot for building packages for Debian sh4. + +Adrian + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + +This has been fixed now and Java works fine again on qemu-sh4 on git master: + +(sid-sh4-sbuild)root@nofan:/# java --version +openjdk 10 2018-03-20 +OpenJDK Runtime Environment (build 10+46-Debian-5) +OpenJDK Zero VM (build 10+46-Debian-5, interpreted mode) +(sid-sh4-sbuild)root@nofan:/# + diff --git a/results/classifier/zero-shot/108/all/1738840 b/results/classifier/zero-shot/108/all/1738840 new file mode 100644 index 000000000..4b70ff73d --- /dev/null +++ b/results/classifier/zero-shot/108/all/1738840 @@ -0,0 +1,207 @@ +permissions: 0.959 +other: 0.958 +semantic: 0.957 +graphic: 0.953 +device: 0.953 +performance: 0.950 +debug: 0.942 +files: 0.941 +boot: 0.931 +PID: 0.928 +KVM: 0.927 +socket: 0.922 +vnc: 0.921 +network: 0.913 + +qemu-img convert qcow2 to raw fails on OS X + +I try to convert a image from qcow2 to raw and the result is a not bootable image. +I dont know if it is a bug in qemu-img convert or with the image it self. + +See this error report for better readability: +https://github.com/coreos/bugs/issues/1121#issuecomment-351968518 + +As a reply here they use 2.9.0 version of + + +$ qemu-img -V +qemu-img version 2.11.0 +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +$ uname -v +Darwin Kernel Version 17.2.0 + +$ mount ./ +/dev/disk1s1 on / (apfs, local, journaled) + +$ wget https://beta.release.core-os.net/amd64-usr/current/coreos_production_openstack_image.img.bz2 + +$ date +Fri Dec 14 17:15:57 CET 2017 + +$ bunzip2 coreos_production_openstack_image.img.bz2 + + +$ cp -a coreos_production_openstack_image.img.org coreos_production_openstack_image.img + +$ shasum coreos_production_openstack_image.img.org +ae2119c6f0390dc36f247f7016923ea85de5d8e6 coreos_production_openstack_image.img.org + +$ qemu-img convert -f qcow2 -O raw coreos_production_openstack_image.img.org coreos_production_openstack_image.bin + +$ qemu-system-x86_64 -m 256 -nographic -hda coreos_production_openstack_image.img -boot c +SeaBIOS (version rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org) + + +iPXE (http://ipxe.org) 00:03.0 C980 PCI2.10 PnP PMM+0FF915A0+0FEF15A0 C980 + + + +Booting from Hard Disk... +GRUB loading.... +Welcome to GRUB! +.... + +$ qemu-system-x86_64 -m 256 -nographic -hda coreos_production_openstack_image.bin -boot c + +SeaBIOS (version rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org) + + +iPXE (http://ipxe.org) 00:03.0 C980 PCI2.10 PnP PMM+0FF915A0+0FEF15A0 C980 + + + +Booting from Hard Disk... +Boot failed: not a bootable disk +.... + + +$ head -c 8192 coreos_production_openstack_image.bin | hexdump -C +00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| +* +00002000 + +$ qemu-img info coreos_production_openstack_image.bin +image: coreos_production_openstack_image.bin +file format: raw +virtual size: 8.5G (9116319744 bytes) +disk size: 217M + +$ qemu-img info coreos_production_openstack_image.img +image: coreos_production_openstack_image.img +file format: qcow2 +virtual size: 8.5G (9116319744 bytes) +disk size: 785M +cluster_size: 65536 +Format specific information: + compat: 0.10 + refcount bits: 16 + +The same version works on Ubuntu so it looks like its only the Mac version or the new APFS filesystem. + +We've had APFS bugs before, if memory serves... perhaps something to do with sparse gap handling? + +Do you have the ability to take a "good" conversion of the qcow2 file (made on a non-APFS partition) and compare it against the "bad" conversion? + +Highlighting the differences might inspire some ideas as to where this has gone wrong, but at present I don't have an OSX computer to test this with, personally. + + +I gave it a try here: +http://termbin.com/ufv4 + +Its only the first 4096 bytes. + + + + + + +I tried to make a quick grep of the start of the disk in the "bad" raw image and it does not exist anywhere so there is more ot it then just a offset issue. + +rg -M 20 -a --encoding=ascii '\xeb\x63\x90\x00\x00\x00\x00\x00\x00\x00\x00\x00' coreos_production_openstack_image.bin.apfs +or +rg -M 20 -a --encoding=ascii 'GRUB \x00Geom\x00Hard Disk\x00Read\x00 Error' coreos_production_openstack_image.bin.apfs + +The actual data seams to start here: +$ hexdump -C coreos_production_openstack_image.bin.apfs | head +00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| +* +0cc4f000 48 8b 4c 24 58 48 89 4c 24 08 48 89 44 24 10 e8 |H.L$XH.L$.H.D$..| +0cc4f010 3c a5 c5 ff 48 8b 44 24 18 48 8b 4c 24 20 48 8d |<...H.D$.H.L$ H.| +0cc4f020 15 9b e9 3f 00 48 39 c2 75 22 48 8b 44 24 48 48 |...?.H9.u"H.D$HH| +0cc4f030 8b 00 48 89 44 24 10 48 89 0c 24 66 c7 44 24 08 |..H.D$.H..$f.D$.| +0cc4f040 00 00 e8 c9 00 00 00 e9 70 ff ff ff 48 89 04 24 |........p...H..$| +0cc4f050 48 89 54 24 08 48 8d 05 e4 cf 3e 00 48 89 44 24 |H.T$.H....>.H.D$| +0cc4f060 10 e8 1a f1 bb ff 0f 0b e8 a3 5a c0 ff e9 7e fe |..........Z...~.| +0cc4f070 ff ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc |................| + +and ends here: +261bf040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| +* +21f600000 + +There are som small small zones of zeroes here and there also but not much. + +And the file size seams small and wrong. +$ ls -lah coreos_production_openstack_image.bin.apfs + +$ du -hs coreos_production_openstack_image.bin.apfs + 16M coreos_production_openstack_image.bin.apfs + + + + + + + + + +Adding "-S 0" on the APFS convert only makes the file 8.5Gb but its still "bad". + + +The image apfs2 here is created with "-S 0"and the .bin is a working one generated on a ubuntu machine. + +Strange thing is that this say they are identical: +$ time qemu-img compare -f qcow2 -F raw coreos_production_openstack_image.img.org coreos_production_openstack_image.bin.apfs +Images are identical. + +real 0m0.078s +user 0m0.016s +sys 0m0.054s + +But these are not: +$ time qemu-img compare -f qcow2 -F raw coreos_production_openstack_image.img.org coreos_production_openstack_image.bin.apfs2 +Content mismatch at offset 0! + +real 0m0.026s +user 0m0.009s +sys 0m0.010s + +But hese are identical :) +$ diff coreos_production_openstack_image.bin.apfs coreos_production_openstack_image.bin.apfs2 +$ echo $? +0 + +And of cause these are not identical: +$ diff coreos_production_openstack_image.bin coreos_production_openstack_image.bin.apfs2 +Binary files coreos_production_openstack_image.bin and coreos_production_openstack_image.bin.apfs2 differ + +$ diff coreos_production_openstack_image.bin coreos_production_openstack_image.bin.apfs +Binary files coreos_production_openstack_image.bin and coreos_production_openstack_image.bin.apfs differ + + + + + +In the termbin: + +So the "good" one is on the left, and the "bad" one is on the right. The bad one is ... completely blank for the first 200+ MB? That's not great. + +so: +.bin.apfs: broken raw file, made on apfs, no arguments(?) +.bin.apfs2: broken raw file, made on apfs, `-S 0` ? +.img.org: qcow2 file (original/working?) +.bin: working raw file, made on Ubuntu? + +Do I have that right? + diff --git a/results/classifier/zero-shot/108/all/1739378 b/results/classifier/zero-shot/108/all/1739378 new file mode 100644 index 000000000..8af858cad --- /dev/null +++ b/results/classifier/zero-shot/108/all/1739378 @@ -0,0 +1,97 @@ +other: 0.986 +debug: 0.985 +semantic: 0.980 +graphic: 0.976 +performance: 0.975 +device: 0.975 +PID: 0.974 +boot: 0.965 +socket: 0.955 +files: 0.955 +permissions: 0.954 +vnc: 0.950 +network: 0.949 +KVM: 0.918 + +migration state save/load of sdcard device is broken + +I'm having different issues trying to have QEMU snapshots working using qemu-system-arm with vexpress-a15 board. + +In this opportunity, I'm trying the git master head version: +# git rev-parse HEAD +af352675efb7e92a1f5f6461a042a12015ab3d12 + +$ /usr/local/bin/qemu-system-arm -kernel kernel/vmlinuz-4.10.0-42-generic -initrd kernel/initrd.img-4.10.0-42-generic -M vexpress-a15 -m 2048 -append 'root=/dev/mmcblk0 rootwait console=tty0' -sd vexpress-4G.qcow2 -dtb device-tree/vexpress-v2p-ca15-tc1.dtb +audio: Could not init `oss' audio driver + +Later on, when the machine finishes booting I savevm ss and quit. However, when I try to restore it, I have that Missing section footer error: + +$ /usr/local/bin/qemu-system-arm -kernel kernel/vmlinuz-4.10.0-42-generic -initrd kernel/initrd.img-4.10.0-42-generic -M vexpress-a15 -m 2048 -append 'root=/dev/mmcblk0 rootwait console=tty0' -sd vexpress-4G.qcow2 -dtb device-tree/vexpress-v2p-ca15-tc1.dtb -loadvm ss +audio: Could not init `oss' audio driver +qemu-system-arm: Missing section footer for sd-card +qemu-system-arm: Error -22 while loading VM state + + +OS: Ubuntu 16.04.3 LTS (xenial) + +$ gcc --version +gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609 + +I've also tried a different ./configure line, explicitly enabling some of the features, i.e. smartcard, with the same results: + +./configure '--disable-user' '--enable-system' '--enable-linux-user' '--enable-modules' '--enable-linux-aio' '--audio-drv-list=pa' '--enable-attr' '--enable-brlapi' '--enable-virtfs' '--enable-cap-ng' '--enable-curl' '--enable-fdt' '--enable-gnutls' '--disable-gtk' '--disable-vte' '--enable-libiscsi' '--enable-curses' '--enable-smartcard' '--enable-rbd' '--enable-vnc-sasl' '--enable-seccomp' '--enable-spice' '--enable-libusb' '--enable-usb-redir' '--enable-xfsctl' '--enable-vnc' '--enable-vnc-jpeg' '--enable-vnc-png' '--enable-kvm' '--enable-vhost-net' + +How have I built it? +# git clone git://git.qemu.org/qemu.git +# cd qemu +# git submodule update --init --checkout +# make clean && ./configure --target-list=arm-softmmu && make -j8 +# sudo make install + +As a reference, and just in case these may be in some way related, I've just submitted another ticket for a different issue with snapshots using Ubuntu Qemu version (https://bugs.launchpad.net/qemu/+bug/1739371) + +Cheers, +Gus + + + +From a quick look my guess would be the wpgrps_size in sd_vmstate is different on the source and destination for some reason - it's the only thing that seems to be variable. +(It could also be whether the subsection is transmitted or not, but that's supposed to sort itself out automatically). + +So, it should be only related to SD? Which virtual device/storage backend do you recommend for snapshots? + + +On 20 December 2017 at 18:44, Dr. David Alan Gilbert +<email address hidden> wrote: +> From a quick look my guess would be the wpgrps_size in sd_vmstate is +> different on the source and destination for some reason + +Good guess: I added a pre_save hook to sdcard.c's vmstate, +which reports wpgrps_size as 201, but in the pre_load hook +it is reported as 0. + +This seems to be because nothing ever calls the sd_reset() +function. I suspect this is down to the "legacy" handling +of sd card setup in sd_init(), or possibly the generic handling +of reset for devices that connect to SD buses. + +(sd_reset() eventually gets called when the guest OS +probes the SD controller and issues a card reset command, +which is why it's correctly set by the time we do a vmsave.) + +thanks +-- PMM + + +I think the sd card migration issue should be fixed by http://patchwork.ozlabs.org/patch/857554/ + +NB that you'll also need to use "-machine secure=off" on the command line, as there's a second bug where we don't successfully migrate with trustzone emulation enabled (which is the default now). + + +Finally I could test it. Yeah man, awesome, that did the trick. It is working like a charm. +You can close the ticket. +Thanks + +The patch has been merged here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0cb57cc701839e7358918 + diff --git a/results/classifier/zero-shot/108/all/1741718 b/results/classifier/zero-shot/108/all/1741718 new file mode 100644 index 000000000..7e3d58831 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1741718 @@ -0,0 +1,227 @@ +device: 0.976 +permissions: 0.972 +debug: 0.970 +other: 0.970 +network: 0.965 +socket: 0.962 +boot: 0.958 +files: 0.957 +vnc: 0.952 +semantic: 0.951 +PID: 0.948 +graphic: 0.946 +performance: 0.945 +KVM: 0.938 + +qemu-system-sparc64: "panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found" with tribblix-sparc-0m16.iso + +qemu-system-sparc64 Niagara VM running Tribblix crashes with "panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found" on QEMU 2.11.0. Happens also with 1 GB, 4 GB, and 8 GB of RAM. + +$ qemu-system-sparc64 -nographic -M niagara -L /home/newman/Downloads/OpenSPARCT1_Arch.1.5/S10image/ -drive if=pflash,readonly=on,file=/home/newman/Downloads/tribblix-sparc-0m16.iso -m 2048 +cpu Probing I/O buses + + +Sun Fire T2000, No Keyboard +Copyright 2005 Sun Microsystems, Inc. All rights reserved. +OpenBoot 4.20.0, 256 MB memory available, Serial #1122867. +[mo23723 obp4.20.0 #0] +Ethernet address 0:80:3:de:ad:3, Host ID: 80112233. + + + +ok boot +Boot device: vdisk File and args: +hsfs-file-system +Loading: /platform/sun4v/boot_archive +ramdisk-root ufs-file-system +Loading: /platform/sun4v/kernel/sparcv9/unix +\ +panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found + +Warning - stack not written to the dumpbuf +000000000180b710 unix:lgrp_traverse+120 (fff32000, 10d5f30, 2000, 7efefeff, 81010100, ff00) + %l0-3: 0000000001876c00 ffffffffffffffff 00000000010d6c00 0000000000000000 + %l4-7: 800000008f000740 800000008fc54750 00000000f0254cc4 00000000010dedd0 +000000000180b800 unix:plat_lgrp_init+14 (4, 180e000, 4, 0, 180b950, 1) + %l0-3: 00000000fff32000 00000000fff340e0 00000000fff34590 00000000010d5f28 + %l4-7: 0000000000000016 0000000000000000 0000000000000016 0000000000000011 +000000000180b8b0 unix:lgrp_plat_init+74 (0, 0, 0, 180ba08, 180ba00, 91) + %l0-3: 0000000000002000 00000000fff34000 0000000001874c00 0000000001874c00 + %l4-7: 0000000000000000 0000000001874c00 000000000180b950 00000000010de048 +000000000180b960 unix:lgrp_init+4 (0, 2000, 70002000, 0, 180c0e8, 0) + %l0-3: 000000000180e380 000000000183c678 000000000180ba08 00000000010d4f90 + %l4-7: 00000000010d4fa0 00000000010d1c00 0000000000004000 0000000080001070 +000000000180ba10 unix:mlsetup+2f4 (180bb80, 180bec0, 0, 0, f025496c, 0) + %l0-3: 00000000018ee000 0000000070002000 0000000070002000 000000000180bad0 + %l4-7: 000000000190c4d8 00000001001f56e0 0000000000000000 0000000080001070 + + +ERROR: Last Trap: Level 14 Interrupt +[Exception handlers interrupted, please file a bug] +[type 'resume' to attempt a normal recovery] + + +Without "if=pflash" VM hangs: + +$ qemu-system-sparc64 -nographic -M niagara -L /home/newman/Downloads/OpenSPARCT1_Arch.1.5/S10image/ -drive readonly=on,file=/home/newman/Downloads/tribblix-sparc-0m16.iso -m 4096 +cpu Probing I/O buses + + +Sun Fire T2000, No Keyboard +Copyright 2005 Sun Microsystems, Inc. All rights reserved. +OpenBoot 4.20.0, 256 MB memory available, Serial #1122867. +[mo23723 obp4.20.0 #0] +Ethernet address 0:80:3:de:ad:3, Host ID: 80112233. + + + +ok boot +Boot device: vdisk File and args: +qemu: fatal: Trap 0x0032 while trap level (6) >= MAXTL (6), Error state +pc: 000000000040f01c npc: 000000000040f020 +%g0-3: 0000000000000000 0000000000000000 0000000000000000 0000009700000280 +%g4-7: 0000000000001000 0000000000000000 0000000000000000 0000000000000000 +%o0-3: 0000000000000000 000000008ffd6000 0000000000008000 0000000000000000 +%o4-7: 0000000000000000 00000000000000f0 00000000fff55701 00000000f020d78c +%l0-3: 000000000002fd10 7ffffffffffffffe 8000000000000000 0000000000000000 +%l4-7: 000000000000000b 800000008fffa750 00000000f026fbf0 00000000f022a0d8 +%i0-3: 0000000080000000 0000000010000000 0000000000000000 0000000000000000 +%i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +pstate: 00000014 ccr: 11 (icc: ---C xcc: ---C) asi: 20 tl: 6 pil: d gl: 6 +tbr: 00000000f0200000 hpstate: 0000000000000004 htba: 0000000000400000 +cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 7 cwp: 0 +fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000004 + +Verified same issue occurs on latest qemu. + +~/qemu qemu-system-sparc64 -version +QEMU emulator version 5.1.90 (v5.2.0-rc0-20-g3c8c36c908) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + + ~/qemu qemu-system-sparc64 -nographic -M niagara -L niagara/S10image/ -drive if=pflash,readonly=on,file=./tribblix-sparc-0m16.iso -m 2048 +cpu Probing I/O buses + + +Sun Fire T2000, No Keyboard +Copyright 2005 Sun Microsystems, Inc. All rights reserved. +OpenBoot 4.20.0, 256 MB memory available, Serial #1122867. +[mo23723 obp4.20.0 #0] +Ethernet address 0:80:3:de:ad:3, Host ID: 80112233. + + + +ok boot +Boot device: vdisk File and args: +hsfs-file-system +Loading: /platform/sun4v/boot_archive +ramdisk-root ufs-file-system +Loading: /platform/sun4v/kernel/sparcv9/unix +\ +panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found + +Warning - stack not written to the dumpbuf +000000000180b710 unix:lgrp_traverse+120 (fff32000, 10d5f30, 2000, 7efefeff, 81010100, ff00) + %l0-3: 0000000001876c00 ffffffffffffffff 00000000010d6c00 0000000000000000 + %l4-7: 800000008f000740 800000008fc54750 00000000f0254cc4 00000000010dedd0 +000000000180b800 unix:plat_lgrp_init+14 (4, 180e000, 4, 0, 180b950, 1) + %l0-3: 00000000fff32000 00000000fff340e0 00000000fff34590 00000000010d5f28 + %l4-7: 0000000000000016 0000000000000000 0000000000000016 0000000000000011 +000000000180b8b0 unix:lgrp_plat_init+74 (0, 0, 0, 180ba08, 180ba00, 91) + %l0-3: 0000000000002000 00000000fff34000 0000000001874c00 0000000001874c00 + %l4-7: 0000000000000000 0000000001874c00 000000000180b950 00000000010de048 +000000000180b960 unix:lgrp_init+4 (0, 2000, 70002000, 0, 180c0e8, 0) + %l0-3: 000000000180e380 000000000183c678 000000000180ba08 00000000010d4f90 + %l4-7: 00000000010d4fa0 00000000010d1c00 0000000000004000 0000000080001070 +000000000180ba10 unix:mlsetup+2f4 (180bb80, 180bec0, 0, 0, f025496c, 0) + %l0-3: 00000000018ee000 0000000070002000 0000000070002000 000000000180bad0 + %l4-7: 000000000190c4d8 00000001001f56e0 0000000000000000 0000000080001070 + + +ERROR: Last Trap: Level 14 Interrupt +[Exception handlers interrupted, please file a bug] +[type 'resume' to attempt a normal recovery] +ok + + +Without if=pflash it now crashes: + +✘ ~/qemu qemu-system-sparc64 -nographic -M niagara -L niagara/S10image/ -drive readonly=on,file=./tribblix-sparc-0m16.iso -m 4096 +cpu Probing I/O buses + + +Sun Fire T2000, No Keyboard +Copyright 2005 Sun Microsystems, Inc. All rights reserved. +OpenBoot 4.20.0, 256 MB memory available, Serial #1122867. +[mo23723 obp4.20.0 #0] +Ethernet address 0:80:3:de:ad:3, Host ID: 80112233. + + + +ok boot +Boot device: vdisk File and args: +qemu: fatal: Trap 0x0032 while trap level (6) >= MAXTL (6), Error state +pc: 000000000040f02c npc: 000000000040f030 +%g0-3: 0000000000000000 0000000000000000 0000000000000000 0000009700000280 +%g4-7: 0000000000001000 0000000000000000 0000000000000000 0000000000000000 +%o0-3: 0000000000000000 000000008ffd6000 0000000000008000 0000000000000000 +%o4-7: 0000000000000000 00000000000000f0 00000000fff55701 00000000f020d78c +%l0-3: 000000000002fd10 7ffffffffffffffe 8000000000000000 0000000000000000 +%l4-7: 000000000000000b 800000008fffa750 00000000f026fbf0 00000000f022a0d8 +%i0-3: 0000000080000000 0000000010000000 0000000000000000 0000000000000000 +%i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +pstate: 00000014 ccr: 11 (icc: ---C xcc: ---C) asi: 20 tl: 6 pil: d gl: 6 +tbr: 00000000f0200000 hpstate: 0000000000000004 htba: 0000000000400000 +cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 7 cwp: 0 +fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000004 + +fish: “qemu-system-sparc64 -nographic…” terminated by signal SIGABRT (Abort) + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1759264 b/results/classifier/zero-shot/108/all/1759264 new file mode 100644 index 000000000..68e9ea68f --- /dev/null +++ b/results/classifier/zero-shot/108/all/1759264 @@ -0,0 +1,233 @@ +permissions: 0.972 +performance: 0.970 +device: 0.969 +semantic: 0.967 +other: 0.964 +PID: 0.964 +debug: 0.964 +graphic: 0.964 +vnc: 0.963 +boot: 0.959 +socket: 0.959 +files: 0.944 +KVM: 0.937 +network: 0.918 + +fpu/softfloat: round_to_int_and_pack refactor broke TriCore ftoi insns + +After the refactor from ab52f973a504f8de0c5df64631ba4caea70a7d9e the bahaviour of int32_to_float32() was altered. + +helper_ftoi() in target/tricore/fpu_helper.c relied on int32_to_float32 to raise the invalid flag if the input was NaN to properly return 0. Likewise if the input is infinity. + +The obvious fix for softfloat would be to raise this flag in round_to_int_and_pack(). However, +I'm not sure if this breaks other targets and I have no easy way to test it. + +Yeah it looks like it was missed, the round_to_uint code does it. + +Do you have a test case I can verify? + +On 04/10/2018 10:07 PM, Alex Bennée wrote: +> Yeah it looks like it was missed, the round_to_uint code does it. +> +> Do you have a test case I can verify? +> + +For the NaN input 0xffffffff the expected result for the flags is that +flag_invalid is raised. + +I can provide you with some TriCore asm, but it is a bit of pain to get +the gnu assembler to build, since the public version is a decade old. + +Cheers, +Bastian + + + +Bastian Koppelmann <email address hidden> writes: + +> On 04/10/2018 10:07 PM, Alex Bennée wrote: +>> Yeah it looks like it was missed, the round_to_uint code does it. +>> +>> Do you have a test case I can verify? +>> +> +> For the NaN input 0xffffffff the expected result for the flags is that +> flag_invalid is raised. +> +> I can provide you with some TriCore asm, but it is a bit of pain to get +> the gnu assembler to build, since the public version is a decade old. + +I'll trust you if you send me a static binary for this particular +verification ;-) + +It would be nice to TriCore tests building in tests/tcg/ but I guess we +need an up to date cross compile environment somewhere. + +> +> Cheers, +> Bastian + + +-- +Alex Bennée + + +On 04/11/2018 01:01 PM, Alex Bennée wrote: +> +> Bastian Koppelmann <email address hidden> writes: +> +>> On 04/10/2018 10:07 PM, Alex Bennée wrote: +>>> Yeah it looks like it was missed, the round_to_uint code does it. +>>> +>>> Do you have a test case I can verify? +>>> +>> +>> For the NaN input 0xffffffff the expected result for the flags is that +>> flag_invalid is raised. +>> +>> I can provide you with some TriCore asm, but it is a bit of pain to get +>> the gnu assembler to build, since the public version is a decade old. +> +> I'll trust you if you send me a static binary for this particular +> verification ;-) +> +> It would be nice to TriCore tests building in tests/tcg/ but I guess we +> need an up to date cross compile environment somewhere. + +That is the problem. There is a gcc/binutils port done by some german +company. And it's not easy to get the source. The one they provide is +pretty old and needs some patching to get in building on modern +machines. Right now I'm trying to set up a test environment. + +Cheers, +Bastian + + +On 04/11/2018 01:01 PM, Alex Bennée wrote: +> Bastian Koppelmann <email address hidden> writes: +> +>> On 04/10/2018 10:07 PM, Alex Bennée wrote: +>>> Yeah it looks like it was missed, the round_to_uint code does it. +>>> +>>> Do you have a test case I can verify? +>>> +>> +>> For the NaN input 0xffffffff the expected result for the flags is that +>> flag_invalid is raised. +>> +>> I can provide you with some TriCore asm, but it is a bit of pain to get +>> the gnu assembler to build, since the public version is a decade old. +> +> I'll trust you if you send me a static binary for this particular +> verification ;-) + +I set up a github repo with working binutils and the corresponding testcase: + +https://github.com/bkoppelmann/tricore-fpu + +The one caveat is, that we cannot produce any binaries with the TriCore +ISA > 1.3. + +In this testcase the last ftoi instruction is supposed to raise the +invalid flag and return 0 since the input was NaN. We did that by only +checking for NaN if any flag was raised after ftoi, then do the NaN +check, and if positive, return 0. + +Cheers, +Bastian + + + +Bastian Koppelmann <email address hidden> writes: + +> On 04/11/2018 01:01 PM, Alex Bennée wrote: +>> Bastian Koppelmann <email address hidden> writes: +>> +>>> On 04/10/2018 10:07 PM, Alex Bennée wrote: +>>>> Yeah it looks like it was missed, the round_to_uint code does it. +>>>> +>>>> Do you have a test case I can verify? +>>>> +>>> +>>> For the NaN input 0xffffffff the expected result for the flags is that +>>> flag_invalid is raised. +>>> +>>> I can provide you with some TriCore asm, but it is a bit of pain to get +>>> the gnu assembler to build, since the public version is a decade old. +>> +>> I'll trust you if you send me a static binary for this particular +>> verification ;-) +> +> I set up a github repo with working binutils and the corresponding +> testcase: +> +> https://github.com/bkoppelmann/tricore-fpu +> +> The one caveat is, that we cannot produce any binaries with the TriCore +> ISA > 1.3. +> +> In this testcase the last ftoi instruction is supposed to raise the +> invalid flag and return 0 since the input was NaN. We did that by only +> checking for NaN if any flag was raised after ftoi, then do the NaN +> check, and if positive, return 0. + +Well it builds and I get an fpu-test.elf but I'm a bit stuck on how to +run it. What are the runes for launching the test? + +> +> Cheers, +> Bastian + + +-- +Alex Bennée + + +On 04/12/2018 03:41 PM, Alex Bennée wrote: +> Bastian Koppelmann <email address hidden> writes: +> +>> On 04/11/2018 01:01 PM, Alex Bennée wrote: +>>> Bastian Koppelmann <email address hidden> writes: +>>> +>>>> On 04/10/2018 10:07 PM, Alex Bennée wrote: +>>>>> Yeah it looks like it was missed, the round_to_uint code does it. +>>>>> +>>>>> Do you have a test case I can verify? +>>>>> +>>>> +>>>> For the NaN input 0xffffffff the expected result for the flags is that +>>>> flag_invalid is raised. +>>>> +>>>> I can provide you with some TriCore asm, but it is a bit of pain to get +>>>> the gnu assembler to build, since the public version is a decade old. +>>> +>>> I'll trust you if you send me a static binary for this particular +>>> verification ;-) +>> +>> I set up a github repo with working binutils and the corresponding +>> testcase: +>> +>> https://github.com/bkoppelmann/tricore-fpu +>> +>> The one caveat is, that we cannot produce any binaries with the TriCore +>> ISA > 1.3. +>> +>> In this testcase the last ftoi instruction is supposed to raise the +>> invalid flag and return 0 since the input was NaN. We did that by only +>> checking for NaN if any flag was raised after ftoi, then do the NaN +>> check, and if positive, return 0. +> +> Well it builds and I get an fpu-test.elf but I'm a bit stuck on how to +> run it. What are the runes for launching the test? + +qemu-system-tricore -M tricore_testboard -kernel fpu-test.elf -nographic + +However, this is not really a test. I usually run these against +Infineons golden (sadly proprietary) simulator and compare register +dumps. I have some more regression tests but I haven't had the time make +them into proper tests, such that we don't need this golden model. + +Cheers, +Bastian + + diff --git a/results/classifier/zero-shot/108/all/1762179 b/results/classifier/zero-shot/108/all/1762179 new file mode 100644 index 000000000..2b4b3f984 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1762179 @@ -0,0 +1,105 @@ +permissions: 0.972 +files: 0.964 +debug: 0.964 +performance: 0.963 +vnc: 0.962 +socket: 0.961 +semantic: 0.958 +network: 0.958 +graphic: 0.957 +PID: 0.955 +other: 0.954 +device: 0.952 +KVM: 0.950 +boot: 0.930 + +Record and replay replay fails with: "ERROR:replay/replay-time.c:49:replay_read_clock: assertion failed" + +QEMU master at 08e173f29461396575c85510eb41474b993cb1fb + +QEMU commands: + + +``` +#!/usr/bin/env bash +cmd="\ +time \ +./out/x86_64/buildroot/host/usr/bin/qemu-system-x86_64 \ +-M pc \ +-append 'root=/dev/sda console=ttyS0 nokaslr printk.time=y - lkmc_eval=\"/rand_check.out;/sbin/ifup -a;wget -S google.com;/poweroff.out;\"' \ +-kernel 'out/x86_64/buildroot/images/bzImage' \ +-nographic \ +\ +-drive file=out/x86_64/buildroot/images/rootfs.ext2.qcow2,if=none,id=img-direct,format=qcow2 \ +-drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \ +-device ide-hd,drive=img-blkreplay \ +\ +-netdev user,id=net1 \ +-device rtl8139,netdev=net1 \ +-object filter-replay,id=replay,netdev=net1 \ +" +echo "$cmd" +eval "$cmd -icount 'shift=7,rr=record,rrfile=replay.bin'" +eval "$cmd -icount 'shift=7,rr=replay,rrfile=replay.bin'" +``` + +Images uploaded to: https://github.com/cirosantilli/linux-kernel-module-cheat/releases/download/test-replay-arm/images4.zip + +The replay failed straight out with: + +``` +ERROR:replay/replay-time.c:49:replay_read_clock: assertion failed: (replay_file && replay_mutex_locked()) +``` + +Images generated with: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/9513c162ef57e6cb70006dfe870856f94ee9a133 + +QEMU configure: + +``` +cd /home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/build/host-qemu-custom; PATH="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin:/home/ciro/bak/git/linux-kernel-modul +e-cheat/out/x86_64/buildroot/host/sbin:./node_modules/.bin:/usr/local/heroku/bin:/home/ciro/android-sdk/platform-tools:/home/ciro/android-sdk/tools:/home/ciro/android-studio//bin:/home/ciro/android-sdk/ndk-bundl +e:/home/ciro/android-sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin:/home/ciro/bak/git/devbin:/home/ciro/bin:/usr/local/texlive/2013/bin/x86_64-linux:/home/ciro/.rvm/gems/ruby-2.4. +1/bin:/home/ciro/.rvm/gems/ruby-2.4.1@global/bin:/home/ciro/.rvm/rubies/ruby-2.4.1/bin:./node_modules/.bin:/usr/local/heroku/bin:/home/ciro/android-sdk/platform-tools:/home/ciro/android-sdk/tools:/home/ciro/andr +oid-studio//bin:/home/ciro/android-sdk/ndk-bundle:/home/ciro/android-sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin:/home/ciro/bak/git/devbin:/home/ciro/bin:/usr/local/texlive/2013 +/bin/x86_64-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/bin:/snap/bin:/home/ciro/bak/git/latex:/home/ciro/.rvm/bin:/home/ciro/anaconda2/bin:/home/ciro/.cab +al/bin:/bin:/home/ciro/.go/bin:/home/ciro/.local/bin/:/home/ciro/bak/git/runlinux:/usr/bin:/home/ciro/bak/git/latex:/home/ciro/.rvm/bin:/home/ciro/anaconda2/bin:/home/ciro/.cabal/bin:/bin:/home/ciro/.go/bin:/home/ciro/.local/bin/:/home/ciro/bak/git/runlinux" PKG_CONFIG="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin/pkg-config" PKG_CONFIG_SYSROOT_DIR="/" PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 PKG_ +CONFIG_ALLOW_SYSTEM_LIBS=1 PKG_CONFIG_LIBDIR="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/lib/pkgconfig:/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/share/pkg +config" AR="/usr/bin/ar" AS="/usr/bin/as" LD="/usr/bin/ld" NM="/usr/bin/nm" CC="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin/ccache /usr/bin/gcc" GCC="/home/ciro/bak/git/linux-kerne +l-module-cheat/out/x86_64/buildroot/host/bin/ccache /usr/bin/gcc" CXX="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin/ccache /usr/bin/g++" CPP="/usr/bin/cpp" OBJCOPY="/usr/bin/objcopy +" RANLIB="/usr/bin/ranlib" CPPFLAGS="-I/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/include" CFLAGS="-O2 -I/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/include +" CXXFLAGS="-O2 -I/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/include" LDFLAGS="-L/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/lib -Wl,-rpath,/home/ciro/bak/g +it/linux-kernel-module-cheat/out/x86_64/buildroot/host/lib" INTLTOOL_PERL=/usr/bin/perl CPP="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin/ccache /usr/bin/gcc -E" ./configure --targe +t-list="x86_64-softmmu" --prefix="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host" --interp-prefix=/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/x86_64-buildroot-l +inux-uclibc/sysroot --cc="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin/ccache /usr/bin/gcc" --host-cc="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin/cca +che /usr/bin/gcc" --python=/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin/python2 --extra-cflags="-O2 -I/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/include" + --extra-ldflags="-L/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/lib -Wl,-rpath,/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/lib" --enable-debug --extra-cflags +=-DDEBUG_PL061=1 --enable-trace-backends=simple --enable-sdl --with-sdlabi=2.0 +``` + +QEMU build: + +``` +PATH="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin:/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/sbin:./node_modules/.bin:/usr/local/heroku/bin:/home/ciro/a +ndroid-sdk/platform-tools:/home/ciro/android-sdk/tools:/home/ciro/android-studio//bin:/home/ciro/android-sdk/ndk-bundle:/home/ciro/android-sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_6 +4/bin:/home/ciro/bak/git/devbin:/home/ciro/bin:/usr/local/texlive/2013/bin/x86_64-linux:/home/ciro/.rvm/gems/ruby-2.4.1/bin:/home/ciro/.rvm/gems/ruby-2.4.1@global/bin:/home/ciro/.rvm/rubies/ruby-2.4.1/bin:./node +_modules/.bin:/usr/local/heroku/bin:/home/ciro/android-sdk/platform-tools:/home/ciro/android-sdk/tools:/home/ciro/android-studio//bin:/home/ciro/android-sdk/ndk-bundle:/home/ciro/android-sdk/ndk-bundle/toolchain +s/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin:/home/ciro/bak/git/devbin:/home/ciro/bin:/usr/local/texlive/2013/bin/x86_64-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/us +r/local/games:/usr/bin:/snap/bin:/home/ciro/bak/git/latex:/home/ciro/.rvm/bin:/home/ciro/anaconda2/bin:/home/ciro/.cabal/bin:/bin:/home/ciro/.go/bin:/home/ciro/.local/bin/:/home/ciro/bak/git/runlinux:/usr/bin:/h +ome/ciro/bak/git/latex:/home/ciro/.rvm/bin:/home/ciro/anaconda2/bin:/home/ciro/.cabal/bin:/bin:/home/ciro/.go/bin:/home/ciro/.local/bin/:/home/ciro/bak/git/runlinux" PKG_CONFIG="/home/ciro/bak/git/linux-kernel-m +odule-cheat/out/x86_64/buildroot/host/bin/pkg-config" PKG_CONFIG_SYSROOT_DIR="/" PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 PKG_CONFIG_LIBDIR="/home/ciro/bak/git/linux-kernel-module-cheat/ou +t/x86_64/buildroot/host/lib/pkgconfig:/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/share/pkgconfig" /usr/bin/make -j8 -C /home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroo +t/build/host-qemu-custom +``` + +I am getting the same errors while doing a "replay". Are there any updates on the resolution/fix ? + +@arna35: I have tested this yet unmerged patch: https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg04286.html and it solves this problem, I will close this issue once it gets merged. + +@Ciro, + +I hope this solves the problem for me too. Thanks for highlighting the patch. + +Looks like the patches have been merged now (see commit cda382594b7ea50aff5f672f32767f9f9fef4c12 and earlier) + +Released with QEMU v5.2.0. + diff --git a/results/classifier/zero-shot/108/all/1765970 b/results/classifier/zero-shot/108/all/1765970 new file mode 100644 index 000000000..5a639be46 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1765970 @@ -0,0 +1,95 @@ +permissions: 0.975 +graphic: 0.973 +debug: 0.970 +performance: 0.969 +other: 0.967 +semantic: 0.966 +device: 0.965 +socket: 0.963 +vnc: 0.963 +PID: 0.956 +KVM: 0.950 +network: 0.950 +files: 0.949 +boot: 0.947 + +qemu-arm (user mode) segfaults in uclibc-ng chroot after upgrade to 2.11.x + +I use a qemu-user chroot + binfmt to build software targetting a raspberry pi. After upgrading from qemu-2.10.1 to 2.11.1 (Gentoo host), I noticed that on my uclibc-ng chroot qemu-arm will segfault when running python and importing the portage module. + +I have bisected qemu down to this commit: + +https://github.com/qemu/qemu/commit/18e80c55bb6ec17c05ec0ba717ec83933c2bfc07 + +If I recompile and change MAX_RESERVED_VA (from the above commit) back to 0x77000000 the problem goes away. NB I have no idea what that does, I just thought I'd see. + + +Other arm chroots (glibc, musl) do not segfault with qemu-2.11, only the uclibc-ng one. Not sure why. + + +The following backtrace was generated from running qemu-arm in gdb and recreating the segfault: + +(gdb) where +#0 0x0000000060726046 in static_code_gen_buffer () +#1 0x0000000060048789 in cpu_tb_exec (cpu=0x6278e310, + itb=0x60725f80 <static_code_gen_buffer+314624>) + at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:167 +#2 0x000000006004937f in cpu_loop_exec_tb (cpu=0x6278e310, + tb=0x60725f80 <static_code_gen_buffer+314624>, last_tb=0x7fffffffd138, + tb_exit=0x7fffffffd130) + at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:627 +#3 0x0000000060049600 in cpu_exec (cpu=0x6278e310) + at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:736 +#4 0x00000000600511c3 in cpu_loop (env=0x627965b0) + at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/linux-user/main.c:585 +#5 0x00000000600534eb in main (argc=4, argv=0x7fffffffd9b8, + envp=0x7fffffffd9e0) + at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/linux-user/main.c:4882 + + + +(gdb) info reg +rax 0x627965b0 1652123056 +rbx 0x62717870 1651603568 +rcx 0x606da000 1617797120 +rdx 0x60726000 1618108416 +rsi 0x60726000 1618108416 +rdi 0x627965b0 1652123056 +rbp 0x7fffffffd0c0 0x7fffffffd0c0 +rsp 0x7fffffffd080 0x7fffffffd080 +r8 0x0 0 +r9 0x2 2 +r10 0x0 0 +r11 0x629280a0 1653768352 +r12 0x60260e40 1613106752 +r13 0x0 0 +r14 0x606a5018 1617580056 +r15 0x0 0 +rip 0x60048789 0x60048789 <cpu_tb_exec+266> +eflags 0x10282 [ SF IF RF ] +cs 0x33 51 +ss 0x2b 43 +ds 0x0 0 +es 0x0 0 +fs 0x0 0 +gs 0x0 0 +(gdb) + +Could you try with current head-of-git (the 2.12 rc4)? We adjusted our logic for setting up the initial reserved space since 2.11 -- it may well not fix this bug, but maybe we'll be lucky... + +Unfortunately, no dice + +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/zero-shot/108/all/1768246 b/results/classifier/zero-shot/108/all/1768246 new file mode 100644 index 000000000..cc1a6c262 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1768246 @@ -0,0 +1,200 @@ +other: 0.974 +permissions: 0.966 +semantic: 0.964 +PID: 0.963 +debug: 0.962 +socket: 0.961 +device: 0.960 +graphic: 0.957 +files: 0.957 +performance: 0.950 +network: 0.945 +vnc: 0.933 +KVM: 0.921 +boot: 0.915 + +cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. + +OpenJDK no longer works on qemu-sh4, it previously did after #1735384 was fixed. + +Crash indicates an assertion failure: + +(sid-sh4-sbuild)root@nofan:/# java --version +qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted +(sid-sh4-sbuild)root@nofan:/# + +Haven't bi-sected the issue yet, but will do so later. + + +John Paul Adrian Glaubitz <email address hidden> writes: + +> Public bug reported: +> +> OpenJDK no longer works on qemu-sh4, it previously did after #1735384 +> was fixed. +> +> Crash indicates an assertion failure: +> +> (sid-sh4-sbuild)root@nofan:/# java --version +> qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. +> qemu: uncaught target signal 6 (Aborted) - core dumped +> Aborted +> (sid-sh4-sbuild)root@nofan:/# +> +> Haven't bi-sected the issue yet, but will do so later. + +Hmm that's ominous - arguably the assert should be inside the +CONFIG_USER but I'm not sure how you get to the point where icount isn't +< 0 after receiving a TB_EXIT_REQUESTED. + +> +> ** Affects: qemu +> Importance: Undecided +> Status: New + + +-- +Alex Bennée + + +On 05/01/2018 05:31 PM, Alex Bennée wrote: +>> Haven't bi-sected the issue yet, but will do so later. +> +> Hmm that's ominous - arguably the assert should be inside the +> CONFIG_USER but I'm not sure how you get to the point where icount isn't +> < 0 after receiving a TB_EXIT_REQUESTED. + +git bisect yielded this: + +4834871bc95b67343248100e2a75ae0d287bc08b is the first bad commit +commit 4834871bc95b67343248100e2a75ae0d287bc08b +Author: Richard Henderson <email address hidden> +Date: Thu Sep 7 11:50:54 2017 -0700 + + target/sh4: Convert to DisasJumpType + + Signed-off-by: Richard Henderson <email address hidden> + Message-Id: <email address hidden> + [aurel32: fix whitespace] + Signed-off-by: Aurelien Jarno <email address hidden> + +:040000 040000 6e0e67cc5d0eb5ef461510d314c6af43eecc08bb aa3399c893c49e6fafda157181cf10f8fbcd0a72 M target + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + +This bug also affects GHC on qemu-sh4: + +checking version of ghc... ./configure: line 3199: 55879 Segmentation fault "${WithGhc-ghc}" --version > conftestghc 2>&1 +8.2.2 +qemu-sh4-static: /build/qemu-fWXVPw/qemu-2.12+dfsg/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +qemu-sh4-static: /build/qemu-fWXVPw/qemu-2.12+dfsg/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +qemu-sh4-static: /build/qemu-fWXVPw/qemu-2.12+dfsg/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +qemu-sh4-static: /build/qemu-fWXVPw/qemu-2.12+dfsg/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +qemu-sh4-static: /build/qemu-fWXVPw/qemu-2.12+dfsg/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Just tested with qemu 5a5c383b1373aeb6c87a0d6060f6c3dc7c53082b. + +-- + .''`. John Paul Adrian Glaubitz +: :' : Debian Developer - <email address hidden> +`. `' Freie Universitaet Berlin - <email address hidden> + `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 + + +Still present on git master: + +/usr/bin/make -f src/server/CMakeFiles/KF5WaylandServer_autogen.dir/build.make src/server/CMakeFiles/KF5WaylandServer_autogen.dir/build +make[3]: Entering directory '/<<PKGBUILDDIR>>/obj-sh4-linux-gnu' +make[3]: Entering directory '/<<PKGBUILDDIR>>/obj-sh4-linux-gnu' +[ 0%] Automatic MOC for target surfaceExtensionHelper +[ 0%] Generating src/KF5Wayland.qch, src/KF5Wayland.tags +cd /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/autotests/server && /usr/bin/cmake -E cmake_autogen /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/autotests/server/CMakeFiles/surfaceExtensionHelper_autogen.dir/AutogenInfo.cmake Debian +cd /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src && cmake -E remove_directory "/<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/KF5Wayland_ECMQchDoxygen" +[ 0%] Automatic MOC for target KF5WaylandClient +[ 0%] Automatic MOC for target kwaylandScanner +cd /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/tools && /usr/bin/cmake -E cmake_autogen /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/tools/CMakeFiles/kwaylandScanner_autogen.dir/AutogenInfo.cmake Debian +cd /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/client && /usr/bin/cmake -E cmake_autogen /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/client/CMakeFiles/KF5WaylandClient_autogen.dir/AutogenInfo.cmake Debian +[ 0%] Automatic MOC for target KF5WaylandServer +cd /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/server && /usr/bin/cmake -E cmake_autogen /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/server/CMakeFiles/KF5WaylandServer_autogen.dir/AutogenInfo.cmake Debian +cd /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src && cmake -E make_directory "/<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/KF5Wayland_ECMQchDoxygen" +qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:634: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +make[3]: *** [autotests/server/CMakeFiles/surfaceExtensionHelper_autogen.dir/build.make:61: autotests/server/CMakeFiles/surfaceExtensionHelper_autogen] Error 139 +make[3]: Leaving directory '/<<PKGBUILDDIR>>/obj-sh4-linux-gnu' +make[2]: *** [CMakeFiles/Makefile2:3729: autotests/server/CMakeFiles/surfaceExtensionHelper_autogen.dir/all] Error 2 +make[2]: *** Waiting for unfinished jobs.... +qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:634: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +make[3]: *** [src/client/CMakeFiles/KF5WaylandClient_autogen.dir/build.make:61: src/client/CMakeFiles/KF5WaylandClient_autogen] Error 139 +make[3]: Leaving directory '/<<PKGBUILDDIR>>/obj-sh4-linux-gnu' +make[2]: *** [CMakeFiles/Makefile2:259: src/client/CMakeFiles/KF5WaylandClient_autogen.dir/all] Error 2 +cd /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src && /usr/bin/doxygen /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/KF5Wayland_ECMQchDoxygen.config +qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:634: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +make[3]: *** [src/tools/CMakeFiles/kwaylandScanner_autogen.dir/build.make:61: src/tools/CMakeFiles/kwaylandScanner_autogen] Error 139 +make[3]: Leaving directory '/<<PKGBUILDDIR>>/obj-sh4-linux-gnu' +make[2]: *** [CMakeFiles/Makefile2:437: src/tools/CMakeFiles/kwaylandScanner_autogen.dir/all] Error 2 +qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:634: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +make[3]: *** [src/server/CMakeFiles/KF5WaylandServer_autogen.dir/build.make:61: src/server/CMakeFiles/KF5WaylandServer_autogen] Error 139 +make[3]: Leaving directory '/<<PKGBUILDDIR>>/obj-sh4-linux-gnu' +make[2]: *** [CMakeFiles/Makefile2:347: src/server/CMakeFiles/KF5WaylandServer_autogen.dir/all] Error 2 +QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-glaubitz' +Building up file structure... +Insert custom filters... +Insert help data for filter section (1 of 1)... +Insert files... +Warning: The file /<<PKGBUILDDIR>>/obj-sh4-linux-gnu/src/KF5Wayland_ECMQchDoxygen/html/dynsections.js does not exist, skipping it... +Insert contents... + +This change seems to fix the problem: + +diff --git a/target/sh4/translate.c b/target/sh4/translate.c +index 1b9a201d6d..5010b0d349 100644 +--- a/target/sh4/translate.c ++++ b/target/sh4/translate.c +@@ -253,7 +253,6 @@ static void gen_goto_tb(DisasContext *ctx, int n, target_ulong dest) + tcg_gen_lookup_and_goto_ptr(); + } + } +- ctx->base.is_jmp = DISAS_NORETURN; + } + + static void gen_jump(DisasContext * ctx) +@@ -324,7 +323,6 @@ static void gen_delayed_conditional_jump(DisasContext * ctx) + gen_jump(ctx); + + gen_set_label(l1); +- ctx->base.is_jmp = DISAS_NEXT; + return; + } + +@@ -1877,6 +1875,7 @@ static void decode_opc(DisasContext * ctx) + ctx->envflags &= ~GUSA_MASK; + + tcg_gen_movi_i32(cpu_flags, ctx->envflags); ++ ctx->base.is_jmp = DISAS_NORETURN; + if (old_flags & DELAY_SLOT_CONDITIONAL) { + gen_delayed_conditional_jump(ctx); + } else { + + +Fix has been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5b38d0264064055255db991 + diff --git a/results/classifier/zero-shot/108/all/1774149 b/results/classifier/zero-shot/108/all/1774149 new file mode 100644 index 000000000..6ad08fa62 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1774149 @@ -0,0 +1,120 @@ +debug: 0.982 +other: 0.980 +semantic: 0.978 +performance: 0.976 +graphic: 0.974 +device: 0.971 +socket: 0.969 +permissions: 0.967 +boot: 0.964 +PID: 0.957 +files: 0.952 +network: 0.945 +vnc: 0.943 +KVM: 0.918 + +qemu-user x86_64 x86 gdb call function from gdb doesn't work + +While running qemu user x86_64 x86 with gdb server, calling functions are not working. + +Here is how to reproduce it: + +run in a terminal: +$ qemu-x86_64 -g 12345 -L / /bin/ls + +In another terminal run gdb: +(gdb) file /bin/ls +(gdb) target remote :12345 +(gdb) b _init +(gdb) c +(gdb) call malloc(1) +Could not fetch register "fs_base"; remote failure reply 'E14' + +In other cases we also got the error: +Could not fetch register "orig_rax"; remote failure reply 'E14' + +Here is how I patched it (it is only a workaround): + +diff --git a/gdbstub.c b/gdbstub.c +index 2a94030..5749efe 100644 +--- a/gdbstub.c ++++ b/gdbstub.c +@@ -668,6 +668,11 @@ static int gdb_read_register(CPUState *cpu, uint8_t *mem_buf, int reg) + return r->get_reg(env, mem_buf, reg - r->base_reg); + } + } ++#ifdef TARGET_X86_64 ++ return 8; ++#elif TARGET_I386 ++ return 4; ++#endif + return 0; + } + +(Our guess for this issue was, gdb is requesting for 'fake' registers to know register size) + +Once we patched that, we got another problem while calling functions from gdb: We could call functions, but only once. + +Here is how to reproduce it: +run in a terminal: +$ qemu-x86_64 -g 12345 -L / /bin/ls + +In another terminal run gdb: +(gdb) file /bin/ls +(gdb) target remote :12345 +(gdb) b _init +(gdb) c +(gdb) call malloc(1) +$1 = (void *) 0x620010 +(gdb) call malloc(1) +Cannot access memory at address 0x40007ffb8f + +Here is how we patched it to make it work: + +diff --git a/exec.c b/exec.c +index 03238a3..d303922 100644 +--- a/exec.c ++++ b/exec.c +@@ -2833,7 +2833,7 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr, + if (!(flags & PAGE_VALID)) + return -1; + if (is_write) { +- if (!(flags & PAGE_WRITE)) ++ if (!(flags & (PAGE_WRITE | PAGE_WRITE_ORG))) + return -1; + /* XXX: this code should not depend on lock_user */ + if (!(p = lock_user(VERIFY_WRITE, addr, l, 0))) + +From what we saw, there is a page which is passed to read-only after first execution, and gdb need to write on that page to put a breakpoint. (on the stack) + +We suspect this is linked to this: +https://qemu.weilnetz.de/w64/2012/2012-06-28/qemu-tech.html#Self_002dmodifying-code-and-translated-code-invalidation + +I have verified the second issue: the second call of function gives error "Cannot access memory at address". +I have tried it for various architectures. It is same for mips. But it works for aarch64. + +It seems the issue is related to gdb code: set_gdbarch_call_dummy_location (gdbarch, ON_STACK); + +What is going on? +The breakpoint is stored on stack and for the first time the address has a flag PAGE_WRITE. +After a call, the address does not have anymore the flag PAGE_WRITE. It is changed in method tb_page_add() (file: accel/tcg/translate-all.c). + +I am thinking more about gdbstub.c. +If there is handled packet M for writing data to memory, it should always write data to given address. +Reason: you are debugging and you want to verify various scenarios, so changing different values on different places may be needed. + + +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/zero-shot/108/all/17743720 b/results/classifier/zero-shot/108/all/17743720 new file mode 100644 index 000000000..e4ab63d55 --- /dev/null +++ b/results/classifier/zero-shot/108/all/17743720 @@ -0,0 +1,781 @@ +other: 0.984 +permissions: 0.981 +debug: 0.974 +graphic: 0.972 +device: 0.971 +performance: 0.965 +semantic: 0.962 +files: 0.961 +PID: 0.955 +socket: 0.954 +vnc: 0.945 +boot: 0.945 +network: 0.944 +KVM: 0.933 + +[Qemu-devel] [BUG] living migrate vm pause forever + +Sometimes, living migrate vm pause forever, migrate job stop, but very small +probability, I canât reproduce. +qemu wait semaphore from libvirt send migrate continue, however libvirt wait +semaphore from qemu send vm pause. + +follow stack: +qemu: +Thread 6 (Thread 0x7f50445f3700 (LWP 18120)): +#0 0x00007f504b84d670 in sem_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 +#1 0x00005574eda1e164 in qemu_sem_wait (sem=sem@entry=0x5574ef6930e0) at +qemu-2.12/util/qemu-thread-posix.c:322 +#2 0x00005574ed8dd72e in migration_maybe_pause (s=0x5574ef692f50, +current_active_state=0x7f50445f2ae4, new_state=10) + at qemu-2.12/migration/migration.c:2106 +#3 0x00005574ed8df51a in migration_completion (s=0x5574ef692f50) at +qemu-2.12/migration/migration.c:2137 +#4 migration_iteration_run (s=0x5574ef692f50) at +qemu-2.12/migration/migration.c:2311 +#5 migration_thread (opaque=0x5574ef692f50) +atqemu-2.12/migration/migration.c:2415 +#6 0x00007f504b847184 in start_thread () from +/lib/x86_64-linux-gnu/libpthread.so.0 +#7 0x00007f504b574bed in clone () from /lib/x86_64-linux-gnu/libc.so.6 + +libvirt: +Thread 95 (Thread 0x7fdb82ffd700 (LWP 28775)): +#0 0x00007fdd177dc404 in pthread_cond_wait@@GLIBC_2.3.2 () from +/lib/x86_64-linux-gnu/libpthread.so.0 +#1 0x00007fdd198c3b07 in virCondWait (c=0x7fdbc4003000, m=0x7fdbc4002f30) at +../../../src/util/virthread.c:252 +#2 0x00007fdd198f36d2 in virDomainObjWait (vm=0x7fdbc4002f20) at +../../../src/conf/domain_conf.c:3303 +#3 0x00007fdd09ffaa44 in qemuMigrationRun (driver=0x7fdd000037b0, +vm=0x7fdbc4002f20, persist_xml=0x0, + cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n <hostname>mss +</hostname>\n +<hostuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +flags=777, + resource=0, spec=0x7fdb82ffc670, dconn=0x0, graphicsuri=0x0, +nmigrate_disks=0, migrate_disks=0x0, compression=0x7fdb78007990, +migParams=0x7fdb82ffc900) + at ../../../src/qemu/qemu_migration.c:3937 +#4 0x00007fdd09ffb26a in doNativeMigrate (driver=0x7fdd000037b0, +vm=0x7fdbc4002f20, persist_xml=0x0, uri=0x7fdb780073a0 +"tcp://172.16.202.17:49152", + cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n <hostname>mss</hostname>\n + <hos---Type <return> to continue, or q <return> to quit--- +tuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +flags=777, + resource=0, dconn=0x0, graphicsuri=0x0, nmigrate_disks=0, +migrate_disks=0x0, compression=0x7fdb78007990, migParams=0x7fdb82ffc900) + at ../../../src/qemu/qemu_migration.c:4118 +#5 0x00007fdd09ffd808 in qemuMigrationPerformPhase (driver=0x7fdd000037b0, +conn=0x7fdb500205d0, vm=0x7fdbc4002f20, persist_xml=0x0, + uri=0x7fdb780073a0 "tcp://172.16.202.17:49152", graphicsuri=0x0, +nmigrate_disks=0, migrate_disks=0x0, compression=0x7fdb78007990, +migParams=0x7fdb82ffc900, + cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n <hostname>mss</hostname>\n + <hostuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +flags=777, + resource=0) at ../../../src/qemu/qemu_migration.c:5030 +#6 0x00007fdd09ffdbb5 in qemuMigrationPerform (driver=0x7fdd000037b0, +conn=0x7fdb500205d0, vm=0x7fdbc4002f20, xmlin=0x0, persist_xml=0x0, +dconnuri=0x0, + uri=0x7fdb780073a0 "tcp://172.16.202.17:49152", graphicsuri=0x0, +listenAddress=0x0, nmigrate_disks=0, migrate_disks=0x0, nbdPort=0, +compression=0x7fdb78007990, + migParams=0x7fdb82ffc900, + cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n <hostname>mss</hostname>\n + <hostuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +flags=777, + dname=0x0, resource=0, v3proto=true) at +../../../src/qemu/qemu_migration.c:5124 +#7 0x00007fdd0a054725 in qemuDomainMigratePerform3 (dom=0x7fdb78007b00, +xmlin=0x0, + cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n <hostname>mss</hostname>\n + <hostuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +dconnuri=0x0, + uri=0x7fdb780073a0 "tcp://172.16.202.17:49152", flags=777, dname=0x0, +resource=0) at ../../../src/qemu/qemu_driver.c:12996 +#8 0x00007fdd199ad0f0 in virDomainMigratePerform3 (domain=0x7fdb78007b00, +xmlin=0x0, + cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n <hostname>mss</hostname>\n + <hostuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +dconnuri=0x0, + uri=0x7fdb780073a0 "tcp://172.16.202.17:49152", flags=777, dname=0x0, +bandwidth=0) at ../../../src/libvirt-domain.c:4698 +#9 0x000055d13923a939 in remoteDispatchDomainMigratePerform3 +(server=0x55d13af90e60, client=0x55d13b0156f0, msg=0x55d13afbf620, +rerr=0x7fdb82ffcbc0, + args=0x7fdb7800b220, ret=0x7fdb78021e90) at ../../../daemon/remote.c:4528 +#10 0x000055d13921a043 in remoteDispatchDomainMigratePerform3Helper +(server=0x55d13af90e60, client=0x55d13b0156f0, msg=0x55d13afbf620, +rerr=0x7fdb82ffcbc0, + args=0x7fdb7800b220, ret=0x7fdb78021e90) at +../../../daemon/remote_dispatch.h:7944 +#11 0x00007fdd19a260b4 in virNetServerProgramDispatchCall (prog=0x55d13af98b50, +server=0x55d13af90e60, client=0x55d13b0156f0, msg=0x55d13afbf620) + at ../../../src/rpc/virnetserverprogram.c:436 +#12 0x00007fdd19a25c17 in virNetServerProgramDispatch (prog=0x55d13af98b50, +server=0x55d13af90e60, client=0x55d13b0156f0, msg=0x55d13afbf620) + at ../../../src/rpc/virnetserverprogram.c:307 +#13 0x000055d13925933b in virNetServerProcessMsg (srv=0x55d13af90e60, +client=0x55d13b0156f0, prog=0x55d13af98b50, msg=0x55d13afbf620) + at ../../../src/rpc/virnetserver.c:148 +------------------------------------------------------------------------------------------------------------------------------------- +æ¬é®ä»¶åå ¶é件å«ææ°åä¸éå¢çä¿å¯ä¿¡æ¯ï¼ä» éäºåéç»ä¸é¢å°åä¸ååº +ç个人æ群ç»ãç¦æ¢ä»»ä½å ¶ä»äººä»¥ä»»ä½å½¢å¼ä½¿ç¨ï¼å æ¬ä½ä¸éäºå ¨é¨æé¨åå°æ³é²ãå¤å¶ã +ææ£åï¼æ¬é®ä»¶ä¸çä¿¡æ¯ãå¦ææ¨éæ¶äºæ¬é®ä»¶ï¼è¯·æ¨ç«å³çµè¯æé®ä»¶éç¥å件人并å é¤æ¬ +é®ä»¶ï¼ +This e-mail and its attachments contain confidential information from New H3C, +which is +intended only for the person or entity whose address is listed above. Any use +of the +information contained herein in any way (including, but not limited to, total +or partial +disclosure, reproduction, or dissemination) by persons other than the intended +recipient(s) is prohibited. If you receive this e-mail in error, please notify +the sender +by phone or email immediately and delete it! + +* Yuchen (address@hidden) wrote: +> +Sometimes, living migrate vm pause forever, migrate job stop, but very small +> +probability, I canât reproduce. +> +qemu wait semaphore from libvirt send migrate continue, however libvirt wait +> +semaphore from qemu send vm pause. +Hi, + I've copied in Jiri Denemark from libvirt. +Can you confirm exactly which qemu and libvirt versions you're using +please. + +> +follow stack: +> +qemu: +> +Thread 6 (Thread 0x7f50445f3700 (LWP 18120)): +> +#0 0x00007f504b84d670 in sem_wait () from +> +/lib/x86_64-linux-gnu/libpthread.so.0 +> +#1 0x00005574eda1e164 in qemu_sem_wait (sem=sem@entry=0x5574ef6930e0) at +> +qemu-2.12/util/qemu-thread-posix.c:322 +> +#2 0x00005574ed8dd72e in migration_maybe_pause (s=0x5574ef692f50, +> +current_active_state=0x7f50445f2ae4, new_state=10) +> +at qemu-2.12/migration/migration.c:2106 +> +#3 0x00005574ed8df51a in migration_completion (s=0x5574ef692f50) at +> +qemu-2.12/migration/migration.c:2137 +> +#4 migration_iteration_run (s=0x5574ef692f50) at +> +qemu-2.12/migration/migration.c:2311 +> +#5 migration_thread (opaque=0x5574ef692f50) +> +atqemu-2.12/migration/migration.c:2415 +> +#6 0x00007f504b847184 in start_thread () from +> +/lib/x86_64-linux-gnu/libpthread.so.0 +> +#7 0x00007f504b574bed in clone () from /lib/x86_64-linux-gnu/libc.so.6 +In migration_maybe_pause we have: + + migrate_set_state(&s->state, *current_active_state, + MIGRATION_STATUS_PRE_SWITCHOVER); + qemu_sem_wait(&s->pause_sem); + migrate_set_state(&s->state, MIGRATION_STATUS_PRE_SWITCHOVER, + new_state); + +the line numbers don't match my 2.12.0 checkout; so I guess that it's +that qemu_sem_wait it's stuck at. + +QEMU must have sent the switch to PRE_SWITCHOVER and that should have +sent an event to libvirt, and libvirt should notice that - I'm +not sure how to tell whether libvirt has seen that event yet or not? + +Dave + +> +libvirt: +> +Thread 95 (Thread 0x7fdb82ffd700 (LWP 28775)): +> +#0 0x00007fdd177dc404 in pthread_cond_wait@@GLIBC_2.3.2 () from +> +/lib/x86_64-linux-gnu/libpthread.so.0 +> +#1 0x00007fdd198c3b07 in virCondWait (c=0x7fdbc4003000, m=0x7fdbc4002f30) at +> +../../../src/util/virthread.c:252 +> +#2 0x00007fdd198f36d2 in virDomainObjWait (vm=0x7fdbc4002f20) at +> +../../../src/conf/domain_conf.c:3303 +> +#3 0x00007fdd09ffaa44 in qemuMigrationRun (driver=0x7fdd000037b0, +> +vm=0x7fdbc4002f20, persist_xml=0x0, +> +cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +> +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n <hostname>mss +> +</hostname>\n +> +<hostuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +> +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +> +flags=777, +> +resource=0, spec=0x7fdb82ffc670, dconn=0x0, graphicsuri=0x0, +> +nmigrate_disks=0, migrate_disks=0x0, compression=0x7fdb78007990, +> +migParams=0x7fdb82ffc900) +> +at ../../../src/qemu/qemu_migration.c:3937 +> +#4 0x00007fdd09ffb26a in doNativeMigrate (driver=0x7fdd000037b0, +> +vm=0x7fdbc4002f20, persist_xml=0x0, uri=0x7fdb780073a0 +> +"tcp://172.16.202.17:49152", +> +cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +> +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n +> +<hostname>mss</hostname>\n <hos---Type <return> to continue, or q <return> +> +to quit--- +> +tuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +> +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +> +flags=777, +> +resource=0, dconn=0x0, graphicsuri=0x0, nmigrate_disks=0, +> +migrate_disks=0x0, compression=0x7fdb78007990, migParams=0x7fdb82ffc900) +> +at ../../../src/qemu/qemu_migration.c:4118 +> +#5 0x00007fdd09ffd808 in qemuMigrationPerformPhase (driver=0x7fdd000037b0, +> +conn=0x7fdb500205d0, vm=0x7fdbc4002f20, persist_xml=0x0, +> +uri=0x7fdb780073a0 "tcp://172.16.202.17:49152", graphicsuri=0x0, +> +nmigrate_disks=0, migrate_disks=0x0, compression=0x7fdb78007990, +> +migParams=0x7fdb82ffc900, +> +cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +> +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n +> +<hostname>mss</hostname>\n +> +<hostuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +> +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +> +flags=777, +> +resource=0) at ../../../src/qemu/qemu_migration.c:5030 +> +#6 0x00007fdd09ffdbb5 in qemuMigrationPerform (driver=0x7fdd000037b0, +> +conn=0x7fdb500205d0, vm=0x7fdbc4002f20, xmlin=0x0, persist_xml=0x0, +> +dconnuri=0x0, +> +uri=0x7fdb780073a0 "tcp://172.16.202.17:49152", graphicsuri=0x0, +> +listenAddress=0x0, nmigrate_disks=0, migrate_disks=0x0, nbdPort=0, +> +compression=0x7fdb78007990, +> +migParams=0x7fdb82ffc900, +> +cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +> +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n +> +<hostname>mss</hostname>\n +> +<hostuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +> +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +> +flags=777, +> +dname=0x0, resource=0, v3proto=true) at +> +../../../src/qemu/qemu_migration.c:5124 +> +#7 0x00007fdd0a054725 in qemuDomainMigratePerform3 (dom=0x7fdb78007b00, +> +xmlin=0x0, +> +cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +> +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n +> +<hostname>mss</hostname>\n +> +<hostuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +> +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +> +dconnuri=0x0, +> +uri=0x7fdb780073a0 "tcp://172.16.202.17:49152", flags=777, dname=0x0, +> +resource=0) at ../../../src/qemu/qemu_driver.c:12996 +> +#8 0x00007fdd199ad0f0 in virDomainMigratePerform3 (domain=0x7fdb78007b00, +> +xmlin=0x0, +> +cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +> +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n +> +<hostname>mss</hostname>\n +> +<hostuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +> +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +> +dconnuri=0x0, +> +uri=0x7fdb780073a0 "tcp://172.16.202.17:49152", flags=777, dname=0x0, +> +bandwidth=0) at ../../../src/libvirt-domain.c:4698 +> +#9 0x000055d13923a939 in remoteDispatchDomainMigratePerform3 +> +(server=0x55d13af90e60, client=0x55d13b0156f0, msg=0x55d13afbf620, +> +rerr=0x7fdb82ffcbc0, +> +args=0x7fdb7800b220, ret=0x7fdb78021e90) at ../../../daemon/remote.c:4528 +> +#10 0x000055d13921a043 in remoteDispatchDomainMigratePerform3Helper +> +(server=0x55d13af90e60, client=0x55d13b0156f0, msg=0x55d13afbf620, +> +rerr=0x7fdb82ffcbc0, +> +args=0x7fdb7800b220, ret=0x7fdb78021e90) at +> +../../../daemon/remote_dispatch.h:7944 +> +#11 0x00007fdd19a260b4 in virNetServerProgramDispatchCall +> +(prog=0x55d13af98b50, server=0x55d13af90e60, client=0x55d13b0156f0, +> +msg=0x55d13afbf620) +> +at ../../../src/rpc/virnetserverprogram.c:436 +> +#12 0x00007fdd19a25c17 in virNetServerProgramDispatch (prog=0x55d13af98b50, +> +server=0x55d13af90e60, client=0x55d13b0156f0, msg=0x55d13afbf620) +> +at ../../../src/rpc/virnetserverprogram.c:307 +> +#13 0x000055d13925933b in virNetServerProcessMsg (srv=0x55d13af90e60, +> +client=0x55d13b0156f0, prog=0x55d13af98b50, msg=0x55d13afbf620) +> +at ../../../src/rpc/virnetserver.c:148 +> +------------------------------------------------------------------------------------------------------------------------------------- +> +æ¬é®ä»¶åå ¶é件å«ææ°åä¸éå¢çä¿å¯ä¿¡æ¯ï¼ä» éäºåéç»ä¸é¢å°åä¸ååº +> +ç个人æ群ç»ãç¦æ¢ä»»ä½å ¶ä»äººä»¥ä»»ä½å½¢å¼ä½¿ç¨ï¼å æ¬ä½ä¸éäºå ¨é¨æé¨åå°æ³é²ãå¤å¶ã +> +ææ£åï¼æ¬é®ä»¶ä¸çä¿¡æ¯ãå¦ææ¨éæ¶äºæ¬é®ä»¶ï¼è¯·æ¨ç«å³çµè¯æé®ä»¶éç¥å件人并å é¤æ¬ +> +é®ä»¶ï¼ +> +This e-mail and its attachments contain confidential information from New +> +H3C, which is +> +intended only for the person or entity whose address is listed above. Any use +> +of the +> +information contained herein in any way (including, but not limited to, total +> +or partial +> +disclosure, reproduction, or dissemination) by persons other than the intended +> +recipient(s) is prohibited. If you receive this e-mail in error, please +> +notify the sender +> +by phone or email immediately and delete it! +-- +Dr. David Alan Gilbert / address@hidden / Manchester, UK + +In migration_maybe_pause we have: + + migrate_set_state(&s->state, *current_active_state, + MIGRATION_STATUS_PRE_SWITCHOVER); + qemu_sem_wait(&s->pause_sem); + migrate_set_state(&s->state, MIGRATION_STATUS_PRE_SWITCHOVER, + new_state); + +the line numbers don't match my 2.12.0 checkout; so I guess that it's that +qemu_sem_wait it's stuck at. + +QEMU must have sent the switch to PRE_SWITCHOVER and that should have sent an +event to libvirt, and libvirt should notice that - I'm not sure how to tell +whether libvirt has seen that event yet or not? + + +Thank you for your attention. +Yes, you are right, QEMU wait semaphore in this place. +I use qemu-2.12.1, libvirt-4.0.0. +Because I added some debug code, so the line numbers doesn't match open qemu + +-----é®ä»¶å件----- +å件人: Dr. David Alan Gilbert [ +mailto:address@hidden +] +åéæ¶é´: 2019å¹´8æ21æ¥ 19:13 +æ¶ä»¶äºº: yuchen (Cloud) <address@hidden>; address@hidden +æé: address@hidden +主é¢: Re: [Qemu-devel] [BUG] living migrate vm pause forever + +* Yuchen (address@hidden) wrote: +> +Sometimes, living migrate vm pause forever, migrate job stop, but very small +> +probability, I canât reproduce. +> +qemu wait semaphore from libvirt send migrate continue, however libvirt wait +> +semaphore from qemu send vm pause. +Hi, + I've copied in Jiri Denemark from libvirt. +Can you confirm exactly which qemu and libvirt versions you're using please. + +> +follow stack: +> +qemu: +> +Thread 6 (Thread 0x7f50445f3700 (LWP 18120)): +> +#0 0x00007f504b84d670 in sem_wait () from +> +/lib/x86_64-linux-gnu/libpthread.so.0 +> +#1 0x00005574eda1e164 in qemu_sem_wait (sem=sem@entry=0x5574ef6930e0) +> +at qemu-2.12/util/qemu-thread-posix.c:322 +> +#2 0x00005574ed8dd72e in migration_maybe_pause (s=0x5574ef692f50, +> +current_active_state=0x7f50445f2ae4, new_state=10) +> +at qemu-2.12/migration/migration.c:2106 +> +#3 0x00005574ed8df51a in migration_completion (s=0x5574ef692f50) at +> +qemu-2.12/migration/migration.c:2137 +> +#4 migration_iteration_run (s=0x5574ef692f50) at +> +qemu-2.12/migration/migration.c:2311 +> +#5 migration_thread (opaque=0x5574ef692f50) +> +atqemu-2.12/migration/migration.c:2415 +> +#6 0x00007f504b847184 in start_thread () from +> +/lib/x86_64-linux-gnu/libpthread.so.0 +> +#7 0x00007f504b574bed in clone () from +> +/lib/x86_64-linux-gnu/libc.so.6 +In migration_maybe_pause we have: + + migrate_set_state(&s->state, *current_active_state, + MIGRATION_STATUS_PRE_SWITCHOVER); + qemu_sem_wait(&s->pause_sem); + migrate_set_state(&s->state, MIGRATION_STATUS_PRE_SWITCHOVER, + new_state); + +the line numbers don't match my 2.12.0 checkout; so I guess that it's that +qemu_sem_wait it's stuck at. + +QEMU must have sent the switch to PRE_SWITCHOVER and that should have sent an +event to libvirt, and libvirt should notice that - I'm not sure how to tell +whether libvirt has seen that event yet or not? + +Dave + +> +libvirt: +> +Thread 95 (Thread 0x7fdb82ffd700 (LWP 28775)): +> +#0 0x00007fdd177dc404 in pthread_cond_wait@@GLIBC_2.3.2 () from +> +/lib/x86_64-linux-gnu/libpthread.so.0 +> +#1 0x00007fdd198c3b07 in virCondWait (c=0x7fdbc4003000, +> +m=0x7fdbc4002f30) at ../../../src/util/virthread.c:252 +> +#2 0x00007fdd198f36d2 in virDomainObjWait (vm=0x7fdbc4002f20) at +> +../../../src/conf/domain_conf.c:3303 +> +#3 0x00007fdd09ffaa44 in qemuMigrationRun (driver=0x7fdd000037b0, +> +vm=0x7fdbc4002f20, persist_xml=0x0, +> +cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +> +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n <hostname>mss +> +</hostname>\n +> +<hostuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +> +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +> +flags=777, +> +resource=0, spec=0x7fdb82ffc670, dconn=0x0, graphicsuri=0x0, +> +nmigrate_disks=0, migrate_disks=0x0, compression=0x7fdb78007990, +> +migParams=0x7fdb82ffc900) +> +at ../../../src/qemu/qemu_migration.c:3937 +> +#4 0x00007fdd09ffb26a in doNativeMigrate (driver=0x7fdd000037b0, +> +vm=0x7fdbc4002f20, persist_xml=0x0, uri=0x7fdb780073a0 +> +"tcp://172.16.202.17:49152", +> +cookiein=0x7fdb780084e0 "<qemu-migration>\n +> +<name>mss-pl_652</name>\n +> +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n +> +<hostname>mss</hostname>\n <hos---Type <return> to continue, or q +> +<return> to quit--- +> +tuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra".. +> +tuuid>., cookieinlen=207, cookieout=0x7fdb82ffcad0, +> +tuuid>cookieoutlen=0x7fdb82ffcac8, flags=777, +> +resource=0, dconn=0x0, graphicsuri=0x0, nmigrate_disks=0, +> +migrate_disks=0x0, compression=0x7fdb78007990, migParams=0x7fdb82ffc900) +> +at ../../../src/qemu/qemu_migration.c:4118 +> +#5 0x00007fdd09ffd808 in qemuMigrationPerformPhase (driver=0x7fdd000037b0, +> +conn=0x7fdb500205d0, vm=0x7fdbc4002f20, persist_xml=0x0, +> +uri=0x7fdb780073a0 "tcp://172.16.202.17:49152", graphicsuri=0x0, +> +nmigrate_disks=0, migrate_disks=0x0, compression=0x7fdb78007990, +> +migParams=0x7fdb82ffc900, +> +cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +> +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n +> +<hostname>mss</hostname>\n +> +<hostuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +> +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +> +flags=777, +> +resource=0) at ../../../src/qemu/qemu_migration.c:5030 +> +#6 0x00007fdd09ffdbb5 in qemuMigrationPerform (driver=0x7fdd000037b0, +> +conn=0x7fdb500205d0, vm=0x7fdbc4002f20, xmlin=0x0, persist_xml=0x0, +> +dconnuri=0x0, +> +uri=0x7fdb780073a0 "tcp://172.16.202.17:49152", graphicsuri=0x0, +> +listenAddress=0x0, nmigrate_disks=0, migrate_disks=0x0, nbdPort=0, +> +compression=0x7fdb78007990, +> +migParams=0x7fdb82ffc900, +> +cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +> +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n +> +<hostname>mss</hostname>\n +> +<hostuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +> +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +> +flags=777, +> +dname=0x0, resource=0, v3proto=true) at +> +../../../src/qemu/qemu_migration.c:5124 +> +#7 0x00007fdd0a054725 in qemuDomainMigratePerform3 (dom=0x7fdb78007b00, +> +xmlin=0x0, +> +cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +> +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n +> +<hostname>mss</hostname>\n +> +<hostuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +> +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +> +dconnuri=0x0, +> +uri=0x7fdb780073a0 "tcp://172.16.202.17:49152", flags=777, +> +dname=0x0, resource=0) at ../../../src/qemu/qemu_driver.c:12996 +> +#8 0x00007fdd199ad0f0 in virDomainMigratePerform3 (domain=0x7fdb78007b00, +> +xmlin=0x0, +> +cookiein=0x7fdb780084e0 "<qemu-migration>\n <name>mss-pl_652</name>\n +> +<uuid>1f2b2334-451e-424b-822a-ea10452abb38</uuid>\n +> +<hostname>mss</hostname>\n +> +<hostuuid>334e344a-4130-4336-5534-323544543642</hostuuid>\n</qemu-migra"..., +> +cookieinlen=207, cookieout=0x7fdb82ffcad0, cookieoutlen=0x7fdb82ffcac8, +> +dconnuri=0x0, +> +uri=0x7fdb780073a0 "tcp://172.16.202.17:49152", flags=777, +> +dname=0x0, bandwidth=0) at ../../../src/libvirt-domain.c:4698 +> +#9 0x000055d13923a939 in remoteDispatchDomainMigratePerform3 +> +(server=0x55d13af90e60, client=0x55d13b0156f0, msg=0x55d13afbf620, +> +rerr=0x7fdb82ffcbc0, +> +args=0x7fdb7800b220, ret=0x7fdb78021e90) at +> +../../../daemon/remote.c:4528 +> +#10 0x000055d13921a043 in remoteDispatchDomainMigratePerform3Helper +> +(server=0x55d13af90e60, client=0x55d13b0156f0, msg=0x55d13afbf620, +> +rerr=0x7fdb82ffcbc0, +> +args=0x7fdb7800b220, ret=0x7fdb78021e90) at +> +../../../daemon/remote_dispatch.h:7944 +> +#11 0x00007fdd19a260b4 in virNetServerProgramDispatchCall +> +(prog=0x55d13af98b50, server=0x55d13af90e60, client=0x55d13b0156f0, +> +msg=0x55d13afbf620) +> +at ../../../src/rpc/virnetserverprogram.c:436 +> +#12 0x00007fdd19a25c17 in virNetServerProgramDispatch (prog=0x55d13af98b50, +> +server=0x55d13af90e60, client=0x55d13b0156f0, msg=0x55d13afbf620) +> +at ../../../src/rpc/virnetserverprogram.c:307 +> +#13 0x000055d13925933b in virNetServerProcessMsg (srv=0x55d13af90e60, +> +client=0x55d13b0156f0, prog=0x55d13af98b50, msg=0x55d13afbf620) +> +at ../../../src/rpc/virnetserver.c:148 +> +---------------------------------------------------------------------- +> +--------------------------------------------------------------- +> +æ¬é®ä»¶åå ¶é件å«ææ°åä¸éå¢çä¿å¯ä¿¡æ¯ï¼ä» éäºåéç»ä¸é¢å°åä¸ååº +> +ç个人æ群ç»ãç¦æ¢ä»»ä½å ¶ä»äººä»¥ä»»ä½å½¢å¼ä½¿ç¨ï¼å æ¬ä½ä¸éäºå ¨é¨æé¨åå°æ³é²ãå¤å¶ã +> +ææ£åï¼æ¬é®ä»¶ä¸çä¿¡æ¯ãå¦ææ¨éæ¶äºæ¬é®ä»¶ï¼è¯·æ¨ç«å³çµè¯æé®ä»¶éç¥å件人并å é¤æ¬ +> +é®ä»¶ï¼ +> +This e-mail and its attachments contain confidential information from +> +New H3C, which is intended only for the person or entity whose address +> +is listed above. Any use of the information contained herein in any +> +way (including, but not limited to, total or partial disclosure, +> +reproduction, or dissemination) by persons other than the intended +> +recipient(s) is prohibited. If you receive this e-mail in error, +> +please notify the sender by phone or email immediately and delete it! +-- +Dr. David Alan Gilbert / address@hidden / Manchester, UK + diff --git a/results/classifier/zero-shot/108/all/1774677 b/results/classifier/zero-shot/108/all/1774677 new file mode 100644 index 000000000..23bcc5463 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1774677 @@ -0,0 +1,180 @@ +debug: 0.963 +semantic: 0.955 +other: 0.952 +performance: 0.947 +vnc: 0.947 +boot: 0.936 +device: 0.936 +socket: 0.935 +graphic: 0.931 +files: 0.917 +PID: 0.916 +KVM: 0.914 +network: 0.910 +permissions: 0.908 + +-icount increases boot time by >10x + +When I specify the -icount option, some guest operations such as booting a Linux kernel take more than 10 times longer than otherwise. For example, the following will boot Aboriginal Linux to the login prompt about 6 seconds on my system (using TCG, not KVM): + +wget http://landley.net/aboriginal/downloads/old/binaries/1.4.5/system-image-i686.tar.gz +gunzip <system-image-i686.tar.gz | tar xfv - +cd system-image-i686 +sh run-emulator.sh + +If I replace the last line with + +QEMU_EXTRA="-icount shift=auto" sh run-emulator.sh + +booting to the login prompt takes about 1 minute 20 seconds. + +I have tried different values for "shift" other than the "auto" used above, but have not been able to find one that gives reasonable performance. Specifying "sleep=off" also did not help. + +During the slow boots, qemu appears to spend most of its time sleeping, not using the host CPU. + +I see this with multiple versions of qemu, including current git sources (c181ddaa176856b3cd2dfd12bbcf25fa9c884a97), and on multiple host OSes, including Debian 9 on x86_64. + +Yes, I can reproduce this. Also, interestingly, with the -icount version when I typed 'exit' to quit the guest I got this abort: + +qemu: fatal: cpu_io_recompile: could not find TB for pc=0x7fcd0aae636e +EAX=c88053a4 EBX=00000069 ECX=c00211a4 EDX=00000000 +ESI=c7812180 EDI=c78126f0 EBP=0000000f ESP=c7a0de44 +EIP=c11ada30 EFL=00000287 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =007b 00000000 ffffffff 00cff300 DPL=3 DS [-WA] +CS =0060 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-] +SS =0068 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =007b 00000000 ffffffff 00cff300 DPL=3 DS [-WA] +FS =0000 00000000 00000000 00000000 +GS =0033 080a130c ffffffff 00dff300 DPL=3 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0080 c12fbe60 0000206b 00008900 DPL=0 TSS32-avl +GDT= c12f6000 000000ff +IDT= ffffc000 000007ff +CR0=8005003b CR2=09d40ffc CR3=07a08000 CR4=00000690 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=c8800000 CCD=c8805200 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=ec00000000000000 4006 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +Aborted (core dumped) + + +...ah, that's the bug fixed by this patch: https://patchwork.ozlabs.org/patch/940058/ + + +The stalls in the test kernel seem to happen at and after the guest prints + +tsc: Refined TSC clocksource calibration: 1000.022 MHz +clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0xe6a2bd9634, max_idle_ns: 440795211s +hdc: QEMU DVD-ROM, ATAPI CD/DVD-ROM drive +clocksource: Switched to clocksource tsc + +so I suspect a bad interaction between what icount is doing and in particular our emulation of the x86 timestamp counter and what Linux does with it. + + +A couple of comments... First, the problem is not limited to Linux guests. In fact, I originally ran across it with a NetBSD guest, but then reproduced it with a Linux guest for the bug report, because in my experience, qemu bug reports involving non-Linux guests tend to be ignored. + +Second, the qemu man page says that "With sleep=on|off, the virtual time will jump to the next timer deadline instantly whenever the virtual cpu goes to sleep mode". Although the text is confusing (see bug 1774412), to me it suggests that when the mode in case is selected, qemu should execute the guest as fast as possible and only provide it with an illusion of the passage of time, and there should be no reason for qemu itself to ever sleep. Yet, regardless of whether I specify "sleep=on" or "sleep=off", qemu sleeps. + + +I bisected this using the following test case (after the setup shown in the original bug report, and replacing "e1000" by "ne2k_pci" in the run-emulator.sh script to avoid a panic in the e1000 driver with some qemu versions): + +QEMU_EXTRA="-icount shift=3,sleep=off" sh run-emulator.sh + +The bisection identified the following commit: + +281b2201e4e18d5b9a26e1e8d81b62b5581a13be is the first bad commit +commit 281b2201e4e18d5b9a26e1e8d81b62b5581a13be +Author: Pavel Dovgalyuk <email address hidden> +Date: Thu Mar 10 14:56:03 2016 +0300 + + icount: remove obsolete warp call + + qemu_clock_warp call in qemu_tcg_wait_io_event function is not needed + anymore, because it is called in every iteration of main_loop_wait. + + Reviewed-by: Paolo Bonzini <email address hidden> + + Signed-off-by: Pavel Dovgalyuk <email address hidden> + Message-Id: <20160310115603.4812.67559.stgit@PASHA-ISP> + Signed-off-by: Paolo Bonzini <email address hidden> + +With revision 281b2201e4e18d5b9a26e1e8d81b62b5581a13be, the test case takes 141 seconds to boot. With the previous revision, 33577b47c64435fcc2a1bc01c7e82534256f1fc3, it takes 1.7 seconds. + + +I can reproduce it. But there is one interesting thing. +When I replace "-nographic" with "-serial stdio" everything is ok, +icount works normally. + +But "-nographic" runs are very slow in icount mode. +It seems that GUI produces some events that force main loop to iterate. + +Does reverting the commit fix it? It was just a cleanup I think. + +Yes, I tried to revert (with some updates to the current code base) and the bug was fixed: + +diff --git a/cpus.c b/cpus.c +index 181ce33..e2fc972 100644 +--- a/cpus.c ++++ b/cpus.c +@@ -1172,6 +1172,13 @@ static void qemu_tcg_rr_wait_io_event(CPUState *cpu) + { + while (all_cpu_threads_idle()) { + stop_tcg_kick_timer(); ++ ++ qemu_mutex_unlock_iothread(); ++ replay_mutex_lock(); ++ qemu_mutex_lock_iothread(); ++ qemu_start_warp_timer(); ++ replay_mutex_unlock(); ++ + qemu_cond_wait(cpu->halt_cond, &qemu_global_mutex); + } + + + +I tested Pavel's patch, applying it to master (c447afd5783b9237fa51b7a85777007d8d568bfc), but I'm afraid it only made things worse - qemu has now been booting the test kernel for 30 minutes but the boot has still not completed. The last console messages printed were: + +piix 0000:00:01.1: not 100% native mode: will probe irqs later + ide0: BM-DMA at 0xc100-0xc107 + ide1: BM-DMA at 0xc108-0xc10f + +Running strace -p on the qemu process shows it calling ppoll once per second: + +ppoll([{fd=0, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=11, events=POLLIN}], 5, {tv_sec=1, tv_nsec=0}, NULL, 8) = 0 (Timeout) +ppoll([{fd=0, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=11, events=POLLIN}], 5, {tv_sec=1, tv_nsec=0}, NULL, 8) = 0 (Timeout) +ppoll([{fd=0, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=11, events=POLLIN}], 5, {tv_sec=1, tv_nsec=0}, NULL, 8) = 0 (Timeout) +ppoll([{fd=0, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=11, events=POLLIN}], 5, {tv_sec=1, tv_nsec=0}, NULL, 8) = 0 (Timeout) +ppoll([{fd=0, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=11, events=POLLIN}], 5, {tv_sec=1, tv_nsec=0}, NULL, 8) = 0 (Timeout) +ppoll([{fd=0, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=11, events=POLLIN}], 5, {tv_sec=1, tv_nsec=0}, NULL, 8) = 0 (Timeout) + + + +We figured out that there are races or something. +I run QEMU under Ubuntu in VirtualBox (which has 1 CPU) and it works normally. +On the real machine with multiple cores QEMU stalls with this patch. + +Looks like the bug was fixed by this commit: + +commit 013aabdc665e4256b38d8875a1a7b5e030ba98f1 +Author: Clement Deschamps <email address hidden> +Date: Sun Oct 21 16:21:03 2018 +0200 + + icount: fix deadlock when all cpus are sleeping + + When all cpus are sleeping (e.g in WFI), to avoid a deadlock + in the main_loop, wake it up in order to start the warp timer. + + Signed-off-by: Clement Deschamps <email address hidden> + Message-Id: <email address hidden> + Signed-off-by: Paolo Bonzini <email address hidden> + + diff --git a/results/classifier/zero-shot/108/all/1779162 b/results/classifier/zero-shot/108/all/1779162 new file mode 100644 index 000000000..b5b629c81 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1779162 @@ -0,0 +1,111 @@ +permissions: 0.987 +graphic: 0.983 +semantic: 0.983 +other: 0.980 +debug: 0.980 +network: 0.978 +device: 0.975 +socket: 0.973 +PID: 0.972 +files: 0.971 +performance: 0.968 +vnc: 0.967 +boot: 0.960 +KVM: 0.956 + +qemu versions 2.10 and 2.11 have error during migration of larger guests + +== Comment: #0 - Christian Borntraeger - 2018-06-28 06:39:27 == +Migration fails with larger guests (e.g. 10GB) on a z system prints an error message in the log + +see /var/log/libvirt/qemu/... +[...] +qemu-system-s390x: KVM_S390_SET_CMMA_BITS failed: Bad address + +This messes up guest state for the CMMA values (guest data corruption) + +This is fixed with + +commit 46fa893355e0bd88f3c59b886f0d75cbd5f0bbbe +Author: Claudio Imbrenda <email address hidden> +AuthorDate: Thu Jan 18 18:51:44 2018 +0100 +Commit: Cornelia Huck <email address hidden> +CommitDate: Mon Jan 22 11:04:52 2018 +0100 + + s390x: fix storage attributes migration for non-small guests + + Fix storage attribute migration so that it does not fail for guests + with more than a few GB of RAM. + With such guests, the index in the buffer would go out of bounds, + usually by large amounts, thus receiving -EFAULT from the kernel. + Migration itself would be successful, but storage attributes would then + not be migrated completely. + + This patch fixes the out of bounds access, and thus migration of all + storage attributes when the guest have large amounts of memory. + + Cc: <email address hidden> + Signed-off-by: Claudio Imbrenda <email address hidden> + Fixes: 903fd80b03243476 ("s390x/migration: Storage attributes device") + Message-Id: <email address hidden> + Reviewed-by: Christian Borntraeger <email address hidden> + Signed-off-by: Cornelia Huck <email address hidden> + +This fix is part of 2.11.1 so the qemu in bionic is fine. +The qemu in artful, as well as the qemu in the cloud archives for 16.04 need this fix, so we have +affected qemus in 17.10 and 16.04. + +Regarding 16.04: +The bug only triggers for host kernels >= 4.13 - in other words when you combine HWE kernel with the qemu from the cloud archive. + +As discussed on IRC, this isn't important for the last week of Artful before EOL. +But it is for the Cloud Archives longer time I'd think. + +So I added a UCA task for them to take a look. + +Hello Christian and Frank, + +Thanks for reporting this and making Ubuntu better. Very much appreciate your details bug description as well. + +I'm working on backporting this to Pike and will update the bug with more details soon. + +Thanks, +Corey + +Hello bugproxy, or anyone else affected, + +Accepted qemu into pike-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. To enable the -proposed repository: + + sudo add-apt-repository cloud-archive:pike-proposed + sudo apt-get update + +Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-pike-needed to verification-pike-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-pike-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +------- Comment From <email address hidden> 2018-06-29 03:41 EDT------- +Fix verified with +2.10+dfsg-0ubuntu3.8~cloud1 + +Thanks for testing. Tagging verification-pike-done according to comment #4 results. + +The verification of the Stable Release Update for qemu has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + + +This bug was fixed in the package qemu - 1:2.10+dfsg-0ubuntu3.8~cloud1 +--------------- + + qemu (1:2.10+dfsg-0ubuntu3.8~cloud1) xenial-pike; urgency=medium + . + * d/p/s390x-fix-storage-attrs-migration-for-non-small-guests.patch: + Backported from upstream 2.11.1 release to enable successful migration + of non-small guests (LP: #1779162). + + +------- Comment From <email address hidden> 2018-07-03 09:10 EDT------- +IBM bugzilla status ->closed : Fix Released by Canonical + diff --git a/results/classifier/zero-shot/108/all/1788582 b/results/classifier/zero-shot/108/all/1788582 new file mode 100644 index 000000000..d2f862907 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1788582 @@ -0,0 +1,89 @@ +KVM: 0.946 +device: 0.945 +debug: 0.940 +graphic: 0.938 +boot: 0.935 +semantic: 0.931 +permissions: 0.930 +PID: 0.927 +socket: 0.927 +vnc: 0.924 +performance: 0.924 +other: 0.918 +network: 0.916 +files: 0.904 + +Race condition during shutdown + +I ran into a bug when I started several VMs in parallel using +libvirt. The VMs are using only a kernel and a initrd (which includes a +minimal OS). The guest OS itself does a 'poweroff -f' as soon as the +login prompt shows up. So the expectaction is that the VMs will start, +the shutdown will be initiated, and the QEMU processes will then +end. But instead some of the QEMU processes get stuck in ppoll(). + +A bisect showed that the first bad commit was +0f12264e7a41458179ad10276a7c33c72024861a ("block: Allow graph changes in +bdrv_drain_all_begin/end sections"). + +I've already tried the current master (13b7b188501d419a7d63c016e00065bcc693b7d4) +since the problem might be related +to the commit a1405acddeb0af6625dd9c30e8277b08e0885bd3 ("aio: Do +aio_notify_accept only during blocking aio_poll"). But the bug is still +there. I’ve reproduced the bug on x86_64 and on s390x. + +The backtrace of a hanging QEMU process: + +(gdb) bt +#0 0x00007f5d0e251b36 in ppoll () from target:/lib64/libc.so.6 +#1 0x0000560191052014 in qemu_poll_ns (fds=0x560193b23d60, nfds=5, timeout=55774838936000) at /home/user/git/qemu/util/qemu-timer.c:334 +#2 0x00005601910531fa in os_host_main_loop_wait (timeout=55774838936000) at /home/user/git/qemu/util/main-loop.c:233 +#3 0x0000560191053119 in main_loop_wait (nonblocking=0) at /home/user/git/qemu/util/main-loop.c:497 +#4 0x0000560190baf454 in main_loop () at /home/user/git/qemu/vl.c:1866 +#5 0x0000560190baa552 in main (argc=71, argv=0x7ffde10e41c8, envp=0x7ffde10e4408) at /home/user/git/qemu/vl.c:4644 + +The used domain definition is: + +<domain type='kvm'> + <name>test</name> + <memory unit='KiB'>716800</memory> + <vcpu placement='static'>2</vcpu> + <iothreads>8</iothreads> + <os> + <type arch='x86_64' machine='pc-i440fx-3.0'>hvm</type> + <kernel>/var/lib/libvirt/images/vmlinuz-4.14.13-200.fc26.x86_64</kernel> + <initrd>/var/lib/libvirt/images/test-image-qemux86_64+modules-4.14.13-200.fc26.x86_64.cpio.gz</initrd> + <cmdline>console=hvc0 STARTUP=shutdown.sh</cmdline> + <boot dev='hd'/> + </os> + <features> + <acpi/> + </features> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>preserve</on_crash> + <devices> + <emulator>/usr/local/qemu/master/bin/qemu-system-x86_64</emulator> + <controller type='usb' index='0' model='piix3-uhci'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </controller> + <console type='pty'> + <target type='virtio' port='0'/> + </console> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <memballoon model='none'/> + </devices> +</domain> + +Do you find the cause of the bug and fix it? + +It was fixed with commit 4cf077b59fc73eec29f8b7 (see patch series https://lists.gnu.org/archive/html/qemu-block/2018-09/msg00504.html). + +Ok, so marking this bug as "fixed" according to Marc's comment. + diff --git a/results/classifier/zero-shot/108/all/1788665 b/results/classifier/zero-shot/108/all/1788665 new file mode 100644 index 000000000..b0a704973 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1788665 @@ -0,0 +1,667 @@ +other: 0.973 +permissions: 0.972 +performance: 0.971 +debug: 0.968 +graphic: 0.966 +device: 0.962 +socket: 0.960 +semantic: 0.959 +files: 0.958 +PID: 0.956 +KVM: 0.955 +vnc: 0.954 +boot: 0.945 +network: 0.944 + +Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM using "Spectre" protection + +Windows 10 (1803) VM using VGA passthrough via qemu script. + +After upgrading Windows 10 Pro VM to version 1803, or possibly after applying the March/April security updates from Microsoft, the VM would show low 2D graphics performance (sluggishness in 2D applications and low Passmark results). + +Turning off Spectre vulnerability protection in Windows remedies the issue. + +Expected behavior: +qemu/kvm hypervisor to expose firmware capabilities of host to guest OS - see https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms + +Background: + +Starting in March or April Microsoft began to push driver updates in their updates / security updates. See https://support.microsoft.com/en-us/help/4073757/protect-your-windows-devices-against-spectre-meltdown + +One update concerns the Intel microcode - see https://support.microsoft.com/en-us/help/4100347. It is activated by default within Windows. + +Once the updates are applied within the Windows guest, 2D graphics performance drops significantly. Other performance benchmarks are not affected. + +A bare metal Windows installation does not display a performance loss after the update. See https://heiko-sieger.info/low-2d-graphics-benchmark-with-windows-10-1803-kvm-vm/ + +Similar reports can be found here: +https://www.reddit.com/r/VFIO/comments/97unx4/passmark_lousy_2d_graphics_performance_on_windows/ + +Hardware: + +6 core Intel Core i7-3930K (-MT-MCP-) + +Host OS: +Linux Mint 19/Ubuntu 18.04 +Kernel: 4.15.0-32-generic x86_64 +Qemu: QEMU emulator version 2.11.1 +Intel microcode (host): 0x714 +dmesg | grep microcode +[ 0.000000] microcode: microcode updated early to revision 0x714, date = 2018-05-08 +[ 2.810683] microcode: sig=0x206d7, pf=0x4, revision=0x714 +[ 2.813340] microcode: Microcode Update Driver: v2.2. + +Note: I manually updated the Intel microcode on the host from 0x713 to 0x714. However, both microcode versions produce the same result in the Windows guest. + +Guest OS: +Windows 10 Pro 64 bit, release 1803 + + + +QEMU is already capable of exposing the new CPU features to guests, so possibly a mis-configuration. Please provide the full QEMU command line args you are using for this guest too. + +Thanks for the reply. I understand that the CPU features are exposed. However, is the host-side Intel microcode exposed to the guest? + +Here is my qemu command: + +qemu-system-x86_64 \ + -runas user \ + -monitor stdio \ + -serial none \ + -parallel none \ + -nodefaults \ + -nodefconfig \ + -name $vmname,process=$vmname \ + -machine q35,accel=kvm,kernel_irqchip=on \ +-cpu host,kvm=off,hv_vendor_id=1234567890ab,hv_vapic,hv_time,hv_relaxed,hv_spinlocks=0x1fff \ + -smp 12,sockets=1,cores=6,threads=2 \ + -m 16G \ + -mem-path /dev/hugepages \ + -mem-prealloc \ + -balloon none \ + -rtc base=localtime,clock=host \ + -vga none \ + -nographic \ + -soundhw hda \ + -device vfio-pci,host=02:00.0,multifunction=on \ + -device vfio-pci,host=02:00.1 \ + -device vfio-pci,host=00:1a.0 \ + -device vfio-pci,host=08:00.0 \ + -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \ + -drive if=pflash,format=raw,file=/tmp/my_vars.fd \ + -boot order=c \ + -drive id=disk0,if=virtio,cache=none,format=raw,aio=native,discard=unmap,detect-zeroes=unmap,file=/dev/mapper/lm13-win10 \ + -drive id=disk1,if=virtio,cache=none,format=raw,aio=native,file=/dev/mapper/photos-photo_stripe \ + -drive id=disk2,if=virtio,cache=none,format=raw,aio=native,file=/dev/mapper/media-photo_raw \ + -netdev type=tap,id=net0,ifname=vmtap0,vhost=on \ + -device virtio-net-pci,netdev=net0,mac=00:16:3e:00:01:01 + + +By the way, the same 2D performance drop happens when I run the VM as root. + + +You're mis-understanding how microcode works a little. Microcode is loaded into physical CPUs in the host. This affects everything that runs on these CPUs thereafter. A KVM guest is merely a process running on the host CPUs, so it is affected by the updated microcode. There is no notion of the virtual CPUs having a different microcode. + +The doc you pointed to above + +https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms + +indicates that you must install the microcode in the host, which enables new CPUs features. These features should then be exposed to the guest. + +You say you've installed the microcode which is good, but did you also update the kernel ? + +Host kernel updates were required in order for KVM to be able to expose the new features from the microcode, to the guest. Essentially if your guest kernel shows "pti ssbd ibrs ibpb stibp" features as present, then thanks to your "-cpu host" usage, the guest should see them too. + + + +Thanks for your explanations - I thought so too. + +The new Intel microcode is applied, as you can see: +dmesg | grep microcode +[ 0.000000] microcode: microcode updated early to revision 0x714, date = 2018-05-08 +[ 2.810683] microcode: sig=0x206d7, pf=0x4, revision=0x714 +[ 2.813340] microcode: Microcode Update Driver: v2.2. + +The host kernel has the features you listed: +cat /proc/cpuinfo | grep flags +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts flush_l1d + +I'm still looking for a way to display the CPU flags under Windows. + +Here is my systeminfo (Windows) output: + + systeminfo + +Host Name: DESKTOP-K3DEAH0 +OS Name: Microsoft Windows 10 Pro +OS Version: 10.0.17134 N/A Build 17134 +OS Manufacturer: Microsoft Corporation +OS Configuration: Standalone Workstation +OS Build Type: Multiprocessor Free +Registered Owner: win +Registered Organization: +Product ID: 00330-80000-00000-AA554 +Original Install Date: 05-Jun-18, 22:58:49 +System Boot Time: 25-Aug-18, 00:17:19 +System Manufacturer: QEMU +System Model: Standard PC (Q35 + ICH9, 2009) +System Type: x64-based PC +Processor(s): 1 Processor(s) Installed. + [01]: Intel64 Family 6 Model 45 Stepping 7 GenuineIntel ~3200 Mhz +BIOS Version: EFI Development Kit II / OVMF 0.0.0, 06-Feb-15 +Windows Directory: C:\WINDOWS +System Directory: C:\WINDOWS\system32 +Boot Device: \Device\HarddiskVolume2 +System Locale: en-us;English (United States) +Input Locale: en-us;English (United States) +Time Zone: (UTC+02:00) Jerusalem +Total Physical Memory: 16,380 MB +Available Physical Memory: 12,955 MB +Virtual Memory: Max Size: 17,380 MB +Virtual Memory: Available: 13,233 MB +Virtual Memory: In Use: 4,147 MB +Page File Location(s): C:\pagefile.sys +Domain: WORKGROUP +Logon Server: \\DESKTOP-K3DEAH0 +Hotfix(s): 4 Hotfix(s) Installed. + [01]: KB4338832 + [02]: KB4343669 + [03]: KB4343902 + [04]: KB4343909 +Network Card(s): 1 NIC(s) Installed. + [01]: Red Hat VirtIO Ethernet Adapter + Connection Name: Ethernet 6 + DHCP Enabled: No + IP address(es) + [01]: 192.168.0.200 +Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed. + +Daniel Berrange: ...Essentially if your guest kernel shows "pti ssbd ibrs ibpb stibp" features as present, then thanks to your "-cpu host" usage, the guest should see them too. + +1. I changed my qemu start script and added +vmx: +-cpu host,kvm=off,hv_vendor_id=1234567890ab,hv_vapic,hv_time,hv_relaxed,hv_spinlocks=0x1fff,+vmx \ + +2. I installed cygwin on the Windows guest and ran cat /proc/cpuinfo. Here the output: + +processor : 11 +vendor_id : GenuineIntel +cpu family : 6 +model : 45 +model name : Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz +stepping : 7 +cpu MHz : 3200.000 +cache size : 4096 KB +physical id : 0 +siblings : 12 +core id : 5 +cpu cores : 6 +apicid : 11 +initial apicid : 11 +fpu : yes +fpu_exception : yes +cpuid level : 13 +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 ss ht pni vmx ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes xsave osxsave avx hypervisor lahf_lm arat xsaveopt tsc_adjust +clflush size : 64 +cache_alignment : 64 +address sizes : 40 bits physical, 48 bits virtual +power management: + +The flags "pti ssbd ibrs ibpb stibp" are not listed! How do I pass these flags/features to the Windows guest? + +For comparison, here the Linux/host cat /proc/cpuinfo (partial): + +processor : 11 +vendor_id : GenuineIntel +cpu family : 6 +model : 45 +model name : Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz +stepping : 7 +microcode : 0x714 +cpu MHz : 4200.015 +cache size : 12288 KB +physical id : 0 +siblings : 12 +core id : 5 +cpu cores : 6 +apicid : 11 +initial apicid : 11 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts flush_l1d +bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf +bogomips : 6399.97 +clflush size : 64 +cache_alignment : 64 +address sizes : 46 bits physical, 48 bits virtual +power management: + + +I'm not convinced we can trust the output from cygwin wrt CPU flags. A better test would be to install a modern Linux guest which has the mitigations, and see if that reports the flags. + + +Thanks, I will do that tomorrow and report back. + +Whew, after some hurdles I managed to install a Linux Mint 19 guest (Ubuntu 18.04). After all updates, here the output: + +$ dmesg | grep microcode +[ 0.036780] core: PEBS disabled due to CPU errata, please upgrade microcode + +So the microcode in the guest is not loaded! But see below: + +$ cat /proc/cpuinfo | grep flags +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm cpuid_fault pti ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid tsc_adjust xsaveopt arat + +Here is the qemu command I use for this Linux guest (it is almost identical to the Windows 10 VM command): + +qemu-system-x86_64 \ + -runas user \ + -monitor stdio \ + -serial none \ + -parallel none \ + -nodefaults \ + -nodefconfig \ + -name $vmname,process=$vmname \ + -machine q35,accel=kvm,kernel_irqchip=on \ +-cpu host,kvm=off,hv_vendor_id=1234567890ab,hv_vapic,hv_time,hv_relaxed,hv_spinlocks=0x1fff \ + -smp 6,sockets=1,cores=3,threads=2 \ + -m 16G \ + -mem-path /dev/hugepages \ + -mem-prealloc \ + -balloon none \ + -rtc base=localtime,clock=host \ + -vga none \ + -nographic \ + -soundhw hda \ + -device vfio-pci,host=02:00.0,multifunction=on \ + -device vfio-pci,host=02:00.1 \ + -device vfio-pci,host=00:1a.0 \ + -device vfio-pci,host=08:00.0 \ + -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \ + -drive if=pflash,format=raw,file=/tmp/my_vars.fd \ + -boot order=c \ + -drive id=disk0,if=virtio,cache=none,format=raw,file=/home/user/win.img \ + -netdev type=tap,id=net0,ifname=vmtap0,vhost=on \ + -device virtio-net-pci,netdev=net0,mac=00:16:3e:00:01:01 + + +Kernel: 4.15.0-33-generic x86_64 + +$ grep microcode /proc/cpuinfo +microcode : 0x1 +microcode : 0x1 +microcode : 0x1 +microcode : 0x1 +microcode : 0x1 +microcode : 0x1 + +In essence: +The microcode is NOT loaded in the Linux VM. However, the following feature flags are listed: "pti ssbd ibrs ibpb". The "stibp" flag is missing. + +Hope this helps. + +Downloaded and ran the spectre-meltdown-checker.sh + +$ spectre-meltdown-checker.sh +Spectre and Meltdown mitigation detection tool v0.39+ + +Checking for vulnerabilities on current system +Kernel is Linux 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 x86_64 +CPU is Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz + +Hardware check +* Hardware support (CPU microcode) for mitigation techniques + * Indirect Branch Restricted Speculation (IBRS) + * SPEC_CTRL MSR is available: YES + * CPU indicates IBRS capability: YES (SPEC_CTRL feature bit) + * Indirect Branch Prediction Barrier (IBPB) + * PRED_CMD MSR is available: YES + * CPU indicates IBPB capability: YES (SPEC_CTRL feature bit) + * Single Thread Indirect Branch Predictors (STIBP) + * SPEC_CTRL MSR is available: YES + * CPU indicates STIBP capability: NO + * Speculative Store Bypass Disable (SSBD) + * CPU indicates SSBD capability: YES (Intel SSBD) + * L1 data cache invalidation + * FLUSH_CMD MSR is available: YES + * Enhanced IBRS (IBRS_ALL) + * CPU indicates ARCH_CAPABILITIES MSR availability: NO + * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO + * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO + * CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO + * Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA): NO + * CPU microcode is known to cause stability problems: NO (model 0x2d family 0x6 stepping 0x7 ucode 0x1 cpuid 0x206d7) + * CPU microcode is the latest known available version: NO (latest known version is 0x714 according to Intel Microcode Guidance, August 8 2018) +* CPU vulnerability to the speculative execution attack variants + * Vulnerable to Variant 1: YES + * Vulnerable to Variant 2: YES + * Vulnerable to Variant 3: YES + * Vulnerable to Variant 3a: YES + * Vulnerable to Variant 4: YES + * Vulnerable to Variant l1tf: YES + +CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' +* Mitigated according to the /sys interface: YES (Mitigation: __user pointer sanitization) +* Kernel has array_index_mask_nospec: YES (1 occurrence(s) found of x86 64 bits array_index_mask_nospec()) +* Kernel has the Red Hat/Ubuntu patch: NO +* Kernel has mask_nospec64 (arm64): NO +> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization) + +CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' +* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB, IBRS_FW) +* Mitigation 1 + * Kernel is compiled with IBRS support: YES + * IBRS enabled and active: YES (for kernel and firmware code) + * Kernel is compiled with IBPB support: YES + * IBPB enabled and active: YES +* Mitigation 2 + * Kernel has branch predictor hardening (arm): NO + * Kernel compiled with retpoline option: YES + * Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation) +> STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability) + +CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' +* Mitigated according to the /sys interface: YES (Mitigation: PTI) +* Kernel supports Page Table Isolation (PTI): YES + * PTI enabled and active: YES + * Reduced performance impact of PTI: YES (CPU supports PCID, performance impact of PTI will be reduced) +* Running as a Xen PV DomU: NO +> STATUS: NOT VULNERABLE (Mitigation: PTI) + +CVE-2018-3640 [rogue system register read] aka 'Variant 3a' +* CPU microcode mitigates the vulnerability: YES +> STATUS: NOT VULNERABLE (your CPU microcode mitigates the vulnerability) + +CVE-2018-3639 [speculative store bypass] aka 'Variant 4' +* Mitigated according to the /sys interface: YES (Mitigation: Speculative Store Bypass disabled via prctl and seccomp) +* Kernel supports speculation store bypass: YES (found in /proc/self/status) +> STATUS: NOT VULNERABLE (Mitigation: Speculative Store Bypass disabled via prctl and seccomp) + +CVE-2018-3615/3620/3646 [L1 terminal fault] aka 'Foreshadow & Foreshadow-NG' +* Mitigated according to the /sys interface: YES (Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable) +> STATUS: NOT VULNERABLE (Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable) + + + +It shows that the microcode is not updated, and reports vulnerability. + +If I understand correctly, the Linux VM should not install the microcode, but report the microcode features of the host. + + * CPU indicates STIBP capability: NO + +Obviously stibp is not passed to the guest. + +Is there any other/better way to pass the host cpu capabilities to the VM? + + +> Whew, after some hurdles I managed to install a Linux Mint 19 guest (Ubuntu 18.04). After all updates, here the output: +> +> $ dmesg | grep microcode +> [ 0.036780] core: PEBS disabled due to CPU errata, please upgrade microcode +> +> So the microcode in the guest is not loaded! But see below: + +As mentioned earlier there is no concept of loading microcode in the guest. Once it is loaded in the host it applies to everything running on that host. + +This message appears to be caused by fact that we do not expose the current microcode version to the guest, so the guest always sees 0x1 as the microcode version, causing this PEBS check to fail. I don't think this is related to the meltdown/spectre fixes - you'd likely get that error message even on older systems before meltdown/spectre + +> $ cat /proc/cpuinfo | grep flags +> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm cpuid_fault pti ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid tsc_adjust xsaveopt arat + +This looks correct - the guest has seen the ssbd, ibrs, ibpb features as required. + +> The microcode is NOT loaded in the Linux VM. However, the following feature flags are listed: "pti > ssbd ibrs ibpb". The "stibp" flag is missing. + +The "stipb" flag is not relevant to guests, it is only needed by the hypervisor, so it is to be expected that the guest doesn't see it. + +Everything seen from this Linux guest says that QEMU / KVM is doing the right thing and the guest has the features needed to mitigate Spectre/Meltdown. + +The possibilities left are that either your Windows guest is lacking software updates that could perhaps improve its performance, or that 2D graphics really is that awful in combination with spectre/meltdown fixes. + +>The possibilities left are that either your Windows guest is lacking software updates that could perhaps improve its performance, or that 2D graphics really is that awful in combination with spectre/meltdown fixes. + +Thanks Daniel. There are two problems with this explanation: + +1. A native "bare metal" Windows 10 (1803) installation with all updates applied does NOT have any 2D performance problems. See my attachment (benchmarks) in the original post. + +2. Both the Windows VM and the Linux VM do not see the microcode (version?), and therefore do not know about the Spectre vulnerability mitigation in the host kernel. However, the Microsoft document https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms suggests that Microsoft Hyper-V can be configured to expose new processor capabilities to guest virtual machines, specifically the ones made available through the microcode updates. Here a quote from the above Microsoft website: +"Firmware updates from your OEM may contain new processor capabilities that can be used to protect against CVE-2017-5715 (IBRS, STIBP, IBPB). Once the virtualization host's firmware has been updated, the hypervisor can make these additional capabilities available to guest virtual machines after taking the following steps." + +The ideal behavior of qemu/kvm would be to expose the microcode capabilities to the guest (I suppose this happens partially as seen by the presence of the "pti ssbd ibrs ibpb" flags), but obviously something is missing. + +But the real important question is this: +In the above scenario, are the VMs protected from Spectre vulnerabilities, simply by having the microcode installed in the host? Even when I disable the Spectre protection inside the Windows VM? + +There is always a performance differential between bare metal & VMs. The actual amount varies depending on alot of different factors and meltdown/spectre have had an effect here - the actual perf hit depends on the CPU models & virtual hardware and more besides - ranging anywhere from 0% to 40% perf hit + +The guest VM *does* know about the Spectre mitigation because it is being given the "ibrs" feature which is sufficient for guest OS to mitigate the problem. STIBP is only needed by the host. Exposing microcode version to the guest is not required as OS should only need to look at the features provided to determine if it can mitigate the flaws. The complaints about microcode version from spectre-meltdown-checker.sh are a bug in that script. The important parts are the "STATUS: NOT VULNERABLE" lines + +If you disable Spectre protection in the Windows VM, then it is not protected from Spectre. The hypervisor protects itself, and exposes the CPU feature(s) that enable the guest to activate its own protection. The hypervisor won't protect the guest directly - it just gives it the tools needed to protect itself. + +> If you disable Spectre protection in the Windows VM, then it is not protected from Spectre. The hypervisor protects itself, and exposes the CPU feature(s) that enable the guest to activate its own protection. The hypervisor won't protect the guest directly - it just gives it the tools needed to protect itself. + +Thanks for the indepth explanation. In other words, Spectre protection inside the Windows VM needs to be enabled to work. + +The only problem is that Windows (or a Linux VM for that matter) either +1. does not recognize some CPU features (as introduced by the microcode on the host); +2. uses code to mitigate the Spectre vulnerability that doesn't work well inside a VM. + +Since I have a comparison versus Windows bare metal with Spectre protection enabled, there might be something that needs improving in the hypervisor. + +In any case, Spectre protection has to be enabled in the Windows VM to be effective, which is a real bummer considering the performance penalty. + +Any chance someone can look into the why there is this performance hit ONLY inside the qemu-kvm VM? Maybe there is a solution to it. + +I find it interesting this is a slow down with PCI passthrough - that's pretty much the case you'd expect there to be least change; it shouldn't be generating lots of vm exit's for example which you'd expect could have been made slower by the recent security changes. + +I suppose one thing you could try is profiling on the host to see if more time is spent in the host kernel or qemu when running the 2d tests with the new vs older windows; if it points to some particular hot spot there then perhaps it might be possible to understand why. + + +Here is another person confirming the bug, with a little more details: + +https://bugzilla.kernel.org/show_bug.cgi?id=200877#c2 + +Sorry for reporting the bug twice, but it is unclear to me whose going to take action. + +I don't have the nvidia for pass through to try this with; but I suggest that you try the following: + + a) Start a windows vm running an older version unaffected by the bug and start a 2d test + b) run 'perf top' on the host while the test is running and capture the results + - make sure you have debug symbols for both qemu (and related libraries) and the kernel + c) now repeat a/b for the newer version of windows that's affected + +add the results of the 'perf top' to this bug; hopefully we'll be able to see qemu or the kernel spending a lot more time in some particular routine in the new version. + +I won’t be able to run any tests for the next 16 days at the very least, as I’m traveling. + + + +> On 5 Sep 2018, at 13:21, Dr. David Alan Gilbert <email address hidden> wrote: +> +> I don't have the nvidia for pass through to try this with; but I suggest +> that you try the following: +> +> a) Start a windows vm running an older version unaffected by the bug and start a 2d test +> b) run 'perf top' on the host while the test is running and capture the results +> - make sure you have debug symbols for both qemu (and related libraries) and the kernel +> c) now repeat a/b for the newer version of windows that's affected +> +> add the results of the 'perf top' to this bug; hopefully we'll be able +> to see qemu or the kernel spending a lot more time in some particular +> routine in the new version. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1788665 +> +> Title: +> Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM +> using "Spectre" protection +> +> Status in QEMU: +> New +> +> Bug description: +> Windows 10 (1803) VM using VGA passthrough via qemu script. +> +> After upgrading Windows 10 Pro VM to version 1803, or possibly after +> applying the March/April security updates from Microsoft, the VM would +> show low 2D graphics performance (sluggishness in 2D applications and +> low Passmark results). +> +> Turning off Spectre vulnerability protection in Windows remedies the +> issue. +> +> Expected behavior: +> qemu/kvm hypervisor to expose firmware capabilities of host to guest OS - see https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms +> +> Background: +> +> Starting in March or April Microsoft began to push driver updates in +> their updates / security updates. See https://support.microsoft.com +> /en-us/help/4073757/protect-your-windows-devices-against-spectre- +> meltdown +> +> One update concerns the Intel microcode - see +> https://support.microsoft.com/en-us/help/4100347. It is activated by +> default within Windows. +> +> Once the updates are applied within the Windows guest, 2D graphics +> performance drops significantly. Other performance benchmarks are not +> affected. +> +> A bare metal Windows installation does not display a performance loss +> after the update. See https://heiko-sieger.info/low-2d-graphics- +> benchmark-with-windows-10-1803-kvm-vm/ +> +> Similar reports can be found here: +> https://www.reddit.com/r/VFIO/comments/97unx4/passmark_lousy_2d_graphics_performance_on_windows/ +> +> Hardware: +> +> 6 core Intel Core i7-3930K (-MT-MCP-) +> +> Host OS: +> Linux Mint 19/Ubuntu 18.04 +> Kernel: 4.15.0-32-generic x86_64 +> Qemu: QEMU emulator version 2.11.1 +> Intel microcode (host): 0x714 +> dmesg | grep microcode +> [ 0.000000] microcode: microcode updated early to revision 0x714, date = 2018-05-08 +> [ 2.810683] microcode: sig=0x206d7, pf=0x4, revision=0x714 +> [ 2.813340] microcode: Microcode Update Driver: v2.2. +> +> Note: I manually updated the Intel microcode on the host from 0x713 to +> 0x714. However, both microcode versions produce the same result in the +> Windows guest. +> +> Guest OS: +> Windows 10 Pro 64 bit, release 1803 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1788665/+subscriptions + + + +Hello All, + +I can reproduce this on two different systems with Ivy-Bridge CPUs: +Xeon E5 2667v2 / X9SRA running Fedora 28, with Windows 10 1803 as KVM guest +Xeon E3 1270v2 / X9SCM running Archlinux, with Windows 10 1803 as KVM guest + +The performance degradation doesn't occur when the Windows 10 guest disables the spectre mitigation using "InSpectre.exe", or when the spec-ctrl flag is disabled in libvirt, or when the cpu-microcode isn't updated in the host. + +I followed the latest suggestion, and enabled "--enable-debug" in qemu-3.0 and also compiled kernel-4.17.19 with CONFIG_DEBUG_INFO=y. However I cannot see any differences while running "perf top" in the host between the affected/unaffected version of windows. CPU usage seems to be the same. + +Any hints would be greatly appreciated. + +Best, +George + +I did a git-bisect between 4.14.18(bad) and 4.14.10(good). Unsurprisingly, this is the first "bad" commit: + + KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL + + commit d28b387fb74da95d69d2615732f50cceb38e9a4d + + +George + +George: Can you confirm how your graphics is setup; the original reporter had an Nvidia card with PCI passthrough; is yours the same? + +Yes, it's an Nvidia GTX 1060 6GB with PCI passthrough to a Windows 1803 KVM guest. As far as I can tell my setup is very similar to Heiko's, only I am using libvirt, not qemu directly. + +It seems that this "bug" affects only 2D-performance mediated through GDI in Windows (CPU-, not GPU-driven). There have been reports that GDI switches a lot between user/kernel space. + +Are vmexits triggered when the guest switches from user- to kernel-space? Could this be subsequently causing IRBS swaps and degradation of performance? Then again, "perf kvm --host stat live" doesn't report an increase in vmexits. + +It would be interesting to know whether this behavior persists under other hypervisors (ESXi or Windows Server 2016). + +I don't think we should see a vmexit on a guest user<->kernel switch. + +You could try a kvm trace: + +trace-cmd record -b 20000 -e kvm + +run your test, then ctrl-c +then + +trace-cmd report + +and you can see all the reasons for exit and see if there are any major differences. + +Yes, it would be good to know if it happened under other hypervisors; although this one is tricky since it's Windows guest with nvidia closed drivers, so it's a bit tricky to know what's going on. + +David, your suggestion seemed helpful, at least there is a difference in the pattern of vmentries and vmexits. See the snapshot attached. + +Explanation of snapshot_1: +Two windows of kernelshark with trace.dats obtained using the command from above; the left window (trace.dat) is with spec-ctrl feature disabled, the right window with spec-ctrl enabled (default). +CPU9 runs the emulator (emulatorpin), and the spikes seen are kvm_set_irq every 16ms. CPUs 2-7 and 19-15 run the vcpu threads. +Halfway through the trace in the snapshot the test begins (passmark 2d image rendering). The VM without spec-ctrl triggers vmentries/vmexits much more often than the VM with spec-ctrl. I could not spot a difference in the pattern of the vmentries/vmexits themselves (snapshot_2 below), only their frequency seems to differ. + +Does anybody have an idea of what is going on? + +George + +snapshot_2 showing the pattern of vmentries/vmexits from the previous comment ("zoom-in"). + +Have we got this the right way around???? +So you're saying the one with spec-ctrl disabled is faster, but has a lot more kvm-exits? + +Just to be sure, I repeated it, with the same result. I have the impression that it might be the time spent between a vmentry and a vmexit that matters in the CPU performance of the guest. I am no expert though. + +This is what I am seeing in the graphs: +vmentry----interval A(s)----vmexit----interval B(s)----vmentry.... +"interval A" seems to be constant, whereas "interval B" seems to be shorter in the VM without spec-ctrl. This would mean that the CPU performs a vmentry much quicker than in the VM with spec-ctrl enabled. I cannot see why though. + +I uploaded the traces here: +https://drive.google.com/open?id=1_2T79_bvLUX-o12XtPRnDQf_nlH7a2tF + +I also tried to give ESXi a try. VMware lets me download only 6.7 from their site. Although I have a workstation motherboard (Supermicro X9SRA), it won't let me start a VM with IOMMU enabled, it complains about failing to register the passthrough GPU. + +It doesn't surprise me too much that the time spent on the host between exit&entry is higher on a host dealing with spec-ctrl; but I wouldn't really expect it to change depending on the guests settings. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +I've switched hosts so I would have to run a series of tests to compare. + +There are a number of new variables: + +1. Windows 10 release (I'm now on Windows 2004) +2. My host OS is now Manjaro +3. CPU is now AMD Ryzen 3900X (before it was Intel 3930k) +4. Kernel is 5.8.18-1-MANJARO +5. qemu 5.1.0 +6. libvirt 6.5.0 +7. New VM configuration using virt-manager/libvirt with EPYC-IBPB model instead of host-passthrough, instead of a qemu bash script to launch the VM. + +Time permitting, I plan to replace Manjaro for a Ubuntu 20.04 based distro. But this will not happen in the very near future. + +In the meantime I will do some a/b tests with spectre protection under Windows enabled/disabled to see if it is still an issue. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1801073 b/results/classifier/zero-shot/108/all/1801073 new file mode 100644 index 000000000..121a62559 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1801073 @@ -0,0 +1,93 @@ +graphic: 0.945 +other: 0.940 +PID: 0.937 +permissions: 0.932 +network: 0.930 +KVM: 0.930 +semantic: 0.927 +socket: 0.923 +performance: 0.920 +files: 0.918 +vnc: 0.917 +debug: 0.909 +boot: 0.905 +device: 0.904 + +util/zbin.c:390:37: error: absolute value function 'abs' given an argument of type 'long int' but has parameter of type 'int' which may cause truncation of value [-Werror=absolute-value] + +For qemu-3.0.0 I see with GCC 9 compiler a new warning: + +$ make -j1 -C roms pxerom VERBOSE=1 V=1 +make: Entering directory '/home/abuild/rpmbuild/BUILD/qemu-3.0.0/roms' +make -C ipxe/src CONFIG=qemu \ + PACKAGING_TIMESTAMP=1534273834 \ + CROSS_COMPILE= \ + bin/8086100e.rom bin/808610d3.rom bin/80861209.rom bin/10500940.rom bin/10222000.rom bin/10ec8139.rom bin/1af41000.rom bin/15ad07b0.rom +make[1]: Entering directory '/home/abuild/rpmbuild/BUILD/qemu-3.0.0/roms/ipxe/src' +gcc -Wall -W -Wformat-nonliteral -O2 -g -Werror util/zbin.c -llzma -o util/zbin +util/zbin.c: In function 'process_zinfo_add': +util/zbin.c:390:37: error: absolute value function 'abs' given an argument of type 'long int' but has parameter of type 'int' which may cause truncation of value [-Werror=absolute-value] + 390 | ( ( addend < 0 ) ? "-" : "" ), abs ( addend ), size, + | ^~~ +util/zbin.c:398:37: error: absolute value function 'abs' given an argument of type 'long int' but has parameter of type 'int' which may cause truncation of value [-Werror=absolute-value] + 398 | ( ( addend < 0 ) ? "-" : "" ), abs ( addend ), size, + | ^~~ +util/zbin.c:419:37: error: absolute value function 'abs' given an argument of type 'long int' but has parameter of type 'int' which may cause truncation of value [-Werror=absolute-value] + 419 | ( ( addend < 0 ) ? "-" : "" ), abs ( addend ), + | ^~~ +cc1: all warnings being treated as errors +make[1]: *** [Makefile.housekeeping:1368: util/zbin] Error 1 + +This bug would be better reported to the upstream for the ipxe rom -- we just ship the source code because we ship the binary. + + +Thank you, I contacted IPXE folks. + +Should be fixed here: +http://git.ipxe.org/ipxe.git/commitdiff/956f6a722 + +Btw. how do you pull changes from ipxe into qemu repo? + +On Mon, 21 Jan 2019 at 12:47, Martin Liska <email address hidden> wrote: +> +> Should be fixed here: +> http://git.ipxe.org/ipxe.git/commitdiff/956f6a722 +> +> Btw. how do you pull changes from ipxe into qemu repo? + +The next step is a QEMU patch which updates our git submodule +to point at a version of IPXE with the fix and also has the +pre-built binaries corresponding to that new version. + +Gerd, it looks like you did the last IPXE update -- could +we do another one with this fix in it? + +thanks +-- PMM + + +On Mon, Jan 21, 2019 at 12:57:16PM +0000, Peter Maydell wrote: +> On Mon, 21 Jan 2019 at 12:47, Martin Liska <email address hidden> wrote: +> > +> > Should be fixed here: +> > http://git.ipxe.org/ipxe.git/commitdiff/956f6a722 +> > +> > Btw. how do you pull changes from ipxe into qemu repo? +> +> The next step is a QEMU patch which updates our git submodule +> to point at a version of IPXE with the fix and also has the +> pre-built binaries corresponding to that new version. +> +> Gerd, it looks like you did the last IPXE update -- could +> we do another one with this fix in it? + +Yes, makes sense to do that, last ipxe rebase was more than a year ago. + +cheers, + Gerd + + + +In QEMU commit fd813c72392a712022d5d75a9 we upgraded our ipxe, so this bug should now be fixed in git master and in the upcoming 4.0 release. + + diff --git a/results/classifier/zero-shot/108/all/1804961 b/results/classifier/zero-shot/108/all/1804961 new file mode 100644 index 000000000..23a53a8bd --- /dev/null +++ b/results/classifier/zero-shot/108/all/1804961 @@ -0,0 +1,179 @@ +semantic: 0.976 +graphic: 0.975 +permissions: 0.973 +other: 0.972 +debug: 0.971 +PID: 0.971 +device: 0.970 +performance: 0.968 +network: 0.967 +socket: 0.966 +vnc: 0.966 +files: 0.964 +boot: 0.956 +KVM: 0.953 + +qemu-system-aarch64: Windows 10 ARM64 BSoD on boot while using virt-3.0 + +When I emulate a virt-3.0 machine, Windows 10 BSoD on boot, with the error code being ACPI_BIOS_ERROR(0x000000A5), virt-2.12 boots fine. + +Windows Build: 10.0.17134.1 +QEMU version: 3.0.0 +Commandline: qemu-system-aarch64 -M virt -accel tcg,thread=multi -cpu cortex-a57 -smp 2 -m 2048 -bios QEMU_EFI.fd -device ramfb -device nec-usb-xhci -device usb-kbd -device usb-tablet -hda disk.vhd -vnc :0 + +By the way, the patch to add DBG2 table discussed here https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg02550.html works (although minor change is required to adapt to the qemu 3.0.0 code), the table is accepted by Windows (Windows require both DBG2 and SPCR to be valid for serial kernel debugging to work), so it may help further diagnosing this issue. + +On Sat, 24 Nov 2018 20:36:54 -0000 +GH Cao <email address hidden> wrote: + +> ** Description changed: +> +> When I emulate a virt-3.0 machine, Windows 10 BSoD on boot, with the +> error code being ACPI_BIOS_ERROR(0x000000A5), virt-2.12 boots fine. +> +> Windows Build: 10.0.17134.1 +> QEMU version: 3.0.0 +> Commandline: qemu-system-aarch64 -M virt -accel tcg,thread=multi -cpu cortex-a57 -smp 2 -m 2048 -bios QEMU_EFI.fd -device ramfb -device nec-usb-xhci -device usb-kbd -device usb-tablet -hda disk.vhd -vnc :0 +> +> By the way, the patch to add DBG2 table discussed here +> - https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg02550.html +> + https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg01719.html +> works (although minor change is required to adapt to the qemu 3.0.0 +> code), the table is accepted by Windows (Windows require both DBG2 and +> SPCR to be valid for serial kernel debugging to work), so it may help +> further diagnosing this issue. +> + +if you are able to attach a debugger early before guest BSODs, +you can try to use AMIL Debugger +https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/the-amli-debugger +to find out what windows doesn't like in ACPI tables. + + +@imammedo: +I am new to kernel debugging, but I managed to get some traces, hope that will help you. + +https://pastebin.com/shWUC1Pk +https://pastebin.com/n0gnSaVx + +And the namespace objects tree of virt-2.12 is this. +https://pastebin.com/GybigJ9r + +On Wed, 28 Nov 2018 19:25:07 -0000 +GH Cao <email address hidden> wrote: + +> @imammedo: +> I am new to kernel debugging, but I managed to get some traces, hope that will help you. +> +> https://pastebin.com/shWUC1Pk +> https://pastebin.com/n0gnSaVx +> + +try it with following amli options set: errbrkon traceon spewon +hopefully errbrkon will stop at the error and the rest of options should provide context + + +Could it be related to: + +commit 17ec075a651a3f9613429c2d97018fce459ed943 +Author: Eric Auger <email address hidden> +Date: Fri Jun 22 13:28:37 2018 +0100 + + hw/arm/virt: Use 256MB ECAM region by default + + With this patch, virt-3.0 machine uses a new 256MB ECAM region + by default instead of the legacy 16MB one, if highmem is set + (LPAE supported by the guest) and (!firmware_loaded || aarch64). + + Indeed aarch32 mode FW may not support this high ECAM region. + +As far as I can tell the only real differences between virt-2.12 and later at the size of the ECAM region and the max number of CPUs it supports: + +static void virt_machine_2_12_options(MachineClass *mc) +{ + VirtMachineClass *vmc = VIRT_MACHINE_CLASS(OBJECT_CLASS(mc)); + + virt_machine_3_0_options(mc); + SET_MACHINE_COMPAT(mc, VIRT_COMPAT_2_12); + vmc->no_highmem_ecam = true; + mc->max_cpus = 255; +} + + +Yeah it seems to be. Windows boots fine after I disable hi ECAM region. + + + +---Original--- +From: "Alex Bennée"<email address hidden> +Date: 2018/12/5 19:41:40 +To: "driver1998"<email address hidden>; +Subject: [Bug 1804961] Re: qemu-system-aarch64: Windows 10 ARM64 BSoD on boot while using virt-3.0 + + +Could it be related to: + +commit 17ec075a651a3f9613429c2d97018fce459ed943 +Author: Eric Auger <email address hidden> +Date: Fri Jun 22 13:28:37 2018 +0100 + + hw/arm/virt: Use 256MB ECAM region by default + + With this patch, virt-3.0 machine uses a new 256MB ECAM region + by default instead of the legacy 16MB one, if highmem is set + (LPAE supported by the guest) and (!firmware_loaded || aarch64). + + Indeed aarch32 mode FW may not support this high ECAM region. + +As far as I can tell the only real differences between virt-2.12 and +later at the size of the ECAM region and the max number of CPUs it +supports: + +static void virt_machine_2_12_options(MachineClass *mc) +{ + VirtMachineClass *vmc = VIRT_MACHINE_CLASS(OBJECT_CLASS(mc)); + + virt_machine_3_0_options(mc); + SET_MACHINE_COMPAT(mc, VIRT_COMPAT_2_12); + vmc->no_highmem_ecam = true; + mc->max_cpus = 255; +} + + +** Tags added: aarch64 acpi + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1804961 + +Title: + qemu-system-aarch64: Windows 10 ARM64 BSoD on boot while using + virt-3.0 + +Status in QEMU: + New + +Bug description: + When I emulate a virt-3.0 machine, Windows 10 BSoD on boot, with the + error code being ACPI_BIOS_ERROR(0x000000A5), virt-2.12 boots fine. + + Windows Build: 10.0.17134.1 + QEMU version: 3.0.0 + Commandline: qemu-system-aarch64 -M virt -accel tcg,thread=multi -cpu cortex-a57 -smp 2 -m 2048 -bios QEMU_EFI.fd -device ramfb -device nec-usb-xhci -device usb-kbd -device usb-tablet -hda disk.vhd -vnc :0 + + By the way, the patch to add DBG2 table discussed here + https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg01719.html + works (although minor change is required to adapt to the qemu 3.0.0 + code), the table is accepted by Windows (Windows require both DBG2 and + SPCR to be valid for serial kernel debugging to work), so it may help + further diagnosing this issue. + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1804961/+subscriptions + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1809665 b/results/classifier/zero-shot/108/all/1809665 new file mode 100644 index 000000000..d1a780e00 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1809665 @@ -0,0 +1,142 @@ +other: 0.983 +permissions: 0.979 +device: 0.978 +semantic: 0.974 +debug: 0.972 +files: 0.971 +graphic: 0.971 +vnc: 0.970 +performance: 0.968 +PID: 0.964 +socket: 0.961 +boot: 0.958 +KVM: 0.952 +network: 0.936 + +Xbox One controller USB passthrough disconnections and stops + +I can't properly passthrough my Xbox One controller to a virtual machine; it causes USB disconnections on the host, ultimately preventing it to work (at all) on the guest + +I've seen a few other cases reported in other websites, which show the same symptoms: + +- https://www.reddit.com/r/VFIO/comments/97dhbw/qemu_w10_xbox_one_controller +- https://unix.stackexchange.com/questions/452751/how-can-i-pass-through-an-xbox-one-controller-to-a-windows-vm-on-ubuntu + +This is sample: + + libusb: error [udev_hotplug_event] ignoring udev action bind + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again + libusb: error [_get_usbfs_fd] libusb couldn't open USB device + /dev/bus/usb/003/016: No such file or directory + +I think this is a quite long-standing issue, as I've been experiencing through several versions, including the current one (3.1). + +I can reproduce this 100% of the times, on multiple host O/S distributions (the current one being based on Ubuntu 18.04 x86-64). + +I compile QEMU directly from source, and execute it via commandline; the command is very long, however, the relevant part is standard (I think): + + -usb \ + -device usb-tablet \ + -device usb-host,vendorid=0x$VGAPT_XBOX_PAD_VEND_ID,productid=0x$VGAPT_XBOX_PAD_PROD_ID \ + +The guest is Windows 10 64bit. + +Do you get a different behavior if you use "-device usb-ehci" or "-device nec-usb-xhci" instead of the "-usb" parameter? + +So! These are the options and respective logs; they still don't make the controller work - it doesn't work at all. + +# option 1 + + -device nec-usb-xhci \ + -device usb-tablet \ + -device usb-host,vendorid=0x$VGAPT_XBOX_PAD_VEND_ID,productid=0x$VGAPT_XBOX_PAD_PROD_ID \ + +# log + + libusb: error [udev_hotplug_event] ignoring udev action bind + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + libusb: error [_open_sysfs_attr] open /sys/bus/usb/devices/1-10/bConfigurationValue failed ret=-1 errno=2 + libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again + libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/001/019: No such file or directory + libusb: error [udev_hotplug_event] ignoring udev action bind + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + libusb: error [_open_sysfs_attr] open /sys/bus/usb/devices/1-10/bConfigurationValue failed ret=-1 errno=2 + libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again + libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/001/020: No such file or directory + libusb: error [udev_hotplug_event] ignoring udev action bind + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] + libusb: error [_open_sysfs_attr] open /sys/bus/usb/devices/1-10/bConfigurationValue failed ret=-1 errno=2 + libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again + libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/001/021: No such file or directory + libusb: error [udev_hotplug_event] ignoring udev action bind + +# option 2 + + -device usb-ehci \ + -device usb-tablet \ + -device usb-host,vendorid=0x$VGAPT_XBOX_PAD_VEND_ID,productid=0x$VGAPT_XBOX_PAD_PROD_ID \ + +# log + + qemu-system-x86_64: Warning: speed mismatch trying to attach usb device "Controller" (full speed) to bus "usb-bus.0", port "2" (high speed) + libusb: error [udev_hotplug_event] ignoring udev action bind + qemu-system-x86_64: Warning: speed mismatch trying to attach usb device "Controller" (full speed) to bus "usb-bus.0", port "2" (high speed) + libusb: error [udev_hotplug_event] ignoring udev action bind + qemu-system-x86_64: Warning: speed mismatch trying to attach usb device "Controller" (full speed) to bus "usb-bus.0", port "2" (high speed) + libusb: error [udev_hotplug_event] ignoring udev action bind + +I've tried another game controller with the second option: + +# option 2b + + -device usb-ehci \ + -device usb-tablet \ + -device usb-host,vendorid=0x$VGAPT_ARCADE_STICK_VEND_ID,productid=0x$VGAPT_ARCADE_STICK_PROD_ID \ + +# log + + libusb: error [udev_hotplug_event] ignoring udev action bind + qemu-system-x86_64: Warning: speed mismatch trying to attach usb device "Arcade Fight Stick" (full speed) to bus "usb-bus.0", port "3" (high speed) + qemu-system-x86_64: Warning: speed mismatch trying to attach usb device "Arcade Fight Stick" (full speed) to bus "usb-bus.0", port "3" (high speed) + qemu-system-x86_64: Warning: speed mismatch trying to attach usb device "Arcade Fight Stick" (full speed) to bus "usb-bus.0", port "3" (high speed) + +and in this configuration, it doesn't work (it does with `-usb`). + +This happened to me as well, but I managed to find a solution, if I ban the xpad driver through modprobe.d, then the problem disappear. + +I added the following line: + + blacklist xpad + +To this file: /etc/modprobe.d/vfio.conf, rebooted, and then I could use my Xbox One S controller with Qemu, I am not sure if it's a xpad bug or a hardware bug. + +> This happened to me as well, but I managed to find a solution, if I ban the xpad driver through modprobe.d, then the problem disappear. + +Thanks, that's very interesting (and useful, although nowadays I use the BT connection). + +Still an issue as of QEMU 6.0.0rc2. + +I can't (still) exclude that it's an issue on the host side, although, when it comes to USB passthrough, I don't have issues with similar devices (mice, keyboards etc.). + +The module blacklist workaround works. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/157 + + diff --git a/results/classifier/zero-shot/108/all/1810 b/results/classifier/zero-shot/108/all/1810 new file mode 100644 index 000000000..02f8b73a7 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1810 @@ -0,0 +1,206 @@ +other: 0.995 +debug: 0.990 +device: 0.989 +semantic: 0.989 +graphic: 0.988 +performance: 0.987 +PID: 0.986 +permissions: 0.984 +boot: 0.980 +vnc: 0.978 +network: 0.978 +KVM: 0.969 +socket: 0.968 +files: 0.948 + +heap-buffer-overflow in esp_do_dma() +Description of problem: +Got a heap-buffer-overflow error when fuzzing the device am53c974. +Steps to reproduce: +Minimized reproducer: + +```plaintext +cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -device \ +am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ +id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest /dev/null\ + -qtest stdio +outl 0xcf8 0x80001010 +outl 0xcfc 0xc000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x05 +outl 0xc03d 0x03000000 +outl 0xc047 0x065a9d80 +outl 0xc00a 0xc10000 +write 0x65a9d 0x1 0x04 +write 0x65a9e 0x1 0x10 +outl 0xc03d 0x03000000 +outl 0xc00a 0xc10000 +outl 0xc00b 0x0800 +outl 0xc00b 0x00 +outl 0xc00b 0x0800 +outl 0xc00b 0x0800 +outl 0xc00b 0x0800 +outl 0xc00b 0x0400 +outl 0xc00b 0x0800 +outl 0xc00b 0x0800 +outw 0xc00b 0x1000 +outw 0xc00b 0x9000 +EOF +``` +Additional information: +The crash report triggered by the reproducer is: + +```plaintext +[I 0.000000] OPENED +[R +0.022834] outl 0xcf8 0x80001010 +[S +0.022864] OK +OK +[R +0.022874] outl 0xcfc 0xc000 +[S +0.022887] OK +OK +[R +0.022942] outl 0xcf8 0x80001004 +[S +0.022990] OK +OK +[R +0.023028] outw 0xcfc 0x05 +[S +0.023508] OK +OK +[R +0.023518] outl 0xc03d 0x03000000 +[S +0.023527] OK +OK +[R +0.023532] outl 0xc047 0x065a9d80 +[S +0.023537] OK +OK +[R +0.023544] outl 0xc00a 0xc10000 +[S +0.023573] OK +OK +[R +0.023581] write 0x65a9d 0x1 0x04 +[S +0.023891] OK +OK +[R +0.023900] write 0x65a9e 0x1 0x10 +[S +0.023906] OK +OK [R +0.023910] outl 0xc03d 0x03000000 +[S +0.023917] OK +OK +[R +0.023921] outl 0xc00a 0xc10000 +[S +0.023983] OK +OK +[R +0.023581] write 0x65a9d 0x1 0x04 +[S +0.023891] OK +OK +[R +0.023900] write 0x65a9e 0x1 0x10 +[S +0.023906] OK +OK [R +0.023910] outl 0xc03d 0x03000000 +[S +0.023917] OK +OK +[R +0.023921] outl 0xc00a 0xc10000 +[S +0.023983] OK +OK +[R +0.023991] outl 0xc00b 0x0800 +[S +0.023998] OK +OK +[R +0.024002] outl 0xc00b 0x00 +[S +0.024008] OK +OK +[R +0.024014] outl 0xc00b 0x0800 +[S +0.024028] OK +OK +[R +0.024034] outl 0xc00b 0x0800 +[S +0.024040] OK +OK +[R +0.024051] outl 0xc00b 0x0800 +[S +0.024058] OK +OK +[R +0.024065] outl 0xc00b 0x0400 +[S +0.024073] OK +OK +[R +0.024082] outl 0xc00b 0x0800 +[S +0.024089] OK +OK +[R +0.024104] outl 0xc00b 0x0800 +[S +0.024121] OK +OK +[R +0.024133] outw 0xc00b 0x1000 +[S +0.024150] OK +OK +[R +0.024159] outw 0xc00b 0x9000 +================================================================= +==63330==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62500020c000 at pc 0x5601fffcf1d4 bp 0x7ffe1920dcf0 sp 0x7ffe1920d4b0 +WRITE of size 32736 at 0x62500020c000 thread T0 + #0 0x5601fffcf1d3 in __asan_memcpy ../../llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 + #1 0x5602015f506b in flatview_read_continue ../softmmu/physmem.c:2726:13 + #2 0x5602015f5ee3 in flatview_read ../softmmu/physmem.c:2762:12 + #3 0x5602015f5bf7 in address_space_read_full ../softmmu/physmem.c:2775:18 + #4 0x560200943ef0 in dma_memory_rw_relaxed ../include/sysemu/dma.h:87:12 + #5 0x560200943ef0 in dma_memory_rw ../include/sysemu/dma.h:130:12 + #6 0x560200943ef0 in pci_dma_rw ../hw/pci/pci_device.h:233:12 + #7 0x560200943ef0 in esp_pci_dma_memory_rw ../hw/scsi/esp-pci.c:283:5 + #8 0x56020092db7e in esp_do_dma ../hw/scsi/esp.c + #9 0x560200935774 in handle_ti ../hw/scsi/esp.c:912:9 + #10 0x560200932db6 in esp_reg_write ../hw/scsi/esp.c:1083:13 + #11 0x56020094574d in esp_pci_io_write ../hw/scsi/esp-pci.c:214:9 + #12 0x5602015b5f23 in memory_region_write_accessor ../softmmu/memory.c:493:5 + #13 0x5602015b56aa in access_with_adjusted_size ../softmmu/memory.c:569:18 + #14 0x5602015b4a50 in memory_region_dispatch_write ../softmmu/memory.c + #15 0x5602015fefbf in flatview_write_continue ../softmmu/physmem.c:2653:23 + #16 0x5602015f6463 in flatview_write ../softmmu/physmem.c:2695:12 + #17 0x5602015f6177 in address_space_write ../softmmu/physmem.c:2791:18 + #18 0x5602015a7e99 in cpu_outw ../softmmu/ioport.c:75:5 + #19 0x560200d28daa in qtest_process_command ../softmmu/qtest.c:483:13 + #20 0x560200d2795b in qtest_process_inbuf ../softmmu/qtest.c:788:9 + #21 0x560201b581a6 in fd_chr_read ../chardev/char-fd.c:72:9 + #22 0x7f8fce57e04d in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5204d) (BuildId: 5fdb313daf182a33a858ba2cc945211b11d34561) + #23 0x560201dc540f in glib_pollfds_poll ../util/main-loop.c:290:9 + #24 0x560201dc540f in os_host_main_loop_wait ../util/main-loop.c:313:5 + #25 0x560201dc540f in main_loop_wait ../util/main-loop.c:592:11 + #26 0x560200d34f76 in qemu_main_loop ../softmmu/runstate.c:732:9 + #27 0x56020173e835 in qemu_default_main ../softmmu/main.c:37:14 + #28 0x7f8fcd3a5082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #29 0x5601fff2009d in _start ./qemu-system-x86_64+0x1e9109d) + +0x62500020c000 is located 0 bytes to the right of 4096-byte region [0x62500020b000,0x62500020c000) +allocated by thread T0 here: + #0 0x5601fffd0a0c in posix_memalign ../../llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3 + #1 0x560201db83da in qemu_try_memalign ../util/memalign.c:53:11 + #2 0x560201db8762 in qemu_memalign ../util/memalign.c:73:15 + #3 0x5602008c779e in scsi_req_enqueue ../hw/scsi/scsi-bus.c:906:10 + #4 0x56020093bd2f in do_command_phase ../hw/scsi/esp.c:296:15 + #5 0x56020093bd2f in do_cmd ../hw/scsi/esp.c:344:5 + #6 0x560200932911 in esp_reg_write ../hw/scsi/esp.c:1112:13 + #7 0x56020094574d in esp_pci_io_write ../hw/scsi/esp-pci.c:214:9 + #8 0x5602015b5f23 in memory_region_write_accessor ../softmmu/memory.c:493:5 + #9 0x5602015b56aa in access_with_adjusted_size ../softmmu/memory.c:569:18 + +SUMMARY: AddressSanitizer: heap-buffer-overflow ./llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 in __asan_memcpy +Shadow bytes around the buggy address: + 0x0c4a800397b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c4a800397c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c4a800397d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c4a800397e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c4a800397f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +=>0x0c4a80039800:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c4a80039810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c4a80039820: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c4a80039830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c4a80039840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c4a80039850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb +==63330==ABORTING +``` diff --git a/results/classifier/zero-shot/108/all/1810433 b/results/classifier/zero-shot/108/all/1810433 new file mode 100644 index 000000000..ab498f1b1 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1810433 @@ -0,0 +1,185 @@ +other: 0.995 +debug: 0.994 +semantic: 0.993 +performance: 0.988 +graphic: 0.986 +device: 0.983 +vnc: 0.981 +PID: 0.980 +boot: 0.973 +permissions: 0.966 +socket: 0.964 +network: 0.951 +KVM: 0.949 +files: 0.943 + +aarch64-linux-user master: inconsistent pwrite behaviour + +Hello, + +I am running aarch64-linux-user from master, commit 20d6c7312f1b812bb9c750f4087f69ac8485cc90 + +And I've found the following inconsistent emulation of pwrite() call when buf==NULL and len=0. +Minimal reproducible sample is the following: + +#define _GNU_SOURCE +#include <stdlib.h> +#include <stdio.h> +#include <unistd.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#include <string.h> + +/* + System | Result +-------------------------+---------------- + Native x86_64 4.12.14 | pwrite ret = 0 + Native aarch64 4.4.159 | pwrite ret = 0 + qemu-aarch64 at x86_64 | pwrite ret = -1 + ( 20d6c7312f1b8 ) | +*/ + +int main(int argc, char** argv) { + int fd = open("test.dat", O_CREAT | O_RDWR, 0644); + if (fd < 0) { + perror("open"); + return 1; + } + + int ret = fallocate(fd, 0, 0, 1000); + if (ret < 0) { + perror("fallocate"); + return 1; + } + + ssize_t ret_pwrite = pwrite(fd, NULL, 0, 0); + printf("pwrite ret = %ld\n", ret_pwrite); + + close(fd); + + return 0; +} + + + + + +This seems related to commit 58cfa6c2e6eb51b23cc98f8, where this was fixed for the write() syscall. In that commit message the author writes "Q. Do pread64/pwrite64 need to be changed similarly? A. Experiment suggests not: both linux and linux-user yield -1 for NULL 0-length reads/writes." That doesn't match your results, though, and looking at the source both write and pwrite syscalls go through the vfs_write() function, so their behaviour for a NULL/0 buffer should be identical. + + +strace from an aarch64 machine: +pwrite64(3, NULL, 0, 0) = 0 + +strace from QEMU: +32029 pwrite64(3,0,0,0,4797560,0) = -1 errno=14 (Bad address) + + +Do you know how to fix it? + +It should be a patch pretty similar to commit 58cfa6c2e6eb51b23cc98f8, but in the pwrite64 codepath. Slightly complicated by needing to deal with the offset possibly being in two input arguments, but basically the same thing. + + +It would be great if you could fix it. + +Also, there are probably should exist POSIX conformance test suites around the world. As far as I understand, this particular issue could be found by running such a test under qemu-linux-user. I mean what if there are other similar issues? + +We run the Linux Test Project LTP test suite. However I think it may not cover this corner case. (It's also possible I missed it last time I went through our failure results -- it's a lot of analysis effort to disentangle "QEMU bug" from "QEMU missing feature that's impracticably hard to implement" from "test case bug", and sometimes tests roll up multiple tests into a single test binary that include things from several of those cases, which means that it's harder to notice when something that should have passed did not.) + + +I've also check qemu-arm with the same test code. Surprisingly, I see correct result: + +pwrite ret = 0 + + +Proposed patch at https://patchwork.ozlabs.org/patch/1022092/ + +NB: my guess is that your pwrite on 32-bit arm test is behaving like that because it isn't going via the pwrite64 syscall, or possibly because glibc there is dealing with the NULL special case early. Use QEMU's -strace argument (or strace on real h/w) to see what libc is actually turning that pwrite() function call into at the syscall level. + + +Commit now in QEMU master as 2bd3f8998e1e7dcd9afc29fab25. This will be in the next release: QEMU 4.0. + + +Thank you! + +пт, 18 янв. 2019 г. в 19:36, Peter Maydell <email address hidden>: +> +> Commit now in QEMU master as 2bd3f8998e1e7dcd9afc29fab25. This will be +> in the next release: QEMU 4.0. +> +> +> ** Changed in: qemu +> Status: In Progress => Fix Committed +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1810433 +> +> Title: +> aarch64-linux-user master: inconsistent pwrite behaviour +> +> Status in QEMU: +> Fix Committed +> +> Bug description: +> Hello, +> +> I am running aarch64-linux-user from master, commit +> 20d6c7312f1b812bb9c750f4087f69ac8485cc90 +> +> And I've found the following inconsistent emulation of pwrite() call when buf==NULL and len=0. +> Minimal reproducible sample is the following: +> +> #define _GNU_SOURCE +> #include <stdlib.h> +> #include <stdio.h> +> #include <unistd.h> +> #include <sys/types.h> +> #include <sys/stat.h> +> #include <fcntl.h> +> #include <string.h> +> +> /* +> System | Result +> -------------------------+---------------- +> Native x86_64 4.12.14 | pwrite ret = 0 +> Native aarch64 4.4.159 | pwrite ret = 0 +> qemu-aarch64 at x86_64 | pwrite ret = -1 +> ( 20d6c7312f1b8 ) | +> */ +> +> int main(int argc, char** argv) { +> int fd = open("test.dat", O_CREAT | O_RDWR, 0644); +> if (fd < 0) { +> perror("open"); +> return 1; +> } +> +> int ret = fallocate(fd, 0, 0, 1000); +> if (ret < 0) { +> perror("fallocate"); +> return 1; +> } +> +> ssize_t ret_pwrite = pwrite(fd, NULL, 0, 0); +> printf("pwrite ret = %ld\n", ret_pwrite); +> +> close(fd); +> +> return 0; +> } +> +> +> Please note, that the same binary executable prints different output at native aarch64 platform and under aarch64-linux-user +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1810433/+subscriptions + + + +-- +With best regards, +Matwey V. Kornilov + + diff --git a/results/classifier/zero-shot/108/all/1815252 b/results/classifier/zero-shot/108/all/1815252 new file mode 100644 index 000000000..ea8fa2dd9 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1815252 @@ -0,0 +1,105 @@ +graphic: 0.983 +semantic: 0.980 +other: 0.975 +vnc: 0.975 +debug: 0.971 +device: 0.968 +permissions: 0.966 +performance: 0.965 +PID: 0.959 +KVM: 0.957 +socket: 0.948 +files: 0.945 +network: 0.924 +boot: 0.923 + +virtio-9p-pci passthrough fsync hang + +Tested against QEMU: e47f81b617684c4546af286d307b69014a83538a + +and $qemu-system-x86_64 --version +QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + ++ exec sudo qemu-system-x86_64 -enable-kvm -bios /usr/share/ovmf/OVMF.fd -cpu host -smp sockets=1,cpus=4,cores=2 -m 2048 -vga none -nographic -chardev socket,id=chrtpm0,path=/tmp/clrwifi/swtpm2/tpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm0 -device tpm-tis,tpmdev=tpm0 -device virtio-rng-pci -netdev user,id=mynet0,hostfwd=tcp::10022-:22 -device virtio-net-pci,netdev=mynet0 -kernel /home/.../Documents/c/iwd/tools/bzImage -append 'console=ttyS0,115200n8 quiet kvm-intel.nested=1 init=/usr/bin/bash initcall_debug tsc=reliable no_timer_check noreplace-smp cryptomgr.notests rootfstype=9p root=/dev/root rootflags=trans=virtio,version=9p2000.u rw' -fsdev local,id=fsdev-root,path=mnt,security_model=passthrough -device virtio-9p-pci,fsdev=fsdev-root,mount_tag=/dev/root +[ 0.000000] Linux version 4.19.0-rc2 (...) (gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)) #10 SMP Fri Feb 8 13:55:20 PST 2019 +[ 0.000000] Command line: console=ttyS0,115200n8 quiet kvm-intel.nested=1 init=/usr/bin/bash initcall_debug tsc=reliable no_timer_check noreplace-smp cryptomgr.notests rootfstype=9p root=/dev/root rootflags=trans=virtio,version=9p2000.u rw +[ 0.000000] KERNEL supported cpus: +[ 0.000000] Intel GenuineIntel +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' +[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 +[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000007e87efff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007e87f000-0x000000007e888fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007e889000-0x000000007e889fff] ACPI data +[ 0.000000] BIOS-e820: [mem 0x000000007e88a000-0x000000007e88bfff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007e88c000-0x000000007e88ffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007e890000-0x000000007e8a9fff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007e8aa000-0x000000007e8b9fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007e8ba000-0x000000007e8bafff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007e8bb000-0x000000007e9e5fff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007e9e6000-0x000000007e9edfff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007e9ee000-0x000000007eb1afff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007eb1b000-0x000000007fb9afff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007fb9b000-0x000000007fbf2fff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007fbf3000-0x000000007fbfafff] ACPI data +[ 0.000000] BIOS-e820: [mem 0x000000007fbfb000-0x000000007fbfefff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000007fbff000-0x000000007ff3ffff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007ff40000-0x000000007ff5ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000007ff60000-0x000000007fffffff] ACPI NVS +[ 0.352469] acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed +Started bpfilter +bash: cannot set terminal process group (-1): Inappropriate ioctl for device +bash: no job control in this shell +grep: /proc/cpuinfo: No such file or directory +grep: /proc/cpuinfo: No such file or directory +root@clr / # passwd +... +openat(AT_FDCWD, "/etc/nshadow", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 +umask(077) = 077 +openat(AT_FDCWD, "/etc/shadow", O_RDONLY|O_CREAT|O_CLOEXEC, 000) = 5 +fcntl(5, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE) +fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 +fchown(4, 0, 0) = 0 +fchmod(4, 0100644) = 0 +lseek(5, 0, SEEK_CUR) = 0 +fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 +read(5, "", 8192) = 0 +close(5) = 0 +fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 +write(4, "root:$6$jihvB1NonG88C5Yt$kvDCqF7"..., 124) = 124 +fsync(4 <- hung here + + + +I forgot to add that the kernel in that image (/usr/lib/kernel/org.clearlinux.*) does not have 9p support. So to compile the kernel I used the attached config + +I forgot to add that the kernel in that image (/usr/lib/kernel/org.clearlinux.*) does not have 9p support. So to compile the kernel I used the attached config + +Damn, I just ran into this bug again! Then realized I'd already reported it.... :( + +Sorry that nobody commented to this ticket in the past... Anyway: + +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/zero-shot/108/all/1815911 b/results/classifier/zero-shot/108/all/1815911 new file mode 100644 index 000000000..3e26fcc6c --- /dev/null +++ b/results/classifier/zero-shot/108/all/1815911 @@ -0,0 +1,71 @@ +permissions: 0.986 +semantic: 0.983 +graphic: 0.982 +device: 0.980 +performance: 0.979 +debug: 0.979 +boot: 0.977 +socket: 0.976 +other: 0.976 +files: 0.971 +PID: 0.969 +vnc: 0.966 +network: 0.963 +KVM: 0.959 + +aptitude crashes qemu-m68k with handle_cpu_signal received signal outside vCPU context + +When building a package with sbuild on Debian, sbuild can use aptitude to resolve dependencies. + +Recently, some changes introduced to aptitude or related packages cause qemu to crash: + +(sid-m68k-sbuild)root@nofan:/# aptitude -y --without-recommends -o Dpkg::Options::=--force-confold -o Aptitude::CmdLine::Ignore-Trust-Violations=false -o Aptitude::ProblemResolver::StepScore=100 -o Aptitude::ProblemResolver::SolutionCost="safety, priority, non-default-versions" -o Aptitude::ProblemResolver::Hints::KeepDummy="reject sbuild-build-depends-core-dummy :UNINST" -o Aptitude::ProblemResolver::Keep-All-Level=55000 -o Aptitude::ProblemResolver::Remove-Essential-Level=maximum install vim +Warning: Invalid locale (please review locale settings, this might lead to problems later): + locale::facet::_S_create_c_locale name not valid +The following NEW packages will be installed: + libgpm2{a} vim vim-common{a} vim-runtime{a} xxd{a} +0 packages upgraded, 5 newly installed, 0 to remove and 1 not upgraded. +Need to get 7225 kB/7260 kB of archives. After unpacking 33.5 MB will be used. +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6019d1bf +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x601b64ab +Segmentation fault +(sid-m68k-sbuild)root@nofan:/# + +The crash does not reproduce on real hardware running Debian unstable. + +It seems it crashes during futex syscall: + +... +[pid 4] getpid() = 4 +[pid 4] tgkill(4, 24, SIGRT_1) = 0 +[pid 24] <... futex resumed> ) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) +[pid 24] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=4, si_uid=0} --- +[pid 4] futex(0x7f77abb4f610, FUTEX_WAIT_PRIVATE, 16777216, NULL <unfinished ...> +[pid 24] getpid() = 4 +[pid 24] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x10} --- +... + +On 2/15/19 1:47 PM, Laurent Vivier wrote: +> It seems it crashes during futex syscall: +> +> ... +> [pid 4] getpid() = 4 +> [pid 4] tgkill(4, 24, SIGRT_1) = 0 +> [pid 24] <... futex resumed> ) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) +> [pid 24] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=4, si_uid=0} --- +> [pid 4] futex(0x7f77abb4f610, FUTEX_WAIT_PRIVATE, 16777216, NULL <unfinished ...> +> [pid 24] getpid() = 4 +> [pid 24] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x10} --- +> ... + +The crash also reproduces with qemu-sh4, so it's not specific to m68k. + + +I think this is probably a duplicate of bug #1594394, in which case it seems to be fixed in 5.0.0+. + +John, can you still reproduce it with the latest version of QEMU? + +Just verified it with a very recently compiled version of QEMU from git master and, indeed, the bug seems to be fixed as I can no longer reproduce the crash. The command executes correctly. + +I guess it's safe to mark this as fixed. + diff --git a/results/classifier/zero-shot/108/all/1817345 b/results/classifier/zero-shot/108/all/1817345 new file mode 100644 index 000000000..41c8ba706 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1817345 @@ -0,0 +1,177 @@ +graphic: 0.987 +semantic: 0.986 +device: 0.985 +files: 0.985 +debug: 0.985 +PID: 0.980 +performance: 0.973 +permissions: 0.972 +other: 0.970 +boot: 0.956 +socket: 0.950 +network: 0.946 +KVM: 0.928 +vnc: 0.919 + +configure script breaks when $source_path contains white spaces + +Hi, + +I noticed that the configure script breaks when the qemu source directory is in a path containing white spaces, in particular the list of targets is not correctly generated when calling "./configure --help". + +Steps to reproduce the problem: + +$ mkdir "dir with spaces" +$ cd dir\ with\ spaces/ +$ git clone https://git.qemu.org/git/qemu.git +$ cd qemu/ +$ ./configure --help | grep -A3 target-list + + +Actual result: + + --target-list=LIST set target list (default: build everything) + Available targets: dir with *-softmmu dir with + *-linux-user + + +Expected result: + + --target-list=LIST set target list (default: build everything) + Available targets: aarch64-softmmu alpha-softmmu + arm-softmmu cris-softmmu hppa-softmmu i386-softmmu + lm32-softmmu m68k-softmmu microblaze-softmmu + + +This happens because the $mak_wilds variable uses spaces to separate different paths, maybe newlines may be used, which are less likely to be in directory names. + +BTW "shellcheck" may help finding some other problems. + +Qemu version: + +$ git describe +v3.1.0-1960-ga05838cb2a + +Thanks, + Antonio + +I think it is better to just disallow building in a path containing spaces, -- there are so many packages and other tools that fails in this config, might require lots of work to fix this AND to ensure all future changes are still working, and there's an easy workaround + +Just my few cents. + +On Sun, 24 Feb 2019 at 19:46, Michael Tokarev +<email address hidden> wrote: +> I think it is better to just disallow building in a path containing +> spaces, -- there are so many packages and other tools that fails in this +> config, might require lots of work to fix this AND to ensure all future +> changes are still working, and there's an easy workaround + +Certainly I bet that the problems with spaces in the path do +not stop with the handling of the target-list help message. +Make does not really get on at all with spaces... +It would probably be helpful if we made configure complain +if it finds spaces in the build or source paths. + +thanks +-- PMM + + +I am OK with just checking and complaining. + +Linux too solves the problem in this way: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Makefile?id=51193b76bfff5027cf96ba63effae808ad67cca7 + +A general "shellcheck" pass wouldn't hurt, tho. + +Thank you, + Antonio + +If calling from any Unix shell, and the parameter has spaces, then we need to quote it.we can also use single quotes, these are more powerful. They stop the shell from interpreting anything ($, !, \, *, ", etc, except '). + + +can't we use this approach here?? + +Deepika: the tricky part is the makefiles, not the configure script... + + +Oh~ +Okay! + +On Sun, Mar 10, 2019, 02:30 Peter Maydell <email address hidden> wrote: + +> Deepika: the tricky part is the makefiles, not the configure script... +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1817345 +> +> Title: +> configure script breaks when $source_path contains white spaces +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> I noticed that the configure script breaks when the qemu source +> directory is in a path containing white spaces, in particular the list +> of targets is not correctly generated when calling "./configure +> --help". +> +> Steps to reproduce the problem: +> +> $ mkdir "dir with spaces" +> $ cd dir\ with\ spaces/ +> $ git clone https://git.qemu.org/git/qemu.git +> $ cd qemu/ +> $ ./configure --help | grep -A3 target-list +> +> +> Actual result: +> +> --target-list=LIST set target list (default: build everything) +> Available targets: dir with *-softmmu dir +> with +> *-linux-user +> +> +> Expected result: +> +> --target-list=LIST set target list (default: build everything) +> Available targets: aarch64-softmmu +> alpha-softmmu +> arm-softmmu cris-softmmu hppa-softmmu +> i386-softmmu +> lm32-softmmu m68k-softmmu microblaze-softmmu +> +> +> This happens because the $mak_wilds variable uses spaces to separate +> different paths, maybe newlines may be used, which are less likely to be in +> directory names. +> +> BTW "shellcheck" may help finding some other problems. +> +> Qemu version: +> +> $ git describe +> v3.1.0-1960-ga05838cb2a +> +> Thanks, +> Antonio +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1817345/+subscriptions +> + + +Antonio has submitted a patchset here: +https://<email address hidden>/ + + +Antonio's patches are in git and will be in the upcoming 4.1.0 release. + + +Patch included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=4ace32e22713ffd79deb22 + diff --git a/results/classifier/zero-shot/108/all/1817525 b/results/classifier/zero-shot/108/all/1817525 new file mode 100644 index 000000000..a5bf2bb29 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1817525 @@ -0,0 +1,102 @@ +other: 0.974 +permissions: 0.968 +device: 0.967 +debug: 0.967 +semantic: 0.966 +performance: 0.964 +KVM: 0.962 +PID: 0.960 +graphic: 0.960 +socket: 0.951 +vnc: 0.951 +boot: 0.947 +files: 0.943 +network: 0.929 + +qemu fails to compile on gcc 9 "block/nvme.c:209:22: error: taking address of packed member of 'struct <anonymous>' may result in an unaligned pointer value [-Werror=address-of-packed-member]" + +Issue: +Qemu compilation fails with below error on ppc64le host with gcc 9, repo(https://github.com/dgibson/qemu.git), branch(ppc-for-4.0), Commit (0483e90393bac8546a1fbc95ab912a1e78e92b00) + + CHK version_gen.h + CC block/nvme.o +block/nvme.c: In function ‘nvme_create_queue_pair’: +block/nvme.c:209:22: error: taking address of packed member of ‘struct <anonymous>’ may result in an unaligned pointer value [-Werror=address-of-packed-member] + 209 | q->sq.doorbell = &s->regs->doorbells[idx * 2 * s->doorbell_scale]; + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +block/nvme.c:216:22: error: taking address of packed member of ‘struct <anonymous>’ may result in an unaligned pointer value [-Werror=address-of-packed-member] + 216 | q->cq.doorbell = &s->regs->doorbells[idx * 2 * s->doorbell_scale + 1]; + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +cc1: all warnings being treated as errors +make: *** [/usr/share/avocado-plugins-vt/build/qemu/rules.mak:69: block/nvme.o] Error 1 + + + +$git commit: +commit 0483e90393bac8546a1fbc95ab912a1e78e92b00 (HEAD -> ppc-for-4.0) +Author: Thomas Huth <email address hidden> +Date: Thu Feb 21 12:24:48 2019 +0100 + + hw/ppc: Use object_initialize_child for correct reference counting + + Both functions, object_initialize() and object_property_add_child() increase + the reference counter of the new object, so one of the references has to be + dropped afterwards to get the reference counting right. Otherwise the child + object will not be properly cleaned up when the parent gets destroyed. + Thus let's use now object_initialize_child() instead to get the reference + counting here right. + + Suggested-by: Eduardo Habkost <email address hidden> + Signed-off-by: Thomas Huth <email address hidden> + Message-Id: <email address hidden> + Reviewed-by: Cédric Le Goater <email address hidden> + Signed-off-by: David Gibson <email address hidden> + + +Note: Same commit on a different ppc64le host with gcc(8.1.1 20180712) compile without any issue. + +Env: + +Power8 + +#lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 160 +On-line CPU(s) list: 0,8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,152 +Off-line CPU(s) list: 1-7,9-15,17-23,25-31,33-39,41-47,49-55,57-63,65-71,73-79,81-87,89-95,97-103,105-111,113-119,121-127,129-135,137-143,145-151,153-159 +Thread(s) per core: 1 +Core(s) per socket: 5 +Socket(s): 4 +NUMA node(s): 4 +Model: 2.1 (pvr 004b 0201) +Model name: POWER8E (raw), altivec supported +CPU max MHz: 3690.0000 +CPU min MHz: 2061.0000 +L1d cache: 64K +L1i cache: 32K +L2 cache: 512K +L3 cache: 8192K +NUMA node0 CPU(s): 0,8,16,24,32 +NUMA node1 CPU(s): 40,48,56,64,72 +NUMA node16 CPU(s): 80,88,96,104,112 +NUMA node17 CPU(s): 120,128,136,144,152 + +# gcc --version +gcc (GCC) 9.0.1 20190209 (Red Hat 9.0.1-0.4) +Copyright (C) 2019 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + + +# uname -r +5.0.0-rc7-ge50585e89 + +The fields of the struct are naturally aligned, so this should be easy enough to fix just by dropping QEMU_PACKED (we already have a compile-time assert that the doorbells field is at the expected address). + +NB: I notice also the struct is marked 'volatile' -- this is a bit of a red flag that the code may not really be doing the right thing here. + + +Fix has been merged: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=83c68e149a9365a3db6de + diff --git a/results/classifier/zero-shot/108/all/1823790 b/results/classifier/zero-shot/108/all/1823790 new file mode 100644 index 000000000..7433f5eff --- /dev/null +++ b/results/classifier/zero-shot/108/all/1823790 @@ -0,0 +1,217 @@ +performance: 0.989 +debug: 0.986 +socket: 0.986 +semantic: 0.985 +device: 0.985 +graphic: 0.985 +PID: 0.983 +permissions: 0.981 +other: 0.978 +vnc: 0.973 +KVM: 0.969 +network: 0.968 +files: 0.958 +boot: 0.933 + +QEMU mishandling of SO_PEERSEC forces systemd into tight loop + +While building Debian images for embedded ARM target systems I detected that QEMU seems to force newer systemd daemons into a tight loop. + +My setup is the following: + +Host machine: Ubuntu 18.04, amd64 +LXD container: Debian Buster, arm64, systemd 241 +QEMU: qemu-aarch64-static, 4.0.0-rc2 (custom build) and 3.1.0 (Debian 1:3.1+dfsg-7) + +To easily reproduce the issue I have created the following repository: +https://github.com/lueschem/edi-qemu + +The call where systemd gets looping is the following: +2837 getsockopt(3,1,31,274891889456,274887218756,274888927920) = -1 errno=34 (Numerical result out of range) + +Furthermore I also verified that the issue is not related to LXD. +The same behavior can be reproduced using systemd-nspawn. + +This issue reported against systemd seems to be related: +https://github.com/systemd/systemd/issues/11557 + +As described on the systemd issue, the syscall we're getting wrong here is getsockopt(fd, SOL_SOCKET, SO_PEERSEC, ...). Our linux-user/syscall.c:do_getsockopt() doesn't have any special case code for the payload on this function, so we treat it as if it were just an integer payload, which is not correct here. + +Unfortunately I can't find any documentation on exactly what SO_PEERSEC does or what the payload format is, which makes it pretty hard to fix this bug :-( It's not listed in the socket(7) manpage -- https://linux.die.net/man/7/socket -- which is where I'd expect to find it, and the kernel source code is pretty confusing in this area. + + +This is probably the tight loop that gets triggered: +https://github.com/systemd/systemd/commit/217d89678269334f461e9abeeffed57077b21454 + +It looks like the previous implementation was just a bit more "tolerant". + +I have just studied a bit the systemd code and this brought me to the following idea/temporary workaround: What about returning -1 (error) and setting errno when getsockopt(fd, SOL_SOCKET, SO_PEERSEC, ...) gets called? This would then let systemd know that SO_PEERSEC is not (yet) implemented. + +I filed the duplicate #1840252 of this bug. + +I think that the options SO_PEERCRED and SO_PEERSEC belong into the context of SELINUX. So maybe the format of the paylod can be found in the sources of libselinux? + +I'd like to compile qemu with a local hack to work around my current problem. Something like Matthias Lüscher suggested. + +@Peter Maydell: could you point me to the location in the qemu source where I could apply such a hack? + +I patched linux-user/syscall.c (see below, branch stable-2.11) which works around my problem. +So far so good, but the qemu-arm that i compiled is terribly slow compared to the one that came with Ubuntu 18.04. Any hints? +I configured as this: +./configure --static --enable-kvm --target-list=arm-linux-user + +diff --git a/linux-user/syscall.c b/linux-user/syscall.c +index 74d56e2ee6..4fa9a09b12 100644 +--- a/linux-user/syscall.c ++++ b/linux-user/syscall.c +@@ -3185,6 +3185,8 @@ static abi_long do_getsockopt(int sockfd, int level, int optname, + case TARGET_SO_SNDTIMEO: + case TARGET_SO_PEERNAME: + goto unimplemented; ++ case TARGET_SO_PEERSEC: /* added to escape infinite loop */ ++ goto unimplemented; + case TARGET_SO_PEERCRED: { + struct ucred cr; + socklen_t crlen; + + + +I'm a bit surprised that this bug doesn't get more attention, as it makes it very hard to run qemu-emulated containers of Bionic hosted on Bionic. Running such containers is a common way to cross-compile packages for foreign architectures in the absence of sufficiently powerful target HW. + +The documentation on SO_PEERSEC is indeed sparse, but I do want to second Fritz in his approach. I don't see a reason, why treating the payload as incorrect and throwing it back at the application is better than handling it and saying it is not implemented (which is the case). + +Arguably, applications should be fixed to handle the error correctly, but I'm afraid that is a can of worms. I have encountered the same problem with systemd, apt and getent. Would the maintainers be open to an SRU request on QEMU for this? + +Could you test the attached patch? + +Thanks, Laurent! I'll get back to you, asap. + +> Could you test the attached patch? +> + +Works great! + +This is my test setup: + +Host machine: Ubuntu 18.04, amd64 +LXD container: Debian Buster, arm64, systemd 241 +QEMU: qemu-aarch64(-static), compiled from source (4.2.0), patched with +your patch. + +Many thanks! +Matthias + + +I carried out the following test: + +* fetched the QEMU coming with 18.04, +* added this patch, +* built an LXD container with arch arm64 and the patched qemu-aarch64-static inside, +* launched it on amd64 + +Previously various systemd services would not come up properly, now they are running like a charm. The only grief I have is that network configuration does not work, but that is due to + + # ip addr + Unsupported setsockopt level=270 optname=11 + +which is a different story. + +Well, it's kind of irrelevant but I am trying that on archlinux and this does not work for me. + +Using systemd-244.2-1 and qemu-user-static-4.2 that I built with Laurent's patch. May be I have done something wrong ? + +I still get that error that leads me here: + +Failed to enqueue loopback interface start request: Operation not supported +Caught <SEGV>, dumped core as pid 3. +Exiting PID 1... + +I am trying to boot with systemd-nspawn an archlinux-arm built for a rpi0. That's fine if I don't boot it. + +Laurent's patch worked for me as well. + +I grabbed the source for the Debian 10 qemu-user-static package, qemu_3.1+dfsg-8+deb10u3, applied the patch and re-built the qemu-arm-static binary. Copying the new binary into a Docker image based on arm32v7/debian:10-slim allowed /sbin/init to bring up the container with a responsive systemctl command. + +Prior to the patch, systemd did not start any services inside the container and systemctl would hang when executed directly. + +Thanks! +-Charlie + +This seems to be the error reported in https://bugs.launchpad.net/qemu/+bug/1857811 + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=6d485a55d0cd + + +Bisect worked and once you find it it seems obvious that this is exactly our case: + +commit 65b261a63a48fbb3b11193361d4ea0c38a3c3dfd +Author: Laurent Vivier <email address hidden> +Date: Thu Jul 9 09:23:32 2020 +0200 + + linux-user: add netlink RTM_SETLINK command + + This command is needed to be able to boot systemd in a container. + + $ sudo systemd-nspawn -D /chroot/armhf/sid/ -b + Spawning container sid on /chroot/armhf/sid. + Press ^] three times within 1s to kill container. + systemd 245.6-2 running in system mode. + Detected virtualization systemd-nspawn. + Detected architecture arm. + + Welcome to Debian GNU/Linux bullseye/sid! + + Set hostname to <virt-arm>. + Failed to enqueue loopback interface start request: Operation not supported + Caught <SEGV>, dumped core as pid 3. + Exiting PID 1... + Container sid failed with error code 255. + + Signed-off-by: Laurent Vivier <email address hidden> + Message-Id: <email address hidden> + + linux-user/fd-trans.c | 1 + + 1 file changed, 1 insertion(+) + +Sorry, posted this on the wrong bug :-/ +I beg your pardon for the noise. + +Hmm, I'm using qemu-5.1.0 and I'm still seeing this (host is bionic, container image is focal) + +[..] +getsockopt(31, SOL_SOCKET, SO_PEERGROUPS, 0x7ffdbd58941c, [4]) = -1 ERANGE (Numerical result out of range) +getsockopt(31, SOL_SOCKET, SO_PEERGROUPS, 0x7ffdbd58941c, [4]) = -1 ERANGE (Numerical result out of range) +getsockopt(31, SOL_SOCKET, SO_PEERGROUPS, 0x7ffdbd58941c, [4]) = -1 ERANGE (Numerical result out of range) +[..] + +Regression? + +I can confirm that I see the same issue when trying to run Ubuntu 20.04 aarch64 in a container, strace shows a tight loop on: + +getsockopt(31, SOL_SOCKET, SO_PEERGROUPS, 0x7ffdbd58941c, [4]) = -1 ERANGE + +Re-building qemu-user-static with the patch has fixed Debian 10 armhf for me, but the same re-build does not seem to help with this Ubuntu issue. + +SO_PEERGROUPS is not implemented and processed as an "int" (this explains the ERANGE) + +Could you try the attached patch? + +In my case the issue with using Ubuntu 20.04 as a container host appears to have come down to the use of the F, or "fix binary", flag by binfmnt_misc: + +# cat /proc/sys/fs/binfmt_misc/qemu-aarch64 +enabled +interpreter /usr/bin/qemu-aarch64-static +flags: OCF +offset 0 +magic 7f454c460201010000000000000000000200b700 +mask ffffffffffffff00fffffffffffffffffeffffff + +This appears to be new in Ubuntu 20.04 relative to 18.04 and results in the qemu-user-static binaries being loaded and locked into memory _when the package is installed_. + +Therefore, what I observed as a regression of the issue was actually just the packaged binaries now taking precedence over patched versions that I had built and copied into place. + +Ubuntu 20.04 ships QEMU 4.2. Using the QEMU 5.1 packages from Debian Bullseye allows SystemD to run in a foreign architecture container without spinning in a loop: + + https://packages.debian.org/bullseye/qemu-user-static + diff --git a/results/classifier/zero-shot/108/all/1834399 b/results/classifier/zero-shot/108/all/1834399 new file mode 100644 index 000000000..7e4b9afa5 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1834399 @@ -0,0 +1,55 @@ +other: 0.990 +graphic: 0.984 +device: 0.982 +semantic: 0.980 +performance: 0.977 +PID: 0.977 +permissions: 0.976 +debug: 0.975 +socket: 0.974 +KVM: 0.971 +vnc: 0.970 +files: 0.968 +boot: 0.965 +network: 0.924 + +Branch out of range on mips o32 building QEMU + +I build lib32-qemu which is a multilib variant for mips o32 on project Yocto with qemumips64. It finally runs command and fails: + + +mips-wrsmllib32-linux-gcc -meb -mabi=32 -mhard-float -fstack-protector-strong -Wformat -Wformat-security -Werror=format-security --sysroot=/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot +-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/include/pixman-1 -I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/dtc/libfdt -pthread -I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/include/glib-2.0 -I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/lib/glib-2.0/include +-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Og -g +-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/capstone/include -I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/tests +-DCAPSTONE_USE_SYS_DYN_MEM -DCAPSTONE_HAS_ARM -DCAPSTONE_HAS_ARM64 -DCAPSTONE_HAS_POWERPC -DCAPSTONE_HAS_X86 +-c arch/AArch64/AArch64InstPrinter.c -o /mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/build/capstone/obj/arch/AArch64/AArch64InstPrinter.o + + + +And error messages: + +{standard input}: Assembler messages: +{standard input}:38045: Error: branch out of range +{standard input}:38269: Error: branch out of range +{standard input}:38493: Error: branch out of range +{standard input}:38717: Error: branch out of range +{standard input}:38941: Error: branch out of range +{standard input}:39165: Error: branch out of range +{standard input}:39389: Error: branch out of range +{standard input}:39613: Error: branch out of range +{standard input}:39728: Error: branch out of range +{standard input}:39990: Error: branch out of range +{standard input}:40252: Error: branch out of range +{standard input}:40514: Error: branch out of range +{standard input}:40776: Error: branch out of range +{standard input}:41038: Error: branch out of range + + +The gcc version is 9.1. I have verified that gcc 8.3 works. And there is no error when remove option '-Og' with gcc 9.1. + +I am not sure whether it is a defect of gcc 9.1 or capstone. Should it be fixed in capstone? Thanks. + +There is no custom assembly within capstone. +This is purely a compiler bug. + diff --git a/results/classifier/zero-shot/108/all/1838312 b/results/classifier/zero-shot/108/all/1838312 new file mode 100644 index 000000000..dbee89593 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1838312 @@ -0,0 +1,658 @@ +permissions: 0.978 +device: 0.975 +semantic: 0.974 +PID: 0.972 +vnc: 0.966 +other: 0.965 +debug: 0.963 +graphic: 0.962 +performance: 0.961 +boot: 0.946 +files: 0.943 +KVM: 0.941 +socket: 0.932 +network: 0.913 + +Qemu virt-manager Segmentation fault + +Hi! + +I installed all these packages: + +sudo apt install qemu +sudo apt install ipxe-qemu-256k-compat-efi-roms libspice-server1 libbluetooth3 +sudo apt install libbrlapi0.6 libcacard0 libfdt1 libusbredirparser1 libvirglrenderer0 libxen-4.9 libxenstore3.0 +sudo apt install cpu-checker ibverbs-providers ipxe-qemu libibverbs1 libiscsi7 libnl-route-3-200 librados2 librbd1 librdmacm1 msr-tools sharutils +sudo apt install qemu-block-extra qemu-system-common qemu-system-data qemu-system-gui qemu-utils +sudo apt install --no-install-recommends qemu-kvm qemu-system-x86 +sudo apt install libauparse0 ebtables gir1.2-gtk-vnc-2.0 gir1.2-libosinfo-1.0 gir1.2-libvirt-glib-1.0 gir1.2-spiceclientglib-2.0 gir1.2-spiceclientgtk-3.0 libvde0 libvdeplug2 libgovirt-common libgovirt2 libgtk-vnc-2.0-0 libgvnc-1.0-0 libosinfo-1.0-0 libphodav-2.0-0 libphodav-2.0-common libspice-client-glib-2.0-8 libspice-client-gtk-3.0-5 libusbredirhost1 libvirt-clients libvirt-daemon libvirt-daemon-driver-storage-rbd libvirt-daemon-system libvirt-glib-1.0-0 libvirt0 osinfo-db python3-libvirt python3-libxml2 spice-client-glib-usb-acl-helper vde2 vde2-cryptcab virt-viewer virtinst virt-manager + +without the i386 packages for Qemu because I want only 64 bit. + +I installed all these packages without error, but when I run + +# virt-manager + +Output: ...shows me: + +Segmentation fault + + +My hardware is 100% ok. +Maybee a broken lib? + + + +How can I fix that? + +syslog: + +kernel: [ 2003.888116] virt-manager[16014]: segfault at 32d0 ip 00000000000032d0 sp 00007ffeb09ac658 error 14 in python3.7[400000+21000] + +kernel: [ 2003.888124] Code: Bad RIP value. + +That is a long list of install commands Hans Peter, wouldn't dependencies just take care of it as well? +Anyway, I installed the same set of packages and it works fine for me. + +Which Ubuntu release are you on? +What machine are you on? +Any further configuration done to libvirt yet? +Maybe a list of all installed packages and their versions (dpkg -l)? + +You might use apport-collect [1] to gather some of that info automatically. + +[1]: http://manpages.ubuntu.com/manpages/bionic/man1/apport-bug.1.html + +@ Christian Ehrhardt, + +I'm on Ubuntu Mate 19.04. + +Machine: AMD, 64 bit + +I done no configuration of 'libvirt' yet. + +I don't wanna install apport. + +I add installed package-list at attachment. + +I hope it will helps. + +I found crash-report from python 3.7 similiar to this error: + +kernel: [ 2003.888116] virt-manager[16014]: segfault at 32d0 ip 00000000000032d0 sp 00007ffeb09ac658 error 14 in python3.7[400000+21000] + +kernel: [ 2003.888124] Code: Bad RIP value. + + +look here: + +ProblemType: Crash +Date: Fri Jul 26 15:03:11 2019 +ExecutablePath: /usr/bin/session-installer +ExecutableTimestamp: 1458142842 +InterpreterPath: /usr/bin/python3.7 +ProcCmdline: /usr/bin/python3 /usr/bin/session-installer +ProcCwd: / +ProcEnviron: + SHELL=/bin/bash + LC_NAME=en_US.UTF-8 + LC_MEASUREMENT=en_US.UTF-8 + LC_PAPER=en_US.UTF-8 + LC_MONETARY=en_US.UTF-8 + LC_NUMERIC=en_US.UTF-8 + LC_TIME=en_US.UTF-8 + LC_IDENTIFICATION=en_US.UTF-8 + LANGUAGE=en_US + LC_TELEPHONE=de_DE.UTF-8 + LC_ADDRESS=de_DE.UTF-8 + LANG=en_US.UTF-8 +ProcMaps: + 00400000-00421000 r--p 00000000 fd:01 2621992 /usr/bin/python3.7 + 00421000-00655000 r-xp 00021000 fd:01 2621992 /usr/bin/python3.7 + 00655000-00801000 r--p 00255000 fd:01 2621992 /usr/bin/python3.7 + 00801000-00802000 r--p 00400000 fd:01 2621992 /usr/bin/python3.7 + 00802000-008a8000 rw-p 00401000 fd:01 2621992 /usr/bin/python3.7 + 008a8000-008cb000 rw-p 00000000 00:00 0 + 02651000-0296c000 rw-p 00000000 00:00 0 [heap] + 7f0869a78000-7f0869c78000 rw-p 00000000 00:00 0 + 7f0869c78000-7f0869c83000 r--p 00000000 fd:01 11010294 /lib/x86_64-linux-gnu/libdbus-1.so.3.19.9 + 7f0869c83000-7f0869cb0000 r-xp 0000b000 fd:01 11010294 /lib/x86_64-linux-gnu/libdbus-1.so.3.19.9 + 7f0869cb0000-7f0869cc5000 r--p 00038000 fd:01 11010294 /lib/x86_64-linux-gnu/libdbus-1.so.3.19.9 + 7f0869cc5000-7f0869cc6000 r--p 0004c000 fd:01 11010294 /lib/x86_64-linux-gnu/libdbus-1.so.3.19.9 + 7f0869cc6000-7f0869cc7000 rw-p 0004d000 fd:01 11010294 /lib/x86_64-linux-gnu/libdbus-1.so.3.19.9 + 7f0869cd8000-7f0869cda000 r--p 00000000 fd:01 2760872 /usr/lib/python3.7/lib-dynload/_json.cpython-37m-x86_64-linux-gnu.so + 7f0869cda000-7f0869ce5000 r-xp 00002000 fd:01 2760872 /usr/lib/python3.7/lib-dynload/_json.cpython-37m-x86_64-linux-gnu.so + 7f0869ce5000-7f0869ce7000 r--p 0000d000 fd:01 2760872 /usr/lib/python3.7/lib-dynload/_json.cpython-37m-x86_64-linux-gnu.so + 7f0869ce7000-7f0869ce8000 r--p 0000e000 fd:01 2760872 /usr/lib/python3.7/lib-dynload/_json.cpython-37m-x86_64-linux-gnu.so + 7f0869ce8000-7f0869ce9000 rw-p 0000f000 fd:01 2760872 /usr/lib/python3.7/lib-dynload/_json.cpython-37m-x86_64-linux-gnu.so + 7f0869cf0000-7f0869cf4000 r--p 00000000 fd:01 2624107 /usr/lib/x86_64-linux-gnu/libapt-inst.so.2.0.0 + 7f0869cf4000-7f0869cfb000 r-xp 00004000 fd:01 2624107 /usr/lib/x86_64-linux-gnu/libapt-inst.so.2.0.0 + 7f0869cfb000-7f0869cfd000 r--p 0000b000 fd:01 2624107 /usr/lib/x86_64-linux-gnu/libapt-inst.so.2.0.0 + 7f0869cfd000-7f0869cfe000 ---p 0000d000 fd:01 2624107 /usr/lib/x86_64-linux-gnu/libapt-inst.so.2.0.0 + 7f0869cfe000-7f0869cff000 r--p 0000d000 fd:01 2624107 /usr/lib/x86_64-linux-gnu/libapt-inst.so.2.0.0 + 7f0869cff000-7f0869d00000 rw-p 0000e000 fd:01 2624107 /usr/lib/x86_64-linux-gnu/libapt-inst.so.2.0.0 + 7f0869d07000-7f0869e98000 rw-p 00000000 00:00 0 + 7f0869e98000-7f0869eb4000 r--p 00000000 fd:01 2631064 /usr/lib/x86_64-linux-gnu/libssl.so.1.1 + 7f0869eb4000-7f0869f01000 r-xp 0001c000 fd:01 2631064 /usr/lib/x86_64-linux-gnu/libssl.so.1.1 + 7f0869f01000-7f0869f1b000 r--p 00069000 fd:01 2631064 /usr/lib/x86_64-linux-gnu/libssl.so.1.1 + 7f0869f1b000-7f0869f24000 r--p 00082000 fd:01 2631064 /usr/lib/x86_64-linux-gnu/libssl.so.1.1 + 7f0869f24000-7f0869f28000 rw-p 0008b000 fd:01 2631064 /usr/lib/x86_64-linux-gnu/libssl.so.1.1 + 7f0869f30000-7f0869f32000 r--p 00000000 fd:01 2627510 /usr/lib/python3/dist-packages/_dbus_glib_bindings.cpython-37m-x86_64-linux-gnu.so + 7f0869f32000-7f0869f34000 r-xp 00002000 fd:01 2627510 /usr/lib/python3/dist-packages/_dbus_glib_bindings.cpython-37m-x86_64-linux-gnu.so + 7f0869f34000-7f0869f35000 r--p 00004000 fd:01 2627510 /usr/lib/python3/dist-packages/_dbus_glib_bindings.cpython-37m-x86_64-linux-gnu.so + 7f0869f35000-7f0869f36000 r--p 00004000 fd:01 2627510 /usr/lib/python3/dist-packages/_dbus_glib_bindings.cpython-37m-x86_64-linux-gnu.so + 7f0869f36000-7f0869f37000 rw-p 00005000 fd:01 2627510 /usr/lib/python3/dist-packages/_dbus_glib_bindings.cpython-37m-x86_64-linux-gnu.so + 7f0869f38000-7f0869f3a000 r--p 00000000 fd:01 2760874 /usr/lib/python3.7/lib-dynload/_lzma.cpython-37m-x86_64-linux-gnu.so + 7f0869f3a000-7f0869f3d000 r-xp 00002000 fd:01 2760874 /usr/lib/python3.7/lib-dynload/_lzma.cpython-37m-x86_64-linux-gnu.so + 7f0869f3d000-7f0869f3f000 r--p 00005000 fd:01 2760874 /usr/lib/python3.7/lib-dynload/_lzma.cpython-37m-x86_64-linux-gnu.so + 7f0869f3f000-7f0869f40000 r--p 00006000 fd:01 2760874 /usr/lib/python3.7/lib-dynload/_lzma.cpython-37m-x86_64-linux-gnu.so + 7f0869f40000-7f0869f42000 rw-p 00007000 fd:01 2760874 /usr/lib/python3.7/lib-dynload/_lzma.cpython-37m-x86_64-linux-gnu.so + 7f0869f48000-7f0869f4a000 r--p 00000000 fd:01 2760292 /usr/lib/python3.7/lib-dynload/_bz2.cpython-37m-x86_64-linux-gnu.so + 7f0869f4a000-7f0869f4c000 r-xp 00002000 fd:01 2760292 /usr/lib/python3.7/lib-dynload/_bz2.cpython-37m-x86_64-linux-gnu.so + 7f0869f4c000-7f0869f4d000 r--p 00004000 fd:01 2760292 /usr/lib/python3.7/lib-dynload/_bz2.cpython-37m-x86_64-linux-gnu.so + 7f0869f4d000-7f0869f4e000 r--p 00004000 fd:01 2760292 /usr/lib/python3.7/lib-dynload/_bz2.cpython-37m-x86_64-linux-gnu.so + 7f0869f4e000-7f0869f4f000 rw-p 00005000 fd:01 2760292 /usr/lib/python3.7/lib-dynload/_bz2.cpython-37m-x86_64-linux-gnu.so + 7f0869f50000-7f0869fd0000 rw-p 00000000 00:00 0 + 7f0869fd0000-7f086a048000 r--p 00000000 fd:01 2630452 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 + 7f086a048000-7f086a1e0000 r-xp 00078000 fd:01 2630452 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 + 7f086a1e0000-7f086a26d000 r--p 00210000 fd:01 2630452 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 + 7f086a26d000-7f086a299000 r--p 0029c000 fd:01 2630452 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 + 7f086a299000-7f086a29b000 rw-p 002c8000 fd:01 2630452 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 + 7f086a29b000-7f086a29e000 rw-p 00000000 00:00 0 + 7f086a2a0000-7f086a360000 rw-p 00000000 00:00 0 + 7f086a360000-7f086a37e000 r-xp 00000000 fd:01 3147544 /usr/local/lib/libgpg-error.so.0.24.2 + 7f086a37e000-7f086a57e000 ---p 0001e000 fd:01 3147544 /usr/local/lib/libgpg-error.so.0.24.2 + 7f086a57e000-7f086a57f000 r--p 0001e000 fd:01 3147544 /usr/local/lib/libgpg-error.so.0.24.2 + 7f086a57f000-7f086a580000 rw-p 0001f000 fd:01 3147544 /usr/local/lib/libgpg-error.so.0.24.2 + 7f086a580000-7f086a695000 r-xp 00000000 fd:01 3147567 /usr/local/lib/libgcrypt.so.20.2.3 + 7f086a695000-7f086a894000 ---p 00115000 fd:01 3147567 /usr/local/lib/libgcrypt.so.20.2.3 + 7f086a894000-7f086a896000 r--p 00114000 fd:01 3147567 /usr/local/lib/libgcrypt.so.20.2.3 + 7f086a896000-7f086a89b000 rw-p 00116000 fd:01 3147567 /usr/local/lib/libgcrypt.so.20.2.3 + 7f086a89b000-7f086a89c000 rw-p 00000000 00:00 0 + 7f086a8a0000-7f086a8af000 r--p 00000000 fd:01 11010259 /lib/x86_64-linux-gnu/libsystemd.so.0.24.0 + 7f086a8af000-7f086a918000 r-xp 0000f000 fd:01 11010259 /lib/x86_64-linux-gnu/libsystemd.so.0.24.0 + 7f086a918000-7f086a939000 r--p 00078000 fd:01 11010259 /lib/x86_64-linux-gnu/libsystemd.so.0.24.0 + 7f086a939000-7f086a93c000 r--p 00098000 fd:01 11010259 /lib/x86_64-linux-gnu/libsystemd.so.0.24.0 + 7f086a93c000-7f086a93d000 rw-p 0009b000 fd:01 11010259 /lib/x86_64-linux-gnu/libsystemd.so.0.24.0 + 7f086a93d000-7f086a93e000 rw-p 00000000 00:00 0 + 7f086a940000-7f086a944000 r--p 00000000 fd:01 11010051 /lib/x86_64-linux-gnu/libudev.so.1.6.12 + 7f086a944000-7f086a95b000 r-xp 00004000 fd:01 11010051 /lib/x86_64-linux-gnu/libudev.so.1.6.12 + 7f086a95b000-7f086a963000 r--p 0001b000 fd:01 11010051 /lib/x86_64-linux-gnu/libudev.so.1.6.12 + 7f086a963000-7f086a964000 ---p 00023000 fd:01 11010051 /lib/x86_64-linux-gnu/libudev.so.1.6.12 + 7f086a964000-7f086a965000 r--p 00023000 fd:01 11010051 /lib/x86_64-linux-gnu/libudev.so.1.6.12 + 7f086a965000-7f086a966000 rw-p 00024000 fd:01 11010051 /lib/x86_64-linux-gnu/libudev.so.1.6.12 + 7f086a968000-7f086a96c000 r--p 00000000 fd:01 2628521 /usr/lib/x86_64-linux-gnu/libzstd.so.1.3.8 + 7f086a96c000-7f086a9f4000 r-xp 00004000 fd:01 2628521 /usr/lib/x86_64-linux-gnu/libzstd.so.1.3.8 + 7f086a9f4000-7f086aa04000 r--p 0008c000 fd:01 2628521 /usr/lib/x86_64-linux-gnu/libzstd.so.1.3.8 + 7f086aa04000-7f086aa05000 ---p 0009c000 fd:01 2628521 /usr/lib/x86_64-linux-gnu/libzstd.so.1.3.8 + 7f086aa05000-7f086aa06000 r--p 0009c000 fd:01 2628521 /usr/lib/x86_64-linux-gnu/libzstd.so.1.3.8 + 7f086aa06000-7f086aa07000 rw-p 0009d000 fd:01 2628521 /usr/lib/x86_64-linux-gnu/libzstd.so.1.3.8 + 7f086aa08000-7f086aa0a000 r--p 00000000 fd:01 2622434 /usr/lib/x86_64-linux-gnu/liblz4.so.1.8.3 + 7f086aa0a000-7f086aa32000 r-xp 00002000 fd:01 2622434 /usr/lib/x86_64-linux-gnu/liblz4.so.1.8.3 + 7f086aa32000-7f086aa35000 r--p 0002a000 fd:01 2622434 /usr/lib/x86_64-linux-gnu/liblz4.so.1.8.3 + 7f086aa35000-7f086aa36000 r--p 0002c000 fd:01 2622434 /usr/lib/x86_64-linux-gnu/liblz4.so.1.8.3 + 7f086aa36000-7f086aa37000 rw-p 0002d000 fd:01 2622434 /usr/lib/x86_64-linux-gnu/liblz4.so.1.8.3 + 7f086aa38000-7f086aa3b000 r--p 00000000 fd:01 11010220 /lib/x86_64-linux-gnu/liblzma.so.5.2.4 + 7f086aa3b000-7f086aa52000 r-xp 00003000 fd:01 11010220 /lib/x86_64-linux-gnu/liblzma.so.5.2.4 + 7f086aa52000-7f086aa5d000 r--p 0001a000 fd:01 11010220 /lib/x86_64-linux-gnu/liblzma.so.5.2.4 + 7f086aa5d000-7f086aa5e000 r--p 00024000 fd:01 11010220 /lib/x86_64-linux-gnu/liblzma.so.5.2.4 + 7f086aa5e000-7f086aa5f000 rw-p 00025000 fd:01 11010220 /lib/x86_64-linux-gnu/liblzma.so.5.2.4 + 7f086aa60000-7f086aa62000 r--p 00000000 fd:01 11010296 /lib/x86_64-linux-gnu/libbz2.so.1.0.4 + 7f086aa62000-7f086aa6f000 r-xp 00002000 fd:01 11010296 /lib/x86_64-linux-gnu/libbz2.so.1.0.4 + 7f086aa6f000-7f086aa71000 r--p 0000f000 fd:01 11010296 /lib/x86_64-linux-gnu/libbz2.so.1.0.4 + 7f086aa71000-7f086aa72000 r--p 00010000 fd:01 11010296 /lib/x86_64-linux-gnu/libbz2.so.1.0.4 + 7f086aa72000-7f086aa73000 rw-p 00011000 fd:01 11010296 /lib/x86_64-linux-gnu/libbz2.so.1.0.4 + 7f086aa78000-7f086ab0d000 r--p 00000000 fd:01 2623796 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.26 + 7f086ab0d000-7f086abff000 r-xp 00095000 fd:01 2623796 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.26 + 7f086abff000-7f086ac48000 r--p 00187000 fd:01 2623796 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.26 + 7f086ac48000-7f086ac49000 ---p 001d0000 fd:01 2623796 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.26 + 7f086ac49000-7f086ac54000 r--p 001d0000 fd:01 2623796 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.26 + 7f086ac54000-7f086ac57000 rw-p 001db000 fd:01 2623796 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.26 + 7f086ac57000-7f086ac5a000 rw-p 00000000 00:00 0 + 7f086ac60000-7f086aca4000 r--p 00000000 fd:01 2626298 /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.2 + 7f086aca4000-7f086addc000 r-xp 00044000 fd:01 2626298 /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.2 + 7f086addc000-7f086ae23000 r--p 0017c000 fd:01 2626298 /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.2 + 7f086ae23000-7f086ae24000 ---p 001c3000 fd:01 2626298 /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.2 + 7f086ae24000-7f086ae2a000 r--p 001c3000 fd:01 2626298 /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.2 + 7f086ae2a000-7f086ae2b000 rw-p 001c9000 fd:01 2626298 /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.2 + 7f086ae30000-7f086ae31000 r--p 00000000 fd:01 2758579 /usr/lib/python3.7/lib-dynload/_opcode.cpython-37m-x86_64-linux-gnu.so + 7f086ae31000-7f086ae32000 r-xp 00001000 fd:01 2758579 /usr/lib/python3.7/lib-dynload/_opcode.cpython-37m-x86_64-linux-gnu.so + 7f086ae32000-7f086ae33000 r--p 00002000 fd:01 2758579 /usr/lib/python3.7/lib-dynload/_opcode.cpython-37m-x86_64-linux-gnu.so + 7f086ae33000-7f086ae34000 r--p 00002000 fd:01 2758579 /usr/lib/python3.7/lib-dynload/_opcode.cpython-37m-x86_64-linux-gnu.so + 7f086ae34000-7f086ae35000 rw-p 00003000 fd:01 2758579 /usr/lib/python3.7/lib-dynload/_opcode.cpython-37m-x86_64-linux-gnu.so + 7f086ae38000-7f086ae41000 r--p 00000000 fd:01 2758580 /usr/lib/python3.7/lib-dynload/_ssl.cpython-37m-x86_64-linux-gnu.so + 7f086ae41000-7f086ae49000 r-xp 00009000 fd:01 2758580 /usr/lib/python3.7/lib-dynload/_ssl.cpython-37m-x86_64-linux-gnu.so + 7f086ae49000-7f086ae4f000 r--p 00011000 fd:01 2758580 /usr/lib/python3.7/lib-dynload/_ssl.cpython-37m-x86_64-linux-gnu.so + 7f086ae4f000-7f086ae50000 r--p 00016000 fd:01 2758580 /usr/lib/python3.7/lib-dynload/_ssl.cpython-37m-x86_64-linux-gnu.so + 7f086ae50000-7f086ae55000 rw-p 00017000 fd:01 2758580 /usr/lib/python3.7/lib-dynload/_ssl.cpython-37m-x86_64-linux-gnu.so + 7f086ae58000-7f086ae6f000 r--p 00000000 fd:01 2624741 /usr/lib/python3/dist-packages/apt_pkg.cpython-37m-x86_64-linux-gnu.so + 7f086ae6f000-7f086ae8d000 r-xp 00017000 fd:01 2624741 /usr/lib/python3/dist-packages/apt_pkg.cpython-37m-x86_64-linux-gnu.so + 7f086ae8d000-7f086aea4000 r--p 00035000 fd:01 2624741 /usr/lib/python3/dist-packages/apt_pkg.cpython-37m-x86_64-linux-gnu.so + 7f086aea4000-7f086aea5000 ---p 0004c000 fd:01 2624741 /usr/lib/python3/dist-packages/apt_pkg.cpython-37m-x86_64-linux-gnu.so + 7f086aea5000-7f086aea7000 r--p 0004c000 fd:01 2624741 /usr/lib/python3/dist-packages/apt_pkg.cpython-37m-x86_64-linux-gnu.so + 7f086aea7000-7f086aeb0000 rw-p 0004e000 fd:01 2624741 /usr/lib/python3/dist-packages/apt_pkg.cpython-37m-x86_64-linux-gnu.so + 7f086aeb0000-7f086aef0000 rw-p 00000000 00:00 0 + 7f086aef0000-7f086aefe000 r--p 00000000 fd:01 2758626 /usr/lib/python3/dist-packages/cairo/_cairo.cpython-37m-x86_64-linux-gnu.so + 7f086aefe000-7f086af10000 r-xp 0000e000 fd:01 2758626 /usr/lib/python3/dist-packages/cairo/_cairo.cpython-37m-x86_64-linux-gnu.so + 7f086af10000-7f086af19000 r--p 00020000 fd:01 2758626 /usr/lib/python3/dist-packages/cairo/_cairo.cpython-37m-x86_64-linux-gnu.so + 7f086af19000-7f086af1a000 r--p 00028000 fd:01 2758626 /usr/lib/python3/dist-packages/cairo/_cairo.cpython-37m-x86_64-linux-gnu.so + 7f086af1a000-7f086af24000 rw-p 00029000 fd:01 2758626 /usr/lib/python3/dist-packages/cairo/_cairo.cpython-37m-x86_64-linux-gnu.so + 7f086af28000-7f086af2c000 r--p 00000000 fd:01 2625396 /usr/lib/x86_64-linux-gnu/libbsd.so.0.9.1 + 7f086af2c000-7f086af3b000 r-xp 00004000 fd:01 2625396 /usr/lib/x86_64-linux-gnu/libbsd.so.0.9.1 + 7f086af3b000-7f086af3e000 r--p 00013000 fd:01 2625396 /usr/lib/x86_64-linux-gnu/libbsd.so.0.9.1 + 7f086af3e000-7f086af3f000 ---p 00016000 fd:01 2625396 /usr/lib/x86_64-linux-gnu/libbsd.so.0.9.1 + 7f086af3f000-7f086af40000 r--p 00016000 fd:01 2625396 /usr/lib/x86_64-linux-gnu/libbsd.so.0.9.1 + 7f086af40000-7f086af41000 rw-p 00017000 fd:01 2625396 /usr/lib/x86_64-linux-gnu/libbsd.so.0.9.1 + 7f086af41000-7f086af42000 rw-p 00000000 00:00 0 + 7f086af48000-7f086af4d000 r-xp 00000000 fd:01 2624172 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 + 7f086af4d000-7f086b14c000 ---p 00005000 fd:01 2624172 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 + 7f086b14c000-7f086b14d000 r--p 00004000 fd:01 2624172 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 + 7f086b14d000-7f086b14e000 rw-p 00005000 fd:01 2624172 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 + 7f086b150000-7f086b152000 r-xp 00000000 fd:01 2627113 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 + 7f086b152000-7f086b352000 ---p 00002000 fd:01 2627113 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 + 7f086b352000-7f086b353000 r--p 00002000 fd:01 2627113 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 + 7f086b353000-7f086b354000 rw-p 00003000 fd:01 2627113 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 + 7f086b358000-7f086b369000 r-xp 00000000 fd:01 2627126 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 + 7f086b369000-7f086b568000 ---p 00011000 fd:01 2627126 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 + 7f086b568000-7f086b569000 r--p 00010000 fd:01 2627126 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 + 7f086b569000-7f086b56a000 rw-p 00011000 fd:01 2627126 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 + 7f086b570000-7f086b588000 r--p 00000000 fd:01 2624054 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 + 7f086b588000-7f086b610000 r-xp 00018000 fd:01 2624054 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 + 7f086b610000-7f086b6a4000 r--p 000a0000 fd:01 2624054 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 + 7f086b6a4000-7f086b6a5000 ---p 00134000 fd:01 2624054 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 + 7f086b6a5000-7f086b6a6000 r--p 00134000 fd:01 2624054 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 + 7f086b6a6000-7f086b6aa000 rw-p 00135000 fd:01 2624054 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 + 7f086b6b0000-7f086b6b9000 r-xp 00000000 fd:01 2626055 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 + 7f086b6b9000-7f086b8b8000 ---p 00009000 fd:01 2626055 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 + 7f086b8b8000-7f086b8b9000 r--p 00008000 fd:01 2626055 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 + 7f086b8b9000-7f086b8ba000 rw-p 00009000 fd:01 2626055 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 + 7f086b8c0000-7f086b8c5000 r--p 00000000 fd:01 2624444 /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0 + 7f086b8c5000-7f086b8ca000 r-xp 00005000 fd:01 2624444 /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0 + 7f086b8ca000-7f086b8cc000 r--p 0000a000 fd:01 2624444 /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0 + 7f086b8cc000-7f086b8cd000 ---p 0000c000 fd:01 2624444 /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0 + 7f086b8cd000-7f086b8ce000 r--p 0000c000 fd:01 2624444 /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0 + 7f086b8ce000-7f086b8cf000 rw-p 0000d000 fd:01 2624444 /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0 + 7f086b8d0000-7f086b8db000 r--p 00000000 fd:01 2621875 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 + 7f086b8db000-7f086b8ee000 r-xp 0000b000 fd:01 2621875 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 + 7f086b8ee000-7f086b8f7000 r--p 0001e000 fd:01 2621875 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 + 7f086b8f7000-7f086b8f8000 r--p 00026000 fd:01 2621875 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 + 7f086b8f8000-7f086b8f9000 rw-p 00027000 fd:01 2621875 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 + 7f086b900000-7f086b905000 r--p 00000000 fd:01 2624103 /usr/lib/x86_64-linux-gnu/libpng16.so.16.36.0 + 7f086b905000-7f086b929000 r-xp 00005000 fd:01 2624103 /usr/lib/x86_64-linux-gnu/libpng16.so.16.36.0 + 7f086b929000-7f086b935000 r--p 00029000 fd:01 2624103 /usr/lib/x86_64-linux-gnu/libpng16.so.16.36.0 + 7f086b935000-7f086b936000 r--p 00034000 fd:01 2624103 /usr/lib/x86_64-linux-gnu/libpng16.so.16.36.0 + 7f086b936000-7f086b937000 rw-p 00035000 fd:01 2624103 /usr/lib/x86_64-linux-gnu/libpng16.so.16.36.0 + 7f086b938000-7f086b944000 r--p 00000000 fd:01 2623278 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.16.1 + 7f086b944000-7f086b9c1000 r-xp 0000c000 fd:01 2623278 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.16.1 + 7f086b9c1000-7f086b9ea000 r--p 00089000 fd:01 2623278 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.16.1 + 7f086b9ea000-7f086b9eb000 ---p 000b2000 fd:01 2623278 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.16.1 + 7f086b9eb000-7f086b9f2000 r--p 000b2000 fd:01 2623278 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.16.1 + 7f086b9f2000-7f086b9f3000 rw-p 000b9000 fd:01 2623278 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.16.1 + 7f086b9f8000-7f086b9ff000 r--p 00000000 fd:01 2624788 /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0 + 7f086b9ff000-7f086ba23000 r-xp 00007000 fd:01 2624788 /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0 + 7f086ba23000-7f086ba3b000 r--p 0002b000 fd:01 2624788 /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0 + 7f086ba3b000-7f086ba3d000 r--p 00042000 fd:01 2624788 /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0 + 7f086ba3d000-7f086ba3e000 rw-p 00044000 fd:01 2624788 /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0 + 7f086ba40000-7f086ba4a000 r--p 00000000 fd:01 2621770 /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.36.0 + 7f086ba4a000-7f086bacd000 r-xp 0000a000 fd:01 2621770 /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.36.0 + 7f086bacd000-7f086badd000 r--p 0008d000 fd:01 2621770 /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.36.0 + 7f086badd000-7f086bae5000 r--p 0009c000 fd:01 2621770 /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.36.0 + 7f086bae5000-7f086bae6000 rw-p 000a4000 fd:01 2621770 /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.36.0 + 7f086bae8000-7f086bafa000 r--p 00000000 fd:01 2624264 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11600.0 + 7f086bafa000-7f086bbc6000 r-xp 00012000 fd:01 2624264 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11600.0 + 7f086bbc6000-7f086bc02000 r--p 000de000 fd:01 2624264 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11600.0 + 7f086bc02000-7f086bc06000 r--p 00119000 fd:01 2624264 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11600.0 + 7f086bc06000-7f086bc07000 rw-p 0011d000 fd:01 2624264 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11600.0 + 7f086bc07000-7f086bc08000 rw-p 00000000 00:00 0 + 7f086bc10000-7f086bc13000 r--p 00000000 fd:01 11010272 /lib/x86_64-linux-gnu/libgcc_s.so.1 + 7f086bc13000-7f086bc24000 r-xp 00003000 fd:01 11010272 /lib/x86_64-linux-gnu/libgcc_s.so.1 + 7f086bc24000-7f086bc28000 r--p 00014000 fd:01 11010272 /lib/x86_64-linux-gnu/libgcc_s.so.1 + 7f086bc28000-7f086bc29000 r--p 00017000 fd:01 11010272 /lib/x86_64-linux-gnu/libgcc_s.so.1 + 7f086bc29000-7f086bc2a000 rw-p 00018000 fd:01 11010272 /lib/x86_64-linux-gnu/libgcc_s.so.1 + 7f086bc30000-7f086bc70000 rw-p 00000000 00:00 0 + 7f086bc70000-7f086bc7a000 r--p 00000000 fd:01 11010331 /lib/x86_64-linux-gnu/libblkid.so.1.1.0 + 7f086bc7a000-7f086bcae000 r-xp 0000a000 fd:01 11010331 /lib/x86_64-linux-gnu/libblkid.so.1.1.0 + 7f086bcae000-7f086bcbe000 r--p 0003e000 fd:01 11010331 /lib/x86_64-linux-gnu/libblkid.so.1.1.0 + 7f086bcbe000-7f086bcbf000 ---p 0004e000 fd:01 11010331 /lib/x86_64-linux-gnu/libblkid.so.1.1.0 + 7f086bcbf000-7f086bcc4000 r--p 0004e000 fd:01 11010331 /lib/x86_64-linux-gnu/libblkid.so.1.1.0 + 7f086bcc4000-7f086bcc5000 rw-p 00053000 fd:01 11010331 /lib/x86_64-linux-gnu/libblkid.so.1.1.0 + 7f086bcc8000-7f086bccc000 r--p 00000000 fd:01 11010530 /lib/x86_64-linux-gnu/libresolv-2.29.so + 7f086bccc000-7f086bcdb000 r-xp 00004000 fd:01 11010530 /lib/x86_64-linux-gnu/libresolv-2.29.so + 7f086bcdb000-7f086bcde000 r--p 00013000 fd:01 11010530 /lib/x86_64-linux-gnu/libresolv-2.29.so + 7f086bcde000-7f086bcdf000 ---p 00016000 fd:01 11010530 /lib/x86_64-linux-gnu/libresolv-2.29.so + 7f086bcdf000-7f086bce0000 r--p 00016000 fd:01 11010530 /lib/x86_64-linux-gnu/libresolv-2.29.so + 7f086bce0000-7f086bce1000 rw-p 00017000 fd:01 11010530 /lib/x86_64-linux-gnu/libresolv-2.29.so + 7f086bce1000-7f086bce3000 rw-p 00000000 00:00 0 + 7f086bce8000-7f086bcee000 r--p 00000000 fd:01 11010270 /lib/x86_64-linux-gnu/libselinux.so.1 + 7f086bcee000-7f086bd06000 r-xp 00006000 fd:01 11010270 /lib/x86_64-linux-gnu/libselinux.so.1 + 7f086bd06000-7f086bd0d000 r--p 0001e000 fd:01 11010270 /lib/x86_64-linux-gnu/libselinux.so.1 + 7f086bd0d000-7f086bd0e000 ---p 00025000 fd:01 11010270 /lib/x86_64-linux-gnu/libselinux.so.1 + 7f086bd0e000-7f086bd0f000 r--p 00025000 fd:01 11010270 /lib/x86_64-linux-gnu/libselinux.so.1 + 7f086bd0f000-7f086bd10000 rw-p 00026000 fd:01 11010270 /lib/x86_64-linux-gnu/libselinux.so.1 + 7f086bd10000-7f086bd12000 rw-p 00000000 00:00 0 + 7f086bd18000-7f086bd23000 r--p 00000000 fd:01 11010466 /lib/x86_64-linux-gnu/libmount.so.1.1.0 + 7f086bd23000-7f086bd5e000 r-xp 0000b000 fd:01 11010466 /lib/x86_64-linux-gnu/libmount.so.1.1.0 + 7f086bd5e000-7f086bd70000 r--p 00046000 fd:01 11010466 /lib/x86_64-linux-gnu/libmount.so.1.1.0 + 7f086bd70000-7f086bd73000 r--p 00057000 fd:01 11010466 /lib/x86_64-linux-gnu/libmount.so.1.1.0 + 7f086bd73000-7f086bd74000 rw-p 0005a000 fd:01 11010466 /lib/x86_64-linux-gnu/libmount.so.1.1.0 + 7f086bd78000-7f086bdaf000 r--p 00000000 fd:01 2621583 /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6000.4 + 7f086bdaf000-7f086beb0000 r-xp 00037000 fd:01 2621583 /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6000.4 + 7f086beb0000-7f086bf36000 r--p 00138000 fd:01 2621583 /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6000.4 + 7f086bf36000-7f086bf3e000 r--p 001bd000 fd:01 2621583 /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6000.4 + 7f086bf3e000-7f086bf3f000 rw-p 001c5000 fd:01 2621583 /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6000.4 + 7f086bf3f000-7f086bf41000 rw-p 00000000 00:00 0 + 7f086bf48000-7f086bfb9000 r-xp 00000000 fd:01 11010538 /lib/x86_64-linux-gnu/libpcre.so.3.13.3 + 7f086bfb9000-7f086c1b8000 ---p 00071000 fd:01 11010538 /lib/x86_64-linux-gnu/libpcre.so.3.13.3 + 7f086c1b8000-7f086c1b9000 r--p 00070000 fd:01 11010538 /lib/x86_64-linux-gnu/libpcre.so.3.13.3 + 7f086c1b9000-7f086c1ba000 rw-p 00071000 fd:01 11010538 /lib/x86_64-linux-gnu/libpcre.so.3.13.3 + 7f086c1c0000-7f086c1c7000 r--p 00000000 fd:01 2621912 /usr/lib/x86_64-linux-gnu/libgirepository-1.0.so.1.0.0 + 7f086c1c7000-7f086c1e7000 r-xp 00007000 fd:01 2621912 /usr/lib/x86_64-linux-gnu/libgirepository-1.0.so.1.0.0 + 7f086c1e7000-7f086c1f4000 r--p 00027000 fd:01 2621912 /usr/lib/x86_64-linux-gnu/libgirepository-1.0.so.1.0.0 + 7f086c1f4000-7f086c1f5000 ---p 00034000 fd:01 2621912 /usr/lib/x86_64-linux-gnu/libgirepository-1.0.so.1.0.0 + 7f086c1f5000-7f086c1f6000 r--p 00034000 fd:01 2621912 /usr/lib/x86_64-linux-gnu/libgirepository-1.0.so.1.0.0 + 7f086c1f6000-7f086c1f7000 rw-p 00035000 fd:01 2621912 /usr/lib/x86_64-linux-gnu/libgirepository-1.0.so.1.0.0 + 7f086c1f8000-7f086c213000 r--p 00000000 fd:01 2621584 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6000.4 + 7f086c213000-7f086c293000 r-xp 0001b000 fd:01 2621584 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6000.4 + 7f086c293000-7f086c315000 r--p 0009b000 fd:01 2621584 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6000.4 + 7f086c315000-7f086c316000 ---p 0011d000 fd:01 2621584 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6000.4 + 7f086c316000-7f086c317000 r--p 0011d000 fd:01 2621584 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6000.4 + 7f086c317000-7f086c318000 rw-p 0011e000 fd:01 2621584 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6000.4 + 7f086c318000-7f086c319000 rw-p 00000000 00:00 0 + 7f086c31a000-7f086c35a000 rw-p 00000000 00:00 0 + 7f086c360000-7f086c362000 r--p 00000000 fd:01 11010327 /lib/x86_64-linux-gnu/libuuid.so.1.3.0 + 7f086c362000-7f086c366000 r-xp 00002000 fd:01 11010327 /lib/x86_64-linux-gnu/libuuid.so.1.3.0 + 7f086c366000-7f086c367000 r--p 00006000 fd:01 11010327 /lib/x86_64-linux-gnu/libuuid.so.1.3.0 + 7f086c367000-7f086c368000 r--p 00006000 fd:01 11010327 /lib/x86_64-linux-gnu/libuuid.so.1.3.0 + 7f086c368000-7f086c369000 rw-p 00007000 fd:01 11010327 /lib/x86_64-linux-gnu/libuuid.so.1.3.0 + 7f086c370000-7f086c37e000 r--p 00000000 fd:01 2621586 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6000.4 + 7f086c37e000-7f086c3b0000 r-xp 0000e000 fd:01 2621586 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6000.4 + 7f086c3b0000-7f086c3c8000 r--p 00040000 fd:01 2621586 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6000.4 + 7f086c3c8000-7f086c3cb000 r--p 00057000 fd:01 2621586 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6000.4 + 7f086c3cb000-7f086c3cc000 rw-p 0005a000 fd:01 2621586 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6000.4 + 7f086c3d0000-7f086c3d2000 r--p 00000000 fd:01 2758578 /usr/lib/python3.7/lib-dynload/_hashlib.cpython-37m-x86_64-linux-gnu.so + 7f086c3d2000-7f086c3d5000 r-xp 00002000 fd:01 2758578 /usr/lib/python3.7/lib-dynload/_hashlib.cpython-37m-x86_64-linux-gnu.so + 7f086c3d5000-7f086c3d6000 r--p 00005000 fd:01 2758578 /usr/lib/python3.7/lib-dynload/_hashlib.cpython-37m-x86_64-linux-gnu.so + 7f086c3d6000-7f086c3d7000 ---p 00006000 fd:01 2758578 /usr/lib/python3.7/lib-dynload/_hashlib.cpython-37m-x86_64-linux-gnu.so + 7f086c3d7000-7f086c3d8000 r--p 00006000 fd:01 2758578 /usr/lib/python3.7/lib-dynload/_hashlib.cpython-37m-x86_64-linux-gnu.so + 7f086c3d8000-7f086c3d9000 rw-p 00007000 fd:01 2758578 /usr/lib/python3.7/lib-dynload/_hashlib.cpython-37m-x86_64-linux-gnu.so + 7f086c3e0000-7f086c3e4000 r--p 00000000 fd:01 2625983 /usr/lib/x86_64-linux-gnu/libcairo-gobject.so.2.11600.0 + 7f086c3e4000-7f086c3e6000 r-xp 00004000 fd:01 2625983 /usr/lib/x86_64-linux-gnu/libcairo-gobject.so.2.11600.0 + 7f086c3e6000-7f086c3e8000 r--p 00006000 fd:01 2625983 /usr/lib/x86_64-linux-gnu/libcairo-gobject.so.2.11600.0 + 7f086c3e8000-7f086c3e9000 ---p 00008000 fd:01 2625983 /usr/lib/x86_64-linux-gnu/libcairo-gobject.so.2.11600.0 + 7f086c3e9000-7f086c3eb000 r--p 00008000 fd:01 2625983 /usr/lib/x86_64-linux-gnu/libcairo-gobject.so.2.11600.0 + 7f086c3eb000-7f086c3ec000 rw-p 0000a000 fd:01 2625983 /usr/lib/x86_64-linux-gnu/libcairo-gobject.so.2.11600.0 + 7f086c3f0000-7f086c3f2000 r--p 00000000 fd:01 2756638 /usr/lib/python3/dist-packages/gi/_gi_cairo.cpython-37m-x86_64-linux-gnu.so + 7f086c3f2000-7f086c3f4000 r-xp 00002000 fd:01 2756638 /usr/lib/python3/dist-packages/gi/_gi_cairo.cpython-37m-x86_64-linux-gnu.so + 7f086c3f4000-7f086c3f5000 r--p 00004000 fd:01 2756638 /usr/lib/python3/dist-packages/gi/_gi_cairo.cpython-37m-x86_64-linux-gnu.so + 7f086c3f5000-7f086c3f6000 r--p 00004000 fd:01 2756638 /usr/lib/python3/dist-packages/gi/_gi_cairo.cpython-37m-x86_64-linux-gnu.so + 7f086c3f6000-7f086c3f7000 rw-p 00005000 fd:01 2756638 /usr/lib/python3/dist-packages/gi/_gi_cairo.cpython-37m-x86_64-linux-gnu.so + 7f086c3f8000-7f086c407000 r--p 00000000 fd:01 2755379 /usr/lib/python3/dist-packages/gi/_gi.cpython-37m-x86_64-linux-gnu.so + 7f086c407000-7f086c431000 r-xp 0000f000 fd:01 2755379 /usr/lib/python3/dist-packages/gi/_gi.cpython-37m-x86_64-linux-gnu.so + 7f086c431000-7f086c441000 r--p 00039000 fd:01 2755379 /usr/lib/python3/dist-packages/gi/_gi.cpython-37m-x86_64-linux-gnu.so + 7f086c441000-7f086c443000 r--p 00048000 fd:01 2755379 /usr/lib/python3/dist-packages/gi/_gi.cpython-37m-x86_64-linux-gnu.so + 7f086c443000-7f086c44a000 rw-p 0004a000 fd:01 2755379 /usr/lib/python3/dist-packages/gi/_gi.cpython-37m-x86_64-linux-gnu.so + 7f086c451000-7f086c4d1000 rw-p 00000000 00:00 0 + 7f086c4d8000-7f086c4df000 r--p 00000000 fd:01 2627042 /usr/lib/python3/dist-packages/_dbus_bindings.cpython-37m-x86_64-linux-gnu.so + 7f086c4df000-7f086c4ed000 r-xp 00007000 fd:01 2627042 /usr/lib/python3/dist-packages/_dbus_bindings.cpython-37m-x86_64-linux-gnu.so + 7f086c4ed000-7f086c4f3000 r--p 00015000 fd:01 2627042 /usr/lib/python3/dist-packages/_dbus_bindings.cpython-37m-x86_64-linux-gnu.so + 7f086c4f3000-7f086c4f4000 ---p 0001b000 fd:01 2627042 /usr/lib/python3/dist-packages/_dbus_bindings.cpython-37m-x86_64-linux-gnu.so + 7f086c4f4000-7f086c4f5000 r--p 0001b000 fd:01 2627042 /usr/lib/python3/dist-packages/_dbus_bindings.cpython-37m-x86_64-linux-gnu.so + 7f086c4f5000-7f086c502000 rw-p 0001c000 fd:01 2627042 /usr/lib/python3/dist-packages/_dbus_bindings.cpython-37m-x86_64-linux-gnu.so + 7f086c508000-7f086c50c000 r--p 00000000 fd:01 2623197 /usr/lib/python3/dist-packages/apt_inst.cpython-37m-x86_64-linux-gnu.so + 7f086c50c000-7f086c510000 r-xp 00004000 fd:01 2623197 /usr/lib/python3/dist-packages/apt_inst.cpython-37m-x86_64-linux-gnu.so + 7f086c510000-7f086c513000 r--p 00008000 fd:01 2623197 /usr/lib/python3/dist-packages/apt_inst.cpython-37m-x86_64-linux-gnu.so + 7f086c513000-7f086c514000 ---p 0000b000 fd:01 2623197 /usr/lib/python3/dist-packages/apt_inst.cpython-37m-x86_64-linux-gnu.so + 7f086c514000-7f086c515000 r--p 0000b000 fd:01 2623197 /usr/lib/python3/dist-packages/apt_inst.cpython-37m-x86_64-linux-gnu.so + 7f086c515000-7f086c516000 rw-p 0000c000 fd:01 2623197 /usr/lib/python3/dist-packages/apt_inst.cpython-37m-x86_64-linux-gnu.so + 7f086c51a000-7f086c67b000 rw-p 00000000 00:00 0 + 7f086c680000-7f086c681000 r--p 00000000 fd:01 2623001 /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0 + 7f086c681000-7f086c682000 r-xp 00001000 fd:01 2623001 /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0 + 7f086c682000-7f086c683000 r--p 00002000 fd:01 2623001 /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0 + 7f086c683000-7f086c684000 r--p 00002000 fd:01 2623001 /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0 + 7f086c684000-7f086c685000 rw-p 00003000 fd:01 2623001 /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0 + 7f086c688000-7f086c68b000 r--p 00000000 fd:01 11010600 /lib/x86_64-linux-gnu/librt-2.29.so + 7f086c68b000-7f086c68f000 r-xp 00003000 fd:01 11010600 /lib/x86_64-linux-gnu/librt-2.29.so + 7f086c68f000-7f086c691000 r--p 00007000 fd:01 11010600 /lib/x86_64-linux-gnu/librt-2.29.so + 7f086c691000-7f086c692000 r--p 00008000 fd:01 11010600 /lib/x86_64-linux-gnu/librt-2.29.so + 7f086c692000-7f086c693000 rw-p 00009000 fd:01 11010600 /lib/x86_64-linux-gnu/librt-2.29.so + 7f086c698000-7f086c699000 r--p 00000000 fd:01 2621585 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.6000.4 + 7f086c699000-7f086c69b000 r-xp 00001000 fd:01 2621585 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.6000.4 + 7f086c69b000-7f086c69c000 r--p 00003000 fd:01 2621585 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.6000.4 + 7f086c69c000-7f086c69d000 r--p 00003000 fd:01 2621585 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.6000.4 + 7f086c69d000-7f086c69e000 rw-p 00004000 fd:01 2621585 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.6000.4 + 7f086c6a0000-7f086c7e0000 rw-p 00000000 00:00 0 + 7f086c7e0000-7f086cda2000 r--p 00000000 fd:01 2622412 /usr/lib/locale/locale-archive + 7f086cda8000-7f086cdb7000 r--p 00000000 fd:01 11010315 /lib/x86_64-linux-gnu/libm-2.29.so + 7f086cdb7000-7f086ce5d000 r-xp 0000f000 fd:01 11010315 /lib/x86_64-linux-gnu/libm-2.29.so + 7f086ce5d000-7f086cef4000 r--p 000b5000 fd:01 11010315 /lib/x86_64-linux-gnu/libm-2.29.so + 7f086cef4000-7f086cef5000 r--p 0014b000 fd:01 11010315 /lib/x86_64-linux-gnu/libm-2.29.so + 7f086cef5000-7f086cef6000 rw-p 0014c000 fd:01 11010315 /lib/x86_64-linux-gnu/libm-2.29.so + 7f086cef8000-7f086cefa000 r--p 00000000 fd:01 11010324 /lib/x86_64-linux-gnu/libz.so.1.2.11 + 7f086cefa000-7f086cf0b000 r-xp 00002000 fd:01 11010324 /lib/x86_64-linux-gnu/libz.so.1.2.11 + 7f086cf0b000-7f086cf11000 r--p 00013000 fd:01 11010324 /lib/x86_64-linux-gnu/libz.so.1.2.11 + 7f086cf11000-7f086cf12000 ---p 00019000 fd:01 11010324 /lib/x86_64-linux-gnu/libz.so.1.2.11 + 7f086cf12000-7f086cf13000 r--p 00019000 fd:01 11010324 /lib/x86_64-linux-gnu/libz.so.1.2.11 + 7f086cf13000-7f086cf14000 rw-p 0001a000 fd:01 11010324 /lib/x86_64-linux-gnu/libz.so.1.2.11 + 7f086cf18000-7f086cf1c000 r--p 00000000 fd:01 11010519 /lib/x86_64-linux-gnu/libexpat.so.1.6.8 + 7f086cf1c000-7f086cf3d000 r-xp 00004000 fd:01 11010519 /lib/x86_64-linux-gnu/libexpat.so.1.6.8 + 7f086cf3d000-7f086cf51000 r--p 00025000 fd:01 11010519 /lib/x86_64-linux-gnu/libexpat.so.1.6.8 + 7f086cf51000-7f086cf52000 ---p 00039000 fd:01 11010519 /lib/x86_64-linux-gnu/libexpat.so.1.6.8 + 7f086cf52000-7f086cf54000 r--p 00039000 fd:01 11010519 /lib/x86_64-linux-gnu/libexpat.so.1.6.8 + 7f086cf54000-7f086cf55000 rw-p 0003b000 fd:01 11010519 /lib/x86_64-linux-gnu/libexpat.so.1.6.8 + 7f086cf58000-7f086cf59000 r--p 00000000 fd:01 11010609 /lib/x86_64-linux-gnu/libutil-2.29.so + 7f086cf59000-7f086cf5a000 r-xp 00001000 fd:01 11010609 /lib/x86_64-linux-gnu/libutil-2.29.so + 7f086cf5a000-7f086cf5b000 r--p 00002000 fd:01 11010609 /lib/x86_64-linux-gnu/libutil-2.29.so + 7f086cf5b000-7f086cf5c000 r--p 00002000 fd:01 11010609 /lib/x86_64-linux-gnu/libutil-2.29.so + 7f086cf5c000-7f086cf5d000 rw-p 00003000 fd:01 11010609 /lib/x86_64-linux-gnu/libutil-2.29.so + 7f086cf60000-7f086cf61000 r--p 00000000 fd:01 11010305 /lib/x86_64-linux-gnu/libdl-2.29.so + 7f086cf61000-7f086cf63000 r-xp 00001000 fd:01 11010305 /lib/x86_64-linux-gnu/libdl-2.29.so + 7f086cf63000-7f086cf64000 r--p 00003000 fd:01 11010305 /lib/x86_64-linux-gnu/libdl-2.29.so + 7f086cf64000-7f086cf65000 r--p 00003000 fd:01 11010305 /lib/x86_64-linux-gnu/libdl-2.29.so + 7f086cf65000-7f086cf66000 rw-p 00004000 fd:01 11010305 /lib/x86_64-linux-gnu/libdl-2.29.so + 7f086cf68000-7f086cf6f000 r--p 00000000 fd:01 11010525 /lib/x86_64-linux-gnu/libpthread-2.29.so + 7f086cf6f000-7f086cf7e000 r-xp 00007000 fd:01 11010525 /lib/x86_64-linux-gnu/libpthread-2.29.so + 7f086cf7e000-7f086cf83000 r--p 00016000 fd:01 11010525 /lib/x86_64-linux-gnu/libpthread-2.29.so + 7f086cf83000-7f086cf84000 r--p 0001a000 fd:01 11010525 /lib/x86_64-linux-gnu/libpthread-2.29.so + 7f086cf84000-7f086cf85000 rw-p 0001b000 fd:01 11010525 /lib/x86_64-linux-gnu/libpthread-2.29.so + 7f086cf85000-7f086cf89000 rw-p 00000000 00:00 0 + 7f086cf90000-7f086cfb5000 r--p 00000000 fd:01 11010130 /lib/x86_64-linux-gnu/libc-2.29.so + 7f086cfb5000-7f086d128000 r-xp 00025000 fd:01 11010130 /lib/x86_64-linux-gnu/libc-2.29.so + 7f086d128000-7f086d171000 r--p 00198000 fd:01 11010130 /lib/x86_64-linux-gnu/libc-2.29.so + 7f086d171000-7f086d174000 r--p 001e0000 fd:01 11010130 /lib/x86_64-linux-gnu/libc-2.29.so + 7f086d174000-7f086d177000 rw-p 001e3000 fd:01 11010130 /lib/x86_64-linux-gnu/libc-2.29.so + 7f086d177000-7f086d17b000 rw-p 00000000 00:00 0 + 7f086d17d000-7f086d180000 rw-p 00000000 00:00 0 + 7f086d188000-7f086d18a000 r--p 00000000 fd:01 2627514 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4 + 7f086d18a000-7f086d18f000 r-xp 00002000 fd:01 2627514 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4 + 7f086d18f000-7f086d190000 r--p 00007000 fd:01 2627514 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4 + 7f086d190000-7f086d191000 r--p 00007000 fd:01 2627514 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4 + 7f086d191000-7f086d192000 rw-p 00008000 fd:01 2627514 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4 + 7f086d198000-7f086d19f000 r--s 00000000 fd:01 3022083 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache + 7f086d1a6000-7f086d1a8000 rw-p 00000000 00:00 0 + 7f086d1a8000-7f086d1a9000 r--p 00000000 fd:01 11010105 /lib/x86_64-linux-gnu/ld-2.29.so + 7f086d1a9000-7f086d1ca000 r-xp 00001000 fd:01 11010105 /lib/x86_64-linux-gnu/ld-2.29.so + 7f086d1ca000-7f086d1d2000 r--p 00022000 fd:01 11010105 /lib/x86_64-linux-gnu/ld-2.29.so + 7f086d1d2000-7f086d1d3000 r--p 00029000 fd:01 11010105 /lib/x86_64-linux-gnu/ld-2.29.so + 7f086d1d3000-7f086d1d4000 rw-p 0002a000 fd:01 11010105 /lib/x86_64-linux-gnu/ld-2.29.so + 7f086d1d4000-7f086d1d5000 rw-p 00000000 00:00 0 + 7f086d1d6000-7f086d1d8000 rw-p 00000000 00:00 0 + 7ffc51666000-7ffc51687000 rw-p 00000000 00:00 0 [stack] + 7ffc51790000-7ffc51793000 r--p 00000000 00:00 0 [vvar] + 7ffc51793000-7ffc51794000 r-xp 00000000 00:00 0 [vdso] +ProcStatus: + Name: session-install + Umask: 0022 + State: R (running) + Tgid: 5886 + Ngid: 0 + Pid: 5886 + PPid: 5885 + TracerPid: 0 + Uid: 0 0 0 0 + Gid: 0 0 0 0 + FDSize: 64 + Groups: 0 + NStgid: 5886 + NSpid: 5886 + NSpgid: 3350 + NSsid: 3350 + VmPeak: 63740 kB + VmSize: 63740 kB + VmLck: 0 kB + VmPin: 0 kB + VmHWM: 30236 kB + VmRSS: 30236 kB + RssAnon: 13316 kB + RssFile: 16920 kB + RssShmem: 0 kB + VmData: 13496 kB + VmStk: 132 kB + VmExe: 2388 kB + VmLib: 15956 kB + VmPTE: 156 kB + VmSwap: 0 kB + HugetlbPages: 0 kB + CoreDumping: 0 + THP_enabled: 1 + Threads: 1 + SigQ: 0/127980 + SigPnd: 0000000000000000 + ShdPnd: 0000000000000000 + SigBlk: 0000000000000000 + SigIgn: 0000000001001000 + SigCgt: 0000000180000002 + CapInh: 0000000000000000 + CapPrm: 0000003fffffffff + CapEff: 0000003fffffffff + CapBnd: 0000003fffffffff + CapAmb: 0000000000000000 + NoNewPrivs: 0 + Seccomp: 0 + Speculation_Store_Bypass: globally mitigated + Cpus_allowed: ff + Cpus_allowed_list: 0-7 + Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 + Mems_allowed_list: 0 + voluntary_ctxt_switches: 87 + nonvoluntary_ctxt_switches: 54 +PythonArgs: ['/usr/bin/session-installer'] +Traceback: + Traceback (most recent call last): + File "/usr/bin/session-installer", line 23, in <module> + from sessioninstaller.core import main + File "/usr/lib/python3/dist-packages/sessioninstaller/core.py", line 47, in <module> + gi.require_version('GtK', '3.0') + File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in require_version + raise ValueError('Namespace %s not available' % namespace) + ValueError: Namespace GtK not available +UserGroups: +_LogindSession: c3 + + + +That crash seems to be from sessioninstaller which is not related to virt-manager. +But never the less from your log: +"ValueError: Namespace GtK not available" + +But virt-manager could require the same. + +In fact things are provided by gir1.2-gtk-3.0 and virt-manager has: + Depends: ... gir1.2-gtk-3.0 (>= 3.10) + +You could clear your /var/crash directory (IIRC by default it won't collect crashes over and over until cleared or reported). And then run virt-mamager again. +Is a new crash created, and if so how does that one look then? + +@ Christian, I delete all files in /var/crash and +run virt-manager again in terminal... + +Segmentation fault is present. + + +I did this, too: + +# sudo su +# PYTHONDEVMODE=1 virt-manager --no-fork + +Fatal Python error: Segmentation fault + +Current thread 0x00007f2309805740 (most recent call first): + File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed + File "<frozen importlib._bootstrap_external>", line 1043 in create_module + File "<frozen importlib._bootstrap>", line 583 in module_from_spec + File "<frozen importlib._bootstrap>", line 670 in _load_unlocked + File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked + File "<frozen importlib._bootstrap>", line 983 in _find_and_load + File "/usr/lib/python3.7/lzma.py", line 27 in <module> + File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed + File "<frozen importlib._bootstrap_external>", line 728 in exec_module + File "<frozen importlib._bootstrap>", line 677 in _load_unlocked + File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked + File "<frozen importlib._bootstrap>", line 983 in _find_and_load + File "/usr/lib/python3.7/shutil.py", line 29 in <module> + File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed + File "<frozen importlib._bootstrap_external>", line 728 in exec_module + File "<frozen importlib._bootstrap>", line 677 in _load_unlocked + File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked + File "<frozen importlib._bootstrap>", line 983 in _find_and_load + File "/usr/lib/python3.7/tempfile.py", line 44 in <module> + File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed + File "<frozen importlib._bootstrap_external>", line 728 in exec_module + File "<frozen importlib._bootstrap>", line 677 in _load_unlocked + File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked + File "<frozen importlib._bootstrap>", line 983 in _find_and_load + File "/usr/lib/python3/dist-packages/apport/report.py", line 12 in <module> + File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed + File "<frozen importlib._bootstrap_external>", line 728 in exec_module + File "<frozen importlib._bootstrap>", line 677 in _load_unlocked + File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked + File "<frozen importlib._bootstrap>", line 983 in _find_and_load + File "/usr/lib/python3/dist-packages/apport/__init__.py", line 5 in <module> + File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed + File "<frozen importlib._bootstrap_external>", line 728 in exec_module + File "<frozen importlib._bootstrap>", line 677 in _load_unlocked + File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked + File "<frozen importlib._bootstrap>", line 983 in _find_and_load + File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed + File "<frozen importlib._bootstrap>", line 953 in _find_and_load_unlocked + File "<frozen importlib._bootstrap>", line 983 in _find_and_load + File "/usr/lib/python3/dist-packages/apport_python_hook.py", line 63 in apport_excepthook +Segmentation fault + +I don't know how to fix that. + +Can you do anything with that @ Christian? + +I removed in "/usr/lib/python3/dist-packages" the file "apport_python_hook.py" + +so the output of # PYTHONDEVMODE=1 virt-manager --no-fork + +is now: + +Traceback (most recent call last): + File "/usr/lib/python3/dist-packages/libvirt.py", line 24, in <module> + import cygvirtmod as libvirtmod +ModuleNotFoundError: No module named 'cygvirtmod' + +During handling of the above exception, another exception occurred: + +Traceback (most recent call last): + File "/usr/share/virt-manager/virt-manager", line 20, in <module> + from virtinst import util + File "/usr/share/virt-manager/virtinst/__init__.py", line 26, in <module> + from virtinst import util + File "/usr/share/virt-manager/virtinst/util.py", line 15, in <module> + import libvirt + File "/usr/lib/python3/dist-packages/libvirt.py", line 28, in <module> + raise lib_e + File "/usr/lib/python3/dist-packages/libvirt.py", line 20, in <module> + import libvirtmod +ImportError: /usr/lib/x86_64-linux-gnu/libhogweed.so.4: symbol nettle_cnd_memcpy version NETTLE_6 not defined in file libnettle.so.6 with link time reference + + +(SOLVED) here: + +https://ubuntu-mate.community/t/cant-run-virt-manager-qemu-segmentation-fault/19996/5 + +So it was stray self built libs in /usr/local - thanks for the ping here Hans. +Marking the bug as invalid then as it is no issue in the package. + diff --git a/results/classifier/zero-shot/108/all/1838390 b/results/classifier/zero-shot/108/all/1838390 new file mode 100644 index 000000000..23dd7fd70 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1838390 @@ -0,0 +1,99 @@ +permissions: 0.984 +boot: 0.983 +other: 0.981 +performance: 0.977 +debug: 0.977 +network: 0.974 +graphic: 0.974 +vnc: 0.974 +device: 0.973 +PID: 0.973 +socket: 0.972 +semantic: 0.971 +files: 0.961 +KVM: 0.959 + +vmx_write_mem: mmu_gva_to_gpa failed when using hvf + +Installed qemu 4.0.0 by homebrew, used below commands: + +1. qemu-img create -f raw arch-vm.img 100G +2. qemu-system-x86_64 -show-cursor -only-migratable -nodefaults -boot order=d -cdrom archlinux-2019.07.01-x86_64.iso -cpu host -device virtio-keyboard -device virtio-mouse -device virtio-tablet -drive file=arch-vm.img,format=raw,if=virtio -m 4096 -machine q35,accel=hvf,vmport=off -nic user,ipv6=off,model=virtio -smp 4,sockets=1,cores=2,threads=2 -soundhw hda -vga virtio + +Displayed bootloader menu successfully, select "Boot Arch Linux" then crashed with message: vmx_write_mem: mmu_gva_to_gpa ffff91953b540000 failed. + +Use tcg accelerator has no problem but very slow. + +See attachment for full crash report. + + + +Also happens to me on a freshly built Qemu master (tip 23919ddfd561). +MBP15,2 OSX 10.14.6 + +Qemu command line: +qemu/x86_64-softmmu/qemu-system-x86_64 -cpu host -accel hvf -m 4G -smp 8 -vga std -nographic -vnc :1 -netdev user,id=net0 -device e1000e,netdev=net0 buster.qcow + +Guest works fine until I try to build a linux-stable tree with "make -j8". + +Ubuntu 18.04 VM crashes after login. Works when the RAM is 4 Gb. Posting this here as the error message looked very similar. + +qemu-system-x86_64 -m 6G -vga virtio -show-cursor -usb -device usb-tablet -enable-kvm -drive file=~/QEMU/ubuntu-desktop-18.04.qcow2,if=virtio -accel hvf -cpu host + +Crashed with below message +vmx_write_mem: mmu_gva_to_gpa ffff97ccb8dbe000 failed +Abort trap: 6 + +Crash report + +I think I was able to fix this crash by specifying the exact host model for the cpu argument. + +1. Determine the CPU type of the host machine. + +$ sysctl -a | grep machdep.cpu.brand_string +machdep.cpu.brand_string: Intel(R) Core(TM) i5-4690 CPU @ 3.50GHz + +2. Find the matching CPU model supported by QEMU. + +$ qemu-system-x86_64 -cpu help + + +This CPU corresponds to "x86 Haswell-v4" in this instance. + +3. Substitute the CPU model in the QEMU command. + +$ qemu-system-x86_64 -cpu Haswell-v4 ... + +Related StackOverflow question: https://stackoverflow.com/q/60231203/9835303 + +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.] + +It still happens to me when I try to run Haiku builds on my macos 10.14. +* QEMU emulator version 7.0.0 + +Command line: +qemu-system-x86_64 -machine q35,accel=hvf -cpu host -smp 4 -m 2048 -vga vmware -boot menu=on -drive file="haiku-minimum.mmc",if=none,format=raw,id=x0 -device ide-hd,drive=x0,bus=ide.0 -usb -device qemu-xhci,id=xhci -device usb-mouse -device usb-kbd -serial stdio -rtc clock=vm,base=localtime + +Output: +[ipro1000] (em) Link is up 1000 Mbps Full Duplex +framebuffer: init_hardware() +vmx_write_mem: mmu_gva_to_gpa ffffffff853b3000 failed +[1] 82284 abort qemu-system-x86_64 -machine q35,accel=hvf -cpu host -smp 4 -m 2048 -vga vmwar + +Haiku boots most of the way and crashes when trying to show desktop. Same happens with -vga virtio and with -vga option completely removed. + + + diff --git a/results/classifier/zero-shot/108/all/1839060 b/results/classifier/zero-shot/108/all/1839060 new file mode 100644 index 000000000..ba1f9cf0e --- /dev/null +++ b/results/classifier/zero-shot/108/all/1839060 @@ -0,0 +1,122 @@ +permissions: 0.964 +other: 0.961 +device: 0.959 +debug: 0.955 +socket: 0.950 +network: 0.950 +vnc: 0.950 +performance: 0.949 +graphic: 0.948 +boot: 0.948 +semantic: 0.947 +PID: 0.946 +files: 0.942 +KVM: 0.929 + +HDA device non functional in Windows 10 1903 + +I made the update to 1903, and the HDA device stopped working. + +The driver says the device is working correctly, but it does not. +When I try to open the Windows sound configuration, the dialog hangs and never shows it's content. + +Several people reported this back in May: + +https://windowsreport.com/windows-10-v1903-ich6-ich9-virtio/ + +I can confirm I have exactly the same problem. + +Host is Arch Linux, current (5.2.5) kernel, QEMU 4.0. + +I enabled HDA debug output and compared an older, working Windows version to 1903, but could not see the difference. The driver seems to issue the same verbs. + +I am happy to provide additional information if needed. + +I've got the same issue. Had to rollback to 1809. + +The working driver is named: +10.0.17763.1 (WinBuild.160101.0800) from 14th sept 2018 + +The non-working driver is: +10.0.18362.1 (WinBuild.160101.0800) from 18th march 2019 + +My versions (both tested): +$ /opt/qemu4/bin/qemu-system-x86_64 --version +QEMU emulator version 4.1.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers +$ qemu-system-x86_64 --version +QEMU emulator version 3.1.1 (qemu-3.1.1-2.fc30) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers + + +My qemu startup line is: +/path/to/correct/qemu-system-x86_64 \ +-runas idarlund \ +-name win10,process=win10 \ +-machine type=q35,accel=kvm,kernel_irqchip=on \ +-cpu host,kvm=off,hv_vendor_id=1234567890ab,hv_vapic,hv_time,hv_relaxed,hv_spinlocks=0x1fff,l3-cache=on,-hypervisor,migratable=no,+invtsc \ +-smp 12,sockets=1,cores=12,threads=1 \ +-m 24G \ +-rtc clock=host,base=localtime \ +-vga none \ +-nographic \ +-serial none \ +-parallel none \ +-usb \ +-soundhw hda \ +-device vfio-pci,host=2a:00.0,multifunction=on \ +-object input-linux,id=mouse1,evdev=/dev/input/by-id/usb-Logitech_Gaming_Mouse_G402_6D8A12705348-event-mouse \ +-object input-linux,id=kbd1,evdev=/dev/input/by-id/usb-Logitech_HID_compliant_keyboard-event-kbd,grab_all=on,repeat=on \ +-device ivshmem-plain,memdev=ivshmem,bus=pcie.0 \ +-object memory-backend-file,id=ivshmem,share=on,mem-path=/dev/shm/looking-glass,size=128M \ +-audiodev pa,id=pa1,server=/run/user/1000/pulse/native \ +-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \ +-drive if=pflash,format=raw,file=/tmp/my_vars.fd \ +-boot order=dc \ +-drive id=disk0,if=virtio,cache=none,format=qcow2,aio=threads,file=/var/lib/libvirt/images/windowstest.qcow2 \ +-netdev type=bridge,id=net0,br=virbr1 \ +-device e1000,netdev=net0,mac=00:16:3e:00:08:02 + +I'm not sure if this bug report should be reported to qemu tho. We should probably file a bug report to Microsoft as well. + +Also posted on Microsoft answers; https://answers.microsoft.com/en-us/windows/forum/windows_10-hardware/qemu-hda-device-non-functional-in-windows-10-1903/9a5309bc-073f-469b-8743-16df7e6e1dbd + +Created Windows feedback as instructed by Andre: +https://aka.ms/AA5wlk7 +Please upvote this to get attention by Microsoft. + +Hi, + +I am trying to dig into this issue, can you please provide the verb debug trace from the working version of windows. + +Tried sending you a message @ginf, but haven't heard back from you so I'm posting here instead; +What kind of debug trace do you want me to give you logs from? +$ /opt/qemu4/bin/qemu-system-x86_64 -d help +Log items (comma separated): +out_asm show generated host assembly code for each compiled TB +in_asm show target assembly code for each compiled TB +op show micro ops for each compiled TB +op_opt show micro ops after optimization +op_ind show micro ops before indirect lowering +int show interrupts/exceptions in short format +exec show trace before each executed TB (lots of logs) +cpu show CPU registers before entering a TB (lots of logs) +fpu include FPU registers in the 'cpu' logging +mmu log MMU-related activities +pcall x86 only: show protected mode far calls/returns/exceptions +cpu_reset show CPU state before CPU resets +unimp log unimplemented functionality +guest_errors log when the guest OS does something invalid (eg accessing a +non-existent register) +page dump pages at beginning of user mode emulation +nochain do not chain compiled TBs so that "exec" and "cpu" show +complete traces +trace:PATTERN enable trace events + +Use "-d trace:help" to get a list of trace events. + + +Microsoft has updated their driver to 10.0.18362.356 and the sound is now working with the audoidev hda. + +Microsoft has fixed their hda driver + diff --git a/results/classifier/zero-shot/108/all/1839428 b/results/classifier/zero-shot/108/all/1839428 new file mode 100644 index 000000000..763b64f68 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1839428 @@ -0,0 +1,176 @@ +other: 0.958 +vnc: 0.946 +semantic: 0.945 +device: 0.943 +performance: 0.937 +debug: 0.932 +socket: 0.932 +boot: 0.930 +permissions: 0.928 +graphic: 0.926 +PID: 0.922 +network: 0.921 +KVM: 0.921 +files: 0.909 + + qemu core dumped when repeat "system_reset" multiple times during guest boot + +commit 864ab314f1d924129d06ac7b571f105a2b76a4b2 (HEAD, tag: v4.1.0-rc4, origin/master, origin/HEAD, master) +Test arch:x86 and power + +Steps: +1.Boot up guest with command +power cmdline: +/usr/libexec/backup/qemu-kvm \ + -smp 8 \ + -m 4096 \ + -nodefaults \ + -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1,bus=pci.0,addr=0x7 \ + -drive file=rhel77-ppc64le-virtio.qcow2,if=none,id=drive_image1,format=qcow2,cache=none \ + -chardev stdio,mux=on,id=serial_id_serial0,server,nowait,signal=off \ + -device spapr-vty,id=serial111,chardev=serial_id_serial0 \ + -mon chardev=serial_id_serial0,mode=readline \ +x86 cmdline: +/usr/libexec/qemu-kvm \ + -m 4096 -smp 8 \ + -boot menu=on \ + -device virtio-blk-pci,id=image1,drive=drive_image1\ + -drive file=rhel77-64-virtio.qcow2,if=none,id=drive_image1,format=qcow2,cache=none \ + -vga std \ + -vnc :9 \ + -nographic \ + -device virtio-net-pci,netdev=net0,id=nic0,mac=52:54:00:c4:e7:84 \ + -netdev tap,id=net0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown,vhost=on \ + +2.when guest start to boot up kernel(when no output infomation),run hmp command "system_reset" + + +Result: + +Sometimes,qemu core dumped with error as following: +system_reset +(qemu) qemu-system-ppc64: /root/qemu/hw/virtio/virtio.c:225: vring_get_region_caches: Assertion `caches != NULL' failed. +b.sh: line 11: 73679 Aborted (core dumped) /usr/local/bin/qemu-system-ppc64 -enable-kvm -smp 8 -m 4096 -nodefaults -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1,bus=pci.0,addr=0x7 -drive file=rhel77-ppc64le-virtio.qcow2,if=none,id=drive_image1,format=qcow2,cache=none -chardev stdio,mux=on,id=serial_id_serial0,server,nowait,signal=off -device spapr-vty,id=serial111,chardev=serial_id_serial0 -mon chardev=serial_id_serial0,mode=readline + +Upstream qemu-v3.1.0 pass +Upstream qemu-v3.1.1 pass +Upstream qemu-v4.0.0 fail +Upstream qemu-v4.0.0-rc0 fail + +So the problem occurs due to patch between qemu-v3.1.1 to qemu-v4.0.0-rc0. + +This issue is very hard to reproduce. + +It sometimes crashes, so I could mark few commits 'bad' while bisecting, but since it is not reliable, I'm not sure a commit is 'good' when there is no crash. + +For now after hours of testing I could reduce Xujun Ma's range to qemu-v3.1.0..1d31f1872b: + +commit 1d31f1872b337e4acac5bf6b3c2a45b66e43b494 (refs/bisect/bad) +Merge: 20b084c4b1 88c869198a +Author: Peter Maydell <email address hidden> +Date: Mon Mar 4 11:04:31 2019 +0000 + + Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging + + pci, pc, virtio: fixes, cleanups, tests + + Lots of work on tests: BiosTablesTest UEFI app, + vhost-user testing for non-Linux hosts. + Misc cleanups and fixes all over the place + + Signed-off-by: Michael S. Tsirkin <email address hidden> + + * remotes/mst/tags/for_upstream: (26 commits) + pci: Sanity test minimum downstream LNKSTA + hw/smbios: fix offset of type 3 sku field + pci: Move NVIDIA vendor id to the rest of ids + virtio-balloon: Safely handle BALLOON_PAGE_SIZE < host page size + virtio-balloon: Use ram_block_discard_range() instead of raw madvise() + virtio-balloon: Rework ballon_page() interface + virtio-balloon: Corrections to address verification + virtio-balloon: Remove unnecessary MADV_WILLNEED on deflate + i386/kvm: ignore masked irqs when update msi routes + contrib/vhost-user-blk: fix the compilation issue + Revert "contrib/vhost-user-blk: fix the compilation issue" + pc-dimm: use same mechanism for [get|set]_addr + tests/data: introduce "uefi-boot-images" with the "bios-tables-test" ISOs + tests/uefi-test-tools: add build scripts + tests: introduce "uefi-test-tools" with the BiosTablesTest UEFI app + roms: build the EfiRom utility from the roms/edk2 submodule + roms: add the edk2 project as a git submodule + vhost-user-test: create a temporary directory per TestServer + vhost-user-test: small changes to init_hugepagefs + vhost-user-test: create a main loop per TestServer + ... + +I found the commit that introduced this regression. + +commit 57830a499f7c815bb0cb325c94a3d8c910d13cfa (HEAD) +Author: Denis Plotnikov <email address hidden> +Date: Fri Feb 15 16:03:25 2019 +0300 + + block: don't set the same context + + Adds a fast path on aio context setting preventing + unnecessary context setting routine. + Also, it prevents issues with cyclic walk of child + bds-es appeared because of registering aio walking + notifiers: + + Call stack: + + 0 __GI_raise + 1 __GI_abort + 2 __assert_fail_base + 3 __GI___assert_fail + 4 bdrv_detach_aio_context (bs=0x55f54d65c000) <<< + 5 bdrv_detach_aio_context (bs=0x55f54fc8a800) + 6 bdrv_set_aio_context (bs=0x55f54fc8a800, ...) + 7 block_job_attached_aio_context + 8 bdrv_attach_aio_context (bs=0x55f54d65c000, ...) <<< + 9 bdrv_set_aio_context (bs=0x55f54d65c000) + 10 blk_set_aio_context + 11 virtio_blk_data_plane_stop + 12 virtio_bus_stop_ioeventfd + 13 virtio_vmstate_change + 14 vm_state_notify (running=0, state=RUN_STATE_SHUTDOWN) + 15 do_vm_stop (state=RUN_STATE_SHUTDOWN, send_stop=true) + 16 vm_stop (state=RUN_STATE_SHUTDOWN) + 17 main_loop_should_exit + 18 main_loop + 19 main + + This can happen because of "new" context attachment to VM disk bds. + When attaching a new context the corresponding aio context handler is + called for each of aio_notifiers registered on the VM disk bds context. + Among those handlers, there is the block_job_attached_aio_context handler + which sets a new aio context for the block job bds. When doing so, + the old context is detached from all the block job bds children and one of + them is the VM disk bds, serving as backing store for the blockjob bds, + although the VM disk bds is actually the initializer of that process. + Since the VM disk bds is protected with walking_aio_notifiers flag + from double processing in recursive calls, the assert fires. + + Signed-off-by: Denis Plotnikov <email address hidden> + Signed-off-by: Kevin Wolf <email address hidden> + +diff --git a/block.c b/block.c +index 4ad0e90d7e..0c12632661 100644 +--- a/block.c ++++ b/block.c +@@ -5265,6 +5265,10 @@ void bdrv_set_aio_context(BlockDriverState *bs, AioContext *new_context) + { + AioContext *ctx = bdrv_get_aio_context(bs); + ++ if (ctx == new_context) { ++ return; ++ } ++ + aio_disable_external(ctx); + bdrv_parent_drained_begin(bs, NULL, false); + bdrv_drain(bs); /* ensure there are no in-flight requests */ + + +Please check if this commit has solved the issue: +https://git.qemu.org/?p=qemu.git;a=commit;h=ebb6ff25cd888a52a64a9adc3692541c6d1d9a42 + diff --git a/results/classifier/zero-shot/108/all/1842038 b/results/classifier/zero-shot/108/all/1842038 new file mode 100644 index 000000000..cb896bae1 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1842038 @@ -0,0 +1,698 @@ +permissions: 0.950 +other: 0.949 +performance: 0.947 +files: 0.946 +semantic: 0.940 +debug: 0.940 +graphic: 0.940 +network: 0.940 +socket: 0.939 +device: 0.938 +vnc: 0.934 +PID: 0.932 +KVM: 0.931 +boot: 0.927 + +qemu 4.0/4.1 segfault on live migrate with virtio-scsi iothread + +[root@kvm-nvme5 qemu]# uname -a +Linux kvm-nvme5 4.14.35-1902.4.8.el7uek.x86_64 #2 SMP Sun Aug 4 22:25:18 GMT 2019 x86_64 x86_64 x86_64 GNU/Linux + +[root@kvm-nvme5 qemu]# qemu-system-x86_64 --version +QEMU emulator version 4.1.0 (qemu-4.1.0-1.el7) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +[root@kvm-nvme5 qemu]# libvirtd --version +libvirtd (libvirt) 5.6.0 + +when migrate +MIGR_OPTS="--live --copy-storage-all --verbose --persistent --undefinesource" +virsh migrate $MIGR_OPTS p12345 qemu+ssh://$SERV/system + +we got segfault if we have option <driver iothread='1'/> in config for virtio-scsi controller + +[1205674.818067] qemu-system-x86[39744]: segfault at 38 ip 00005575890ad411 sp 00007ffd3c10a0e0 error 6 in qemu-system-x86_64[5575889ad000+951000] + +On 4.0 we have error with this context(dont save all output) "qemu_coroutine_get_aio_context(co)' failed" + +If we remove option +<driver iothread='1'/> +migrate work fine without segfaults + +2019-08-30 08:25:35.402+0000: starting up libvirt version: 5.6.0, package: 1.el7 (Unknown, 2019-08-06-09:57:56, mock), qemu version: 4.1.0qemu-4.1.0-1.el7, kernel: 4.14.35-1902.4.8.el7uek.x86_64, hostname: kvm-nvme5 +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-75-p541999 \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-75-p541999/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-75-p541999/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-75-p541999/.config \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-x86_64 \ +-name guest=p541999,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-75-p541999/master-key.aes \ +-machine pc-q35-4.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu Cascadelake-Server,ss=on,hypervisor=on,tsc-adjust=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,xsaves=on,rdctl-no=on,ibrs-all=on,skip-l1dfl-vmentry=on,mds-no=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1000,hv-vpindex,hv-runtime,hv-synic,hv-stimer,hv-fre +quencies,hv-reenlightenment,hv-tlbflush \ +-m 2148 \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-object iothread,id=iothread1 \ +-uuid ff20ae7f-8cfe-4ec5-bd50-e78f8a167414 \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=44,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x5.0x7 \ +-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x5 \ +-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x5.0x1 \ +-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x5.0x2 \ +-device virtio-scsi-pci,iothread=iothread1,id=scsi0,bus=pcie.0,addr=0x9 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pcie.0,addr=0x6 \ +-drive file=/dev/vm/p541999,format=raw,if=none,id=drive-scsi0-0-0-0,cache=none,discard=unmap,aio=threads,throttling.bps-write=52428800,throttling.bps-write-max=314572800,throttling.bps-write-max-length=120 \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2,write-cache=on \ +-drive if=none,id=drive-sata0-0-0,readonly=on \ +-device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-netdev tap,fd=47,id=hostnet0,vhost=on,vhostfd=48 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:00:54:19:99,bus=pcie.0,addr=0x3 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,fd=49,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-vnc 0.0.0.0:6128,password \ +-device cirrus-vga,id=video0,bus=pcie.0,addr=0x1 \ +-device virtio-balloon-pci,id=balloon0,bus=pcie.0,addr=0x8 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +char device redirected to /dev/pts/5 (label charserial0) +2019-08-30 08:27:00.539+0000: shutting down, reason=crashed + + +config: +<domain type='kvm'> + <name>p541999</name> + <uuid>ff20ae7f-8cfe-4ec5-bd50-e78f8a167414</uuid> + <memory unit='KiB'>2199552</memory> + <currentMemory unit='KiB'>2199552</currentMemory> + <vcpu placement='static'>1</vcpu> + <iothreads>1</iothreads> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-q35-4.0'>hvm</type> + <boot dev='cdrom'/> + <boot dev='hd'/> + <bootmenu enable='yes'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + <hyperv> + <relaxed state='on'/> + <vapic state='on'/> + <spinlocks state='on' retries='4096'/> + <vpindex state='on'/> + <runtime state='on'/> + <synic state='on'/> + <stimer state='on'/> + <frequencies state='on'/> + <reenlightenment state='on'/> + <tlbflush state='on'/> + </hyperv> + <msrs unknown='ignore'/> + </features> + <cpu mode='host-model' check='full'> + <model fallback='forbid'/> + </cpu> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='yes'/> + <timer name='hypervclock' present='yes'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='none' io='threads' discard='unmap'/> + <source dev='/dev/vm/p541999'/> + <backingStore/> + <target dev='sda' bus='scsi'/> + <iotune> + <write_bytes_sec>52428800</write_bytes_sec> + <write_bytes_sec_max>314572800</write_bytes_sec_max> + <write_bytes_sec_max_length>120</write_bytes_sec_max_length> + </iotune> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <target dev='sdb' bus='sata'/> + <readonly/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/> + </controller> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </controller> + <controller type='scsi' index='0' model='virtio-scsi'> + <driver iothread='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> + </controller> + <controller type='pci' index='0' model='pcie-root'/> + <controller type='sata' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> + </controller> + <interface type='bridge'> + <mac address='00:00:00:54:19:99'/> + <source bridge='br0'/> + <bandwidth> + <inbound average='12500' peak='12500' burst='1024'/> + <outbound average='12500' peak='12500' burst='1024'/> + </bandwidth> + <model type='virtio'/> + <filterref filter='clean-traffic'> + <parameter name='CTRL_IP_LEARNING' value='none'/> + <parameter name='IP' value='1.2.3.4'/> + </filterref> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <channel type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/p541999.agent'/> + <target type='virtio' name='org.qemu.guest_agent.0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='vnc' port='12028' autoport='no' listen='0.0.0.0' passwd='SUPERPASSWORD'> + <listen type='address' address='0.0.0.0'/> + </graphics> + <video> + <model type='cirrus' vram='16384' heads='1' primary='yes'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </memballoon> + </devices> + <seclabel type='none' model='none'/> +</domain> + +On Fri, Aug 30, 2019 at 08:44:35AM -0000, Dmitriy wrote: +> Public bug reported: + +Thanks for reporting this. There have been fixes for virtio-scsi with +iothreads lately, but QEMU 4.1.0 is fairly recent so it should have most +of them. + +Can you try qemu.git/master? + +> +> [root@kvm-nvme5 qemu]# uname -a +> Linux kvm-nvme5 4.14.35-1902.4.8.el7uek.x86_64 #2 SMP Sun Aug 4 22:25:18 GMT 2019 x86_64 x86_64 x86_64 GNU/Linux +> +> [root@kvm-nvme5 qemu]# qemu-system-x86_64 --version +> QEMU emulator version 4.1.0 (qemu-4.1.0-1.el7) +> Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers +> +> [root@kvm-nvme5 qemu]# libvirtd --version +> libvirtd (libvirt) 5.6.0 +> +> when migrate +> MIGR_OPTS="--live --copy-storage-all --verbose --persistent --undefinesource" +> virsh migrate $MIGR_OPTS p12345 qemu+ssh://$SERV/system +> +> we got segfault if we have option <driver iothread='1'/> in config for +> virtio-scsi controller +> +> [1205674.818067] qemu-system-x86[39744]: segfault at 38 ip +> 00005575890ad411 sp 00007ffd3c10a0e0 error 6 in qemu-system- +> x86_64[5575889ad000+951000] +> +> On 4.0 we have error with this context(dont save all output) +> "qemu_coroutine_get_aio_context(co)' failed" +> +> If we remove option +> <driver iothread='1'/> +> migrate work fine without segfaults +> +> 2019-08-30 08:25:35.402+0000: starting up libvirt version: 5.6.0, package: 1.el7 (Unknown, 2019-08-06-09:57:56, mock), qemu version: 4.1.0qemu-4.1.0-1.el7, kernel: 4.14.35-1902.4.8.el7uek.x86_64, hostname: kvm-nvme5 +> LC_ALL=C \ +> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +> HOME=/var/lib/libvirt/qemu/domain-75-p541999 \ +> XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-75-p541999/.local/share \ +> XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-75-p541999/.cache \ +> XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-75-p541999/.config \ +> QEMU_AUDIO_DRV=none \ +> /usr/bin/qemu-system-x86_64 \ +> -name guest=p541999,debug-threads=on \ +> -S \ +> -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-75-p541999/master-key.aes \ +> -machine pc-q35-4.0,accel=kvm,usb=off,dump-guest-core=off \ +> -cpu Cascadelake-Server,ss=on,hypervisor=on,tsc-adjust=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,xsaves=on,rdctl-no=on,ibrs-all=on,skip-l1dfl-vmentry=on,mds-no=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1000,hv-vpindex,hv-runtime,hv-synic,hv-stimer,hv-fre +> quencies,hv-reenlightenment,hv-tlbflush \ +> -m 2148 \ +> -overcommit mem-lock=off \ +> -smp 1,sockets=1,cores=1,threads=1 \ +> -object iothread,id=iothread1 \ +> -uuid ff20ae7f-8cfe-4ec5-bd50-e78f8a167414 \ +> -no-user-config \ +> -nodefaults \ +> -chardev socket,id=charmonitor,fd=44,server,nowait \ +> -mon chardev=charmonitor,id=monitor,mode=control \ +> -rtc base=utc,driftfix=slew \ +> -global kvm-pit.lost_tick_policy=delay \ +> -no-shutdown \ +> -boot menu=on,strict=on \ +> -device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x5.0x7 \ +> -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x5 \ +> -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x5.0x1 \ +> -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x5.0x2 \ +> -device virtio-scsi-pci,iothread=iothread1,id=scsi0,bus=pcie.0,addr=0x9 \ +> -device virtio-serial-pci,id=virtio-serial0,bus=pcie.0,addr=0x6 \ +> -drive file=/dev/vm/p541999,format=raw,if=none,id=drive-scsi0-0-0-0,cache=none,discard=unmap,aio=threads,throttling.bps-write=52428800,throttling.bps-write-max=314572800,throttling.bps-write-max-length=120 \ +> -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2,write-cache=on \ +> -drive if=none,id=drive-sata0-0-0,readonly=on \ +> -device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +> -netdev tap,fd=47,id=hostnet0,vhost=on,vhostfd=48 \ +> -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:00:54:19:99,bus=pcie.0,addr=0x3 \ +> -chardev pty,id=charserial0 \ +> -device isa-serial,chardev=charserial0,id=serial0 \ +> -chardev socket,id=charchannel0,fd=49,server,nowait \ +> -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +> -vnc 0.0.0.0:6128,password \ +> -device cirrus-vga,id=video0,bus=pcie.0,addr=0x1 \ +> -device virtio-balloon-pci,id=balloon0,bus=pcie.0,addr=0x8 \ +> -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +> -msg timestamp=on +> char device redirected to /dev/pts/5 (label charserial0) +> 2019-08-30 08:27:00.539+0000: shutting down, reason=crashed +> +> +> config: +> <domain type='kvm'> +> <name>p541999</name> +> <uuid>ff20ae7f-8cfe-4ec5-bd50-e78f8a167414</uuid> +> <memory unit='KiB'>2199552</memory> +> <currentMemory unit='KiB'>2199552</currentMemory> +> <vcpu placement='static'>1</vcpu> +> <iothreads>1</iothreads> +> <resource> +> <partition>/machine</partition> +> </resource> +> <os> +> <type arch='x86_64' machine='pc-q35-4.0'>hvm</type> +> <boot dev='cdrom'/> +> <boot dev='hd'/> +> <bootmenu enable='yes'/> +> </os> +> <features> +> <acpi/> +> <apic/> +> <pae/> +> <hyperv> +> <relaxed state='on'/> +> <vapic state='on'/> +> <spinlocks state='on' retries='4096'/> +> <vpindex state='on'/> +> <runtime state='on'/> +> <synic state='on'/> +> <stimer state='on'/> +> <frequencies state='on'/> +> <reenlightenment state='on'/> +> <tlbflush state='on'/> +> </hyperv> +> <msrs unknown='ignore'/> +> </features> +> <cpu mode='host-model' check='full'> +> <model fallback='forbid'/> +> </cpu> +> <clock offset='utc'> +> <timer name='rtc' tickpolicy='catchup'/> +> <timer name='pit' tickpolicy='delay'/> +> <timer name='hpet' present='yes'/> +> <timer name='hypervclock' present='yes'/> +> </clock> +> <on_poweroff>destroy</on_poweroff> +> <on_reboot>restart</on_reboot> +> <on_crash>restart</on_crash> +> <devices> +> <emulator>/usr/bin/qemu-system-x86_64</emulator> +> <disk type='block' device='disk'> +> <driver name='qemu' type='raw' cache='none' io='threads' discard='unmap'/> +> <source dev='/dev/vm/p541999'/> +> <backingStore/> +> <target dev='sda' bus='scsi'/> +> <iotune> +> <write_bytes_sec>52428800</write_bytes_sec> +> <write_bytes_sec_max>314572800</write_bytes_sec_max> +> <write_bytes_sec_max_length>120</write_bytes_sec_max_length> +> </iotune> +> <address type='drive' controller='0' bus='0' target='0' unit='0'/> +> </disk> +> <disk type='file' device='cdrom'> +> <driver name='qemu' type='raw'/> +> <target dev='sdb' bus='sata'/> +> <readonly/> +> <address type='drive' controller='0' bus='0' target='0' unit='0'/> +> </disk> +> <controller type='usb' index='0' model='ich9-ehci1'> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/> +> </controller> +> <controller type='usb' index='0' model='ich9-uhci1'> +> <master startport='0'/> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/> +> </controller> +> <controller type='usb' index='0' model='ich9-uhci2'> +> <master startport='2'/> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/> +> </controller> +> <controller type='usb' index='0' model='ich9-uhci3'> +> <master startport='4'/> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/> +> </controller> +> <controller type='virtio-serial' index='0'> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> +> </controller> +> <controller type='scsi' index='0' model='virtio-scsi'> +> <driver iothread='1'/> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> +> </controller> +> <controller type='pci' index='0' model='pcie-root'/> +> <controller type='sata' index='0'> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> +> </controller> +> <interface type='bridge'> +> <mac address='00:00:00:54:19:99'/> +> <source bridge='br0'/> +> <bandwidth> +> <inbound average='12500' peak='12500' burst='1024'/> +> <outbound average='12500' peak='12500' burst='1024'/> +> </bandwidth> +> <model type='virtio'/> +> <filterref filter='clean-traffic'> +> <parameter name='CTRL_IP_LEARNING' value='none'/> +> <parameter name='IP' value='1.2.3.4'/> +> </filterref> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> +> </interface> +> <serial type='pty'> +> <target type='isa-serial' port='0'> +> <model name='isa-serial'/> +> </target> +> </serial> +> <console type='pty'> +> <target type='serial' port='0'/> +> </console> +> <channel type='unix'> +> <source mode='bind' path='/var/lib/libvirt/qemu/p541999.agent'/> +> <target type='virtio' name='org.qemu.guest_agent.0'/> +> <address type='virtio-serial' controller='0' bus='0' port='1'/> +> </channel> +> <input type='mouse' bus='ps2'/> +> <input type='keyboard' bus='ps2'/> +> <graphics type='vnc' port='12028' autoport='no' listen='0.0.0.0' passwd='SUPERPASSWORD'> +> <listen type='address' address='0.0.0.0'/> +> </graphics> +> <video> +> <model type='cirrus' vram='16384' heads='1' primary='yes'/> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> +> </video> +> <memballoon model='virtio'> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> +> </memballoon> +> </devices> +> <seclabel type='none' model='none'/> +> </domain> +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1842038 +> +> Title: +> qemu 4.0/4.1 segfault on live migrate with virtio-scsi iothread +> +> Status in QEMU: +> New +> +> Bug description: +> [root@kvm-nvme5 qemu]# uname -a +> Linux kvm-nvme5 4.14.35-1902.4.8.el7uek.x86_64 #2 SMP Sun Aug 4 22:25:18 GMT 2019 x86_64 x86_64 x86_64 GNU/Linux +> +> [root@kvm-nvme5 qemu]# qemu-system-x86_64 --version +> QEMU emulator version 4.1.0 (qemu-4.1.0-1.el7) +> Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers +> +> [root@kvm-nvme5 qemu]# libvirtd --version +> libvirtd (libvirt) 5.6.0 +> +> when migrate +> MIGR_OPTS="--live --copy-storage-all --verbose --persistent --undefinesource" +> virsh migrate $MIGR_OPTS p12345 qemu+ssh://$SERV/system +> +> we got segfault if we have option <driver iothread='1'/> in config for +> virtio-scsi controller +> +> [1205674.818067] qemu-system-x86[39744]: segfault at 38 ip +> 00005575890ad411 sp 00007ffd3c10a0e0 error 6 in qemu-system- +> x86_64[5575889ad000+951000] +> +> On 4.0 we have error with this context(dont save all output) +> "qemu_coroutine_get_aio_context(co)' failed" +> +> If we remove option +> <driver iothread='1'/> +> migrate work fine without segfaults +> +> 2019-08-30 08:25:35.402+0000: starting up libvirt version: 5.6.0, package: 1.el7 (Unknown, 2019-08-06-09:57:56, mock), qemu version: 4.1.0qemu-4.1.0-1.el7, kernel: 4.14.35-1902.4.8.el7uek.x86_64, hostname: kvm-nvme5 +> LC_ALL=C \ +> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +> HOME=/var/lib/libvirt/qemu/domain-75-p541999 \ +> XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-75-p541999/.local/share \ +> XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-75-p541999/.cache \ +> XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-75-p541999/.config \ +> QEMU_AUDIO_DRV=none \ +> /usr/bin/qemu-system-x86_64 \ +> -name guest=p541999,debug-threads=on \ +> -S \ +> -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-75-p541999/master-key.aes \ +> -machine pc-q35-4.0,accel=kvm,usb=off,dump-guest-core=off \ +> -cpu Cascadelake-Server,ss=on,hypervisor=on,tsc-adjust=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,xsaves=on,rdctl-no=on,ibrs-all=on,skip-l1dfl-vmentry=on,mds-no=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1000,hv-vpindex,hv-runtime,hv-synic,hv-stimer,hv-fre +> quencies,hv-reenlightenment,hv-tlbflush \ +> -m 2148 \ +> -overcommit mem-lock=off \ +> -smp 1,sockets=1,cores=1,threads=1 \ +> -object iothread,id=iothread1 \ +> -uuid ff20ae7f-8cfe-4ec5-bd50-e78f8a167414 \ +> -no-user-config \ +> -nodefaults \ +> -chardev socket,id=charmonitor,fd=44,server,nowait \ +> -mon chardev=charmonitor,id=monitor,mode=control \ +> -rtc base=utc,driftfix=slew \ +> -global kvm-pit.lost_tick_policy=delay \ +> -no-shutdown \ +> -boot menu=on,strict=on \ +> -device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x5.0x7 \ +> -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x5 \ +> -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x5.0x1 \ +> -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x5.0x2 \ +> -device virtio-scsi-pci,iothread=iothread1,id=scsi0,bus=pcie.0,addr=0x9 \ +> -device virtio-serial-pci,id=virtio-serial0,bus=pcie.0,addr=0x6 \ +> -drive file=/dev/vm/p541999,format=raw,if=none,id=drive-scsi0-0-0-0,cache=none,discard=unmap,aio=threads,throttling.bps-write=52428800,throttling.bps-write-max=314572800,throttling.bps-write-max-length=120 \ +> -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2,write-cache=on \ +> -drive if=none,id=drive-sata0-0-0,readonly=on \ +> -device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +> -netdev tap,fd=47,id=hostnet0,vhost=on,vhostfd=48 \ +> -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:00:54:19:99,bus=pcie.0,addr=0x3 \ +> -chardev pty,id=charserial0 \ +> -device isa-serial,chardev=charserial0,id=serial0 \ +> -chardev socket,id=charchannel0,fd=49,server,nowait \ +> -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +> -vnc 0.0.0.0:6128,password \ +> -device cirrus-vga,id=video0,bus=pcie.0,addr=0x1 \ +> -device virtio-balloon-pci,id=balloon0,bus=pcie.0,addr=0x8 \ +> -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +> -msg timestamp=on +> char device redirected to /dev/pts/5 (label charserial0) +> 2019-08-30 08:27:00.539+0000: shutting down, reason=crashed +> +> +> config: +> <domain type='kvm'> +> <name>p541999</name> +> <uuid>ff20ae7f-8cfe-4ec5-bd50-e78f8a167414</uuid> +> <memory unit='KiB'>2199552</memory> +> <currentMemory unit='KiB'>2199552</currentMemory> +> <vcpu placement='static'>1</vcpu> +> <iothreads>1</iothreads> +> <resource> +> <partition>/machine</partition> +> </resource> +> <os> +> <type arch='x86_64' machine='pc-q35-4.0'>hvm</type> +> <boot dev='cdrom'/> +> <boot dev='hd'/> +> <bootmenu enable='yes'/> +> </os> +> <features> +> <acpi/> +> <apic/> +> <pae/> +> <hyperv> +> <relaxed state='on'/> +> <vapic state='on'/> +> <spinlocks state='on' retries='4096'/> +> <vpindex state='on'/> +> <runtime state='on'/> +> <synic state='on'/> +> <stimer state='on'/> +> <frequencies state='on'/> +> <reenlightenment state='on'/> +> <tlbflush state='on'/> +> </hyperv> +> <msrs unknown='ignore'/> +> </features> +> <cpu mode='host-model' check='full'> +> <model fallback='forbid'/> +> </cpu> +> <clock offset='utc'> +> <timer name='rtc' tickpolicy='catchup'/> +> <timer name='pit' tickpolicy='delay'/> +> <timer name='hpet' present='yes'/> +> <timer name='hypervclock' present='yes'/> +> </clock> +> <on_poweroff>destroy</on_poweroff> +> <on_reboot>restart</on_reboot> +> <on_crash>restart</on_crash> +> <devices> +> <emulator>/usr/bin/qemu-system-x86_64</emulator> +> <disk type='block' device='disk'> +> <driver name='qemu' type='raw' cache='none' io='threads' discard='unmap'/> +> <source dev='/dev/vm/p541999'/> +> <backingStore/> +> <target dev='sda' bus='scsi'/> +> <iotune> +> <write_bytes_sec>52428800</write_bytes_sec> +> <write_bytes_sec_max>314572800</write_bytes_sec_max> +> <write_bytes_sec_max_length>120</write_bytes_sec_max_length> +> </iotune> +> <address type='drive' controller='0' bus='0' target='0' unit='0'/> +> </disk> +> <disk type='file' device='cdrom'> +> <driver name='qemu' type='raw'/> +> <target dev='sdb' bus='sata'/> +> <readonly/> +> <address type='drive' controller='0' bus='0' target='0' unit='0'/> +> </disk> +> <controller type='usb' index='0' model='ich9-ehci1'> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/> +> </controller> +> <controller type='usb' index='0' model='ich9-uhci1'> +> <master startport='0'/> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/> +> </controller> +> <controller type='usb' index='0' model='ich9-uhci2'> +> <master startport='2'/> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/> +> </controller> +> <controller type='usb' index='0' model='ich9-uhci3'> +> <master startport='4'/> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/> +> </controller> +> <controller type='virtio-serial' index='0'> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> +> </controller> +> <controller type='scsi' index='0' model='virtio-scsi'> +> <driver iothread='1'/> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> +> </controller> +> <controller type='pci' index='0' model='pcie-root'/> +> <controller type='sata' index='0'> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> +> </controller> +> <interface type='bridge'> +> <mac address='00:00:00:54:19:99'/> +> <source bridge='br0'/> +> <bandwidth> +> <inbound average='12500' peak='12500' burst='1024'/> +> <outbound average='12500' peak='12500' burst='1024'/> +> </bandwidth> +> <model type='virtio'/> +> <filterref filter='clean-traffic'> +> <parameter name='CTRL_IP_LEARNING' value='none'/> +> <parameter name='IP' value='1.2.3.4'/> +> </filterref> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> +> </interface> +> <serial type='pty'> +> <target type='isa-serial' port='0'> +> <model name='isa-serial'/> +> </target> +> </serial> +> <console type='pty'> +> <target type='serial' port='0'/> +> </console> +> <channel type='unix'> +> <source mode='bind' path='/var/lib/libvirt/qemu/p541999.agent'/> +> <target type='virtio' name='org.qemu.guest_agent.0'/> +> <address type='virtio-serial' controller='0' bus='0' port='1'/> +> </channel> +> <input type='mouse' bus='ps2'/> +> <input type='keyboard' bus='ps2'/> +> <graphics type='vnc' port='12028' autoport='no' listen='0.0.0.0' passwd='SUPERPASSWORD'> +> <listen type='address' address='0.0.0.0'/> +> </graphics> +> <video> +> <model type='cirrus' vram='16384' heads='1' primary='yes'/> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> +> </video> +> <memballoon model='virtio'> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> +> </memballoon> +> </devices> +> <seclabel type='none' model='none'/> +> </domain> +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1842038/+subscriptions +> + + +https://lists.gnu.org/archive/html/qemu-block/2019-09/msg00481.html +fix issue and migration work fine + diff --git a/results/classifier/zero-shot/108/all/1842787 b/results/classifier/zero-shot/108/all/1842787 new file mode 100644 index 000000000..cc3403acd --- /dev/null +++ b/results/classifier/zero-shot/108/all/1842787 @@ -0,0 +1,223 @@ +device: 0.944 +other: 0.939 +performance: 0.938 +permissions: 0.936 +files: 0.933 +debug: 0.931 +KVM: 0.929 +PID: 0.928 +semantic: 0.926 +socket: 0.924 +graphic: 0.922 +vnc: 0.921 +boot: 0.919 +network: 0.915 + +Writes permanently hang with very heavy I/O on virtio-scsi - worse on virtio-blk + +Up to date Arch Linux on host and guest. linux 5.2.11. QEMU 4.1.0. Full command line at bottom. + +Host gives QEMU two thin LVM volumes. The first is the root filesystem, and the second is for heavy I/O, on a Samsung 970 Evo 1TB. + +When maxing out the I/O on the second virtual block device using virtio-blk, I often get a "lockup" in about an hour or two. From the advise of iggy in IRC, I switched over to virtio-scsi. It ran perfectly for a few days, but then "locked up" in the same way. + +By "lockup", I mean writes to the second virtual block device permanently hang. I can read files from it, but even "touch foo" never times out, cannot be "kill -9"'ed, and is stuck in uninterruptible sleep. + +When this happens, writes to the first virtual block device with the root filesystem are fine, so the O/S itself remains responsive. + +The second virtual block device uses BTRFS. But, I have also tried XFS and reproduced the issue. + +In guest, when this starts, it starts logging "task X blocked for more than Y seconds". Below is an example of one of these. At this point, anything that is or does in the future write to this block device gets stuck in uninterruptible sleep. + +----- + +INFO: task kcompactd:232 blocked for more than 860 seconds. + Not tained 5.2.11-1 #1 +"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this messae. +kcompactd0 D 0 232 2 0x80004000 +Call Trace: + ? __schedule+0x27f/0x6d0 + schedule+0x3d/0xc0 + io_schedule+0x12/0x40 + __lock_page+0x14a/0x250 + ? add_to_page_cache_lru+0xe0/0xe0 + migrate_pages+0x803/0xb70 + ? isolate_migratepages_block+0x9f0/0x9f0 + ? __reset_isolation_suitable+0x110/0x110 + compact_zone+0x6a2/0xd30 + kcompactd_do_work+0x134/0x260 + ? kvm_clock_read+0x14/0x30 + ? kvm_sched_clock_read+0x5/0x10 + kcompactd+0xd3/0x220 + ? wait_woken+0x80/0x80 + kthread+0xfd/0x130 + ? kcompactd_do_work+0x260/0x260 + ? kthread_park+0x80/0x80 + ret_from_fork+0x35/0x40 + +----- + +In guest, there are no other dmesg/journalctl entries other than "task...blocked". + +On host, there are no dmesg/journalctl entries whatsoever. Everything else in host continues to work fine, including other QEMU VM's on the same underlying SSD (but obviously different lvm volumes.) + +I understand there might not be enough to go on here, and I also understand it's possible this isn't a QEMU bug. Happy to run given commands or patches to help diagnose what's going on here. + +I'm now running a custom compiled QEMU 4.1.0, with debug symbols, so I can get a meaningful backtrace from the host point of view. + +----- + +/usr/bin/qemu-system-x86_64 + -name arch,process=qemu:arch + -no-user-config + -nodefaults + -nographic + -uuid 0528162b-2371-41d5-b8da-233fe61b6458 + -pidfile /tmp/0528162b-2371-41d5-b8da-233fe61b6458.pid + -machine q35,accel=kvm,vmport=off,dump-guest-core=off + -cpu SandyBridge-IBRS + -smp cpus=24,cores=12,threads=1,sockets=2 + -m 24G + -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd + -drive if=pflash,format=raw,readonly,file=/var/qemu/0528162b-2371-41d5-b8da-233fe61b6458.fd + -monitor telnet:localhost:8000,server,nowait,nodelay + -spice unix,addr=/tmp/0528162b-2371-41d5-b8da-233fe61b6458.sock,disable-ticketing + -device ioh3420,id=pcie.1,bus=pcie.0,slot=0 + -device virtio-vga,bus=pcie.1,addr=0 + -usbdevice tablet + -netdev bridge,id=network0,br=br0 + -device virtio-net-pci,netdev=network0,mac=02:37:de:79:19:09,bus=pcie.0,addr=3 + -device virtio-scsi-pci,id=scsi1 + -drive driver=raw,node-name=hd0,file=/dev/lvm/arch_root,if=none,discard=unmap + -device scsi-hd,drive=hd0,bootindex=1 + -drive driver=raw,node-name=hd1,file=/dev/lvm/arch_nvme,if=none,discard=unmap + -device scsi-hd,drive=hd1,bootindex=2 + +----- + +On Thu, Sep 05, 2019 at 03:42:03AM -0000, James Harvey wrote: +> ** Description changed: +> +> Up to date Arch Linux on host and guest. linux 5.2.11. QEMU 4.1.0. +> Full command line at bottom. +> +> Host gives QEMU two thin LVM volumes. The first is the root filesystem, +> and the second is for heavy I/O, on a Samsung 970 Evo 1TB. +> +> When maxing out the I/O on the second virtual block device using virtio- +> blk, I often get a "lockup" in about an hour or two. From the advise of +> iggy in IRC, I switched over to virtio-scsi. It ran perfectly for a few +> days, but then "locked up" in the same way. +> +> By "lockup", I mean writes to the second virtual block device +> permanently hang. I can read files from it, but even "touch foo" never +> times out, cannot be "kill -9"'ed, and is stuck in uninterruptible +> sleep. +> +> When this happens, writes to the first virtual block device with the +> root filesystem are fine, so the O/S itself remains responsive. +> +> The second virtual block device uses BTRFS. But, I have also tried XFS +> and reproduced the issue. +> +> In guest, when this starts, it starts logging "task X blocked for more +> than Y seconds". Below is an example of one of these. At this point, +> anything that is or does in the future write to this block device gets +> stuck in uninterruptible sleep. +> +> ----- +> +> INFO: task kcompactd:232 blocked for more than 860 seconds. +> Not tained 5.2.11-1 #1 +> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this messae. +> kcompactd0 D 0 232 2 0x80004000 +> Call Trace: +> ? __schedule+0x27f/0x6d0 +> schedule+0x3d/0xc0 +> io_schedule+0x12/0x40 +> __lock_page+0x14a/0x250 +> ? add_to_page_cache_lru+0xe0/0xe0 +> migrate_pages+0x803/0xb70 +> ? isolate_migratepages_block+0x9f0/0x9f0 +> ? __reset_isolation_suitable+0x110/0x110 +> compact_zone+0x6a2/0xd30 +> kcompactd_do_work+0x134/0x260 +> ? kvm_clock_read+0x14/0x30 +> ? kvm_sched_clock_read+0x5/0x10 +> kcompactd+0xd3/0x220 +> ? wait_woken+0x80/0x80 +> kthread+0xfd/0x130 +> ? kcompactd_do_work+0x260/0x260 +> ? kthread_park+0x80/0x80 +> ret_from_fork+0x35/0x40 +> +> ----- +> +> In guest, there are no other dmesg/journalctl entries other than +> "task...blocked". +> +> On host, there are no dmesg/journalctl entries whatsoever. Everything +> else in host continues to work fine, including other QEMU VM's on the +> same underlying SSD (but obviously different lvm volumes.) +> +> I understand there might not be enough to go on here, and I also +> understand it's possible this isn't a QEMU bug. Happy to run given +> commands or patches to help diagnose what's going on here. +> +> I'm now running a custom compiled QEMU 4.1.0, with debug symbols, so I +> can get a meaningful backtrace from the host point of view. +> +> I've only recently tried this level of I/O, so can't say if this is a +> new issue. +> +> + When writes are hanging, on host, I can connect to the monitor. Running +> + "info block" shows nothing unusual. +> + +> ----- +> +> /usr/bin/qemu-system-x86_64 +> -name arch,process=qemu:arch +> -no-user-config +> -nodefaults +> -nographic +> -uuid 0528162b-2371-41d5-b8da-233fe61b6458 +> -pidfile /tmp/0528162b-2371-41d5-b8da-233fe61b6458.pid +> -machine q35,accel=kvm,vmport=off,dump-guest-core=off +> -cpu SandyBridge-IBRS +> -smp cpus=24,cores=12,threads=1,sockets=2 +> -m 24G +> -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd +> -drive if=pflash,format=raw,readonly,file=/var/qemu/0528162b-2371-41d5-b8da-233fe61b6458.fd +> -monitor telnet:localhost:8000,server,nowait,nodelay +> -spice unix,addr=/tmp/0528162b-2371-41d5-b8da-233fe61b6458.sock,disable-ticketing +> -device ioh3420,id=pcie.1,bus=pcie.0,slot=0 +> -device virtio-vga,bus=pcie.1,addr=0 +> -usbdevice tablet +> -netdev bridge,id=network0,br=br0 +> -device virtio-net-pci,netdev=network0,mac=02:37:de:79:19:09,bus=pcie.0,addr=3 +> -device virtio-scsi-pci,id=scsi1 +> -drive driver=raw,node-name=hd0,file=/dev/lvm/arch_root,if=none,discard=unmap +> -device scsi-hd,drive=hd0,bootindex=1 +> -drive driver=raw,node-name=hd1,file=/dev/lvm/arch_nvme,if=none,discard=unmap +> -device scsi-hd,drive=hd1,bootindex=2 + +Please post backtrace of all QEMU threads when I/O is hung. You can use +"gdb -p $(pidog qemu-system-x86_64)" to connect GDB and "thread apply +all bt" to produce a backtrace of all threads. + +Stefan + + +Apologies, it looks like I ran into two separate bugs, one with XFS, and one with BTRFS, that had the same symptom, initially making me to think this must be a QEMU issue. + +Using blktrace, I was able to see within the VM, that the virtio block device wasn't getting the writes that were going into uninterruptible sleep. + +So, this should be able to be closed. For some reason, virtio-blk seemed to trigger the bugs more rapidly, but at this point, I can't say there is anything at fault with it or virtio-scsi. + + +BTRFS issue was discussed and linked to here https://lore.kernel.org<email address hidden>/ and has been released. I've been able to run it for several days without a lockup, so it seems to have fixed the issue for me. + +I just emailed the XFS list about the separate problems with it. No idea if it's an issue in more recent kernels than 5.1.15-5.1.16, which is what I was running at the time of the XFS errors. (Like the original report said, I was on 5.2.11 at that point.) See https://www.spinics.net/lists/linux-xfs/msg31927.html + +Thanks for updating us on this issue, which turned out not to be a QEMU bug. + diff --git a/results/classifier/zero-shot/108/all/1844053 b/results/classifier/zero-shot/108/all/1844053 new file mode 100644 index 000000000..8bfeab3fe --- /dev/null +++ b/results/classifier/zero-shot/108/all/1844053 @@ -0,0 +1,95 @@ +other: 0.957 +permissions: 0.952 +device: 0.942 +files: 0.942 +boot: 0.942 +socket: 0.940 +debug: 0.939 +PID: 0.939 +performance: 0.937 +semantic: 0.932 +graphic: 0.929 +network: 0.927 +KVM: 0.924 +vnc: 0.919 + +task blocked for more than X seconds - events drm_fb_helper_dirty_work + +I've had bunches of these errors on 9 different boots, between 2019-08-21 and now, with Arch host and guest, from linux 5.1.16 to 5.2.14 on host and guest, with QEMU 4.0.0 and 4.1.0. spice 0.14.2, spice-gtk 0.37, spice-protocol 0.14.0, virt-viewer 8.0. + +I've been fighting with some other issues related to a 5.2 btrfs regression, a QEMU qxl regression (see bug 1843151) which I ran into when trying to temporarily abandon virtio-vga, and I haven't paid enough attention to what impact it has on the system when these occur. In journalctl, I can see I often rebooted minutes after they occurred, but sometimes much later. That must mean whenever I saw it happen that I rebooted the VM, or potentially it impacted functionality of the system. + +Please let me know if and how I can get more information for you if needed. + +I've replicated this on both a system with integrated ASPEED video, and on an AMD Vega 64 running amdgpu. + +As an example, I have one boot which reported at 122 seconds, 245, 368, 491, 614, 737, 860, 983, 1105, 1228, then I rebooted. + +I have another that reported 122/245/368/491/614/737, went away for 10 minutes, then started reporting again 122/245/368/491, and went away. Then, I rebooted about 20 hours later. + +Host system has no graphical impact when this happens, and logs nothing in its journalctl. + +========== + +INFO: task kworker/0:1:15 blocked for more than 122 seconds. + Not tainted 5.2.14-1 #1 +"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. +kworker/0:1 D 0 15 2 0x800004000 +Workqueue: events drm_fb_helper_dirty_work [drm_kms_helper] +Call Trace: + ? __schedule+0x27f/0x6d0 + schedule+0x3d/0xc0 + virtio_gpu_queue_fenced_ctrl_buffer+0xa1/0x130 [virtio_gpu] + ? wait_woken+0x80/0x80 + virtio_gpu_surface_dirty+0x2a5/0x300 [virtio_gpu] + drm_fb_helper_dirty_work+0x156/0x160 [drm_kms_helper] + process_one_work+0x19a/0x3b0 + worker_tread+0x50/0x3a0 + kthread+0xfd/0x130 + ? process_one_work+0x3b0/0x3b0 + ? kthread_park+0x80/0x80 + ret_from_fork+0x35/0x40 + +========== + +/usr/bin/qemu-system-x86_64 \ + -name vm,process=qemu:vm \ + -no-user-config \ + -nodefaults \ + -nographic \ + -uuid <uuid> \ + -pidfile <pidfile> \ + -machine q35,accel=kvm,vmport=off,dump-guest-core=off \ + -cpu SandyBridge-IBRS \ + -smp cpus=4,cores=2,threads=1,sockets=2 \ + -m 4G \ + -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd \ + -drive if=pflash,format=raw,file=/var/qemu/efivars/vm.fd \ + -monitor telnet:localhost:8000,server,nowait,nodelay \ + -spice unix,addr=/tmp/spice.vm.sock,disable-ticketing \ + -device ioh3420,id=pcie.1,bus=pcie.0,slot=0 \ + -device virtio-vga,bus=pcie.1,addr=0 \ + -usbdevice tablet \ + -netdev bridge,id=network0,br=br0 \ + -device virtio-net-pci,netdev=network0,mac=F4:F6:34:F6:34:2d,bus=pcie.0,addr=3 \ + -device virtio-scsi-pci,id=scsi1 \ + -drive driver=raw,node-name=hd0,file=/dev/lvm/vm,if=none,discard=unmap,cache=none,aio=threads + +I have the same problem running ubuntu 20.04 on Centos 7 host with qlx... + + +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/zero-shot/108/all/1844635 b/results/classifier/zero-shot/108/all/1844635 new file mode 100644 index 000000000..e721945b0 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1844635 @@ -0,0 +1,158 @@ +debug: 0.989 +semantic: 0.988 +other: 0.986 +performance: 0.986 +graphic: 0.984 +permissions: 0.984 +device: 0.981 +boot: 0.980 +PID: 0.978 +socket: 0.975 +network: 0.975 +vnc: 0.974 +files: 0.973 +KVM: 0.968 + +qemu bug where load linux kernel + +i found a qemu bug ,when the qemu start and parse the kernel file . + +This vulnerability can be exploited. + +thanks + +/**** + + +(gdb) set args -nodefaults -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial stdio -device pci-testdev -machine accel=kvm -m 2048 -smp 2 -cpu host -machine kernel_irqchip=split -kernel poc1 +(gdb) r +Starting program: /usr/bin/qemu-system-x86_64 -nodefaults -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial stdio -device pci-testdev -machine accel=kvm -m 2048 -smp 2 -cpu host -machine kernel_irqchip=split -kernel ./poc/poc1 +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +[New Thread 0x7fffe9a03700 (LWP 30066)] +[New Thread 0x7fffe9202700 (LWP 30068)] +[New Thread 0x7fffe8a01700 (LWP 30069)] + +Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +__memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:249 +249 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory. +(gdb) bt +#0 0x00007ffff2390b1f in __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:249 +#1 0x00005555559ebdcf in rom_copy () +#2 0x00005555558dd1b3 in load_multiboot () +#3 0x00005555558de1c3 in () +#4 0x00005555558e19d1 in pc_memory_init () +#5 0x00005555558e4ee3 in () +#6 0x00005555559e8500 in machine_run_board_init () +#7 0x0000555555834959 in main () +(gdb) c +Continuing. +Couldn't get registers: No such process. +Couldn't get registers: No such process. +(gdb) [Thread 0x7fffe8a01700 (LWP 30069) exited] +[Thread 0x7fffe9202700 (LWP 30068) exited] +[Thread 0x7fffe9a03700 (LWP 30066) exited] + +Program terminated with signal SIGSEGV, Segmentation fault. +The program no longer exists. + +***/ + + + +bug reason and how to fix it +/* + * Copies memory from registered ROMs to dest. Any memory that is contained in + * a ROM between addr and addr + size is copied. Note that this can involve + * multiple ROMs, which need not start at addr and need not end at addr + size. + */ +int rom_copy(uint8_t *dest, hwaddr addr, size_t size) +{ + hwaddr end = addr + size; + uint8_t *s, *d = dest; + size_t l = 0; + Rom *rom; + + QTAILQ_FOREACH(rom, &roms, next) { + if (rom->fw_file) { + continue; + } + if (rom->mr) { + continue; + } + if (rom->addr + rom->romsize < addr) { + continue; + } + if (rom->addr > end) { + break; + } + + d = dest + (rom->addr - addr); + s = rom->data; + l = rom->datasize; + + if ((d + l) > (dest + size)) { + l = dest - d; + } + + if (l > 0) { + memcpy(d, s, l); //*****crash here how to fix check the size l.******// + } + + if (rom->romsize > rom->datasize) { + /* If datasize is less than romsize, it means that we didn't + * allocate all the ROM because the trailing data are only zeros. + */ + + d += l; + l = rom->romsize - rom->datasize; + + if ((d + l) > (dest + size)) { + /* Rom size doesn't fit in the destination area. Adjust to avoid + * overflow. + */ + l = dest - d; + } + + if (l > 0) { + memset(d, 0x0, l); + } + } + } + + return (d + l) - dest; +} + +I can't reproduce the issue with your "poc" binary here. Which version of QEMU were you exactly using? Can you reproduce it with the latest version from the master branch? + +Also there is already a size check some lines earlier: + + if ((d + l) > (dest + size)) { + l = dest - d; + } + +Isn't that sufficient? + +Also please explain how this vulnerability could be exploited? The code patch is not triggered by the guest, is it? + +hi , + + if ((d + l) > (dest + size)) { + l = dest - d; + } +the l will be a very big Unsigned number. + +the check was bypassed,try the new poc . i reproduce it with the latest +version on ubuntu . (apt install qemu , i got the latest version) + +hi Thomas,please try the new poc. +thanks + +Thanks a lot! With the new poc, I was able to reproduce the crash. +I've forwarded the information to the QEMU security team (next time, it would be great if you could do that directly, see https://wiki.qemu.org/SecurityProcess for details), and after some discussion about the severity of the bug, I've now posted a patch to the mailing: + + https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg05960.html + +Fix has been merged: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e423455c4f23a1a8 + diff --git a/results/classifier/zero-shot/108/all/1847525 b/results/classifier/zero-shot/108/all/1847525 new file mode 100644 index 000000000..e3504926e --- /dev/null +++ b/results/classifier/zero-shot/108/all/1847525 @@ -0,0 +1,126 @@ +other: 0.968 +permissions: 0.958 +KVM: 0.954 +performance: 0.954 +vnc: 0.952 +files: 0.952 +device: 0.950 +semantic: 0.949 +debug: 0.947 +PID: 0.942 +socket: 0.940 +graphic: 0.939 +network: 0.936 +boot: 0.935 + +qemu-system-i386 eats a lot of cpu after just few hours, with sdl,gl=on + +I already send this email to <email address hidden> , but I can't see it arriving in archives, so here is copy. + +Hello, all! + +I use qemu-system-i386/qemu-system_x86_64 for rebuilding Slax-like live cd/dvd. +Usually guests (with various self-compiled kernels and X stack with kde3 on top of them) +boot up normally, but if I left them to run in GUI mode for few hours - qemu process on host +started to eat more and more cpu for itself - more notiecable if I set host cpu to lowest possible +frequency via trayfreq applet (1400Mhz in my case). + +Boot line a bit complicated, but I really prefer to have sound and usb inside VM. +qemu-system-i386 -cdrom /dev/shm/CDROM-4.4.194_5.iso -m 1.9G -enable-kvm -soundhw es1370 -smp 2 -display sdl,gl=on -usb -cpu host -rtc clock=vm + +rtc clock=vm was taken from https://bugs.launchpad.net/qemu/+bug/1174654 but apparently not helping. +After just 3 hours of uptime (copied line from 'top' on host) + +31943 guest 20 0 2412m 791m 38m R 51 6.7 66:36.51 qemu-system-i38 + +I use Xorg 1.19.7 on host, with mesa git/nouveau as GL driver. But my card has not very big amount of VRAM - only 384Mb. +May be this limitation is playing some role .. but 'end-user' result was after 1-2 day of guest uptime I run into completely frozen guest +(may be when qemu was hitting 100 one core usage on host some internal timer just made guest kernel too upset/froze? + I was sleeping or doing other things on host for all this time, with VM just supposedly running at another virtual desktop - +in KDE3 + built-in compositor ....) + +I wonder if more mainstream desktop users (on GNOME, Xfce, etc) and/or users of other distros (I use self-re-compiled Slackware) +actually can see same problem? + +qemu-system-i386 --version +QEMU emulator version 4.1.50 (v4.1.0-1188-gc6f5012ba5-dirty) +but I saw same behavior for quite some time .. just never reported it in hope it will go away. + +cat /proc/cpuinfo +processor : 0 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-4300 Quad-Core Processor +stepping : 0 +microcode : 0x6000852 +cpu MHz : 1399.977 +cache size : 2048 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 2 +apicid : 16 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 13 +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 constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold +bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass +bogomips : 7600.06 +TLB size : 1536 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro + +[and 3x more of the same, for 3 remaining cores] + +Gcc is Slackware 14.2's gcc 5.5.0, but I saw this with 4.9.2 too. +This might be 32-bit host problem. But may be just no-one tried to run qemu with GUI guest for literaly days? + +Host kernel is + uname -a +Linux slax 5.1.12-x64 #1 SMP PREEMPT Wed Jun 19 12:31:05 MSK 2019 x86_64 AMD FX(tm)-4300 Quad-Core Processor AuthenticAMD GNU/Linux + +I was trying newish 5.3.2 but my compilation was not as stable as this one +(I tend to change few things, like max cpu count, preemption mode, numa support .... +for more distribution-like, yet most stable and performant for me kernel) + +Kernel world is moving fast, so I'll try to recompile new 5.3.x too .... + + +I guess I should provide perf/profiler output, but for this I need to recompile qemu. +I'll try to come back with more details soon. + +Thanks for your attention and possible feedback! + +Illustration for this bug (link to screenshot): + +https://www.imgbin.net/z/9W9eVVvbll.png + +as you hopefully can see, just after less than 6 hrs of guest uptime HOST cpu is eaten at 70% by qemu-system-i386 task .. up from just 50% two hours ago! By this rate it will not survive even day of uptime.... + +this one still with me. + +qemu-system-x86_64 --version +QEMU emulator version 4.2.91 (v5.0.0-rc1-dirty) + +on 32-bit host (Slackware, but with 64-bit kernel) compiled with gcc 5.5.0 + +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/zero-shot/108/all/1850570 b/results/classifier/zero-shot/108/all/1850570 new file mode 100644 index 000000000..f66a2004e --- /dev/null +++ b/results/classifier/zero-shot/108/all/1850570 @@ -0,0 +1,374 @@ +other: 0.988 +performance: 0.987 +PID: 0.985 +semantic: 0.982 +device: 0.981 +permissions: 0.979 +graphic: 0.977 +boot: 0.976 +network: 0.975 +debug: 0.972 +vnc: 0.968 +socket: 0.963 +KVM: 0.960 +files: 0.959 + +Cannot use usb-host on Mac OS + +Usb-host will not work on Mac OS 10.15. Qemu runs, though it gives these errors and the drive does not show up. Also, when Qemu is starting the drive ejects and remounts twice. Qemu built with ./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl --disable-cocoa --enable-sdl-image. + +qemu-system-i386 image.qcow -usb -device usb-kbd -device usb-host,vendorid=0x0781,productid=0x5571 +libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found +libusb: error [darwin_claim_interface] interface not found + +> +> Message: 9 +> Date: Wed, 30 Oct 2019 01:46:54 -0000 +> From: John Canada <email address hidden> +> To: <email address hidden> +> Subject: [Bug 1850570] [NEW] Cannot use usb-host on Mac OS +> Message-ID: +> < +> <email address hidden> +> > +> +> Content-Type: text/plain; charset="utf-8" +> +> Public bug reported: +> +> Usb-host will not work on Mac OS 10.15. Qemu runs, though it gives +> these errors and the drive does not show up. Also, when Qemu is +> starting the drive ejects and remounts twice. Qemu built with +> ./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl +> --disable-cocoa --enable-sdl-image. +> +> qemu-system-i386 image.qcow -usb -device usb-kbd -device +> usb-host,vendorid=0x0781,productid=0x5571 +> libusb: error [darwin_claim_interface] USBInterfaceOpen: another process +> has device opened for exclusive access +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] USBInterfaceOpen: another process +> has device opened for exclusive access +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1850570 +> +> Title: +> Cannot use usb-host on Mac OS +> +> Status in QEMU: +> New +> +> Bug description: +> Usb-host will not work on Mac OS 10.15. Qemu runs, though it gives +> these errors and the drive does not show up. Also, when Qemu is +> starting the drive ejects and remounts twice. Qemu built with +> ./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl +> --disable-cocoa --enable-sdl-image. +> +> qemu-system-i386 image.qcow -usb -device usb-kbd -device +> usb-host,vendorid=0x0781,productid=0x5571 +> libusb: error [darwin_claim_interface] USBInterfaceOpen: another process +> has device opened for exclusive access +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] USBInterfaceOpen: another process +> has device opened for exclusive access +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1850570/+subscriptions +> +> +> +Have you tried running QEMU under root yet? I had a similar issue with +accessing the optical drive on my computer until I ran QEMU like this: + +sudo qemu-system-i386 ... + + +Yes, I tried running as root. I also tried it on a different computer that is running Mac OS 10.13, and it gave the same errors. + + +> On Oct 31, 2019, at 7:35 PM, <email address hidden> wrote: +> +> Message: 10 +> Date: Thu, 31 Oct 2019 18:39:11 -0000 +> From: John Canada <email address hidden> +> To: <email address hidden> +> Subject: [Bug 1850570] Re: Cannot use usb-host on Mac OS +> Message-ID: +> <email address hidden> +> Content-Type: text/plain; charset="utf-8" +> +> Yes, I tried running as root. I also tried it on a different computer +> that is running Mac OS 10.13, and it gave the same errors. +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1850570 +> +> Title: +> Cannot use usb-host on Mac OS +> +> Status in QEMU: +> New +> +> Bug description: +> Usb-host will not work on Mac OS 10.15. Qemu runs, though it gives +> these errors and the drive does not show up. Also, when Qemu is +> starting the drive ejects and remounts twice. Qemu built with +> ./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl +> --disable-cocoa --enable-sdl-image. +> +> qemu-system-i386 image.qcow -usb -device usb-kbd -device usb-host,vendorid=0x0781,productid=0x5571 +> libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1850570/+subscriptions + + +Try this. Unplug the USB device. Plug it back in, and as fast as you can start QEMU. + +My theory is another program might be using the device. This could be Spotlight trying to index the drive. + +Another possibility is libusb is not compatible with Mac OS 10.13 yet. + +Do you have another computer that runs Mac OS 10.12 or under that you can test on? + + + + +I am also having problems with using real USB devices. I tried a C-Media USB sound card, a CISCO USB headset, and a PNY flash drive. All of them seem to be detected by the Windows 7 guest, but can't be started for some reason. I have tried running as root. I didn't see any libusb errors. My Windows 2000 guest also has issues with starting the USB sound card. + +My command-line: +sudo qemu-system-x86_64 -hda "Windows 7 HD.qcow2" -boot "c" -m 5000 -device ich9-usb-ehci1 -device usb-host,vendorid=0x0930,productid=0x6545 + +Even when I unmount the flash drive first Mac OS 11.1 will actually mount the flash drive when I try using it in QEMU. + +On Sun, Apr 4, 2021 at 8:30 PM John Arbuckle <email address hidden> wrote: +> +> I am also having problems with using real USB devices. I tried a C-Media +> USB sound card, a CISCO USB headset, and a PNY flash drive. All of them +> seem to be detected by the Windows 7 guest, but can't be started for +> some reason. I have tried running as root. I didn't see any libusb +> errors. My Windows 2000 guest also has issues with starting the USB +> sound card. +> +> My command-line: +> sudo qemu-system-x86_64 -hda "Windows 7 HD.qcow2" -boot "c" -m 5000 -device ich9-usb-ehci1 -device usb-host,vendorid=0x0930,productid=0x6545 +> +> Even when I unmount the flash drive first Mac OS 11.1 will actually +> mount the flash drive when I try using it in QEMU. +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1850570 +> +> Title: +> Cannot use usb-host on Mac OS +> +> Status in QEMU: +> New +> +> Bug description: +> Usb-host will not work on Mac OS 10.15. Qemu runs, though it gives +> these errors and the drive does not show up. Also, when Qemu is +> starting the drive ejects and remounts twice. Qemu built with +> ./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl +> --disable-cocoa --enable-sdl-image. +> +> qemu-system-i386 image.qcow -usb -device usb-kbd -device usb-host,vendorid=0x0781,productid=0x5571 +> libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> libusb: error [darwin_claim_interface] interface not found +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1850570/+subscriptions +> + +Hi John, + +I experience similar issues when passing through USB devices in +qemu-system-ppc. macOS load a kext for the device and will not unload +it when libusb tries to connect to the device. I wrote this on the +emaculation site: + +For USB storage devices you might need to: +Run a terminal and execute: sudo kextunload +/System/Library/Extensions/IOUSBMassStorageDriver.kext + +Other devices might be using other kexts (drivers), so you would need +to find out which kext is loaded for the device. Some devices might be +using a kext that is also in use for other host devices. If you unload +such a kext, the host will loose access to those devices. + +I have not yet found a way to reliably find which kexts are loaded and +to unload them. + +Best, +Howard + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/183 + + diff --git a/results/classifier/zero-shot/108/all/1852 b/results/classifier/zero-shot/108/all/1852 new file mode 100644 index 000000000..a61e73d97 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1852 @@ -0,0 +1,125 @@ +permissions: 0.984 +graphic: 0.979 +device: 0.975 +PID: 0.974 +other: 0.972 +debug: 0.971 +semantic: 0.967 +performance: 0.965 +files: 0.961 +boot: 0.950 +KVM: 0.949 +socket: 0.946 +vnc: 0.921 +network: 0.916 + +aarch64: crash failed to analyze vmcore of dump-guest-memory +Description of problem: +``` +1、 dump guest memory +virsh qemu-monitor-command 3 --hmp "dump-guest-memory /home/ecs3.kdump" +2、crash kdump failed +[root@ceasphere-node-1 home]# ./crash ./vmlinux ./ecs3.kdump + +crash 7.2.9-2.el8 +Copyright (C) 2002-2020 Red Hat, Inc. +Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation +Copyright (C) 1999-2006 Hewlett-Packard Co +Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited +Copyright (C) 2006, 2007 VA Linux Systems Japan K.K. +Copyright (C) 2005, 2011 NEC Corporation +Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc. +Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc. +This program is free software, covered by the GNU General Public License, +and you are welcome to change it and/or distribute copies of it under +certain conditions. Enter "help copying" to see the conditions. +This program has absolutely no warranty. Enter "help warranty" for details. + +crash: read error: kernel virtual address: ffff000010e0ba48 type: "vabits_user" +GNU gdb (GDB) 7.6 +Copyright (C) 2013 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "aarch64-unknown-linux-gnu"... + +crash: read error: kernel virtual address: ffff000011a609b8 type: "possible" +WARNING: cannot read cpu_possible_map +crash: read error: kernel virtual address: ffff000011a60bb8 type: "present" +WARNING: cannot read cpu_present_map +crash: read error: kernel virtual address: ffff000011a607b8 type: "online" +WARNING: cannot read cpu_online_map +crash: read error: kernel virtual address: ffff000011a60db8 type: "active" +WARNING: cannot read cpu_active_map +crash: read error: kernel virtual address: ffff0000123da120 type: "shadow_timekeeper xtime_sec" +crash: read error: kernel virtual address: ffff000011a6a6ac type: "init_uts_ns" +crash: ./vmlinux and ./ecs3.kdump do not match! + +Usage: + + crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile form) + crash [OPTION]... [NAMELIST] (live system form) + +Enter "crash -h" for details. +``` +Steps to reproduce: +1. virsh create vm.xml +2. virsh qemu-monitor-command 3 --hmp "dump-guest-memory /home/ecs3.kdump" +3. crash ./vmlinux ./ecs3.kdump +Additional information: +The vmcore by 'echo c > /proc/sysrq-trigger' in guest is ok, crash work. + +``` +[root@ceasphere-node-1 home]# crash ./vmlinux ./vmcore + +crash 8.0.3-1.el9 +Copyright (C) 2002-2022 Red Hat, Inc. +Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation +Copyright (C) 1999-2006 Hewlett-Packard Co +Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited +Copyright (C) 2006, 2007 VA Linux Systems Japan K.K. +Copyright (C) 2005, 2011, 2020-2022 NEC Corporation +Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc. +Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc. +Copyright (C) 2015, 2021 VMware, Inc. +This program is free software, covered by the GNU General Public License, +and you are welcome to change it and/or distribute copies of it under +certain conditions. Enter "help copying" to see the conditions. +This program has absolutely no warranty. Enter "help warranty" for details. + +GNU gdb (GDB) 10.2 +Copyright (C) 2021 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "aarch64-unknown-linux-gnu". +Type "show configuration" for configuration details. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... + + KERNEL: ./vmlinux + DUMPFILE: ./vmcore [PARTIAL DUMP] + CPUS: 4 + DATE: Wed Aug 30 09:06:01 CST 2023 + UPTIME: 00:01:08 +LOAD AVERAGE: 0.91, 0.34, 0.12 + TASKS: 158 + NODENAME: localhost + RELEASE: 4.18.0-305.3.1.el8.aarch64 + VERSION: #1 SMP Tue Jun 1 16:22:50 UTC 2021 + MACHINE: aarch64 (unknown Mhz) + MEMORY: 16 GB + PANIC: "sysrq: SysRq : Trigger a crash" + PID: 1310 + COMMAND: "bash" + TASK: ffff8003d47d3200 [THREAD_INFO: ffff8003d47d3200] + CPU: 1 + STATE: TASK_RUNNING (SYSRQ) + +crash> +``` diff --git a/results/classifier/zero-shot/108/all/1852781 b/results/classifier/zero-shot/108/all/1852781 new file mode 100644 index 000000000..838190db0 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1852781 @@ -0,0 +1,86 @@ +KVM: 0.960 +permissions: 0.947 +boot: 0.947 +vnc: 0.938 +files: 0.936 +performance: 0.935 +debug: 0.932 +graphic: 0.932 +device: 0.930 +socket: 0.929 +other: 0.929 +semantic: 0.915 +network: 0.912 +PID: 0.906 + +qemu s390x on focal - applications breaking + +Running qemu-system-s390x (1:4.0+dfsg-0ubuntu10) on an x86-64 Focal host with an upgrade of a Eoan s390x VM to a Focal s390x is triggering random breakage, for example: + +sudo apt-get update && sudo apt-get dist-upgrade + +... +... + +Unpacking debianutils (4.9) over (4.8.6.3) ... +Setting up debianutils (4.9) ... +Use of uninitialized value $ARGV[0] in string ne at /usr/sbin/update-mime line 43. +(Reading database ... 83640 files and directories currently installed.) +Preparing to unpack .../bash_5.0-5ubuntu1_s390x.deb ... +Unpacking bash (5.0-5ubuntu1) over (5.0-4ubuntu1) ... +Setting up bash (5.0-5ubuntu1) ... +[12124.788618] User process fault: interruption code 0007 ilc:3 in bash[2aa3d780000+149000] +dpkg: error processing package bash (--configure): + installed bash package post-installation script subprocess was killed by signal (Floating point exception), core du +mped +Errors were encountered while processing: + bash +E: Sub-process /usr/bin/dpkg returned an error code (1) + +And now bash is completely broken: + +cking@eoan-s390x:~$ bash +[12676.204389] User process fault: interruption code 0007 ilc:3 in bash[2aa14780000+149000] + +Floating point exception (core dumped) + +The upgrade works OK on a s390x, so I'm assuming it's something to do with the qemu emulation. + +I've also seen in the dmesg log: + +[ 287.624414] User process fault: interruption code 0007 ilc:3 in libstdc++.so.6.0.28[3ffb3e00000+21d000] +[ 288.991706] User process fault: interruption code 0007 ilc:3 in libstdc++.so.6.0.28[3ff90080000+21d000] + +ps is showing QEMU is running as follows: + +/usr/bin/qemu-system-s390x -name guest=ubuntu20.04-focal-s390x,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-10-ubuntu20.04-focal-s3/master-key.aes -machine s390-ccw-virtio-eoan,accel=tcg,usb=off,dump-guest-core=off -m 2048 -overcommit mem-lock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 6501dfbf-16d7-4412-a9d5-1ee808b42804 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=24,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0002 -device virtio-serial-ccw,id=virtio-serial0,devno=fe.0.0003 -drive file=/pool-ssd/virt/ubuntu19.10-eaon-s390x-clone,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-ccw,scsi=off,devno=fe.0.0000,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-scsi0-0-0-0,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 -netdev tap,fd=27,id=hostnet0 -device virtio-net-ccw,netdev=hostnet0,id=net0,mac=52:54:00:a3:21:68,devno=fe.0.0001 -chardev socket,id=charchannel0,fd=28,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev pty,id=charconsole0 -device sclpconsole,chardev=charconsole0,id=console0 -device virtio-balloon-ccw,id=balloon0,devno=fe.0.0004 -object rng-random,id=objrng0,filename=/dev/urandom -device virtio-rng-ccw,rng=objrng0,id=rng0,devno=fe.0.0005 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + + +Hi Colin, +I didn't read much if the details but I think it is clear. + +Per request of IBM focal got -march=z13 but tcg has no emulation for some +of the instructions of this cpu. + +That is the breakage that you are seeing and afaik there is nothing we can +do than waiting for qemu to grow that support. + + +Can you please test again with the latest QEMU 4.2 RC? There have been quite a lot of fixes in this area in the past months, so maybe this issue has already been resolved in 4.2. + +[Expired for QEMU because there has been no activity for 60 days.] + +[Expired for Ubuntu on IBM z Systems because there has been no activity for 60 days.] + +FYI - Focal now contains 4.2 which might (or not) have the bits you need. +You most likely get further, but I can't give guarantees if enough of march=z13 is supported to work for a full Focal (not sure on vector instructions for example) including all of userspace. + +Marking it incomplete - if someone wants to try please go for it and let us know. +Otherwise let it expire again ... + +Seems like you have to set all to "incomplete" to restart the expire counter again... + +[Expired for Ubuntu on IBM z Systems because there has been no activity for 60 days.] + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1865048 b/results/classifier/zero-shot/108/all/1865048 new file mode 100644 index 000000000..213d4a066 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1865048 @@ -0,0 +1,131 @@ +device: 0.970 +other: 0.968 +debug: 0.964 +permissions: 0.959 +performance: 0.958 +socket: 0.953 +files: 0.950 +PID: 0.947 +network: 0.942 +vnc: 0.939 +boot: 0.932 +graphic: 0.931 +semantic: 0.921 +KVM: 0.911 + +qemu-img --force-share does not disable file locking + +The new option "--force-share" for qemu-img does not disable file locking. + +I tried it with version qemu-img version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.21~cloud0) and I traced the source code of the current git trunk. + +Sample to demonstrate: + +# strace qemu-img info --force-share testfile.qcow2 2>&1 | grep F_RDLCK +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 +fcntl(11, F_OFD_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=100, l_len=1}) = 0 + +I traced the passing of the --force-share option through the source code (I used commit 6c599282f8 as of Mon Feb 17 13:32:25 2020 +0000) + +qemu-img.c:img_info() + force_share = true; +qemu-img.c:collect_image_info_list(force_share) +qemu-img.c:img_open(force_share) +qemu-img.c:img_open_file(force_share) + qdict_put_bool(options, BDRV_OPT_FORCE_SHARE, true); +block/block-backend.c:blk_new_open(options) +block.c:bdrv_open(options) +block.c:bdrv_open_inheritoptions() +block.c:bdrv_open_common(options) + bs->force_share = qemu_opt_get_bool(opts, BDRV_OPT_FORCE_SHARE, false); +block.c:bdrv_open_driver(bs) +include/block/block_int.h:int (*bdrv_file_open)(BlockDriverState *bs, QDict *options, int flags, +block/file-posix.c:.bdrv_file_open = raw_open, +block/file-posix.c:raw_open_common(bs) + locking = qapi_enum_parse(&OnOffAuto_lookup, + qemu_opt_get(opts, "locking"), + ON_OFF_AUTO_AUTO, &local_err); + ignoring bs->force_share + +At the end, bs->force_share is ignored in determining the locking value. + +Hi, + +That’s intentional. The man page says this: + + --force-share (-U) + If specified, "qemu-img" will open the image in shared mode, + allowing other QEMU processes to open it in write mode. For + example, this can be used to get the image information (with + 'info' subcommand) when the image is used by a running guest. + +It says nothing about not using file locks. All it will do is cause qemu-img to signal to other processes that it’s OK for them to use the image in any way, or if there already is another process having opened the image for any access, qemu-img will not complain. + +For example, open a qemu-io process on some image: + +$ qemu-io foo.qcow2 + +And in another shell, invoke qemu-img: + +$ qemu-img info foo.qcow2 +qemu-img: Could not open 'foo.qcow2': Failed to get shared "write" lock +Is another process using the image [foo.qcow2]? + +$ qemu-img info --force-share foo.qcow2 +image: foo.qcow2 +file format: qcow2 +[...] + + +force-share is evaluated in bdrv_child_perm in block.c. The file locks qemu sets are an extension of the internal “permission” system we use for block nodes: For example, when some guest device wants write access to an image, it has to take the WRITE permission. That will be disallowed if there is some other user of the image that does not allow taking the WRITE permission (we say: it “unshares” the WRITE permission). force-share enforces sharing all permissions, but it does not disable the permission system. + +The file locks are used to transmit that internal mechanism of taking/sharing permissions across different processes. Unshared permissions are reflected by locks between offset 200 and 299. Taken permissions are reflected by locks between offset 100 and 199. As you can see, qemu-img with --force-share does not unshare any permissions (it does not take any locks after offset 200). The only lock it takes is offset 100, which corresponds to CONSISTENT_READ. That permission means “I want to read from the image and get back something sane”. So if any other process uses the image in such a way that this is impossible (i.e., it has to unshare CONSISTENT_READ), qemu-img info will complain, regardless of --force-share. + + +File locks can only be completely disabled through file-posix’s @locking option (locking=false), e.g. like so: + +$ qemu-img info --image-opts file.filename=foo.qcow2,file.locking=off + +But that is strongly discouraged, and I have yet to see a case where this would be the right thing to do. + +Max + +Hi Maz, + +thanks for the information! + +The situation we're in is where we are suspecting the file locking on a shared network file system to be broken, so we were looking for ways to avoid any locking. I had tried some variations on your image-opts style invocation, but did not find any variant where the automatic file format detection would be preserved. For instance, with --image-opts driver=file,filename=foo.qcow2,locking=off it would think the file is raw. But the one you give seems to do what I want to experiment with, so thanks again! + +-Olaf. + +Hi Olaf, + +Every “node” in the block graph corresponds to some driver. A driver can be a protocol or a format driver (or a filter driver, but that isn’t important here). In your example, there is only a single node, for a protocol driver (namely “file”). You need a format driver node on top to interpret the image format. + +If you use file.driver=file,file.filename=foo.qcow2,file.locking=off, then that specifies the options driver, filename, and locking for a node under another node’s “file” link. So this has to create two nodes. The node on top (for which no options are specified) should default to being a format node whose format is probed. + +Of course you can also give options to the top (format) node, like e.g. the driver. (In fact, you should probably give the driver, because format probing is considered dangerous.) + +Then it would look like this: driver=qcow2,file.driver=file,file.filename=foo.qcow2,file.locking=off + +(Or, in JSON, but that only works with qemu’s -blockdev (but I think it’s better for visualizing the resulting block graph: + {"node-name": "some-node-name", + "driver": "qcow2", + "file": { + "driver": "file", + "filename": "foo.qcow2", + "locking": false + } }) + + +Hope that helps, + +Max + diff --git a/results/classifier/zero-shot/108/all/1865099 b/results/classifier/zero-shot/108/all/1865099 new file mode 100644 index 000000000..2fe39323d --- /dev/null +++ b/results/classifier/zero-shot/108/all/1865099 @@ -0,0 +1,588 @@ +other: 0.983 +graphic: 0.981 +semantic: 0.980 +debug: 0.969 +files: 0.953 +permissions: 0.948 +boot: 0.937 +performance: 0.934 +device: 0.934 +vnc: 0.930 +KVM: 0.930 +PID: 0.929 +network: 0.925 +socket: 0.920 + +cannot run x64 based system on x64 host with Intel Haxm + +i am trying to run Windows 10 x64 on Windows 10 x64 host with intel haxm as kernel accelerator, but the system never boots, as far i read the documentation everything should be fine... + +the logs are qemu: + + +` +D:\vm>qemu-system-x86_64 -d guest_errors,out_asm,in_asm,op,op_opt,op_ind,int,exec,cpu,fpu,mmu,pcall,cpu_reset,unimp,page,nochain -cpu core2duo -smp 4 -accel hax -drive file=w10.img,index=0,media=disk,format=raw -cdrom "E:\test\W10x64ProEn-UK.iso" -m 4G -L Bios -usbdevice mouse -usbdevice keyboard -boot menu=on -rtc base=localtime,clock=host -name windows +qemu-system-x86_64: -usbdevice mouse: '-usbdevice' is deprecated, please use '-device usb-...' instead +qemu-system-x86_64: -usbdevice keyboard: '-usbdevice' is deprecated, please use '-device usb-...' instead +HAX is working and emulator runs in fast virt mode. +CPU Reset (CPU 0) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=00000000 EFL=00000000 [-------] CPL=0 II=0 A20=0 SMM=0 HLT=0 +ES =0000 00000000 00000000 00000000 +CS =0000 00000000 00000000 00000000 +SS =0000 00000000 00000000 00000000 +DS =0000 00000000 00000000 00000000 +FS =0000 00000000 00000000 00000000 +GS =0000 00000000 00000000 00000000 +LDT=0000 00000000 00000000 00000000 +TR =0000 00000000 00000000 00000000 +GDT= 00000000 00000000 +IDT= 00000000 00000000 +CR0=00000000 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=0000000000000000 DR7=0000000000000000 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=0000 FSW=0000 [ST=0] FTW=ff MXCSR=00000000 +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 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 1) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=00000000 EFL=00000000 [-------] CPL=0 II=0 A20=0 SMM=0 HLT=0 +ES =0000 00000000 00000000 00000000 +CS =0000 00000000 00000000 00000000 +SS =0000 00000000 00000000 00000000 +DS =0000 00000000 00000000 00000000 +FS =0000 00000000 00000000 00000000 +GS =0000 00000000 00000000 00000000 +LDT=0000 00000000 00000000 00000000 +TR =0000 00000000 00000000 00000000 +GDT= 00000000 00000000 +IDT= 00000000 00000000 +CR0=00000000 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=0000000000000000 DR7=0000000000000000 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=0000 FSW=0000 [ST=0] FTW=ff MXCSR=00000000 +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 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 2) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=00000000 EFL=00000000 [-------] CPL=0 II=0 A20=0 SMM=0 HLT=0 +ES =0000 00000000 00000000 00000000 +CS =0000 00000000 00000000 00000000 +SS =0000 00000000 00000000 00000000 +DS =0000 00000000 00000000 00000000 +FS =0000 00000000 00000000 00000000 +GS =0000 00000000 00000000 00000000 +LDT=0000 00000000 00000000 00000000 +TR =0000 00000000 00000000 00000000 +GDT= 00000000 00000000 +IDT= 00000000 00000000 +CR0=00000000 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=0000000000000000 DR7=0000000000000000 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=0000 FSW=0000 [ST=0] FTW=ff MXCSR=00000000 +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 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 3) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=00000000 EFL=00000000 [-------] CPL=0 II=0 A20=0 SMM=0 HLT=0 +ES =0000 00000000 00000000 00000000 +CS =0000 00000000 00000000 00000000 +SS =0000 00000000 00000000 00000000 +DS =0000 00000000 00000000 00000000 +FS =0000 00000000 00000000 00000000 +GS =0000 00000000 00000000 00000000 +LDT=0000 00000000 00000000 00000000 +TR =0000 00000000 00000000 00000000 +GDT= 00000000 00000000 +IDT= 00000000 00000000 +CR0=00000000 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=0000000000000000 DR7=0000000000000000 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +EFER=0000000000000000 +FCW=0000 FSW=0000 [ST=0] FTW=ff MXCSR=00000000 +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 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 0) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +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 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 1) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +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 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 2) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +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 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 3) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +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 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 1) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +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 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 2) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +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 +CR0 update: CR0=0x60000010 +CPU Reset (CPU 3) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006fb +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=00000000 CCD=00000000 CCO=DYNAMIC +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 +CR0 update: CR0=0x60000010 +VCPU shutdown request +VCPU shutdown request +VCPU shutdown request +` + + +intel haxm (kernel logs): + + +`haxm_warning: Ignored guest CR8 write, val=0x0 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored guest CR8 write, val=0x2 +haxm_warning: Ignored guest CR8 write, val=0x0 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored guest CR8 write, val=0x2 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored guest CR8 write, val=0x2 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored guest CR8 write, val=0xf +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored unsupported CR8 read, returning 0 +haxm_warning: Ignored guest CR8 write, val=0x2 +haxm_warning: Ignored guest CR8 write, val=0x0 +haxm_panic: Triple fault +haxm_warning: 4000 VMX_PIN_CONTROLS: 1f +haxm_warning: 4002 VMX_PRIMARY_PROCESSOR_CONTROLS: 969861fe +haxm_warning: 401e VMX_SECONDARY_PROCESSOR_CONTROLS: aa +haxm_warning: 4004 VMX_EXCEPTION_BITMAP: 40000 +haxm_warning: 4006 VMX_PAGE_FAULT_ERROR_CODE_MASK: 0 +haxm_warning: 4008 VMX_PAGE_FAULT_ERROR_CODE_MATCH: 0 +haxm_warning: 400c VMX_EXIT_CONTROLS: 236fff +haxm_warning: 400e VMX_EXIT_MSR_STORE_COUNT: 0 +haxm_warning: 4010 VMX_EXIT_MSR_LOAD_COUNT: 0 +haxm_warning: 4012 VMX_ENTRY_CONTROLS: 93ff +haxm_warning: 4014 VMX_ENTRY_MSR_LOAD_COUNT: 0 +haxm_warning: 4016 VMX_ENTRY_INTERRUPT_INFO: 8 +haxm_warning: 4018 VMX_ENTRY_EXCEPTION_ERROR_CODE: 0 +haxm_warning: 401a VMX_ENTRY_INSTRUCTION_LENGTH: 0 +haxm_warning: 401c VMX_TPR_THRESHOLD: 0 +haxm_warning: 6000 VMX_CR0_MASK: ffffffffe0000020 +haxm_warning: 6002 VMX_CR4_MASK: ffffffffffc8f860 +haxm_warning: 6004 VMX_CR0_READ_SHADOW: 80050031 +haxm_warning: 6006 VMX_CR4_READ_SHADOW: 6a0 +haxm_warning: 400a VMX_CR3_TARGET_COUNT: 0 +haxm_warning: 6008 VMX_CR3_TARGET_VAL_BASE: 0 +haxm_warning: 0000 VMX_VPID: 1 +haxm_warning: 2000 VMX_IO_BITMAP_A: 26e7b9000 +haxm_warning: 2002 VMX_IO_BITMAP_B: 26e7b7000 +haxm_warning: 2004 VMX_MSR_BITMAP: 26e7b6000 +haxm_warning: 2006 VMX_EXIT_MSR_STORE_ADDRESS: 0 +haxm_warning: 2008 VMX_EXIT_MSR_LOAD_ADDRESS: 0 +haxm_warning: 200a VMX_ENTRY_MSR_LOAD_ADDRESS: 0 +haxm_warning: 2010 VMX_TSC_OFFSET: fff957a04c01d76b +haxm_warning: 2012 VMX_VAPIC_PAGE: 0 +haxm_warning: 2014 VMX_APIC_ACCESS_PAGE: 0 +haxm_warning: 201a VMX_EPTP: 1fb1f001e +haxm_warning: 482e VMX_PREEMPTION_TIMER: 0 +haxm_warning: 4400 VMX_INSTRUCTION_ERROR_CODE: 0 +haxm_warning: 4402 VM_EXIT_INFO_REASON: 2 +haxm_warning: 4404 VM_EXIT_INFO_INTERRUPT_INFO: 0 +haxm_warning: 4406 VM_EXIT_INFO_EXCEPTION_ERROR_CODE: 0 +haxm_warning: 4408 VM_EXIT_INFO_IDT_VECTORING: 0 +haxm_warning: 440a VM_EXIT_INFO_IDT_VECTORING_ERROR_CODE: 0 +haxm_warning: 440c VM_EXIT_INFO_INSTRUCTION_LENGTH: 1 +haxm_warning: 440e VM_EXIT_INFO_INSTRUCTION_INFO: 0 +haxm_warning: 6400 VM_EXIT_INFO_QUALIFICATION: 0 +haxm_warning: 6402 VM_EXIT_INFO_IO_ECX: 60 +haxm_warning: 6404 VM_EXIT_INFO_IO_ESI: 1 +haxm_warning: 6406 VM_EXIT_INFO_IO_EDI: 1 +haxm_warning: 6408 VM_EXIT_INFO_IO_EIP: 191f405c +haxm_warning: 640a VM_EXIT_INFO_GUEST_LINEAR_ADDRESS: 0 +haxm_warning: 2400 VM_EXIT_INFO_GUEST_PHYSICAL_ADDRESS: 1ea07ff0 +haxm_warning: 6c16 HOST_RIP: fffff80602e01a73 +haxm_warning: 6c14 HOST_RSP: ffff9b0aae6b74e0 +haxm_warning: 6c00 HOST_CR0: 80050033 +haxm_warning: 6c02 HOST_CR3: 12f527002 +haxm_warning: 6c04 HOST_CR4: 372678 +haxm_warning: 0c02 HOST_CS_SELECTOR: 10 +haxm_warning: 0c06 HOST_DS_SELECTOR: 28 +haxm_warning: 0c00 HOST_ES_SELECTOR: 28 +haxm_warning: 0c08 HOST_FS_SELECTOR: 0 +haxm_warning: 0c0a HOST_GS_SELECTOR: 0 +haxm_warning: 0c04 HOST_SS_SELECTOR: 18 +haxm_warning: 0c0c HOST_TR_SELECTOR: 40 +haxm_warning: 6c06 HOST_FS_BASE: 0 +haxm_warning: 6c08 HOST_GS_BASE: ffffad001d939000 +haxm_warning: 6c0a HOST_TR_BASE: ffffad001d5f7000 +haxm_warning: 6c0c HOST_GDTR_BASE: ffffad001d5f8fb0 +haxm_warning: 6c0e HOST_IDTR_BASE: ffffad001d5f6000 +haxm_warning: 4c00 HOST_SYSENTER_CS: 0 +haxm_warning: 6c10 HOST_SYSENTER_ESP: 0 +haxm_warning: 6c12 HOST_SYSENTER_EIP: 0 +haxm_warning: 681e GUEST_RIP: fffff807167c9370 +haxm_warning: 6820 GUEST_RFLAGS: 10082 +haxm_warning: 681c GUEST_RSP: fffff8071aa67708 +haxm_warning: 6800 GUEST_CR0: 80050031 +haxm_warning: 6802 GUEST_CR3: 1aa000 +haxm_warning: 6804 GUEST_CR4: 26e0 +haxm_warning: 0800 GUEST_ES_SELECTOR: 2b +haxm_warning: 0802 GUEST_CS_SELECTOR: 10 +haxm_warning: 0804 GUEST_SS_SELECTOR: 0 +haxm_warning: 0806 GUEST_DS_SELECTOR: 2b +haxm_warning: 0808 GUEST_FS_SELECTOR: 53 +haxm_warning: 080a GUEST_GS_SELECTOR: 2b +haxm_warning: 080c GUEST_LDTR_SELECTOR: 0 +haxm_warning: 080e GUEST_TR_SELECTOR: 40 +haxm_warning: 4814 GUEST_ES_AR: c0f3 +haxm_warning: 4816 GUEST_CS_AR: 209b +haxm_warning: 4818 GUEST_SS_AR: 1c000 +haxm_warning: 481a GUEST_DS_AR: c0f3 +haxm_warning: 481c GUEST_FS_AR: 40f3 +haxm_warning: 481e GUEST_GS_AR: c0f3 +haxm_warning: 4820 GUEST_LDTR_AR: 1c000 +haxm_warning: 4822 GUEST_TR_AR: 8b +haxm_warning: 6806 GUEST_ES_BASE: 0 +haxm_warning: 6808 GUEST_CS_BASE: 0 +haxm_warning: 680a GUEST_SS_BASE: 0 +haxm_warning: 680c GUEST_DS_BASE: 0 +haxm_warning: 680e GUEST_FS_BASE: 0 +haxm_warning: 6810 GUEST_GS_BASE: fffff807128d3000 +haxm_warning: 6812 GUEST_LDTR_BASE: 0 +haxm_warning: 6814 GUEST_TR_BASE: fffff8071aa5c000 +haxm_warning: 6816 GUEST_GDTR_BASE: fffff8071aa5dfb0 +haxm_warning: 6818 GUEST_IDTR_BASE: fffff8071aa5b000 +haxm_warning: 4800 GUEST_ES_LIMIT: ffffffff +haxm_warning: 4802 GUEST_CS_LIMIT: 0 +haxm_warning: 4804 GUEST_SS_LIMIT: ffffffff +haxm_warning: 4806 GUEST_DS_LIMIT: ffffffff +haxm_warning: 4808 GUEST_FS_LIMIT: 3c00 +haxm_warning: 480a GUEST_GS_LIMIT: ffffffff +haxm_warning: 480c GUEST_LDTR_LIMIT: ffffffff +haxm_warning: 480e GUEST_TR_LIMIT: 67 +haxm_warning: 4810 GUEST_GDTR_LIMIT: 57 +haxm_warning: 4812 GUEST_IDTR_LIMIT: fff +haxm_warning: 2800 GUEST_VMCS_LINK_PTR: ffffffffffffffff +haxm_warning: 2802 GUEST_DEBUGCTL: 0 +haxm_warning: 2804 GUEST_PAT: 0 +haxm_warning: 2806 GUEST_EFER: d01 +haxm_warning: 2808 GUEST_PERF_GLOBAL_CTRL: 0 +haxm_warning: 280a GUEST_PDPTE0: 3380050011 +haxm_warning: 280c GUEST_PDPTE1: 4000 +haxm_warning: 280e GUEST_PDPTE2: 3380050011 +haxm_warning: 2810 GUEST_PDPTE3: 3380050011 +haxm_warning: 681a GUEST_DR7: 400 +haxm_warning: 6822 GUEST_PENDING_DBE: 0 +haxm_warning: 482a GUEST_SYSENTER_CS: 0 +haxm_warning: 6824 GUEST_SYSENTER_ESP: 0 +haxm_warning: 6826 GUEST_SYSENTER_EIP: 0 +haxm_warning: 4828 GUEST_SMBASE: 0 +haxm_warning: 4824 GUEST_INTERRUPTIBILITY: 0 +haxm_warning: 4826 GUEST_ACTIVITY_STATE: 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: vcpu has panicked, id:0 +haxm_error: log_host_cr4_vmxe: 0 +haxm_error: log_host_cr4 0 +haxm_error: log_vmxon_res 0 +haxm_error: log_vmxon_addr 26e7ad000 +haxm_error: log_vmxon_err_type1 0 +haxm_error: log_vmxon_err_type2 0 +haxm_error: log_vmxon_err_type3 0 +haxm_error: log_vmclear_err 0 +haxm_error: log_vmptrld_err 0 +haxm_error: log_vmoff_no 0 +haxm_error: log_vmxoff_res 0 +haxm_error: ...........hax_teardown_vm +` + +The QEMU project is currently moving 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/zero-shot/108/all/1874073 b/results/classifier/zero-shot/108/all/1874073 new file mode 100644 index 000000000..9083f1f6d --- /dev/null +++ b/results/classifier/zero-shot/108/all/1874073 @@ -0,0 +1,324 @@ +debug: 0.981 +permissions: 0.981 +graphic: 0.980 +device: 0.979 +PID: 0.977 +files: 0.974 +performance: 0.973 +semantic: 0.972 +socket: 0.970 +other: 0.970 +network: 0.956 +KVM: 0.954 +boot: 0.950 +vnc: 0.944 + +openrisc_sim.c:87:42: error: 'cpu_irqs[0]' may be used uninitialized in this function [-Werror=maybe-uninitialized] + +I see the warning since gcc10: + +static void openrisc_sim_init(MachineState *machine): +... + qemu_irq *cpu_irqs[2]; +... + + + serial_mm_init(get_system_memory(), 0x90000000, 0, serial_irq, + 115200, serial_hd(0), DEVICE_NATIVE_ENDIAN); + +I would initialize cpu_irqs[2] with {}. + +Suggested patch: + +diff --git a/hw/openrisc/openrisc_sim.c b/hw/openrisc/openrisc_sim.c +index 79e7049..724dcd0 100644 +--- a/hw/openrisc/openrisc_sim.c ++++ b/hw/openrisc/openrisc_sim.c +@@ -129,7 +129,7 @@ static void openrisc_sim_init(MachineState *machine) + const char *kernel_filename = machine->kernel_filename; + OpenRISCCPU *cpu = NULL; + MemoryRegion *ram; +- qemu_irq *cpu_irqs[2]; ++ qemu_irq *cpu_irqs[2] = {}; + qemu_irq serial_irq; + int n; + unsigned int smp_cpus = machine->smp.cpus; + +I'm not sure why the compiler thinks it might be uninitialized here -- is it just that it's not aware that smp_cpus can't be zero and so the loop will always initialize cpu_irqs[0] ? + + +Note that our -Wmaybe-uninitialized warnings tends to report false positives. We have a rich meta bug for it: +https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 + +That's why it can't prove the variable is initialized in all possible execution paths. + +Does adding "assert(smp_cpus >= 1 && smp_cpus <= 2);" after the assignment to smp_cpus give the compiler enough information to know there's no use of uninitialized data? + + +Confirming Peter's suggestion does silent the warning. + +-- >8 -- +diff --git a/hw/openrisc/openrisc_sim.c b/hw/openrisc/openrisc_sim.c +index d08ce61811..02f5259e5e 100644 +--- a/hw/openrisc/openrisc_sim.c ++++ b/hw/openrisc/openrisc_sim.c +@@ -134,6 +134,7 @@ static void openrisc_sim_init(MachineState *machine) + int n; + unsigned int smp_cpus = machine->smp.cpus; + ++ assert(smp_cpus >= 1 && smp_cpus <= 2); + for (n = 0; n < smp_cpus; n++) { + cpu = OPENRISC_CPU(cpu_create(machine->cpu_type)); + if (cpu == NULL) { +--- + +On 5/26/20 8:51 PM, Eric Blake wrote: +> On my Fedora 32 machine, gcc 10.1.1 at -O2 (the default for a bare +> './configure') has a false-positive complaint: +> +> CC or1k-softmmu/hw/openrisc/openrisc_sim.o +> /home/eblake/qemu/hw/openrisc/openrisc_sim.c: In function ‘openrisc_sim_init’: +> /home/eblake/qemu/hw/openrisc/openrisc_sim.c:87:42: error: ‘cpu_irqs[0]’ may be used uninitialized in this function [-Werror=maybe-uninitialized] +> 87 | sysbus_connect_irq(s, i, cpu_irqs[i][irq_pin]); +> | ~~~~~~~~^~~ +> +> Initializing both pointers of cpu_irqs[] to NULL is sufficient to shut +> up the compiler, even though they are definitely assigned in +> openrisc_sim_init() prior to the inlined call to +> openrisc_sim_ompic_init() containing the line in question. +> +> Signed-off-by: Eric Blake <email address hidden> +> --- +> hw/openrisc/openrisc_sim.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/hw/openrisc/openrisc_sim.c b/hw/openrisc/openrisc_sim.c +> index d08ce6181199..95011a8015b4 100644 +> --- a/hw/openrisc/openrisc_sim.c +> +++ b/hw/openrisc/openrisc_sim.c +> @@ -129,7 +129,7 @@ static void openrisc_sim_init(MachineState *machine) +> const char *kernel_filename = machine->kernel_filename; +> OpenRISCCPU *cpu = NULL; +> MemoryRegion *ram; +> - qemu_irq *cpu_irqs[2]; +> + qemu_irq *cpu_irqs[2] = {}; + +Ah I now remembered why this warning sound familiar: +https://bugs.launchpad.net/qemu/+bug/1874073 + +Peter suggested a different fix, I tested it, and was expecting Martin +Liska to post an updated patch. + +> qemu_irq serial_irq; +> int n; +> unsigned int smp_cpus = machine->smp.cpus; +> + + + +Hello. The assert approach is preferred. + +When compiling with GCC 10 (Fedora 32) using CFLAGS=-O2 we get: + + CC or1k-softmmu/hw/openrisc/openrisc_sim.o + hw/openrisc/openrisc_sim.c: In function ‘openrisc_sim_init’: + hw/openrisc/openrisc_sim.c:87:42: error: ‘cpu_irqs[0]’ may be used uninitialized in this function [-Werror=maybe-uninitialized] + 87 | sysbus_connect_irq(s, i, cpu_irqs[i][irq_pin]); + | ~~~~~~~~^~~ + +While humans can tell smp_cpus will always be in the [1, 2] range, +(openrisc_sim_machine_init sets mc->max_cpus = 2), the compiler +can't. + +Add an assertion to give the compiler a hint there's no use of +uninitialized data. + +Buglink: https://bugs.launchpad.net/qemu/+bug/1874073 +Reported-by: Martin Liška <email address hidden> +Suggested-by: Peter Maydell <email address hidden> +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- + hw/openrisc/openrisc_sim.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/hw/openrisc/openrisc_sim.c b/hw/openrisc/openrisc_sim.c +index d08ce61811..02f5259e5e 100644 +--- a/hw/openrisc/openrisc_sim.c ++++ b/hw/openrisc/openrisc_sim.c +@@ -134,6 +134,7 @@ static void openrisc_sim_init(MachineState *machine) + int n; + unsigned int smp_cpus = machine->smp.cpus; + ++ assert(smp_cpus >= 1 && smp_cpus <= 2); + for (n = 0; n < smp_cpus; n++) { + cpu = OPENRISC_CPU(cpu_create(machine->cpu_type)); + if (cpu == NULL) { +-- +2.21.3 + + + +On 6/8/20 2:14 AM, Philippe Mathieu-Daudé wrote: +> When compiling with GCC 10 (Fedora 32) using CFLAGS=-O2 we get: + +In the subject: s/silent/silence/ + +> +> CC or1k-softmmu/hw/openrisc/openrisc_sim.o +> hw/openrisc/openrisc_sim.c: In function ‘openrisc_sim_init’: +> hw/openrisc/openrisc_sim.c:87:42: error: ‘cpu_irqs[0]’ may be used uninitialized in this function [-Werror=maybe-uninitialized] +> 87 | sysbus_connect_irq(s, i, cpu_irqs[i][irq_pin]); +> | ~~~~~~~~^~~ +> +> While humans can tell smp_cpus will always be in the [1, 2] range, +> (openrisc_sim_machine_init sets mc->max_cpus = 2), the compiler +> can't. +> +> Add an assertion to give the compiler a hint there's no use of +> uninitialized data. +> +> Buglink: https://bugs.launchpad.net/qemu/+bug/1874073 +> Reported-by: Martin Liška <email address hidden> +> Suggested-by: Peter Maydell <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> hw/openrisc/openrisc_sim.c | 1 + +> 1 file changed, 1 insertion(+) + +Tested-by: Eric Blake <email address hidden> + +With the typo fixed, +Reviewed-by: Eric Blake <email address hidden> + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + + +When compiling with GCC 10 (Fedora 32) using CFLAGS=-O2 we get: + + CC or1k-softmmu/hw/openrisc/openrisc_sim.o + hw/openrisc/openrisc_sim.c: In function ‘openrisc_sim_init’: + hw/openrisc/openrisc_sim.c:87:42: error: ‘cpu_irqs[0]’ may be used uninitialized in this function [-Werror=maybe-uninitialized] + 87 | sysbus_connect_irq(s, i, cpu_irqs[i][irq_pin]); + | ~~~~~~~~^~~ + +While humans can tell smp_cpus will always be in the [1, 2] range, +(openrisc_sim_machine_init sets mc->max_cpus = 2), the compiler +can't. + +Add an assertion to give the compiler a hint there's no use of +uninitialized data. + +Buglink: https://bugs.launchpad.net/qemu/+bug/1874073 +Reported-by: Martin Liška <email address hidden> +Suggested-by: Peter Maydell <email address hidden> +Reviewed-by: Thomas Huth <email address hidden> +Tested-by: Eric Blake <email address hidden> +Reviewed-by: Eric Blake <email address hidden> +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- +v2: Fixed typo in subject (eblake) +Supersedes: <email address hidden> +--- + hw/openrisc/openrisc_sim.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/hw/openrisc/openrisc_sim.c b/hw/openrisc/openrisc_sim.c +index d08ce61811..02f5259e5e 100644 +--- a/hw/openrisc/openrisc_sim.c ++++ b/hw/openrisc/openrisc_sim.c +@@ -134,6 +134,7 @@ static void openrisc_sim_init(MachineState *machine) + int n; + unsigned int smp_cpus = machine->smp.cpus; + ++ assert(smp_cpus >= 1 && smp_cpus <= 2); + for (n = 0; n < smp_cpus; n++) { + cpu = OPENRISC_CPU(cpu_create(machine->cpu_type)); + if (cpu == NULL) { +-- +2.21.3 + + + +Le 08/06/2020 à 18:06, Philippe Mathieu-Daudé a écrit : +> When compiling with GCC 10 (Fedora 32) using CFLAGS=-O2 we get: +> +> CC or1k-softmmu/hw/openrisc/openrisc_sim.o +> hw/openrisc/openrisc_sim.c: In function ‘openrisc_sim_init’: +> hw/openrisc/openrisc_sim.c:87:42: error: ‘cpu_irqs[0]’ may be used uninitialized in this function [-Werror=maybe-uninitialized] +> 87 | sysbus_connect_irq(s, i, cpu_irqs[i][irq_pin]); +> | ~~~~~~~~^~~ +> +> While humans can tell smp_cpus will always be in the [1, 2] range, +> (openrisc_sim_machine_init sets mc->max_cpus = 2), the compiler +> can't. +> +> Add an assertion to give the compiler a hint there's no use of +> uninitialized data. +> +> Buglink: https://bugs.launchpad.net/qemu/+bug/1874073 +> Reported-by: Martin Liška <email address hidden> +> Suggested-by: Peter Maydell <email address hidden> +> Reviewed-by: Thomas Huth <email address hidden> +> Tested-by: Eric Blake <email address hidden> +> Reviewed-by: Eric Blake <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> v2: Fixed typo in subject (eblake) +> Supersedes: <email address hidden> +> --- +> hw/openrisc/openrisc_sim.c | 1 + +> 1 file changed, 1 insertion(+) +> +> diff --git a/hw/openrisc/openrisc_sim.c b/hw/openrisc/openrisc_sim.c +> index d08ce61811..02f5259e5e 100644 +> --- a/hw/openrisc/openrisc_sim.c +> +++ b/hw/openrisc/openrisc_sim.c +> @@ -134,6 +134,7 @@ static void openrisc_sim_init(MachineState *machine) +> int n; +> unsigned int smp_cpus = machine->smp.cpus; +> +> + assert(smp_cpus >= 1 && smp_cpus <= 2); +> for (n = 0; n < smp_cpus; n++) { +> cpu = OPENRISC_CPU(cpu_create(machine->cpu_type)); +> if (cpu == NULL) { +> + +Applied to my trivial-patches branch. + +Thanks, +Laurent + + + +On 6/9/20 3:42 PM, Stafford Horne wrote: + +>>> While humans can tell smp_cpus will always be in the [1, 2] range, +>>> (openrisc_sim_machine_init sets mc->max_cpus = 2), the compiler +>>> can't. +>>> +>>> Add an assertion to give the compiler a hint there's no use of +>>> uninitialized data. +>>> + +> Acked-by: Stafford Horne <email address hidden> +> +> I see there are now two patches for this, I kind of like this assert fix. +> +> Shall I queue it for OpenRISC pulling? Or can someone else pick this up? + +Looks like Laurent already volunteered to queue it through the trivial +patches tree. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + + +Merged in commit 1db889c71f37d5bad411b2ef83a69739d9d598f9. + diff --git a/results/classifier/zero-shot/108/all/1874264 b/results/classifier/zero-shot/108/all/1874264 new file mode 100644 index 000000000..aea74bba1 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1874264 @@ -0,0 +1,425 @@ +permissions: 0.991 +semantic: 0.986 +performance: 0.984 +debug: 0.982 +boot: 0.982 +device: 0.982 +graphic: 0.981 +other: 0.980 +PID: 0.980 +network: 0.977 +socket: 0.973 +files: 0.972 +vnc: 0.971 +KVM: 0.964 + +AIX 7.2 TL4 SP1 cannot IPL with QEMU >2.11.2 ppc64-softmmu + +kens@LAPTOP-JN77KAC2$ qemu-system-ppc64 -version +QEMU emulator version 4.2.93 (v5.0.0-rc3-8-g3119154db0-dirty) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +qemu-system-ppc64 \ + -name "IBM AIX - IBM POWER9" \ + -M pseries \ + -cpu POWER9 \ + -smp 8 \ + -m 8192 \ + -nodefaults \ + -nographic \ + -prom-env input-device=/vdevice/vty@71000000 \ + -prom-env output-device=/vdevice/vty@71000000 \ + -serial tcp::9019,server,nowait \ + -monitor tcp::9020,server,nowait \ + -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9018-10.0.2.18:22 \ + -device virtio-net-pci,netdev=mynet0 \ + -drive file=images/aix-ppc64.img,format=qcow2,if=none,id=hd,media=disk,cache=unsafe \ + -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \ + -drive file=images/iso/blank-cdrom,format=raw,media=cdrom,cache=unsafe + +------------------------------------------------------------------------------- + Welcome to AIX. + boot image timestamp: 14:18:40 03/27/2020 + processor count: 8; memory size: 8192MB; kernel size: 45422205 + boot device: /pci@800000020000000/scsi@1/disk@100000000000000 + AIX vm,uuid property contains invalid data +processing splpar characteristic: MaxEntCap +processing splpar characteristic: DesMem +processing splpar characteristic: DesProcs +processing splpar characteristic: MaxPlatProcs +processing splpar characteristic: HostThrs + +AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot argument +------------------------------------------------------------------------------- + Starqemu-system-ppc64: OS terminated: 888 102 700 C20 + + +qemu-system-ppc64 \ + -name "IBM AIX - IBM POWER8" \ + -M pseries \ + -cpu POWER8 \ + -smp 8 \ + -m 8192 \ + -nodefaults \ + -nographic \ + -prom-env input-device=/vdevice/vty@71000000 \ + -prom-env output-device=/vdevice/vty@71000000 \ + -serial tcp::9019,server,nowait \ + -monitor tcp::9020,server,nowait \ + -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9018-10.0.2.18:22 \ + -device virtio-net-pci,netdev=mynet0 \ + -drive file=images/aix-ppc64.img,format=qcow2,if=none,id=hd,media=disk,cache=unsafe \ + -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \ + -drive file=images/iso/blank-cdrom,format=raw,media=cdrom,cache=unsafe + +------------------------------------------------------------------------------- + Welcome to AIX. + boot image timestamp: 14:18:40 03/27/2020 + processor count: 8; memory size: 8192MB; kernel size: 45422205 + boot device: /pci@800000020000000/scsi@1/disk@100000000000000 + AIX vm,uuid property contains invalid data +processing splpar characteristic: MaxEntCap +processing splpar characteristic: DesMem +processing splpar characteristic: DesProcs +processing splpar characteristic: MaxPlatProcs +processing splpar characteristic: HostThrs + +AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot argument +------------------------------------------------------------------------------- + Star** +ERROR:/home/kens/tmp/qemu/cpus.c:1727:qemu_tcg_cpu_thread_fn: assertion failed: (cpu->halted) + + +kens@LAPTOP-JN77KAC2$ qemu-system-ppc64 -version +QEMU emulator version 2.11.2 +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +qemu-system-ppc64 \ + -name "IBM AIX - IBM POWER9" \ + -M pseries,cap-htm=off \ + -cpu POWER9 \ + -smp 8 \ + -m 8192 \ + -nodefaults \ + -nographic \ + -prom-env input-device=/vdevice/vty@71000000 \ + -prom-env output-device=/vdevice/vty@71000000 \ + -serial tcp::9019,server,nowait \ + -monitor tcp::9020,server,nowait \ + -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9018-10.0.2.18:22 \ + -device virtio-net-pci,netdev=mynet0 \ + -drive file=images/aix-ppc64.img,format=qcow2,if=none,id=hd,media=disk,cache=unsafe \ + -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \ + -drive file=images/iso/blank-cdrom,format=raw,media=cdrom,cache=unsafe + +------------------------------------------------------------------------------- + Welcome to AIX. + boot image timestamp: 14:18:40 03/27/2020 + processor count: 8; memory size: 8192MB; kernel size: 45422205 + boot device: /pci@800000020000000/scsi@1/disk@100000000000000 + AIX vm,uuid property contains invalid data +processing splpar characteristic: MaxEntCap +processing splpar characteristic: DesMem +processing splpar characteristic: DesProcs +processing splpar characteristic: MaxPlatProcs + +AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot argument +------------------------------------------------------------------------------- + Star +0539 +0811 +0539 +0812 +0708 +0811 +0811 +0811 +0811 +0811 +0811 +0811 +0811 +078c +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +078c +0539 +2071 +0539 +2073 +0539 +25b3vscsi_send_capabilities: capabilities size mismatch ! +VSCSI: Unknown MAD type 09 + +0539 +0538 +0539 +0591 +0539 +0538 +0539 +0538 +0539 +25b0 +0539 + +0511 +0551 +0517 +0517 +0517 +0517 +0553 +0517 +0517 +0538 +0539 +0538 +0539 +270b +0539 +0538 +0539 +2070 +0539 +0538 +0539 +0811 +0539 +0811 +0539 +0812 +0708 +0811 +0811 +0811 +0811 +0811 +0811 +0811 +0811 +078c +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +25b6 +078c +04ee +078c +0727 +0727 +2071 +2072 +2072 +2071 +0539 +25b3 +0539 +25b5 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0581 +0539 +0538 +0539 +7000 +0539 +0538 +0539 +0538 +0539 +0538 +0581 +0581 +0539 +0538 +0539 +25b0 +0539 +0538 +0539 +0538 +0539 +0731 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +0538 +0539 +2028 +0539 +0538 +0539 + +0c33 +Saving Base Customize Data to boot disk +Starting the sync daemon +Starting the error daemon + +System initialization completed. +TE=OFF +CHKEXEC=OFF +CHKSHLIB=OFF +CHKSCRIPT=OFF +CHKKERNEXT=OFF +STOP_UNTRUSTD=OFF +STOP_ON_CHKFAIL=OFF +LOCK_KERN_POLICIES=OFF +TSD_FILES_LOCK=OFF +TSD_LOCK=OFF +TEP=OFF +TLP=OFF +Successfully updated the Kernel Authorization Table. +Successfully updated the Kernel Role Table. +Successfully updated the Kernel Command Table. +Successfully updated the Kernel Device Table. +Successfully updated the Kernel Object Domain Table. +Successfully updated the Kernel Domains Table. +Successfully updated the Kernel RBAC log level. +Successfully updated the Kernel RBAC log level. +OPERATIONAL MODE Security Flags +ROOT : ENABLED +TRACEAUTH : DISABLED +System runtime mode is now OPERATIONAL MODE. +Setting tunable parameters...complete +Checking for srcmstr active...complete +Starting tcpip daemons: +0513-059 The sendmail Subsystem has been started. Subsystem PID is 4456846. +0513-059 The syslogd Subsystem has been started. Subsystem PID is 4522382. +0513-059 The portmap Subsystem has been started. Subsystem PID is 4194776. +0513-059 The inetd Subsystem has been started. Subsystem PID is 4129230. +0513-059 The snmpmibd Subsystem has been started. Subsystem PID is 4325672. +Finished starting tcpip daemons. + + +AIX Version 7 +Copyright IBM Corporation, 1982, 2019. +Console login: root +root's Password: + +******************************************************************************* +* * +* * +* Welcome to AIX Version 7.2! * +* * +* * +* Please see the README file in /usr/lpp/bos for information pertinent to * +* this release of the AIX Operating System. * +* * +* * +******************************************************************************* +Last login: Wed Apr 22 07:21:19 EDT 2020 on /dev/vty0 + +root@aix-ppc64# oslevel -s +7200-04-01-1939 +root@aix-ppc64# + +Did this ever work before? AFAIK AIX was never really running on QEMU... + +Hi, Thomas. Yes! Of course I had it working beautifully before, with only a minor issue executing a small number of XCOFF binaries, that is why I specified the QEMU version (2.11.2) AIX last worked with in the title of this bug. + +Check it out: + +kens@LAPTOP-JN77KAC2$ qemu-system-ppc64 -version +QEMU emulator version 2.11.2 +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +kens@LAPTOP-JN77KAC2$ ssh -p9018 localhost +Last login: Thu May 6 10:06:55 EDT 2021 on ssh from 10.0.2.2 +******************************************************************************* +* * +* * +* Welcome to AIX Version 7.2! * +* * +* * +* Please see the README file in /usr/lpp/bos for information pertinent to * +* this release of the AIX Operating System. * +* * +* * +******************************************************************************* +kens@aix-ppc64$ lsattr -El sys0 -a modelname +modelname IBM pSeries (emulated by qemu) Machine name False + +kens@aix-ppc64$ lsattr -El proc0 +frequency 1000000000 Processor Speed False +smt_enabled false Processor SMT enabled False +smt_threads 1 Processor SMT threads False +state enable Processor state False +type PowerPC_POWER9 Processor type False + + + +Pretty cool, right? + +Something changed after 2.11.2 that broke something in the tcg cpu execution emulation. + +This is the error I get when I try to boot AIX in any QEMU version > 2.11.2: + +ERROR:/home/kens/tmp/qemu/cpus.c:1727:qemu_tcg_cpu_thread_fn: assertion failed: (cpu->halted) + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/269 + + diff --git a/results/classifier/zero-shot/108/all/1877015 b/results/classifier/zero-shot/108/all/1877015 new file mode 100644 index 000000000..a9edeec20 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1877015 @@ -0,0 +1,194 @@ +semantic: 0.998 +permissions: 0.998 +socket: 0.998 +PID: 0.998 +debug: 0.998 +graphic: 0.997 +other: 0.997 +device: 0.997 +files: 0.997 +performance: 0.997 +vnc: 0.997 +network: 0.996 +boot: 0.996 +KVM: 0.992 + +virtio only support packed ring size power of 2 + +Issue discription： +When QEMU starts with "-device virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,rx_queue_size=1025,tx_queue_size=1025,mq=on,vectors=15,packed=on" + +It raises error: Invalid rx_queue_size (= 1025), must be a power of 2 between 256 and 1024 + +Analysis: +According to virtio1.1 spec, the packed queue size value does not have to be a power of 2. + +Maybe the virtio need to be revised? + +On Wed, May 6, 2020 at 10:51 AM xuan <email address hidden> wrote: + +> Public bug reported: +> +> Issue discription： +> When QEMU starts with "-device +> virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,rx_queue_size=1025,tx_queue_size=1025,mq=on,vectors=15,packed=on" +> +> It raises error: Invalid rx_queue_size (= 1025), must be a power of 2 +> between 256 and 1024 +> +> Analysis: +> According to virtio1.1 spec, the packed queue size value does not have to +> be a power of 2. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1877015 +> +> Title: +> virtio only support packed ring size power of 2 between 256 and 1024 +> +> Status in QEMU: +> New +> +> Bug description: +> Issue discription： +> When QEMU starts with "-device +> virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,rx_queue_size=1025,tx_queue_size=1025,mq=on,vectors=15,packed=on" +> +> It raises error: Invalid rx_queue_size (= 1025), must be a power of 2 +> between 256 and 1024 +> +> Analysis: +> According to virtio1.1 spec, the packed queue size value does not have +> to be a power of 2. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1877015/+subscriptions +> +> + +-- + 此致 +礼 +罗勇刚 +Yours + sincerely, +Yonggang Luo + + +Thank you for your reply. I think the code should add the handling for packed ring size to follow the spec. + +Thank you for your reply. I think the code should add the handling for packed ring size to follow the spec. + +-----Original Message----- +From: <email address hidden> <email address hidden> On Behalf Of Yonggang Luo +Sent: Wednesday, May 6, 2020 12:32 PM +To: Ding, Xuan <email address hidden> +Subject: Re: [Bug 1877015] [NEW] virtio only support packed ring size power of 2 between 256 and 1024 + +Maybe the virtio need to be revised? + +On Wed, May 6, 2020 at 10:51 AM xuan <email address hidden> wrote: + +> Public bug reported: +> +> Issue discription： +> When QEMU starts with "-device +> virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,rx_queue_size=1025,tx_queue_size=1025,mq=on,vectors=15,packed=on" +> +> It raises error: Invalid rx_queue_size (= 1025), must be a power of 2 +> between 256 and 1024 +> +> Analysis: +> According to virtio1.1 spec, the packed queue size value does not have +> to be a power of 2. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1877015 +> +> Title: +> virtio only support packed ring size power of 2 between 256 and 1024 +> +> Status in QEMU: +> New +> +> Bug description: +> Issue discription： +> When QEMU starts with "-device +> virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,rx_queue_size=1025,tx_queue_size=1025,mq=on,vectors=15,packed=on" +> +> It raises error: Invalid rx_queue_size (= 1025), must be a power of 2 +> between 256 and 1024 +> +> Analysis: +> According to virtio1.1 spec, the packed queue size value does not +> have to be a power of 2. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1877015/+subscriptions +> +> + +-- + 此致 +礼 +罗勇刚 +Yours + sincerely, +Yonggang Luo + +-- +You received this bug notification because you are subscribed to the bug report. +https://bugs.launchpad.net/bugs/1877015 + +Title: + virtio only support packed ring size power of 2 + +Status in QEMU: + New + +Bug description: + Issue discription： + When QEMU starts with "-device virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,rx_queue_size=1025,tx_queue_size=1025,mq=on,vectors=15,packed=on" + + It raises error: Invalid rx_queue_size (= 1025), must be a power of 2 + between 256 and 1024 + + Analysis: + According to virtio1.1 spec, the packed queue size value does not have to be a power of 2. + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1877015/+subscriptions + + +The QEMU project is currently moving 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. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/270 + + diff --git a/results/classifier/zero-shot/108/all/1879587 b/results/classifier/zero-shot/108/all/1879587 new file mode 100644 index 000000000..716d3a7ee --- /dev/null +++ b/results/classifier/zero-shot/108/all/1879587 @@ -0,0 +1,115 @@ +debug: 0.990 +permissions: 0.987 +semantic: 0.985 +performance: 0.984 +other: 0.982 +graphic: 0.982 +device: 0.980 +socket: 0.976 +PID: 0.975 +vnc: 0.968 +boot: 0.964 +files: 0.956 +network: 0.950 +KVM: 0.940 + +Register number in ESR is incorrect for certain banked registers when switching from AA32 to AA64 + +I am running into a situation where I have: +- A hypervisor running in EL2, AA64 +- A guest running in EL1, AA32 + +We trap certain accesses to special registers such as DACR (via HCR.TVM). One instruction that is trapped is: + +ee03ef10 -> mcr 15, 0, lr, cr3, cr0, {0} + +The guest is running in SVC mode. So, LR should refer to LR_svc there. LR_svc is mapped to X18 in AA64. So, ESR should reflect that. However, the actual ESR value is: 0xfe00dc0 + +If we decode the 'rt': +>>> (0xfe00dc0 >> 5) & 0x1f +14 + +My understanding is that 14 is incorrect in the context of AA64. rt should be set to 18. The current mode being SVC, LR refers to LR_svc not LR_usr. In other words, the mapping between registers in AA64 and AA32 doesn't seem to be accounted for. I've tested this with Qemu 5.0.0 + +Let me know if that makes sense and if you would like more info. I am also happy to test patches. +Thanks for all the great work on Qemu! + +This is with qemu-system-aarch64 - forgot to mention it explicitly. So, it will only affect qemu for ARM 64-bit. + +Thanks for the bug report; I think this patch should fix it: + +https://<email address hidden>/ + +Any chance you could test it? + + +Of course. I just tested the patch (used the branch from https://github.com/patchew-project/qemu) and it didn't seem to help. Could that be linked to the fact that the translation is only in the SMC exception path? It should probably target the MSR exception path also (and probably others too). It's just a guess as I am not very familiar with the code. If that's enough info, do let me know how to gather more useful information. + +Maybe it's covered by EXCP_HYP_TRAP already... + +Hmm, that's odd. The switch statement fall-throughs and case labels mean that that code should be executed for all exceptions taken to AArch64 except for IRQ/FIQ/VIRQ/VFIQ. (You could probably confirm that by running QEMU under a debugger and putting in suitable breakpoints.) + +Do you have a test case image/command line I could use to reproduce the issue ? + + +Unfortunately, I won't be able to send the code or binary for the hypervisor as of now (it will become available at some point in the future though). I've done a bit of debugging on the QEMU code and it seems like the approach you are taking works fine in general but the register mapping code doesn't seem quite right. Applying this patch (on top of yours): + +From e2182581dcdeedc2cb88cd21b88b4db744677737 Mon Sep 17 00:00:00 2001 +From: Julien Freche <email address hidden> +Date: Tue, 4 Aug 2020 11:54:49 -0700 +Subject: [PATCH] Possible fix + +--- + target/arm/helper.c | 11 +++++------ + 1 file changed, 5 insertions(+), 6 deletions(-) + +diff --git a/target/arm/helper.c b/target/arm/helper.c +index 60b80228fd..455c92b891 100644 +--- a/target/arm/helper.c ++++ b/target/arm/helper.c +@@ -9619,17 +9619,16 @@ static int aarch64_regnum(CPUARMState *env, int aarch32_reg) + switch (mode) { + case ARM_CPU_MODE_USR: + case ARM_CPU_MODE_SYS: +- return 14; + case ARM_CPU_MODE_HYP: +- return 16; ++ return 14; + case ARM_CPU_MODE_IRQ: +- return 18; ++ return 16; + case ARM_CPU_MODE_SVC: +- return 20; ++ return 18; + case ARM_CPU_MODE_ABT: +- return 22; ++ return 20; + case ARM_CPU_MODE_UND: +- return 24; ++ return 22; + case ARM_CPU_MODE_FIQ: + return 30; + default: +-- +2.28.0 + +Based on the ARM documentation, I would think that LR_svc maps to X18, not X20. I fixed the ones that seemed wrong but I haven't check every possible case so you may want to double check this. With the patch I was able to boot Linux correctly. + +Let me know if that makes sense + + +Whoops, yes. I somehow misread that table (I think I failed to spot that there is no LR_hyp and it just shares r14 with usr/sys, so I did a cut-n-paste of the SP cases to LR, which isn't right). I think your adjustment to the patch is correct. I'll do a v2 patch for you to test, but it will just be those fixes applied to v1. + + +v2 is here https://patches.linaro.org/patch/247434/ -- hoping to put that in master today... + + + +It seems like this is your patch plus my fixup so this is good to me and already tested locally. Thanks again. + +Hey Julien, what fixup do you need on top of Peter's v2? + +Peter's v2 already includes the fixup (update #6) + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a65dabf71a9f9b949 + diff --git a/results/classifier/zero-shot/108/all/1880822 b/results/classifier/zero-shot/108/all/1880822 new file mode 100644 index 000000000..f55b7cb5b --- /dev/null +++ b/results/classifier/zero-shot/108/all/1880822 @@ -0,0 +1,287 @@ +debug: 0.992 +semantic: 0.989 +device: 0.989 +permissions: 0.988 +boot: 0.988 +KVM: 0.988 +vnc: 0.988 +PID: 0.987 +socket: 0.987 +other: 0.987 +performance: 0.987 +graphic: 0.984 +network: 0.983 +files: 0.982 + +CVE-2020-13253 QEMU: sd: OOB access could crash the guest resulting in DoS + +An out-of-bounds read access issue was found in the SD Memory Card emulator of the QEMU. It occurs while performing block write commands via sdhci_write(), if a guest user has sent 'address' which is OOB of 's->wp_groups'. A guest user/process may use this flaw to crash the QEMU process resulting in DoS. + +#!/bin/sh + +cat << EOF > inp +outl 0xcf8 0x80001810 +outl 0xcfc 0xe1068000 +outl 0xcf8 0x80001814 +outl 0xcf8 0x80001804 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fa20 +write 0xe106802c 0x1 0x6d +write 0xe106800f 0x1 0xf7 +write 0xe106800a 0x6 0x9b4b9b5a9b69 +write 0xe1068028 0x3 0x6d6d6d +write 0xe106800f 0x1 0x02 +write 0xe1068005 0xb 0x055cfbffffff000000ff03 +write 0xe106800c 0x1d 0x050bc6c6c6c6c6c6c6c6762e4c5e0bc603040000000000e10200110000 +write 0xe1068003 0xd 0x2b6de02c3a6de02c496de02c58 +EOF + +../bin/qemu-system-x86_64 -qtest stdio -enable-kvm -monitor none \ + -serial none -M pc-q35-5.0 -device sdhci-pci,sd-spec-version=3 \ + -device sd-card,drive=mydrive -nographic \ + -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive < inp + +This bug and the reproducer above is shared by - Alexander Bulekov <email address hidden> + +Upstream patch thread + -> https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg05877.html + +Patch reducing the exposure to this bug: +https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00823.html + +Avoid OOB access by verifying the requested address belong to +the actual card size. Return ADDRESS_ERROR when not in range. + + "SD Specifications Part 1 Physical Layer Simplified Spec. v3.01" + + 4.3.4 Data Write + + * Block Write + + Write command is rejected if BLOCK_LEN_ERROR or ADDRESS_ERROR + occurred and no data transfer is performed. + +Fixes: CVE-2020-13253 +Reported-by: Alexander Bulekov <email address hidden> +Buglink: https://bugs.launchpad.net/qemu/+bug/1880822 +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- +Cc: Prasad J Pandit <email address hidden> +--- + hw/sd/sd.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/hw/sd/sd.c b/hw/sd/sd.c +index 3c06a0ac6d..0ced3b5e14 100644 +--- a/hw/sd/sd.c ++++ b/hw/sd/sd.c +@@ -1211,6 +1211,10 @@ static sd_rsp_type_t sd_normal_command(SDState *sd, SDRequest req) + /* Writing in SPI mode not implemented. */ + if (sd->spi) + break; ++ if (addr >= sd->size) { ++ sd->card_status |= ADDRESS_ERROR; ++ return sd_r1; ++ } + sd->state = sd_receivingdata_state; + sd->data_start = addr; + sd->data_offset = 0; +-- +2.21.3 + + + +On 6/4/20 8:03 PM, Paolo Bonzini wrote: +> On 04/06/20 19:34, Philippe Mathieu-Daudé wrote: +>> Avoid OOB access by verifying the requested address belong to +>> the actual card size. Return ADDRESS_ERROR when not in range. +>> +>> "SD Specifications Part 1 Physical Layer Simplified Spec. v3.01" +>> +>> 4.3.4 Data Write +>> +>> * Block Write +>> +>> Write command is rejected if BLOCK_LEN_ERROR or ADDRESS_ERROR +>> occurred and no data transfer is performed. +>> +>> Fixes: CVE-2020-13253 +>> Reported-by: Alexander Bulekov <email address hidden> +>> Buglink: https://bugs.launchpad.net/qemu/+bug/1880822 +>> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +>> --- +>> Cc: Prasad J Pandit <email address hidden> +>> --- +>> hw/sd/sd.c | 4 ++++ +>> 1 file changed, 4 insertions(+) +>> +>> diff --git a/hw/sd/sd.c b/hw/sd/sd.c +>> index 3c06a0ac6d..0ced3b5e14 100644 +>> --- a/hw/sd/sd.c +>> +++ b/hw/sd/sd.c +>> @@ -1211,6 +1211,10 @@ static sd_rsp_type_t sd_normal_command(SDState *sd, SDRequest req) +>> /* Writing in SPI mode not implemented. */ +>> if (sd->spi) +>> break; +>> + if (addr >= sd->size) { +>> + sd->card_status |= ADDRESS_ERROR; +>> + return sd_r1; +>> + } +>> sd->state = sd_receivingdata_state; +>> sd->data_start = addr; +>> sd->data_offset = 0; +>> +> +> I'm not sure if you want me to queue it, but I did. + +Hmm I guess I typed "^RPrasad" in my shell to have the last git-publish +command with his email, and I didn't noticed you were also there... + +Anyway looking at it again, this patch is wrong because I should check +for addr + blksize < sd_size instead. Can you drop it please? + +> Probably we should +> add <email address hidden> to the hw/sd stanza. + +OK will do. + +> +> Paolo +> + + +Avoid OOB access by verifying the requested address belong to +the actual card size. Return ADDRESS_ERROR when not in range. +Only move the state machine to ReceivingData if there is no +pending error. + + "SD Specifications Part 1 Physical Layer Simplified Spec. v3.01" + + 4.3.4 Data Write + + * Block Write + + Write command is rejected if BLOCK_LEN_ERROR or ADDRESS_ERROR + occurred and no data transfer is performed. + +Fixes: CVE-2020-13253 +Reported-by: Alexander Bulekov <email address hidden> +Buglink: https://bugs.launchpad.net/qemu/+bug/1880822 +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- +Cc: Prasad J Pandit <email address hidden> + +v2: check for blksz in range, only go to sd_receivingdata_state + if no error. +--- + hw/sd/sd.c | 17 +++++++++-------- + 1 file changed, 9 insertions(+), 8 deletions(-) + +diff --git a/hw/sd/sd.c b/hw/sd/sd.c +index 3c06a0ac6d..2254dc7acc 100644 +--- a/hw/sd/sd.c ++++ b/hw/sd/sd.c +@@ -1211,17 +1211,18 @@ static sd_rsp_type_t sd_normal_command(SDState *sd, SDRequest req) + /* Writing in SPI mode not implemented. */ + if (sd->spi) + break; +- sd->state = sd_receivingdata_state; +- sd->data_start = addr; +- sd->data_offset = 0; +- sd->blk_written = 0; +- +- if (sd->data_start + sd->blk_len > sd->size) ++ if (addr + sd->blk_len >= sd->size) { + sd->card_status |= ADDRESS_ERROR; +- if (sd_wp_addr(sd, sd->data_start)) ++ } else if (sd_wp_addr(sd, sd->data_start)) { + sd->card_status |= WP_VIOLATION; +- if (sd->csd[14] & 0x30) ++ } else if (sd->csd[14] & 0x30) { + sd->card_status |= WP_VIOLATION; ++ } else { ++ sd->state = sd_receivingdata_state; ++ sd->data_start = addr; ++ sd->data_offset = 0; ++ sd->blk_written = 0; ++ } + return sd_r1; + + default: +-- +2.21.3 + + + +On 6/4/20 8:25 PM, Philippe Mathieu-Daudé wrote: +> Avoid OOB access by verifying the requested address belong to +> the actual card size. Return ADDRESS_ERROR when not in range. +> Only move the state machine to ReceivingData if there is no +> pending error. +> +> "SD Specifications Part 1 Physical Layer Simplified Spec. v3.01" +> +> 4.3.4 Data Write +> +> * Block Write +> +> Write command is rejected if BLOCK_LEN_ERROR or ADDRESS_ERROR +> occurred and no data transfer is performed. +> +> Fixes: CVE-2020-13253 +> Reported-by: Alexander Bulekov <email address hidden> +> Buglink: https://bugs.launchpad.net/qemu/+bug/1880822 + +While the reproducer triggers the OOB via CMD24, other commands have the +same problem, so I'll post a v3. + +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> Cc: Prasad J Pandit <email address hidden> +> +> v2: check for blksz in range, only go to sd_receivingdata_state +> if no error. +> --- +> hw/sd/sd.c | 17 +++++++++-------- +> 1 file changed, 9 insertions(+), 8 deletions(-) +> +> diff --git a/hw/sd/sd.c b/hw/sd/sd.c +> index 3c06a0ac6d..2254dc7acc 100644 +> --- a/hw/sd/sd.c +> +++ b/hw/sd/sd.c +> @@ -1211,17 +1211,18 @@ static sd_rsp_type_t sd_normal_command(SDState *sd, SDRequest req) +> /* Writing in SPI mode not implemented. */ +> if (sd->spi) +> break; +> - sd->state = sd_receivingdata_state; +> - sd->data_start = addr; +> - sd->data_offset = 0; +> - sd->blk_written = 0; +> - +> - if (sd->data_start + sd->blk_len > sd->size) +> + if (addr + sd->blk_len >= sd->size) { +> sd->card_status |= ADDRESS_ERROR; +> - if (sd_wp_addr(sd, sd->data_start)) +> + } else if (sd_wp_addr(sd, sd->data_start)) { +> sd->card_status |= WP_VIOLATION; +> - if (sd->csd[14] & 0x30) +> + } else if (sd->csd[14] & 0x30) { +> sd->card_status |= WP_VIOLATION; +> + } else { +> + sd->state = sd_receivingdata_state; +> + sd->data_start = addr; +> + sd->data_offset = 0; +> + sd->blk_written = 0; +> + } +> return sd_r1; +> +> default: +> + + + +v3: +https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg01316.html + +Fixed in commit 790762e5487114341cccc5bffcec4cb3c022c3cd. + diff --git a/results/classifier/zero-shot/108/all/1882817 b/results/classifier/zero-shot/108/all/1882817 new file mode 100644 index 000000000..f153bda42 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1882817 @@ -0,0 +1,95 @@ +debug: 0.977 +permissions: 0.968 +graphic: 0.965 +semantic: 0.960 +vnc: 0.959 +device: 0.956 +PID: 0.955 +other: 0.954 +performance: 0.949 +files: 0.947 +socket: 0.945 +boot: 0.938 +network: 0.930 +KVM: 0.924 + +Segfault in audio_pcm_sw_write with audio over VNC + +QEMU 5.0.0, built with ./configure --target-list=x86_64-softmmu --enable-debug --disable-strip --disable-docs --disable-sdl + +Running on a headless host (Ryzen 3600), Arch Linux, 64bit latest. +Guest is also Arch Linux, 64bit. + +Started with qemu-system-x86_64 -vnc 0.0.0.0:0 -enable-kvm -m 4096 -cpu host -smp cores=2,threads=1,sockets=1 -machine q35 -vga std -device + ich9-ahci,id=ahci -drive file=vm0.qcow2,format=qcow2,if=none,id=dsk0 -device ide-hd,drive=dsk0,bus=ahci.0 -soundhw hda + +So, a headless VM is running on a server and is being connected to over VNC. The virtual sound card is detected and speaker test is running inside the VM. So far so good. + +Then, i tell the VNC client to enable audio (QEMU Audio Client Message, 255,1,0). QEMU responds with a "stream is about to start" message (QEMU Audio Server Message, 255,1,1) and then promptly crashes without sending anything else. + +Running it in GDB produces a crash at audio/audio.c:739 + +Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +audio_pcm_sw_write (sw=0x5555575bbf30, buf=0x0, size=1628) at audio/audio.c:739 +739 if (!sw->hw->pcm_ops->volume_out) { + +The exact sequence of events does not matter - i can enable sound before playing anything, and then it would say nothing and keep working, but crash with the same message once anything sound-playing is launched in the VM. + +Using different soundhw or adding various audiodev options does not seem to affect anything. + +I can't quite figure out if the QEMU Audio VNC extension is supposed to work at all or not, but it would be handy to me if it is. + +On 6/9/20 7:10 PM, Artyom wrote: +> Public bug reported: +> +> QEMU 5.0.0, built with ./configure --target-list=x86_64-softmmu +> --enable-debug --disable-strip --disable-docs --disable-sdl +> +> Running on a headless host (Ryzen 3600), Arch Linux, 64bit latest. +> Guest is also Arch Linux, 64bit. +> +> Started with qemu-system-x86_64 -vnc 0.0.0.0:0 -enable-kvm -m 4096 -cpu host -smp cores=2,threads=1,sockets=1 -machine q35 -vga std -device +> ich9-ahci,id=ahci -drive file=vm0.qcow2,format=qcow2,if=none,id=dsk0 -device ide-hd,drive=dsk0,bus=ahci.0 -soundhw hda +> +> So, a headless VM is running on a server and is being connected to over +> VNC. The virtual sound card is detected and speaker test is running +> inside the VM. So far so good. +> +> Then, i tell the VNC client to enable audio (QEMU Audio Client Message, +> 255,1,0). QEMU responds with a "stream is about to start" message (QEMU +> Audio Server Message, 255,1,1) and then promptly crashes without sending +> anything else. +> +> Running it in GDB produces a crash at audio/audio.c:739 +> +> Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +> audio_pcm_sw_write (sw=0x5555575bbf30, buf=0x0, size=1628) at audio/audio.c:739 +> 739 if (!sw->hw->pcm_ops->volume_out) { + +Isn't it the one fixed by +https://<email address hidden>/msg705896.html? + +> +> The exact sequence of events does not matter - i can enable sound before +> playing anything, and then it would say nothing and keep working, but +> crash with the same message once anything sound-playing is launched in +> the VM. +> +> Using different soundhw or adding various audiodev options does not seem +> to affect anything. +> +> I can't quite figure out if the QEMU Audio VNC extension is supposed to +> work at all or not, but it would be handy to me if it is. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + + + +Great. +Can confirm, that patch fixes it. + +commit cbaf25d1f59ee13fc7542a06ea70784f2e000c04. + diff --git a/results/classifier/zero-shot/108/all/1885247 b/results/classifier/zero-shot/108/all/1885247 new file mode 100644 index 000000000..1b4e8d5b0 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1885247 @@ -0,0 +1,300 @@ +permissions: 0.992 +graphic: 0.991 +debug: 0.991 +socket: 0.991 +semantic: 0.989 +PID: 0.986 +device: 0.984 +performance: 0.984 +other: 0.982 +boot: 0.982 +files: 0.982 +network: 0.978 +vnc: 0.977 +KVM: 0.961 + +Build error in Intel 32-bit hosts + +The code base is on master, checked out on Thursday June25th 2020, 0250c595c9d. The build procedure: + +$ mkdir build-gcc +$ cd build-gcc +$ ../configure +$ make + +The build error message is: + + CC x86_64-softmmu/hw/hyperv/hyperv.o + CC x86_64-softmmu/hw/hyperv/hyperv_testdev.o + CC x86_64-softmmu/hw/hyperv/vmbus.o +/home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c: In function ‘gpadl_iter_io’: +/home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c:386:13: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] + p = (void *)(((uintptr_t)iter->map & TARGET_PAGE_MASK) | off_in_page); + ^ +cc1: all warnings being treated as errors +make[1]: *** [/home/rtrk/Build/qemu-master/rules.mak:69: hw/hyperv/vmbus.o] Error 1 +make: *** [Makefile:527: x86_64-softmmu/all] Error 2 + +пет, 26. јун 2020. у 09:11 Aleksandar Markovic +<email address hidden> је написао/ла: +> +> Public bug reported: +> +> The code base is on master, checked out on Thursday June25th 2020, +> 0250c595c9d. The build procedure: +> +> $ mkdir build-gcc +> $ cd build-gcc +> $ ../configure +> $ make +> +> The build error message is: +> +> CC x86_64-softmmu/hw/hyperv/hyperv.o +> CC x86_64-softmmu/hw/hyperv/hyperv_testdev.o +> CC x86_64-softmmu/hw/hyperv/vmbus.o +> /home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c: In function ‘gpadl_iter_io’: +> /home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c:386:13: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> p = (void *)(((uintptr_t)iter->map & TARGET_PAGE_MASK) | off_in_page); +> ^ +> cc1: all warnings being treated as errors +> make[1]: *** [/home/rtrk/Build/qemu-master/rules.mak:69: hw/hyperv/vmbus.o] Error 1 +> make: *** [Makefile:527: x86_64-softmmu/all] Error 2 +> + +Jon, + +Do arilyou have any comment or insight on this? + +Thanks, +Aleksandar + +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1885247 +> +> Title: +> Build error in Intel 32-bit hosts +> +> Status in QEMU: +> New +> +> Bug description: +> The code base is on master, checked out on Thursday June25th 2020, +> 0250c595c9d. The build procedure: +> +> $ mkdir build-gcc +> $ cd build-gcc +> $ ../configure +> $ make +> +> The build error message is: +> +> CC x86_64-softmmu/hw/hyperv/hyperv.o +> CC x86_64-softmmu/hw/hyperv/hyperv_testdev.o +> CC x86_64-softmmu/hw/hyperv/vmbus.o +> /home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c: In function ‘gpadl_iter_io’: +> /home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c:386:13: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +> p = (void *)(((uintptr_t)iter->map & TARGET_PAGE_MASK) | off_in_page); +> ^ +> cc1: all warnings being treated as errors +> make[1]: *** [/home/rtrk/Build/qemu-master/rules.mak:69: hw/hyperv/vmbus.o] Error 1 +> make: *** [Makefile:527: x86_64-softmmu/all] Error 2 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1885247/+subscriptions +> + + +I suspect an extra uintptr_t cast will fix this: + +p = (void *)(uintptr_t)(((uintptr_t)iter->map & TARGET_PAGE_MASK) | off_in_page); + +Which looks kind of ugly but then the code is taking a host void* (iter->map), casting it to integer to do arithmetic on and then wanting to get it back to a void* which is inherently going to result in a mess of casting... + + +On 6/26/20 9:37 AM, Aleksandar Markovic wrote: +> пет, 26. јун 2020. у 09:11 Aleksandar Markovic +> <email address hidden> је написао/ла: +>> +>> Public bug reported: +>> +>> The code base is on master, checked out on Thursday June25th 2020, +>> 0250c595c9d. The build procedure: +>> +>> $ mkdir build-gcc +>> $ cd build-gcc +>> $ ../configure +>> $ make +>> +>> The build error message is: +>> +>> CC x86_64-softmmu/hw/hyperv/hyperv.o +>> CC x86_64-softmmu/hw/hyperv/hyperv_testdev.o +>> CC x86_64-softmmu/hw/hyperv/vmbus.o +>> /home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c: In function ‘gpadl_iter_io’: +>> /home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c:386:13: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] +>> p = (void *)(((uintptr_t)iter->map & TARGET_PAGE_MASK) | off_in_page); +>> ^ +>> cc1: all warnings being treated as errors +>> make[1]: *** [/home/rtrk/Build/qemu-master/rules.mak:69: hw/hyperv/vmbus.o] Error 1 +>> make: *** [Makefile:527: x86_64-softmmu/all] Error 2 + +FWIW there is no CI job covering x86 KVM on 32-bit host build. +Should this be covered? I guess the problem is no CI services +provide 32-bit x86... + + + +On 6/26/20 11:20 AM, Thomas Huth wrote: +> On 26/06/2020 11.13, Philippe Mathieu-Daudé wrote: +>> On 6/26/20 9:37 AM, Aleksandar Markovic wrote: +>>> пет, 26. јун 2020. у 09:11 Aleksandar Markovic +>>> <email address hidden> је написао/ла: +>>>> +>>>> Public bug reported: +>>>> +>>>> The code base is on master, checked out on Thursday June25th 2020, +>>>> 0250c595c9d. The build procedure: +>>>> +>>>> $ mkdir build-gcc +>>>> $ cd build-gcc +>>>> $ ../configure +>>>> $ make +>>>> +>>>> The build error message is: +>>>> +>>>> CC x86_64-softmmu/hw/hyperv/hyperv.o +>>>> CC x86_64-softmmu/hw/hyperv/hyperv_testdev.o +>>>> CC x86_64-softmmu/hw/hyperv/vmbus.o +>>>> /home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c: In function +>>>> ‘gpadl_iter_io’: +>>>> /home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c:386:13: error: cast +>>>> to pointer from integer of different size [-Werror=int-to-pointer-cast] +>>>> p = (void *)(((uintptr_t)iter->map & TARGET_PAGE_MASK) | +>>>> off_in_page); +>>>> ^ +>>>> cc1: all warnings being treated as errors +>>>> make[1]: *** [/home/rtrk/Build/qemu-master/rules.mak:69: +>>>> hw/hyperv/vmbus.o] Error 1 +>>>> make: *** [Makefile:527: x86_64-softmmu/all] Error 2 +>> +>> FWIW there is no CI job covering x86 KVM on 32-bit host build. +>> Should this be covered? I guess the problem is no CI services +>> provide 32-bit x86... +> +> You can certainly provide either a container, or install the 32-bit +> libraries in a 64-bit environment. Then run +> +> PKG_CONFIG_LIBDIR=... ./configure --extra-cflags=-m32 +> +> and it should be possible to build 32-bit binaries, too. +> +> Alternatively, we could add a cross-compilation job that builds with +> i686-w64-mingw32 in 32-bit. + +Oh, this case is covered: +https://app.shippable.com/github/qemu/qemu/runs/2437/2/console + +But this doesn't use KVM ;) + + + +пет, 26. јун 2020. у 12:54 Jon Doron <email address hidden> је написао/ла: +> +> Is there a container I can download which has your build environment? +> + +Hello, Jon. + +I don't know about the container, but, as Peter noted, the following +(non-beautiful) diff fixes the build problem on the real host: + +diff --git a/hw/hyperv/vmbus.c b/hw/hyperv/vmbus.c +index f371240176..9220f7b529 100644 +--- a/hw/hyperv/vmbus.c ++++ b/hw/hyperv/vmbus.c +@@ -383,7 +383,8 @@ static ssize_t gpadl_iter_io(GpadlIter *iter, void +*buf, uint32_t len) + } + } + +- p = (void *)(((uintptr_t)iter->map & TARGET_PAGE_MASK) | off_in_page); ++ p = (void *)(uintptr_t)(((uintptr_t)iter->map & TARGET_PAGE_MASK) | ++ off_in_page); + if (iter->dir == DMA_DIRECTION_FROM_DEVICE) { + memcpy(p, buf, cplen); + } else { + +Not sure if this is an optimal/most-elegant solution though. + +Warmly, +Aleksandar + + +> On Fri, Jun 26, 2020 at 12:27 PM Philippe Mathieu-Daudé +> <email address hidden> wrote: +> > +> > On 6/26/20 11:20 AM, Thomas Huth wrote: +> > > On 26/06/2020 11.13, Philippe Mathieu-Daudé wrote: +> > >> On 6/26/20 9:37 AM, Aleksandar Markovic wrote: +> > >>> пет, 26. јун 2020. у 09:11 Aleksandar Markovic +> > >>> <email address hidden> је написао/ла: +> > >>>> +> > >>>> Public bug reported: +> > >>>> +> > >>>> The code base is on master, checked out on Thursday June25th 2020, +> > >>>> 0250c595c9d. The build procedure: +> > >>>> +> > >>>> $ mkdir build-gcc +> > >>>> $ cd build-gcc +> > >>>> $ ../configure +> > >>>> $ make +> > >>>> +> > >>>> The build error message is: +> > >>>> +> > >>>> CC x86_64-softmmu/hw/hyperv/hyperv.o +> > >>>> CC x86_64-softmmu/hw/hyperv/hyperv_testdev.o +> > >>>> CC x86_64-softmmu/hw/hyperv/vmbus.o +> > >>>> /home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c: In function +> > >>>> ‘gpadl_iter_io’: +> > >>>> /home/rtrk/Build/qemu-master/hw/hyperv/vmbus.c:386:13: error: cast +> > >>>> to pointer from integer of different size [-Werror=int-to-pointer-cast] +> > >>>> p = (void *)(((uintptr_t)iter->map & TARGET_PAGE_MASK) | +> > >>>> off_in_page); +> > >>>> ^ +> > >>>> cc1: all warnings being treated as errors +> > >>>> make[1]: *** [/home/rtrk/Build/qemu-master/rules.mak:69: +> > >>>> hw/hyperv/vmbus.o] Error 1 +> > >>>> make: *** [Makefile:527: x86_64-softmmu/all] Error 2 +> > >> +> > >> FWIW there is no CI job covering x86 KVM on 32-bit host build. +> > >> Should this be covered? I guess the problem is no CI services +> > >> provide 32-bit x86... +> > > +> > > You can certainly provide either a container, or install the 32-bit +> > > libraries in a 64-bit environment. Then run +> > > +> > > PKG_CONFIG_LIBDIR=... ./configure --extra-cflags=-m32 +> > > +> > > and it should be possible to build 32-bit binaries, too. +> > > +> > > Alternatively, we could add a cross-compilation job that builds with +> > > i686-w64-mingw32 in 32-bit. +> > +> > Oh, this case is covered: +> > https://app.shippable.com/github/qemu/qemu/runs/2437/2/console +> > +> > But this doesn't use KVM ;) +> > + + +Fix had been included here: +https://gitlab.com/qemu-project/qemu/-/commit/8b39aa90e90 +... thus closing this ticket now. + diff --git a/results/classifier/zero-shot/108/all/1885827 b/results/classifier/zero-shot/108/all/1885827 new file mode 100644 index 000000000..ffd29b347 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1885827 @@ -0,0 +1,436 @@ +other: 0.957 +graphic: 0.954 +permissions: 0.949 +semantic: 0.945 +debug: 0.936 +vnc: 0.934 +network: 0.934 +boot: 0.929 +performance: 0.924 +socket: 0.924 +PID: 0.922 +files: 0.917 +device: 0.909 +KVM: 0.907 + +building plugin failed on Windows with mingw + +I want to build QEMU 4.2.0's plugin module on Windows 7/10 with Mingw, but the building process faild. + +The step I follow is listed below: +1. create "dsp_build" diretory under source file folder + +2. change directory to dsp_build , and run ../configure --target-list=dsp-softmmu --cross-prefix=x86_64-w64-mingw32- --enable-gtk --enable-sdl --enable-debug --enable-plugins +3. build qemu project +4. switch dir to /dsp_build, make -C tests/plugin, yeilds error: + CC bb.o + D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:17:24: error: variable 'qemu_plugin_version' definition is marked dllimport + 17 | QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION; + | ^~~~~~~~~~~~~~~~~~~ + D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:17:24: warning: 'qemu_plugin_version' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] + D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c: In function 'vcpu_tb_exec': + D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:33:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] + 33 | unsigned long n_insns = (unsigned long)udata; + | ^ + D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c: In function 'vcpu_tb_trans': + D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:51:46: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] + 51 | (void *)n_insns); + +5. Then , I modified the QEMU_flags and the compilation command arguments($(CC) ..) in the makefile : + + BUILD_DIR := $(CURDIR)/../.. + + include $(BUILD_DIR)/config-host.mak + include $(SRC_PATH)/rules.mak + + $(call set-vpath, $(SRC_PATH)/tests/plugin) + + NAMES := + NAMES += bb + NAMES += empty + NAMES += insn + NAMES += mem + NAMES += hotblocks + NAMES += howvec + NAMES += hotpages + + SONAMES := $(addsuffix .so,$(addprefix lib,$(NAMES))) + + QEMU_CFLAGS += -fPIC -DBUILDING_DLL #added -DBUILDING_DLL + QEMU_CFLAGS += -I$(SRC_PATH)/include/qemu + + all: $(SONAMES) + + lib%.so: %.o + $(CC) -fPIC -shared -o $@ $^ $(LDLIBS) -L /c/msys64/mingw64/lib/ -lglib-2.0 + # original cmd: $(CC) -shared -Wl,-soname,$@ -o $@ $^ $(LDLIBS) + + clean: + rm -f *.o *.so *.d + rm -Rf .libs + + .PHONY: all clean + +6. Executing make yeilds: + +make: enter “/d/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/build_dsp/tests/plugin” + CC bb.o +x86_64-w64-mingw32-gcc -fPIC -shared -o libbb.so bb.o -L /c/msys64/mingw64/lib/ -lglib-2.0 +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `plugin_exit': +D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:28: undefined reference to `qemu_plugin_outs' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:29: undefined reference to `__stack_chk_fail' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `vcpu_tb_trans': +D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:41: undefined reference to `qemu_plugin_tb_n_insns' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:44: undefined reference to `qemu_plugin_register_vcpu_tb_exec_inline' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:46: undefined reference to `qemu_plugin_register_vcpu_tb_exec_inline' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:49: undefined reference to `qemu_plugin_register_vcpu_tb_exec_cb' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `qemu_plugin_install': +D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:63: undefined reference to `qemu_plugin_register_vcpu_tb_trans_cb' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:64: undefined reference to `qemu_plugin_register_atexit_cb' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o:bb.c:(.rdata$.refptr.__stack_chk_guard[.refptr.__stack_chk_guard]+0x0): undefined reference to `__stack_chk_guard' +collect2.exe: error: ld returned 1 exit status + + It looks like linking problem(fail to link functions defined in api.c, core.c...), but I have no idea what goes wrong. If I mannualy add api.o, core.o in the compilation command, still get error like undefined reference to '__stack_chk_guard'. + My collegue can build 4.2.0 plugins on Ubuntu Linux without any problem. + + If I keep "-Wl,-soname,$@" in the command , I got similar linking errors. + +makefile: +SONAMES := $(addsuffix .dll,$(addprefix lib,$(NAMES))) + +QEMU_CFLAGS += -fPIC -fno-stack-protector -DBUILDING_DLL +QEMU_CFLAGS += -I$(SRC_PATH)/include/qemu + +all: $(SONAMES) +lib%.dll: %.o + $(CC) -shared -Wl,-soname,$@ -o $@ $^ $(LDLIBS) + +output: +x86_64-w64-mingw32-gcc -shared -Wl,-soname,libbb.dll -o libbb.dll bb.o +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `g_autoptr_cleanup_generic_gfree': +C:/msys64/mingw64/include/glib-2.0/glib/glib-autocleanups.h:28: undefined reference to `g_free' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `plugin_exit': +C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:27: undefined reference to `g_strdup_printf' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:29: undefined reference to `qemu_plugin_outs' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `vcpu_tb_trans': +C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:42: undefined reference to `qemu_plugin_tb_n_insns' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:45: undefined reference to `qemu_plugin_register_vcpu_tb_exec_inline' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:47: undefined reference to `qemu_plugin_register_vcpu_tb_exec_inline' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:50: undefined reference to `qemu_plugin_register_vcpu_tb_exec_cb' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `qemu_plugin_install': +C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:64: undefined reference to `qemu_plugin_register_vcpu_tb_trans_cb' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:65: undefined reference to `qemu_plugin_register_atexit_cb' +collect2.exe: error: ld returned 1 exit status + + On windows, I replace $LDLIBS with $LIBS here, because $LDLIBS seems undefined. But still yields linking error, except. + lib%.dll: %.o + $(CC) -shared -Wl,-soname,$@ -o $@ $^ $(LIBS)" + +x86_64-w64-mingw32-gcc -shared -Wl,-soname,libbb.dll -o libbb.dll bb.o -ldl -LC:/msys64/mingw64/lib -lz -LC:/msys64/mingw64/lib -lgmodule-2.0 -pthread -lglib-2.0 -lintl -LC:/msys64/mingw64/lib -lgthread-2.0 -pthread -lglib-2.0 -lintl -lwinmm -lws2_32 -liphlpapi +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `plugin_exit': +C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:29: undefined reference to `qemu_plugin_outs' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `vcpu_tb_trans': +C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:42: undefined reference to `qemu_plugin_tb_n_insns' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:45: undefined reference to `qemu_plugin_register_vcpu_tb_exec_inline' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:47: undefined reference to `qemu_plugin_register_vcpu_tb_exec_inline' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:50: undefined reference to `qemu_plugin_register_vcpu_tb_exec_cb' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `qemu_plugin_install': +C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:64: undefined reference to `qemu_plugin_register_vcpu_tb_trans_cb' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:65: undefined reference to `qemu_plugin_register_atexit_cb' + + The libdl library (where dlopen() is defined) was not shipped with MSYS2 mingw . It is compiled from source(https://github.com/dlfcn-win32/dlfcn-win32), and I place the generated libdl.dll, libdl.a, libdl.dll.a in C:\msys64\mingw64\include. dlfcn.h in C:\msys64\mingw64\include. + + +Xiaolei <email address hidden> writes: + +> If I keep "-Wl,-soname,$@" in the command , I got similar linking errors. +> +> makefile: +> SONAMES := $(addsuffix .dll,$(addprefix lib,$(NAMES))) +> +> QEMU_CFLAGS += -fPIC -fno-stack-protector -DBUILDING_DLL +> QEMU_CFLAGS += -I$(SRC_PATH)/include/qemu +> +> all: $(SONAMES) +> lib%.dll: %.o +> $(CC) -shared -Wl,-soname,$@ -o $@ $^ $(LDLIBS) +> +> output: +> x86_64-w64-mingw32-gcc -shared -Wl,-soname,libbb.dll -o libbb.dll bb.o +> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `g_autoptr_cleanup_generic_gfree': +> C:/msys64/mingw64/include/glib-2.0/glib/glib-autocleanups.h:28: undefined reference to `g_free' +> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `plugin_exit': +> C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:27: undefined reference to `g_strdup_printf' +> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:29: undefined reference to `qemu_plugin_outs' +> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `vcpu_tb_trans': +> C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:42: undefined reference to `qemu_plugin_tb_n_insns' +> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:45: undefined reference to `qemu_plugin_register_vcpu_tb_exec_inline' +> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:47: undefined reference to `qemu_plugin_register_vcpu_tb_exec_inline' +> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:50: undefined reference to `qemu_plugin_register_vcpu_tb_exec_cb' +> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `qemu_plugin_install': +> C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:64: undefined reference to `qemu_plugin_register_vcpu_tb_trans_cb' +> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:65: undefined reference to `qemu_plugin_register_atexit_cb' +> collect2.exe: error: ld returned 1 exit status + +Cc'ing Emilio as he wrote the initial code so I assume built it at one point. + +-- +Alex Bennée + + +I never built the plugin code on anything other than Linux :( +All I did for Windows is to try to follow https://gcc.gnu.org/wiki/Visibility + +Can you please try the following patch (with no other changes)? +The patch applies on top of v4.2.0. + +diff --git a/tests/plugin/Makefile b/tests/plugin/Makefile +index 75467b6db8..5b3611ad63 100644 +--- a/tests/plugin/Makefile ++++ b/tests/plugin/Makefile +@@ -16,7 +16,7 @@ NAMES += hotpages + + SONAMES := $(addsuffix .so,$(addprefix lib,$(NAMES))) + +-QEMU_CFLAGS += -fPIC ++QEMU_CFLAGS += -fPIC -DBUILDING_DLL + QEMU_CFLAGS += -I$(SRC_PATH)/include/qemu + + all: $(SONAMES) + + + +Xiaolei confirmed to me via email that adding -DBUILDING_DLL is not enough to fix the problem. + +I looked into this a bit further and it looks like we need an "import library" to be created when compiling the QEMU binary. This is accomplished by adding "-Wl,--out-implib,libqemu_plugin.a" to the linker invocation to build the QEMU binary. See these two stackoverflow questions: +- https://stackoverflow.com/questions/17601949/building-a-shared-library-using-gcc-on-linux-and-mingw-on-windows +- https://stackoverflow.com/questions/39759060/compile-to-dll-with-some-undefined-references-with-mingw + +It's not clear to me whether any import library with the symbols needed can work, or whether each target binary needs its corresponding import library, e.g. aarch64-linux-user and x86_64-linux-user need different libraries. The below is an attempt at the latter approach; one would just have to link the appropriate import library with "-l" when building the plugin. + +Please give this a try, and don't forget to also pass -DBUILDING_DLL to the linker. + + +diff --git a/Makefile b/Makefile +index b437a346d7..5cc1bc8e23 100644 +--- a/Makefile ++++ b/Makefile +@@ -866,8 +866,14 @@ ICON_SIZES=16x16 24x24 32x32 48x48 64x64 128x128 256x256 512x512 + install-includedir: + $(INSTALL_DIR) "$(DESTDIR)$(includedir)" + ++install-libdir: ++ $(INSTALL_DIR) "$(DESTDIR)$(libdir)" ++ for d in $(TARGET_DIRS); do \ ++ $(INSTALL_DIR) "$(DESTDIR)$(libdir)/$$d"; \ ++ done ++ + install: all $(if $(BUILD_DOCS),install-doc) \ +- install-datadir install-localstatedir install-includedir \ ++ install-datadir install-localstatedir install-includedir install-libdir \ + $(if $(INSTALL_BLOBS),$(edk2-decompressed)) \ + recurse-install + ifneq ($(TOOLS),) +@@ -932,6 +938,11 @@ ifdef CONFIG_GTK + endif + ifeq ($(CONFIG_PLUGIN),y) + $(INSTALL_DATA) $(SRC_PATH)/include/qemu/qemu-plugin.h "$(DESTDIR)$(includedir)/qemu-plugin.h" ++# ifeq MINGW, WINDOWS or similar. ++ for d in $(TARGET_DIRS); do \ ++ $(INSTALL_DATA) "$$d/libqemu_plugin.dll.a" "$(DESTDIR)$(libdir)/$$d/libqemu_plugin.dll.a"; \ ++ done ++# endif + endif + $(INSTALL_DIR) "$(DESTDIR)$(qemu_datadir)/keymaps" + set -e; for x in $(KEYMAPS); do \ +diff --git a/configure b/configure +index 6099be1d84..9606f6e888 100755 +--- a/configure ++++ b/configure +@@ -7455,6 +7455,9 @@ if test "$plugins" = "yes" ; then + "If \$plugins=yes, either \$ld_dynamic_list or " \ + "\$ld_exported_symbols_list should have been set to 'yes'." + fi ++ # if test "$mingw32" = "yes" ; then # or mingw, or windows; I don't know. ++ QEMU_LDFLAGS="-Wl,--out-implib,libqemu_plugin.dll.a" ++ # fi + fi + + if test "$tcg_interpreter" = "yes"; then + + + +Hi, + I patched configure file and makefile. The output is listed below. + The project is configured as : + #../configure --target-list=dsp-softmmu --cross-prefix=x86_64-w64-mingw32- --enable-gtk --enable-sdl --enable-debug --enable-plugins --extra-cflags="-DBUILDING_DLL" + + But running make yeilds error: + CC dsp-softmmu/trace/generated-helpers.o + CC dsp-softmmu/trace/control-target.o + LINK dsp-softmmu/qemu-system-dspw.exe +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lfdt +collect2.exe: error: ld returned 1 exit status +make[1]: *** [Makefile:208: qemu-system-dspw.exe] Error 1 +make: *** [Makefile:491: dsp-softmmu/all] Error 2 + + We then reconfigured by disable the -fdt : + ../configure --target-list=dsp-softmmu --cross-prefix=x86_64-w64-mingw32- --enable-gtk --enable-sdl --enable-debug --enable-plugins --disable-fdt --extra-cflags="-DBUILDING_DLL" + Build finished and running "make -C tests/plugin" gets similar linking errors: + + x86_64-w64-mingw32-gcc -shared -Wl,-soname,libbb.so -o libbb.so bb.o +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `g_autoptr_cleanup_generic_gfree': +C:/msys64/mingw64/include/glib-2.0/glib/glib-autocleanups.h:28: undefined reference to `g_free' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `plugin_exit': +C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:27: undefined reference to `g_strdup_printf' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:29: undefined reference to `qemu_plugin_outs' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:30: undefined reference to `__stack_chk_fail' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `vcpu_tb_trans': +C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:42: undefined reference to `qemu_plugin_tb_n_insns' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:45: undefined reference to `qemu_plugin_register_vcpu_tb_exec_inline' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:47: undefined reference to `qemu_plugin_register_vcpu_tb_exec_inline' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:50: undefined reference to `qemu_plugin_register_vcpu_tb_exec_cb' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `qemu_plugin_install': +C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:64: undefined reference to `qemu_plugin_register_vcpu_tb_trans_cb' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/QRS_Project/simdsp/qemu-4.2.0/tests/plugin/bb.c:65: undefined reference to `qemu_plugin_register_atexit_cb' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o:bb.c:(.rdata$.refptr.__stack_chk_guard[.refptr.__stack_chk_guard]+0x0): undefined reference to `__stack_chk_guard' +collect2.exe: error: ld returned 1 exit status + +---------makefile ----------- +BUILD_DIR := $(CURDIR)/../.. + +include $(BUILD_DIR)/config-host.mak +include $(SRC_PATH)/rules.mak + +$(call set-vpath, $(SRC_PATH)/tests/plugin) +#out +NAMES := +NAMES += bb +NAMES += empty +NAMES += insn +NAMES += mem +NAMES += hotblocks +NAMES += howvec +NAMES += hotpages + +SONAMES := $(addsuffix .so,$(addprefix lib,$(NAMES))) + +QEMU_CFLAGS += -fPIC -DBUILDING_DLL +QEMU_CFLAGS += -I$(SRC_PATH)/include/qemu + +all: $(SONAMES) + +lib%.so: %.o + $(CC) -shared -Wl,-soname,$@ -o $@ $^ $(LDLIBS) + +clean: + rm -f *.o *.so *.d + rm -Rf .libs + +.PHONY: all clean + + + + +You're getting close. + +1. From the build directory, find the import library created, e.g. `find . -name 'libqemu_plugin.dll.a'`. If you're building x86_64-linux-user, it should be in `x86_64-linux-user/libqemu_plugin.dll.a`. + +2. Go back to the `build/tests/plugin` directory. + +3. Link the empty plugin with: +x86_64-w64-mingw32-gcc -shared -Wl,-soname,libempty.so -o libempty.so empty.o -L/path/to/libqemu_plugin.dll.a/directory -lqemu_plugin.dll + +Note the added -L and -l flags. + +If that works, move on to the other plugins, although you might have to comment out the glib-dependent code. But let's not go there yet; try to build the empty plugin first. + +Hi Emilio, + I got the ideas for the attempt with a dummy dll. However, my collegue and I both failed to generate libqemu_plugin.dll.a during make process. + And running "make install" yields errors as follows: + +mkdir -p "C:/QEMU_install/QEMUa/applications" +install -c -m 0644 /c/QRS_Project/simdsp/qemu-4.2.0/ui/qemu.desktop \ + "C:/QEMU_install/QEMUa/applications/qemu.desktop" +make -C po install +make[1]: enter “/c/QRS_Project/simdsp/qemu-4.2.0/dsp_debug/po” +for obj in bg.mo de_DE.mo fr_FR.mo hu.mo it.mo tr.mo zh_CN.mo; do \ + base=$(basename $obj .mo); \ + install -d C:/QEMU_install/QEMUa/share/locale/$base/LC_MESSAGES; \ + install -m644 $obj C:/QEMU_install/QEMUa/share/locale/$base/LC_MESSAGES/qemu.mo; \ +done +make[1]: leave “/c/QRS_Project/simdsp/qemu-4.2.0/dsp_debug/po” +install -c -m 0644 /c/QRS_Project/simdsp/qemu-4.2.0/include/qemu/qemu-plugin.h "C:/QEMU_install/QEMUa/include/qemu-plugin.h" +for d in dsp-softmmu; do \ + install -c -m 0644 "$d/libqemu_plugin.dll.a" "C:/QEMU_install/QEMUa/lib/$d/libqemu_plugin.dll.a"; \ +done +install: unable to get 'dsp-softmmu/libqemu_plugin.dll.a' file status (stat): No such file or directory +make: *** [Makefile:890：install] error 1 + Any ideas? + + +You should then find out why libqemu_plugin.dll.a is not working. It is possible though that your linked is calling the import library something else, for instance adding a .dll extension to it. + +You will have to run a few tests with your linker (I'd just use the examples from the stackoverflow links I posted above) to see the name of the import library that gets created. My assumption is that some library gets created, otherwise the linked should give you an error and AFAICT it does not. + +Once you find what the import library us, you should be in good shape to adapt the above for QEMU. Let us know how it goes! + + +Emilio G. Cota <email address hidden> writes: + +> You should then find out why libqemu_plugin.dll.a is not working. It is +> possible though that your linked is calling the import library something +> else, for instance adding a .dll extension to it. +> +> You will have to run a few tests with your linker (I'd just use the +> examples from the stackoverflow links I posted above) to see the name of +> the import library that gets created. My assumption is that some library +> gets created, otherwise the linked should give you an error and AFAICT +> it does not. +> +> Once you find what the import library us, you should be in good shape to +> adapt the above for QEMU. Let us know how it goes! + +I did have a go but couldn't get far with the mingw docker images. I got +somewhat distracted yesterday solving the mysterious regenerating +syscall_nr.h problem so I've run out of bandwidth to look at this any +longer. If the two of you find an eventual solution please send me a +patch. + +Thanks. + +-- +Alex Bennée + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1890290 b/results/classifier/zero-shot/108/all/1890290 new file mode 100644 index 000000000..8491ac40d --- /dev/null +++ b/results/classifier/zero-shot/108/all/1890290 @@ -0,0 +1,153 @@ +permissions: 0.977 +boot: 0.975 +debug: 0.974 +network: 0.973 +device: 0.972 +files: 0.971 +other: 0.971 +semantic: 0.969 +socket: 0.969 +performance: 0.968 +graphic: 0.968 +KVM: 0.968 +PID: 0.966 +vnc: 0.958 + +PowerPC L2(nested virt) kvm guest fails to boot with ic-mode=dual,kernel-irqchip=on - `KVM is too old to support ic-mode=dual,kernel-irqchip=on` + +Env: +HW: Power 9 DD2.3 +Host L0: 5.8.0-rc5-g8ba4ffcd8 +Qemu: 5.0.50 (v5.0.0-533-gdebe78ce14) +Libvirt: 6.4.0 +L1: 5.8.0-rc5-ge9919e11e +qemu_version': '5.0.50 (v5.1.0-rc2-dirty) +libvirt_version': '6.4.0' +L2: 5.8.0-rc7-g6ba1b005f + + +1. boot a L2 KVM guest with `ic-mode=dual,kernel-irqchip=on` + +/usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name 'vm1' --machine pseries --memory=8192 --vcpu=8,maxvcpus=8,sockets=1,cores=2,t +hreads=4 --import --nographics --serial pty --memballoon model=virtio --disk path=/home/tests/data/avocado-vt/images/f31-ppc64le.qcow2,bus=virtio,size=10,format=qcow2 --network +=bridge=virbr0,model=virtio,mac=52:54:00:e6:fe:f6 --mac=52:54:00:e6:fe:f6 --boot emulator=/usr/share/avocado-plugins-vt/bin/qemu,kernel=/tmp/linux/vmlinux,kernel_args="root=/de +v/vda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug selinux=0" --noautoconsole --qemu-commandline=" -M pseries,ic-mode=dual,kernel-irqchip=on" + + +ERROR internal error: process exited while connecting to monitor: 2020-08-04T11:12:53.304482Z qemu: KVM is too old to support ic-mode=dual,kernel-irqchip=on + + + + +Qemu Log: +``` +/usr/share/avocado-plugins-vt/bin/qemu \ +-name guest=vm1,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-vm1/master-key.aes \ +-machine pseries-5.1,accel=kvm,usb=off,dump-guest-core=off \ +-cpu POWER9 \ +-m 8192 \ +-overcommit mem-lock=off \ +-smp 8,sockets=1,dies=1,cores=2,threads=4 \ +-uuid 20a3351b-2776-4e75-9059-c070fe3dd44b \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=34,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-kernel /tmp/linux/vmlinux \ +-append 'root=/dev/vda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug selinux=0' \ +-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.0,addr=0x2 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 \ +-blockdev '{"driver":"file","filename":"/home/tests/data/avocado-vt/images/f31-ppc64le.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device virtio-blk-pci,bus=pci.0,addr=0x4,drive=libvirt-1-format,id=virtio-disk0,bootindex=1 \ +-netdev tap,fd=37,id=hostnet0,vhost=on,vhostfd=38 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e6:fe:f6,bus=pci.0,addr=0x1 \ +-chardev pty,id=charserial0 \ +-device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 \ +-chardev socket,id=charchannel0,fd=39,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \ +-M pseries,ic-mode=dual,kernel-irqchip=on \ +-msg timestamp=on +2020-08-04 11:12:53.169+0000: Domain id=5 is tainted: custom-argv +2020-08-04 11:12:53.179+0000: 11120: info : libvirt version: 6.4.0, package: 1.fc31 (Unknown, 2020-06-02-05:09:40, ltc-wspoon4.aus.stglabs.ibm.com) +2020-08-04 11:12:53.179+0000: 11120: info : hostname: atest-guest +2020-08-04 11:12:53.179+0000: 11120: info : virObjectUnref:347 : OBJECT_UNREF: obj=0x7fff0c117c40 +char device redirected to /dev/pts/0 (label charserial0) +2020-08-04T11:12:53.304482Z qemu: KVM is too old to support ic-mode=dual,kernel-irqchip=on +2020-08-04 11:12:53.694+0000: shutting down, reason=failed +``` + +This is currently expected because the L2 KVM guest uses the historical KVM XICS device (not the XICS-on-XIVE one) and this can be only created once during the VM lifetime for the moment. + +This is a limitation in KVM, that can be addressed in several ways: +1) change the historical KVM XICS device to implement the release() method instead of destroy(), so that userspace can close() and re-create the device multiple times during the VM lifetime, as we have already done in KVM XIVE and KVM XICS-on-XIVE for powernv +2) have the KVM XICS-on-XIVE device to work under pseries + +I already have a tentative patch for 1) and I guess 2) would be part of a more global work to supporting nested KVM XIVE. + +But it is definitely not an issue in QEMU. + + +As per this the table https://www.qemu.org/docs/master/specs/ppc-spapr-xive.html#kvm-negotiation + +reported qemu error msg "KVM is too old to support ic-mode=dual,kernel-irqchip=on" indicates the +guest os is legacy, but that's not the case here, whereas kernel levels are near upstream which has support for xive. + +My understanding of the env I used as below + +Level | XIVE KVM support | XIVE support(in kernel or emulation) +-------------------------------------------------- + L0 | Yes | Yes + L1 | No | Yes(booted with irqchip: in-kernel) + L2 | No | Yes + +So, ideally when a L2 guest is started with ic-mode=dual,kernel-irqchip=on, we should have seen below error +(2) QEMU fails with ``kernel_irqchip requested but unavailable: + IRQ_XIVE capability must be present for KVM`` + +but we actually saw the reported one, which is misleading. + + + +this section of table in particular, https://www.qemu.org/docs/master/specs/ppc-spapr-xive.html#no-xive-support-in-kvm + +Hmm... the documentation might need an update. I'll have a look. + +Posted a patch to the list. + +http://patchwork.ozlabs.org/project<email address hidden>/ + +Satheesh, + +Can you please review and test ? + + +@Greg, + +Thanks for the patch, I see it already got applied into 5.2, tested and works fine, + +# git log -2 --oneline +1972794 (HEAD -> master) spapr: Clarify error and documentation for broken KVM XICS +e1d322c (grafted, tag: v5.1.0-rc3, origin/master, origin/HEAD) Update version for v5.1.0-rc3 release + + + +# /usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name 'vm1' --machine pseries --memory=8192 --vcpu=8,maxvcpus=8,sockets=1,cores=8,threads=1 --import --nographics --serial pty --memballoon model=virtio --controller type=scsi,model=virtio-scsi --disk path=/home/tests/data/avocado-vt/images/f31-ppc64le.qcow2,bus=scsi,size=10,format=qcow2 --network=bridge=virbr0,model=virtio,mac=52:54:00:5c:f1:fe --mac=52:54:00:5c:f1:fe --boot emulator=/home/qemu/ppc64-softmmu/qemu-system-ppc64,kernel=/boot/vmlinuz-5.8.0-rc5-ge9919e11e,kernel_args="root=/dev/sda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug selinux=0" --noautoconsole --qemu-commandline=" -M pseries,ic-mode=dual,kernel-irqchip=on";virsh console vm1 + +Starting install... +ERROR internal error: process exited while connecting to monitor: 2020-08-07T07:05:38.633057Z qemu-system-ppc64: KVM is incompatible with ic-mode=dual,kernel-irqchip=on +This can happen with an old KVM or in a KVM nested guest. +Try without kernel-irqchip or with kernel-irqchip=off. + +Regards, +-Satheesh + +Released with QEMU v5.2.0. + diff --git a/results/classifier/zero-shot/108/all/1890360 b/results/classifier/zero-shot/108/all/1890360 new file mode 100644 index 000000000..9e051644c --- /dev/null +++ b/results/classifier/zero-shot/108/all/1890360 @@ -0,0 +1,267 @@ +other: 0.985 +permissions: 0.980 +device: 0.979 +graphic: 0.972 +files: 0.972 +performance: 0.971 +semantic: 0.970 +debug: 0.970 +socket: 0.969 +PID: 0.962 +network: 0.960 +boot: 0.950 +KVM: 0.945 +vnc: 0.942 + +Assertion failure in address_space_unmap through virtio-blk + +Hello, +Reproducer: +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-device virtio-blk,drive=mydrive \ +-nodefaults -nographic -qtest stdio +outl 0xcf8 0x80001010 +outl 0xcfc 0xc001 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xc006 0x3aff9090 +outl 0xcf8 0x8000100e +outl 0xcfc 0x41005e1e +write 0x3b00002 0x1 0x5e +write 0x3b00004 0x1 0x5e +write 0x3aff5e6 0x1 0x11 +write 0x3aff5eb 0x1 0xc6 +write 0x3aff5ec 0x1 0xc6 +write 0x7 0x1 0xff +write 0x8 0x1 0xfb +write 0xc 0x1 0x11 +write 0xe 0x1 0x5e +write 0x5e8 0x1 0x11 +write 0x5ec 0x1 0xc6 +outl 0x410e 0x10e +EOF + + +qemu-fuzz-i386: /exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. +==789== ERROR: libFuzzer: deadly signal + #8 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 + #9 in address_space_unmap /exec.c:3623:9 + #10 in dma_memory_unmap /include/sysemu/dma.h:145:5 + #11 in virtqueue_unmap_sg /hw/virtio/virtio.c:690:9 + #12 in virtqueue_fill /hw/virtio/virtio.c:843:5 + #13 in virtqueue_push /hw/virtio/virtio.c:917:5 + #14 in virtio_blk_req_complete /hw/block/virtio-blk.c:83:5 + #15 in virtio_blk_handle_request /hw/block/virtio-blk.c:671:13 + #16 in virtio_blk_handle_vq /hw/block/virtio-blk.c:780:17 + #17 in virtio_queue_notify_aio_vq /hw/virtio/virtio.c:2324:15 + #18 in virtio_queue_host_notifier_aio_read /hw/virtio/virtio.c:3495:9 + #19 in aio_dispatch_handler /util/aio-posix.c:328:9 + #20 in aio_dispatch_handlers /util/aio-posix.c:371:20 + #21 in aio_dispatch /util/aio-posix.c:381:5 + #22 in aio_ctx_dispatch /util/async.c:306:5 + #23 in g_main_context_dispatch + + +With -trace virtio\* + +... +[S +0.099667] OK +[R +0.099681] write 0x5ec 0x1 0xc6 +OK +[S +0.099690] OK +[R +0.099700] outl 0x410e 0x10e +29575@1596590112.074339:virtio_queue_notify vdev 0x62d000030590 n 0 vq 0x7f9b93fc9800 +29575@1596590112.074423:virtio_blk_data_plane_start dataplane 0x60600000f260 +OK +[S +0.099833] OK +29575@1596590112.076459:virtio_queue_notify vdev 0x62d000030590 n 0 vq 0x7f9b93fc9800 +29575@1596590112.076642:virtio_blk_handle_read vdev 0x62d000030590 req 0x611000043e80 sector 0 nsectors 0 +29575@1596590112.076651:virtio_blk_req_complete vdev 0x62d000030590 req 0x611000043e80 status 1 +qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. + + +-Alex + +Hi Stefan, +This looks an awful lot like the one you looked at here: +https://<email address hidden>/msg705719.html +though this one is for virtio-pci, while that one was for virtio-mmio: + +They are probably the same issue, but the original reproducer no longer +causes an asserion failure for me, so maybe there was already a fix.. +-Alex + +On 200805 0116, Alexander Bulekov wrote: +> Public bug reported: +> +> Hello, +> Reproducer: +> cat << EOF | ./i386-softmmu/qemu-system-i386 \ +> -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +> -device virtio-blk,drive=mydrive \ +> -nodefaults -nographic -qtest stdio +> outl 0xcf8 0x80001010 +> outl 0xcfc 0xc001 +> outl 0xcf8 0x80001014 +> outl 0xcf8 0x80001004 +> outw 0xcfc 0x7 +> outl 0xc006 0x3aff9090 +> outl 0xcf8 0x8000100e +> outl 0xcfc 0x41005e1e +> write 0x3b00002 0x1 0x5e +> write 0x3b00004 0x1 0x5e +> write 0x3aff5e6 0x1 0x11 +> write 0x3aff5eb 0x1 0xc6 +> write 0x3aff5ec 0x1 0xc6 +> write 0x7 0x1 0xff +> write 0x8 0x1 0xfb +> write 0xc 0x1 0x11 +> write 0xe 0x1 0x5e +> write 0x5e8 0x1 0x11 +> write 0x5ec 0x1 0xc6 +> outl 0x410e 0x10e +> EOF +> +> +> qemu-fuzz-i386: /exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. +> ==789== ERROR: libFuzzer: deadly signal +> #8 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 +> #9 in address_space_unmap /exec.c:3623:9 +> #10 in dma_memory_unmap /include/sysemu/dma.h:145:5 +> #11 in virtqueue_unmap_sg /hw/virtio/virtio.c:690:9 +> #12 in virtqueue_fill /hw/virtio/virtio.c:843:5 +> #13 in virtqueue_push /hw/virtio/virtio.c:917:5 +> #14 in virtio_blk_req_complete /hw/block/virtio-blk.c:83:5 +> #15 in virtio_blk_handle_request /hw/block/virtio-blk.c:671:13 +> #16 in virtio_blk_handle_vq /hw/block/virtio-blk.c:780:17 +> #17 in virtio_queue_notify_aio_vq /hw/virtio/virtio.c:2324:15 +> #18 in virtio_queue_host_notifier_aio_read /hw/virtio/virtio.c:3495:9 +> #19 in aio_dispatch_handler /util/aio-posix.c:328:9 +> #20 in aio_dispatch_handlers /util/aio-posix.c:371:20 +> #21 in aio_dispatch /util/aio-posix.c:381:5 +> #22 in aio_ctx_dispatch /util/async.c:306:5 +> #23 in g_main_context_dispatch +> +> +> With -trace virtio\* +> +> ... +> [S +0.099667] OK +> [R +0.099681] write 0x5ec 0x1 0xc6 +> OK +> [S +0.099690] OK +> [R +0.099700] outl 0x410e 0x10e +> 29575@1596590112.074339:virtio_queue_notify vdev 0x62d000030590 n 0 vq 0x7f9b93fc9800 +> 29575@1596590112.074423:virtio_blk_data_plane_start dataplane 0x60600000f260 +> OK +> [S +0.099833] OK +> 29575@1596590112.076459:virtio_queue_notify vdev 0x62d000030590 n 0 vq 0x7f9b93fc9800 +> 29575@1596590112.076642:virtio_blk_handle_read vdev 0x62d000030590 req 0x611000043e80 sector 0 nsectors 0 +> 29575@1596590112.076651:virtio_blk_req_complete vdev 0x62d000030590 req 0x611000043e80 status 1 +> qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. +> +> +> -Alex +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1890360 +> +> Title: +> Assertion failure in address_space_unmap through virtio-blk +> +> Status in QEMU: +> New +> +> Bug description: +> Hello, +> Reproducer: +> cat << EOF | ./i386-softmmu/qemu-system-i386 \ +> -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +> -device virtio-blk,drive=mydrive \ +> -nodefaults -nographic -qtest stdio +> outl 0xcf8 0x80001010 +> outl 0xcfc 0xc001 +> outl 0xcf8 0x80001014 +> outl 0xcf8 0x80001004 +> outw 0xcfc 0x7 +> outl 0xc006 0x3aff9090 +> outl 0xcf8 0x8000100e +> outl 0xcfc 0x41005e1e +> write 0x3b00002 0x1 0x5e +> write 0x3b00004 0x1 0x5e +> write 0x3aff5e6 0x1 0x11 +> write 0x3aff5eb 0x1 0xc6 +> write 0x3aff5ec 0x1 0xc6 +> write 0x7 0x1 0xff +> write 0x8 0x1 0xfb +> write 0xc 0x1 0x11 +> write 0xe 0x1 0x5e +> write 0x5e8 0x1 0x11 +> write 0x5ec 0x1 0xc6 +> outl 0x410e 0x10e +> EOF +> +> +> qemu-fuzz-i386: /exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. +> ==789== ERROR: libFuzzer: deadly signal +> #8 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 +> #9 in address_space_unmap /exec.c:3623:9 +> #10 in dma_memory_unmap /include/sysemu/dma.h:145:5 +> #11 in virtqueue_unmap_sg /hw/virtio/virtio.c:690:9 +> #12 in virtqueue_fill /hw/virtio/virtio.c:843:5 +> #13 in virtqueue_push /hw/virtio/virtio.c:917:5 +> #14 in virtio_blk_req_complete /hw/block/virtio-blk.c:83:5 +> #15 in virtio_blk_handle_request /hw/block/virtio-blk.c:671:13 +> #16 in virtio_blk_handle_vq /hw/block/virtio-blk.c:780:17 +> #17 in virtio_queue_notify_aio_vq /hw/virtio/virtio.c:2324:15 +> #18 in virtio_queue_host_notifier_aio_read /hw/virtio/virtio.c:3495:9 +> #19 in aio_dispatch_handler /util/aio-posix.c:328:9 +> #20 in aio_dispatch_handlers /util/aio-posix.c:371:20 +> #21 in aio_dispatch /util/aio-posix.c:381:5 +> #22 in aio_ctx_dispatch /util/async.c:306:5 +> #23 in g_main_context_dispatch +> +> +> With -trace virtio\* +> +> ... +> [S +0.099667] OK +> [R +0.099681] write 0x5ec 0x1 0xc6 +> OK +> [S +0.099690] OK +> [R +0.099700] outl 0x410e 0x10e +> 29575@1596590112.074339:virtio_queue_notify vdev 0x62d000030590 n 0 vq 0x7f9b93fc9800 +> 29575@1596590112.074423:virtio_blk_data_plane_start dataplane 0x60600000f260 +> OK +> [S +0.099833] OK +> 29575@1596590112.076459:virtio_queue_notify vdev 0x62d000030590 n 0 vq 0x7f9b93fc9800 +> 29575@1596590112.076642:virtio_blk_handle_read vdev 0x62d000030590 req 0x611000043e80 sector 0 nsectors 0 +> 29575@1596590112.076651:virtio_blk_req_complete vdev 0x62d000030590 req 0x611000043e80 status 1 +> qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. +> +> +> -Alex +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1890360/+subscriptions +> + + +Fix: + +commit 7bd04a041addcdef6a03e6498aafaea55ca6e88b +Author: Stefan Hajnoczi <email address hidden> +Date: Thu Sep 17 10:44:54 2020 +0100 + + virtio-blk: undo destructive iov_discard_*() operations + +Released with QEMU v5.2.0. + diff --git a/results/classifier/zero-shot/108/all/1893691 b/results/classifier/zero-shot/108/all/1893691 new file mode 100644 index 000000000..b689fe216 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1893691 @@ -0,0 +1,146 @@ +other: 0.986 +debug: 0.983 +semantic: 0.981 +permissions: 0.980 +vnc: 0.979 +socket: 0.979 +performance: 0.979 +files: 0.979 +graphic: 0.979 +network: 0.978 +PID: 0.977 +KVM: 0.977 +device: 0.977 +boot: 0.976 + +Chardev logfile is not written (regression between 5.0 and 5.1) + +After update from version 5.0 to 5.1, logfile stopped being populated with console output. The file is being created, but remains empty. + +Relevant command line options: + +-mon chardev=char0 +-serial chardev:char0 +-chardev socket,host=127.0.0.10,port=2323,server,nowait,telnet,mux=on,id=char0,logfile=/home/jurkiew/.machiner/runs/2020-08-31T21:46:55-0/internal/log + + +Full command line: + +qemu-system-x86_64 +-nodefaults +-no-user-config +-snapshot +-enable-kvm +-cpu +host +-nographic +-echr +17 +-mon +chardev=char0 +-serial +chardev:char0 +-rtc +clock=vm +-object +rng-random,filename=/dev/urandom,id=rng0 +-device +virtio-rng-pci,rng=rng0,max-bytes=512,period=1000 +-name +2020-08-31T21:46:55-0,debug-threads=on +-smp +sockets=1,cores=9,threads=2 +-m +251G +-overcommit +cpu-pm=on +-pidfile +/home/jurkiew/.machiner/runs/2020-08-31T21:46:55-0/internal/pid +-net +nic,model=virtio +-net +user,hostfwd=tcp:127.0.0.10:2222-:22,hostfwd=tcp:127.0.0.10:8000-:8000,hostfwd=tcp:127.0.0.10:9000-:9000 +-fsdev +local,id=machiner_internal_dir,security_model=none,path=/home/jurkiew/.machiner/runs/2020-08-31T21:46:55-0/internal +-device +virtio-9p-pci,fsdev=machiner_internal_dir,mount_tag=machiner_internal_dir +-fsdev +local,id=machiner_lower_dir,security_model=none,readonly,path=. +-device +virtio-9p-pci,fsdev=machiner_lower_dir,mount_tag=machiner_lower_dir +-fsdev +local,id=machiner_upper_dir,security_model=mapped-xattr,fmode=0777,dmode=0777,path=/home/jurkiew/.machiner/runs/2020-08-31T21:46:55-0 +-device +virtio-9p-pci,fsdev=machiner_upper_dir,mount_tag=machiner_upper_dir +-device +virtio-scsi +-drive +if=none,file=/home/jurkiew/.machiner/images/famtar/image.qcow2,discard=on,id=famtar +-device +scsi-hd,drive=famtar +-chardev +socket,host=127.0.0.10,port=2323,server,nowait,telnet,mux=on,id=char0,logfile=/home/jurkiew/.machiner/runs/2020-08-31T21:46:55-0/internal/log + +(Subscribing Dan Berrange as char person). + +Is there any chance you could bisect to see the exact change? + +This regression is specific to the "socket" chardev and was caused by this commit: + +commit 271094474b65de1ad7aaf729938de3d9b9d0d36f (refs/bisect/bad) +Author: Dima Stepanov <email address hidden> +Date: Thu May 28 12:11:18 2020 +0300 + + char-socket: return -1 in case of disconnect during tcp_chr_write + + During testing of the vhost-user-blk reconnect functionality the qemu + SIGSEGV was triggered: + start qemu as: + x86_64-softmmu/qemu-system-x86_64 -m 1024M -M q35 \ + -object memory-backend-file,id=ram-node0,size=1024M,mem-path=/dev/shm/qemu,share=on \ + -numa node,cpus=0,memdev=ram-node0 \ + -chardev socket,id=chardev0,path=./vhost.sock,noserver,reconnect=1 \ + -device vhost-user-blk-pci,chardev=chardev0,num-queues=4 --enable-kvm + start vhost-user-blk daemon: + ./vhost-user-blk -s ./vhost.sock -b test-img.raw + + If vhost-user-blk will be killed during the vhost initialization + process, for instance after getting VHOST_SET_VRING_CALL command, then + QEMU will fail with the following backtrace: + + Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. + 0x00005555559272bb in vhost_user_read (dev=0x7fffef2d53e0, msg=0x7fffffffd5b0) + at ./hw/virtio/vhost-user.c:260 + 260 CharBackend *chr = u->user->chr; + + #0 0x00005555559272bb in vhost_user_read (dev=0x7fffef2d53e0, msg=0x7fffffffd5b0) + at ./hw/virtio/vhost-user.c:260 + #1 0x000055555592acb8 in vhost_user_get_config (dev=0x7fffef2d53e0, config=0x7fffef2d5394 "", config_len=60) + at ./hw/virtio/vhost-user.c:1645 + #2 0x0000555555925525 in vhost_dev_get_config (hdev=0x7fffef2d53e0, config=0x7fffef2d5394 "", config_len=60) + at ./hw/virtio/vhost.c:1490 + #3 0x00005555558cc46b in vhost_user_blk_device_realize (dev=0x7fffef2d51a0, errp=0x7fffffffd8f0) + at ./hw/block/vhost-user-blk.c:429 + #4 0x0000555555920090 in virtio_device_realize (dev=0x7fffef2d51a0, errp=0x7fffffffd948) + at ./hw/virtio/virtio.c:3615 + #5 0x0000555555a9779c in device_set_realized (obj=0x7fffef2d51a0, value=true, errp=0x7fffffffdb88) + at ./hw/core/qdev.c:891 + ... + + The problem is that vhost_user_write doesn't get an error after + disconnect and try to call vhost_user_read(). The tcp_chr_write() + routine should return -1 in case of disconnect. Indicate the EIO error + if this routine is called in the disconnected state. + + Signed-off-by: Dima Stepanov <email address hidden> + Reviewed-by: Marc-André Lureau <email address hidden> + Message-Id: <email address hidden> + Reviewed-by: Michael S. Tsirkin <email address hidden> + Signed-off-by: Michael S. Tsirkin <email address hidden> + + + +https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg04809.html + +Released with QEMU v5.2.0. + diff --git a/results/classifier/zero-shot/108/all/1894818 b/results/classifier/zero-shot/108/all/1894818 new file mode 100644 index 000000000..04dfd0ae6 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1894818 @@ -0,0 +1,324 @@ +permissions: 0.986 +device: 0.982 +debug: 0.980 +PID: 0.979 +boot: 0.979 +performance: 0.978 +other: 0.978 +semantic: 0.977 +graphic: 0.976 +network: 0.976 +files: 0.968 +socket: 0.966 +vnc: 0.955 +KVM: 0.931 + +COLO's guest VNC client hang after failover + +Hello, + +After setting up COLO's primary and secondary VMs, +I installed the vncserver and xrdp (apt install tightvncserver xrdp) inside the VM. + +I access the VM from another PC via VNC/RDP client, and everything is OK. +Then, kill the primary VM and issue the failover commands. + +The expected result is that the VNC/RDP client can resume after failover. +But in my test, the VNC client's screen hangs and cannot be recovered no longer. + +BTW, it works well after killing SVM. + +Thanks. + +Regards, +Derek + +On Tue, 08 Sep 2020 10:25:52 -0000 +Launchpad Bug Tracker <email address hidden> wrote: + +> You have been subscribed to a public bug by Derek Su (dereksu): +> +> Hello, +> +> After setting up COLO's primary and secondary VMs, +> I installed the vncserver and xrdp (apt install tightvncserver xrdp) inside the VM. +> +> I access the VM from another PC via VNC/RDP client, and everything is OK. +> Then, kill the primary VM and issue the failover commands. +> +> The expected result is that the VNC/RDP client can reconnect and resume +> automatically after failover. (I've confirmed the VNC/RDP client can +> reconnect automatically.) +> +> But in my test, the VNC client's screen hangs and cannot be recovered no +> longer. (I need to restart VNC client by myself.) +> +> BTW, it works well after killing SVM. +> +> Here is my QEMU networking device +> ``` +> -device virtio-net-pci,id=e0,netdev=hn0 \ +> -netdev tap,id=hn0,br=br0,vhost=off,helper=/usr/local/libexec/qemu-bridge-helper \ +> ``` +> +> Thanks. +> +> Regards, +> Derek +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + +Hello, +Can you show the full qemu command line? + +Regards, +Lukas Straub + + +Hi, Lukas + +It caused by the advanced watchdog (AWD) feature instead of COLO itself. +I will check it if my misuse or not, thanks. + +Best regards, + +Derek + +Lukas Straub <email address hidden> 於 2020年9月8日 週二 下午8:30寫道： + +> On Tue, 08 Sep 2020 10:25:52 -0000 +> Launchpad Bug Tracker <email address hidden> wrote: +> +> > You have been subscribed to a public bug by Derek Su (dereksu): +> > +> > Hello, +> > +> > After setting up COLO's primary and secondary VMs, +> > I installed the vncserver and xrdp (apt install tightvncserver xrdp) +> inside the VM. +> > +> > I access the VM from another PC via VNC/RDP client, and everything is OK. +> > Then, kill the primary VM and issue the failover commands. +> > +> > The expected result is that the VNC/RDP client can reconnect and resume +> > automatically after failover. (I've confirmed the VNC/RDP client can +> > reconnect automatically.) +> > +> > But in my test, the VNC client's screen hangs and cannot be recovered no +> > longer. (I need to restart VNC client by myself.) +> > +> > BTW, it works well after killing SVM. +> > +> > Here is my QEMU networking device +> > ``` +> > -device virtio-net-pci,id=e0,netdev=hn0 \ +> > -netdev +> tap,id=hn0,br=br0,vhost=off,helper=/usr/local/libexec/qemu-bridge-helper \ +> > ``` +> > +> > Thanks. +> > +> > Regards, +> > Derek +> > +> > ** Affects: qemu +> > Importance: Undecided +> > Status: New +> > +> +> Hello, +> Can you show the full qemu command line? +> +> Regards, +> Lukas Straub +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1894818 +> +> Title: +> COLO's guest VNC client hang after failover +> +> Status in QEMU: +> New +> +> Bug description: +> Hello, +> +> After setting up COLO's primary and secondary VMs, +> I installed the vncserver and xrdp (apt install tightvncserver xrdp) +> inside the VM. +> +> I access the VM from another PC via VNC/RDP client, and everything is OK. +> Then, kill the primary VM and issue the failover commands. +> +> The expected result is that the VNC/RDP client can reconnect and +> resume automatically after failover. (I've confirmed the VNC/RDP +> client can reconnect automatically.) +> +> But in my test, the VNC client's screen hangs and cannot be recovered +> no longer. I need to restart VNC client by myself. +> +> BTW, it works well after killing SVM. +> +> Here is my QEMU networking device +> ``` +> -device virtio-net-pci,id=e0,netdev=hn0 \ +> -netdev +> tap,id=hn0,br=br0,vhost=off,helper=/usr/local/libexec/qemu-bridge-helper \ +> ``` +> +> Thanks. +> +> Regards, +> Derek +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1894818/+subscriptions +> + + +Hi, Lukas + +After fixing the misuse of AWD. +There is still a high probability of the VNC/RDP client hangs after PVM died and SVM takeover. + +Here are the steps. + +1. Start PVM script +``` +imagefolder="/mnt/nfs2/vms" + + qemu-system-x86_64 -enable-kvm -cpu qemu64,+kvmclock -m 4096 -smp 2 -qmp stdio \ + -device piix3-usb-uhci -device usb-tablet -name primary \ + -device virtio-net-pci,id=e0,netdev=hn0 \ + -netdev tap,id=hn0,br=br0,vhost=off,helper=/usr/local/libexec/qemu-bridge-helper \ + -chardev socket,id=mirror0,host=0.0.0.0,port=9003,server,nowait \ + -chardev socket,id=compare1,host=0.0.0.0,port=9004,server,wait \ + -chardev socket,id=compare0,host=127.0.0.1,port=9001,server,nowait \ + -chardev socket,id=compare0-0,host=127.0.0.1,port=9001 \ + -chardev socket,id=compare_out,host=127.0.0.1,port=9005,server,nowait \ + -chardev socket,id=compare_out0,host=127.0.0.1,port=9005 \ + -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0 \ + -object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out \ + -object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0 \ + -object iothread,id=iothread1 \ + -object colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,\ +outdev=compare_out0,iothread=iothread1 \ + -drive if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\ +children.0.file.filename=$imagefolder/primary.qcow2,children.0.driver=qcow2 -vnc :0 -S +``` + +2. Start SVM script +``` +#!/bin/bash + +imagefolder="/mnt/nfs2/vms" +primary_ip=127.0.0.1 + +qemu-img create -f qcow2 $imagefolder/secondary-active.qcow2 100G +qemu-img create -f qcow2 $imagefolder/secondary-hidden.qcow2 100G + +qemu-system-x86_64 -enable-kvm -cpu qemu64,+kvmclock -m 4096 -smp 2 -qmp stdio \ +-device piix3-usb-uhci -device usb-tablet -name secondary \ +-device virtio-net-pci,id=e0,netdev=hn0 \ +-netdev tap,id=hn0,br=br0,vhost=off,helper=/usr/local/libexec/qemu-bridge-helper \ +-chardev socket,id=red0,host=$primary_ip,port=9003,reconnect=1 \ +-chardev socket,id=red1,host=$primary_ip,port=9004,reconnect=1 \ +-object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 \ +-object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1 \ +-object filter-rewriter,id=rew0,netdev=hn0,queue=all \ +-drive if=none,id=parent0,file.filename=$imagefolder/secondary.qcow2,driver=qcow2 \ +-drive if=none,id=childs0,driver=replication,mode=secondary,file.driver=qcow2,\ +top-id=colo-disk0,file.file.filename=$imagefolder/secondary-active.qcow2,\ +file.backing.driver=qcow2,file.backing.file.filename=$imagefolder/secondary-hidden.qcow2,\ +file.backing.backing=parent0 \ +-drive if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,children.0=childs0 \ +-vnc :1 \ +-incoming tcp:0.0.0.0:9998 +``` + +3. On Secondary VM's QEMU monitor, issue command +{'execute':'qmp_capabilities'} +{'execute': 'nbd-server-start', 'arguments': {'addr': {'type': 'inet', 'data': {'host': '0.0.0.0', 'port': '9999'} } } } +{'execute': 'nbd-server-add', 'arguments': {'device': 'parent0', 'writable': true } } + +4. On Primary VM's QEMU monitor, issue command: +{'execute':'qmp_capabilities'} +{'execute': 'human-monitor-command', 'arguments': {'command-line': 'drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.2,file.port=9999,file.export=parent0,node-name=replication0'}} +{'execute': 'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', 'node': 'replication0' } } +{'execute': 'migrate-set-capabilities', 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true } ] } } +{'execute': 'migrate', 'arguments': {'uri': 'tcp:127.0.0.2:9998' } } + +5. kill PVM + +6. On SVM, issues +``` +{'execute': 'nbd-server-stop'} +{'execute': 'x-colo-lost-heartbeat'} + +{'execute': 'object-del', 'arguments':{ 'id': 'f2' } } +{'execute': 'object-del', 'arguments':{ 'id': 'f1' } } +{'execute': 'chardev-remove', 'arguments':{ 'id': 'red1' } } +{'execute': 'chardev-remove', 'arguments':{ 'id': 'red0' } } +``` + +I use "-device virtio-net-pci" here, but after replacing with "-device rtl8139", +the behavior seems normal. +Is "-device virtio-net-pci" available in COLO? + +Thanks. + +Regards, +Derek + + +Hi, + +I also tested some emulated nic devices and virtio network devices (in the attachment). + +The VNC client's screen cannot be recovered while using all virtio network devices and the emulated e1000e nic. + +Thanks. + +Regards, +Derek + + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1894869 b/results/classifier/zero-shot/108/all/1894869 new file mode 100644 index 000000000..ae68f099d --- /dev/null +++ b/results/classifier/zero-shot/108/all/1894869 @@ -0,0 +1,162 @@ +other: 0.989 +network: 0.988 +semantic: 0.987 +debug: 0.983 +files: 0.983 +device: 0.981 +socket: 0.980 +graphic: 0.980 +permissions: 0.978 +vnc: 0.977 +performance: 0.969 +PID: 0.967 +KVM: 0.963 +boot: 0.954 + +Chelsio T4 has old MSIX PBA offset bug + +There exists a bug with Chelsio NICs T4 that causes the following error: + +kvm: -device vfio-pci,host=0000:83:00.7,id=hostpci1.7,bus=pci.0,addr=0x11.7: vfio 0000:83:00.7: hardware reports invalid configuration, MSIX PBA outside of specified BAR + +I was working with a downstream Proxmox developer to try to fix this issue, and they provided me with the following change to make from line 1484 of hw/vfio/pci.c: + +static void vfio_msix_early_setup(VFIOPCIDevice *vdev, Error **errp) + * is 0x1000, so we hard code that here. + */ + if (vdev->vendor_id == PCI_VENDOR_ID_CHELSIO && +- (vdev->device_id & 0xff00) == 0x5800) { ++ ((vdev->device_id & 0xff00) == 0x5800 || ++ (vdev->device_id & 0xff00) == 0x1425)) { + msix->pba_offset = 0x1000; + } else if (vdev->msix_relo == OFF_AUTOPCIBAR_OFF) { + error_setg(errp, "hardware reports invalid configuration, " + +However, I found that this did not fix the issue, so the bug appears to work differently than the one that was present on the T5 NICs which has already been patched. I have attached the output of my lspci -nnkvv + + + +There are no BAR resources for this device: + +83:00.7 Ethernet controller [0200]: Chelsio Communications Inc Device [1425:0000] + Subsystem: Chelsio Communications Inc Device [1425:0000] + Physical Slot: 818 + Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + NUMA node: 1 + +Note the lack of any regions here. + + Capabilities: [40] Power Management version 3 + Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [48] MSI: Enable- Count=1/32 Maskable+ 64bit+ + Address: 0000000000000000 Data: 0000 + Masking: 00000000 Pending: 00000000 + Capabilities: [60] MSI-X: Enable- Count=32 Masked- + Vector table: BAR=4 offset=00000000 + PBA: BAR=4 offset=00001000 + +There is no BAR4 for either the vector table or the PBA, the device is broken. Maybe check dmesg for resource allocation errors. Note that a device ID of 0000 is also reported for this device. Does this device provide any useful function in the host outside of vfio? + +PS, this can never be true: + ++ (vdev->device_id & 0xff00) == 0x1425)) + +The lower byte would always be 00. It's the wrong fix anyway, BAR4 is still missing. + +There exists a bug with Chelsio NICs that causes the following error: + +kvm: -device vfio-pci,host=0000:83:00.7,id=hostpci1.7,bus=pci.0,addr=0x11.7: vfio 0000:83:00.7: hardware reports invalid configuration, MSIX PBA outside of specified BAR + +This bug was fixed in later versions of Qemu, and is caused by vendor misconfigurations of their MSIX PBA. I know a catchall fix was implemented in recent versions of Qemu, as well as patches applied to hotfix it in earlier versions. I encountered this bug using a Chelsio T4 device, and I believe the patches are for T5 and newer. + +Here is an email chain that has a patch for this situation: +https://patchwork.ozlabs.org/project<email address hidden>/ + +I'd appreciate it if anyone could tell me what the best course of action to fix it on my system would be. I assume the solution is to either build Qemu with this patch applied, or update the version of Qemu in my Proxmox installation, but I do not know which is the better route to go. + +The patch you mention is already included in our QEMU builds, but as you correctly said it's only implemented for T5 devices. + +You'd have to go about patching your QEMU yourself if you want this to work, or message the upstream QEMU maintainers to include a fix (or even better: provide them with the fix :) ). + +In any case, a full 'lspci -nnkvv' output for your device (and any virtual functions thereof) would help. + +I've attached a QEMU patch for you to try, it has "0xNNNN" instead of the actual device ID of your T4, so change that before applying the patch. No liability of this working at all, here be dragons and if it breaks everything you're on your own, but I believe it's simple enough to work, provided the hardware quirk is the same on T4 as on T5. + +You can find our QEMU downstream at https://git.proxmox.com/?p=pve-qemu.git;a=summary, if you put it in debian/patches/pve and mention the file in debian/patches/series you should be able to build a pve-qemu against it. Check out our developer documentation (https://pve.proxmox.com/wiki/Developer_Documentation) as well. + +Created attachment 614 +experimental T4 patch, change 0xNNNN to device id + +Created attachment 615 +Full output of lspci -nnkvv + +Created attachment 616 +Output of lspci -nnkvv with Chelsio devices only + +Thank you so much for your reply! I have attached the lspci you requested. I think the most recent version of qemu actually has a fix for all devices that give this error, as there were reports of some HBA cards also causing it. I would like to try applying your patch, however for several days now my builds of pve-qemu have been getting stopped by a missing dependency called libproxmox-backup-qemu0-dev. I have seen other people on the forums mention that it exists in the repository, but every time I git clone pve-qemu.git and attempt to build I get the same error. I thought it would be taken care of by mk-build-deps, but even that gets stopped by the same missing dependency. Apt install isn't able to find it either. Would you be able to tell me where I can find this dependency? + +You need to configure our PBS repository to get the library: + +# echo "deb http://download.proxmox.com/debian/pbs buster pbstest" >> /etc/apt/sources.list.d/pbs.list +# apt update +# apt install libproxmox-backup-qemu0-dev + +> I think the most recent version of qemu actually has a fix for all devices that give this error, as there were reports of some HBA cards also causing it. + +Hm, not sure about that, the patch I added is against our 5.1 build from the repo. That said, 5.1 is newer than what's currently rolled out, so you can also try just building the repo version without any patches and see if that fixes it. That would be nice, since 5.1 will be rolled out soon-ish anyway :) + +I managed to get the package installed. Apparently my sources.list was set to jessie instead of buster. Fixing this allowed me to download that package, however make still fails, but with new errors. Progress! I'll attach the errors, but I understand if helping me fix this is outside of what you're willing to help me with. +As a side note, the machine that I am configuring this on is not deployed, does not have a deadline for deployment, and has no data stored on it at all. As such, I'm willing to make just about any changes to it that you think might help, or that you may want to test. + +Created attachment 618 +New errors + +Hm, it appears your linker isn't finding the library. Try installing the 'libproxmox-backup-qemu0' package as well, that should have been a dependency of the -dev package though... Make sure /usr/lib/libproxmox_backup_qemu.so.0 exists. If you use "make deb" it also might be necessary to run the build as root. + +I ran into problems building it with the patch applied. I know how to correct those errors, but I decided to check if I could build without the patches and found that the build fails for other reasons, too. I have attached the new errors. I have attached the new output. + +Just so that I understand it correctly, does the value that PCI_VENDOR_ID_CHELSIO stores equal 1425? Since I have two of the same Chelsio NIC installed, would that mean that I have to insert both 8100 and 8300 as my device IDs for my two cards in the patch, and have it evaluate whether they are equal to the value at vdev->device_id for the if statement the same way you did? Or should I just be bale to do it with a single device ID? + +Created attachment 620 +New errors given by make after installing libproxmox-backup-qemu0 + +There's no relevant error in the output you posted? You should have two files 'pve-qemu-kvm_5.1.0-1_amd64.deb' and 'pve-qemu-kvm-dbg_5.1.0-1_amd64.deb' in the repository root now, which you can install with 'apt install ./*.deb' or similar. If not, you might need a 'make clean' before the 'make deb'. + +> Just so that I understand it correctly, does the value that +> PCI_VENDOR_ID_CHELSIO stores equal 1425? Since I have two of the same +> Chelsio NIC installed, would that mean that I have to insert both 8100 and +> 8300 as my device IDs for my two cards in the patch, and have it evaluate +> whether they are equal to the value at vdev->device_id for the if statement +> the same way you did? Or should I just be bale to do it with a single device +> ID? + +# rg "PCI_VENDOR_ID_CHELSIO" + include/hw/pci/pci_ids.h + 219:#define PCI_VENDOR_ID_CHELSIO 0x1425 + +Yes. + +And also yes, if you need two different device IDs you need to add more clauses to the 'or', e.g.: + + ((vdev->device_id & 0xff00) == 0x5800 || + (vdev->device_id & 0xff00) == 0x8100) || + (vdev->device_id & 0xff00) == 0x8300)) { + +Yes, you were right, I thought the warnings being set to evaluate as errors would stop the build, but I completely missed where it said it built the .deb packages. I got it built and installed this time, but I still get the same error when I attempt to boot a vm with the Chelsio cards. I have started a bug report with the upstream qemu devs. + +Yeah, I figured out that the logic behind that patch was failed and corrected it to get the same error again already. Just to clarify, it is two of the same card giving the same error. I ran dmesg --level=err, but got no output. In the full output of dmesg, though, I noticed that there are some problems with the nics, but I don't know enough about this to know if there's anything I can do about it. I included dmesg output here. I don't believe the nics are giving the host any functionality since I added the driver for them to the blacklist, so it shouldn't even be getting loaded by it. In case it's useful, I'm not sure if SR-IOV is enabled on these cards or not, though I'm trying to use PCI passthrough for my VMs. + +I don't understand the purpose of function 7 on these cards, the class code indicates an Ethernet device, but without any BARs, I very much doubt that the functions provide any useful service. Config space is invalid for the function as QEMU identifies, the referenced BAR resource for the MSI-X vector table and PBA is invalid. Without proving that the function provides an actual netdev interface in the host, I don't see any value to adding a quirk to work around the invalid MSI-X capability. The solution is to simply not assign this function to a VM. + +SR-IOV is not enable on these cards. Perhaps enabling SR-IOV would provide the additional NICs you're trying to assign. + +I was able to boot a VM with just the functions of the device with the ethernet controller function ID added as PCI devices. Something I noticed while adding in those devices though is that all of the others have a description associated with them in Proxmox, but the one that's causing the boot to fail doesn't. I attached a picture of the menu, 81:00.7 has no functions associated with it. So it seems like it just doesn't have any function at all? Unless it benefits QEMU to know whether turning SR-IOV on for these cards fixes the problem, I don't think I'm going to go through the process of turning it on, since the process looks terrible. Thank you for your help. + +The device ID on function 7 is 0x0000 which is typically not valid, there's no entry for it in the PCI IDs database. Someone from Chelsio would need to explain why it's even exposed, but there doesn't seem to be any value in quirking it since it provides no useful function. + +https://bugs.launchpad.net/qemu/+bug/1894869 + +Here's the discussion with the upstream devs. The problem ended up being on Chelsio's part as either the .7 funciton fo these cards should not have even been exposed to the OS in the first place, or SR-IOV is necessary to actually correct the parameters of this function. Unfortunately, it looks like SR-IOV is no longer possible to enable on these cards. Thank you for your help. + diff --git a/results/classifier/zero-shot/108/all/1895399 b/results/classifier/zero-shot/108/all/1895399 new file mode 100644 index 000000000..eddef7e8d --- /dev/null +++ b/results/classifier/zero-shot/108/all/1895399 @@ -0,0 +1,142 @@ +other: 0.986 +semantic: 0.981 +graphic: 0.977 +device: 0.974 +performance: 0.968 +debug: 0.967 +permissions: 0.966 +PID: 0.964 +files: 0.954 +vnc: 0.952 +socket: 0.949 +KVM: 0.940 +boot: 0.939 +network: 0.938 + +Docfix: add missing virtiofsd cache default 'auto' + +The usage command line for virtiofsd has: + +void fuse_cmdline_help(void) +{ + printf(" -h --help print help\n" +... + " -o cache=<mode> cache mode. could be one of \"auto, " + "always, none\"\n" + " default: auto\n" + + +But the default: auto info is missing from the man page. I suggest this patch: + +--- docs/tools/virtiofsd.rst 2020-09-10 18:07:45.380430677 -0500 ++++ /tmp/virtiofsd.rst 2020-09-12 11:48:10.440815204 -0500 +@@ -106,6 +106,7 @@ + forbids the FUSE client from caching to achieve best coherency at the cost of + performance. ``auto`` acts similar to NFS with a 1 second metadata cache + timeout. ``always`` sets a long cache lifetime at the expense of coherency. ++ The default is ``auto``. + + Examples + -------- + +On Sat, Sep 12, 2020 at 04:53:54PM -0000, Harry Coin wrote: +> Public bug reported: +> +> The usage command line for virtiofsd has: +> +> void fuse_cmdline_help(void) +> { +> printf(" -h --help print help\n" +> ... +> " -o cache=<mode> cache mode. could be one of \"auto, " +> "always, none\"\n" +> " default: auto\n" +> +> +> But the default: auto info is missing from the man page. I suggest this patch: +> +> --- docs/tools/virtiofsd.rst 2020-09-10 18:07:45.380430677 -0500 +> +++ /tmp/virtiofsd.rst 2020-09-12 11:48:10.440815204 -0500 +> @@ -106,6 +106,7 @@ +> forbids the FUSE client from caching to achieve best coherency at the cost of +> performance. ``auto`` acts similar to NFS with a 1 second metadata cache +> timeout. ``always`` sets a long cache lifetime at the expense of coherency. +> + The default is ``auto``. +> +> Examples +> -------- +> + +Thanks, that looks good. + +Please either submit a patch +(https://wiki.qemu.org/Contribute/SubmitAPatch) or reply with a line in +the following format so I can send a patch on your behalf: + + Signed-off-by: Full Name <email address hidden> + +The "Signed-off-by:" tag indicates that you are contributing under the +Developer Certificate of Origin (https://developercertificate.org/) that +QEMU, Linux, and other open source projects use. + + +On 9/14/20 5:08 AM, Stefan Hajnoczi wrote: +> On Sat, Sep 12, 2020 at 04:53:54PM -0000, Harry Coin wrote: +>> Public bug reported: +>> +>> The usage command line for virtiofsd has: +>> +>> void fuse_cmdline_help(void) +>> { +>> printf(" -h --help print help\n" +>> ... +>> " -o cache=<mode> cache mode. could be one of \"auto, " +>> "always, none\"\n" +>> " default: auto\n" +>> +>> +>> But the default: auto info is missing from the man page. I suggest this patch: +>> +>> --- docs/tools/virtiofsd.rst 2020-09-10 18:07:45.380430677 -0500 +>> +++ /tmp/virtiofsd.rst 2020-09-12 11:48:10.440815204 -0500 +>> @@ -106,6 +106,7 @@ +>> forbids the FUSE client from caching to achieve best coherency at the cost of +>> performance. ``auto`` acts similar to NFS with a 1 second metadata cache +>> timeout. ``always`` sets a long cache lifetime at the expense of coherency. +>> + The default is ``auto``. +>> +>> Examples +>> -------- +>> +> Thanks, that looks good. +> +> Please either submit a patch +> (https://wiki.qemu.org/Contribute/SubmitAPatch) or reply with a line in +> the following format so I can send a patch on your behalf: +> +> Signed-off-by: Full Name <email address hidden> +> +> The "Signed-off-by:" tag indicates that you are contributing under the +> Developer Certificate of Origin (https://developercertificate.org/) that +> QEMU, Linux, and other open source projects use. +> +OK. First time for everything: + +Signed-off-by: Harry G. Coin <email address hidden> + + + + +On Mon, Sep 14, 2020 at 02:53:57PM -0000, Harry Coin wrote: +> OK. First time for everything: +> +> Signed-off-by: Harry G. Coin <email address hidden> + +Thank you. I posted your patch to the QEMU mailing list with your +authorship information: +https://<email address hidden>/ + + +Fix had been included here: +https://gitlab.com/qemu-project/qemu/-/commit/f1303afe222759105f + diff --git a/results/classifier/zero-shot/108/all/1895471 b/results/classifier/zero-shot/108/all/1895471 new file mode 100644 index 000000000..18f3d58ed --- /dev/null +++ b/results/classifier/zero-shot/108/all/1895471 @@ -0,0 +1,94 @@ +other: 0.983 +graphic: 0.979 +debug: 0.975 +permissions: 0.972 +semantic: 0.972 +device: 0.971 +performance: 0.966 +socket: 0.961 +PID: 0.957 +boot: 0.942 +vnc: 0.942 +files: 0.927 +network: 0.917 +KVM: 0.913 + +compilation error with clang in util/async.c + +configured with ` CC=clang CXX=clang++ ../configure --target-list=x86_64-softmmu --enable-kvm --enable-curl --enable-debug --enable-jemalloc --enable-fuzzing --enable-sdl` and after make I get the following error related to c11 atomics. I'm using clang because I'm experimenting with fuzzer + +[glitz@archlinux /code/qemu/build]$ ninja -j5 +[479/2290] Compiling C object libqemuutil.a.p/util_async.c.o +FAILED: libqemuutil.a.p/util_async.c.o +clang -Ilibqemuutil.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/p11-kit-1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -Ilinux-headers -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Werror -std=gnu99 -g -m64 -mcx16 -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-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -fstack-protector-strong -fsanitize=fuzzer-no-link -iquote /code/qemu/tcg/i386 -isystem /code/qemu/linux-headers -iquote . -iquote /code/qemu -iquote /code/qemu/accel/tcg -iquote /code/qemu/include -iquote /code/qemu/disas/libvixl -pthread -fPIC -MD -MQ libqemuutil.a.p/util_async.c.o -MF libqemuutil.a.p/util_async.c.o.d -o libqemuutil.a.p/util_async.c.o -c ../util/async.c +../util/async.c:79:17: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid) + old_flags = atomic_fetch_or(&bh->flags, BH_PENDING | new_flags); + ^ ~~~~~~~~~~ +/usr/lib/clang/10.0.1/include/stdatomic.h:138:42: note: expanded from macro 'atomic_fetch_or' +#define atomic_fetch_or(object, operand) __c11_atomic_fetch_or(object, operand, __ATOMIC_SEQ_CST) + ^ ~~~~~~ +../util/async.c:105:14: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid) + *flags = atomic_fetch_and(&bh->flags, + ^ ~~~~~~~~~~ +/usr/lib/clang/10.0.1/include/stdatomic.h:144:43: note: expanded from macro 'atomic_fetch_and' +#define atomic_fetch_and(object, operand) __c11_atomic_fetch_and(object, operand, __ATOMIC_SEQ_CST) + ^ ~~~~~~ +2 errors generated. +[483/2290] Compiling C object libqemuutil.a.p/util_qemu-error.c.o +ninja: build stopped: subcommand failed. + +On Sun, Sep 13, 2020 at 06:56:12PM -0000, Amey Narkhede wrote: +> configured with ` CC=clang CXX=clang++ ../configure --target- +> list=x86_64-softmmu --enable-kvm --enable-curl --enable-debug --enable- +> jemalloc --enable-fuzzing --enable-sdl` and after make I get the +> following error related to c11 atomics. I'm using clang because I'm +> experimenting with fuzzer +> +> [glitz@archlinux /code/qemu/build]$ ninja -j5 +> [479/2290] Compiling C object libqemuutil.a.p/util_async.c.o +> FAILED: libqemuutil.a.p/util_async.c.o +> clang -Ilibqemuutil.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/p11-kit-1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -Ilinux-headers -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Werror -std=gnu99 -g -m64 -mcx16 -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-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -fstack-protector-strong -fsanitize=fuzzer-no-link -iquote /code/qemu/tcg/i386 -isystem /code/qemu/linux-headers -iquote . -iquote /code/qemu -iquote /code/qemu/accel/tcg -iquote /code/qemu/include -iquote /code/qemu/disas/libvixl -pthread -fPIC -MD -MQ libqemuutil.a.p/util_async.c.o -MF libqemuutil.a.p/util_async.c.o.d -o libqemuutil.a.p/util_async.c.o -c ../util/async.c +> ../util/async.c:79:17: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid) +> old_flags = atomic_fetch_or(&bh->flags, BH_PENDING | new_flags); +> ^ ~~~~~~~~~~ +> /usr/lib/clang/10.0.1/include/stdatomic.h:138:42: note: expanded from macro 'atomic_fetch_or' +> #define atomic_fetch_or(object, operand) __c11_atomic_fetch_or(object, operand, __ATOMIC_SEQ_CST) +> ^ ~~~~~~ +> ../util/async.c:105:14: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid) +> *flags = atomic_fetch_and(&bh->flags, +> ^ ~~~~~~~~~~ +> /usr/lib/clang/10.0.1/include/stdatomic.h:144:43: note: expanded from macro 'atomic_fetch_and' +> #define atomic_fetch_and(object, operand) __c11_atomic_fetch_and(object, operand, __ATOMIC_SEQ_CST) +> ^ ~~~~~~ +> 2 errors generated. +> [483/2290] Compiling C object libqemuutil.a.p/util_qemu-error.c.o +> ninja: build stopped: subcommand failed. + +This happens when a system header file includes <stdatomic.h>. QEMU's +"atomic.h" conflicts with <stdatomic.h> in that QEMU atomic variables do +not need to be declared _Atomic. + +Please rerun the full clang command-line above from your meson build +directory with -E instead of -c. Then upload the +libqemuutil.a.p/util_async.c.o so we can see why stdatomic.h was +included. + + +Ok. So I attached the util_async.o file below + +On Mon, Sep 14, 2020 at 10:52:16AM -0000, Amey Narkhede wrote: +> Ok. So I attached the util_async.o file below + +It looks like you can work around this issue with ./configure --disable-linux-io-uring. + +I'll investigate what can be done to solve the interference between +<stdatomic.h> and QEMU's "atomic.h" next week. + + +Mailing list discussion about how to fix this: +https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg07392.html + +I think this has been fixed here: +https://gitlab.com/qemu-project/qemu/-/commit/d73415a315471a +... so I'm closing this now. If you still have problems, please open a new ticket in our new issue tracker here: https://gitlab.com/qemu-project/qemu/-/issues + diff --git a/results/classifier/zero-shot/108/all/1896096 b/results/classifier/zero-shot/108/all/1896096 new file mode 100644 index 000000000..d6cc758a8 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1896096 @@ -0,0 +1,435 @@ +device: 0.958 +other: 0.954 +debug: 0.948 +permissions: 0.945 +vnc: 0.945 +performance: 0.942 +network: 0.936 +KVM: 0.933 +semantic: 0.932 +PID: 0.932 +boot: 0.928 +files: 0.927 +socket: 0.923 +graphic: 0.918 + +Git version: Build process is broken in block_curl.c.o + +Gcc version: 10.2.0 +Glusterfs: 8.1 +Libguestfs: 1.42 + +Configure options used: + +configure \ + --prefix=/usr \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --libexecdir=/usr/lib/qemu \ + --extra-ldflags="$LDFLAGS" \ + --smbd=/usr/bin/smbd \ + --enable-modules \ + --enable-sdl \ + --disable-werror \ + --enable-slirp=system \ + --enable-xfsctl \ + --audio-drv-list="pa alsa sdl" + +Error log attached. Here is the beginning: + +/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib/Scrt1.o: in function `_start': +(.text+0x24): undefined reference to `main' +/usr/bin/ld: libblock-curl.a(block_curl.c.o): in function `curl_block_init': + + + +Please give more info on your host OS build environment, and most importantly confirm that you have tried doing a build from a *completely* clean git checkout. Recent build system changes introduced risk of problems if you have not done a full clean. "git clean -f -x -d" will delete every file in your git checkout that is not committed, ensuring you are starting from a pristine checkout. + +I'm using Archlinux. Trying right now a build from scratch and I will report asap. Keeping fingers crossed. + +Build process is still broken even with a blank new version of git source code. + + +Once again, everything start while processing block_curl.so. + +Here is the beginning of the error log: + +Linking target block-curl.so +/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib/Scrt1.o: in function `_start': +(.text+0x24): undefined reference to `main' +/usr/bin/ld: libblock-curl.a(block_curl.c.o): in function `curl_block_init': + + +Curl version: 7.72.0 if it matters. + +Attaching error log. + + + +Can you attach the full build log, including all the "configure" output, and ideally pass "V=1" as an arg to 'make' + +Full build log from start to crash. + +Nothing looks especially unusual there, but clear it is failing to link the block-curl.so as a library and is instead linking it as an executable and thus failing to find "main". I can't explain why that would be the case. + +From log: +> The Meson build system +> Version: 0.55.3 + +Perhaps a(nother) problem with meson? + +Try "meson=git" + +Added Paolo for his Meson expertize in case he can spot the flaw + +Tried meson-git, and it is still breaking on the same file. No luck here. + +Can you do the build using "make V=1" so that we actually see the compiler command lines used in the log file. + +Log with make V=1 as requested. + +cc -o block-curl.so -Wl,--as-needed -Wl,--allow-shlib-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,block-curl.so -Wl,--whole-archive libblock-curl.a -Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -m64 -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -fstack-protector-strong -O2 -g -fPIE -DPIE -std=gnu99 -Wall -g -pie -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now libmodule-common.a -lcurl -Wl,--export-dynamic -pthread -lgmodule-2.0 -lglib-2.0 -lglib-2.0 -Wl,--end-group + +It could be because of -pie overriding -shared. You wrote that you have --extra-ldflags="$LDFLAGS" but what is $LDFLAGS? + +When I looked at /etc/makepkg.conf on my Archlinux, I found; LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" + + +Please attach config-host.mak and config.log. Hopefully that is enough to blame one of you, :) configure, meson.build or Meson itself. + + + + + +The problem is caused by the extra flags you're forcing on the compiler: + +Using 'CFLAGS' from environment with value: '-O2 -g -fPIE -DPIE -std=gnu99 -Wall' +Using 'LDFLAGS' from environment with value: '-g -pie -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' +Using 'CPPFLAGS' from environment with value: '-D_FORTIFY_SOURCE=2' + +Most particularly the "-pie" in LDFLAGS. This is only valid for executables, not shared libraries, and thus it breaks the build. + +I used these settings until Qemu 5.1.0 was released and it worked. These flags are used by archlinux for stable qemu release packaging. + +See https://github.com/archlinux/svntogit-packages/blob/packages/qemu/trunk/PKGBUILD + +Since qemu moved to meson, it breaks. I don't know why it used to work before. Thanks for your answer anyway. + + + +FYI, QEMU automatically enables PIC/PIE as needed, so there's no need to set it via these flags. + +In fact everything in your $CFLAGS is already set by QEMU out of the box too. + +For LDFLAGS you can cull the -g and -pie + +Before the meson port, the "-pie" arg was on the CLI *before* the "-shared" arg so the "-shared" wins and results in a shared library. + +After the meson port, "-shared" appears first, and so "-pie" wins and tries to create an executable. + +IOW, this passing of -pie was always wrong, and it was only by luck that it didn't break the build before. + +So, I'll try to tweak LDFLAGS and if it doesn't work, well... That's life. Thanks for the infos. + +Even with LDFLAGS tweaking, it breaks. Anyway, thanks for your help here. + +What's your new configure command line? Attach the config.log and make V=1 +log again please. + +That said, I noticed that the flags were included twice in the linker +command line so maybe you've only removed them in one place. + +Il ven 18 set 2020, 18:20 Frederic Bezies <email address hidden> ha +scritto: + +> Even with LDFLAGS tweaking, it breaks. Anyway, thanks for your help +> here. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1896096 +> +> Title: +> Git version: Build process is broken in block_curl.c.o +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1896096/+subscriptions +> +> + + +FWIW, I reproduced the original failure using your LDFLAGS, and tested that removing '-pie' made it work + +Configure line: configure \ + --prefix=/usr \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --libexecdir=/usr/lib/qemu \ + --smbd=/usr/bin/smbd \ + --extra-ldflags="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" \ + --enable-modules \ + --enable-sdl \ + --disable-werror \ + --enable-slirp=system \ + --enable-xfsctl \ + --audio-drv-list="pa alsa sdl" + +And qemu log build using make -V=1. + +Hope it helps. + +You have to unset LDFLAGS, or remove -pie. Specifying --extra-ldflags is +useless because Meson already obeys the LDFLAGS environment variable. + +Il ven 18 set 2020, 19:11 Frederic Bezies <email address hidden> ha +scritto: + +> And qemu log build using make -V=1. +> +> Hope it helps. +> +> ** Attachment added: "qemuv1-2.log" +> +> https://bugs.launchpad.net/qemu/+bug/1896096/+attachment/5412260/+files/qemuv1-2.log +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1896096 +> +> Title: +> Git version: Build process is broken in block_curl.c.o +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1896096/+subscriptions +> +> + + +Chiming in here as the user who initially suggested Arch use this: + +--extra-ldflags="$LDFLAGS" + +qemu-5.0.0 introduced a breaking change whereby LDFLAGS from the environment were ignored. For Arch, this resulted in exclusion of `--as-needed' from the link, which naturally caused dependency chaos. + +The Arch Build System globally sets CFLAGS and LDFLAGS in the build environment to try and ensure all pkgs are built to distro standards. The build systems for most pkgs in the distro respect FLAGS from the environment. + +When qemu-5.2.0 is released, Arch will obviously need to adapt to account for Meson changes. + + + +Huh. I thought we ignored the environment LDFLAGS/CFLAGS from much earlier than 5.0 and was about to ask if honouring it was a change introduced with the Meson switch! My (not necessarily very considered) opinion is that generally it's better not to honour the environment CFLAGS and LDFLAGS because they can have all sorts of random stuff in them that just doesn't work in complicated cases like QEMU, as in this example where they included "-pie". --extra-ldflags has the semantics of "add these on top of whatever the standard set of QEMU build flags is" so the user doesn't need to try to specify absolutely everything, and it's clear from the configure line that extra non-default options are being added. + + +Just for your information, I added this before configure and it is still broken: export LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" + + +I think I'll wait until Qemu 5.2.0 is released to see how Archlinux will fix this annoying behaviour. + +You can include the output of the build to help debugging this further failure. + +LDFLAGS has legitimate used but I think it would make sense to fail configure if LDFLAGS contains -pie. Perhaps Meson could do so as well. + +Building log while settings LDFLAGS as is: export LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" + +Nope, something is overriding your LDFLAGS and adding -pie back. Please +open a bug on Arch, if they want to enable PIE by default they can do it in +gcc and binutils. + +Adding -pie to LDFLAGS is as nonsensical as adding -shared. + + +Well, I'll wait until qemu 5.2.0 is released to see how archlinux work around this problem. Thanks anyway for your help. + +Looking deeper into this... I believe there are indeed qemu bugs here. + +It's actually the qemu configure script which is adding `-pie' + +$ echo $LDFLAGS +-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now + +Yet meson-logs/meson-log.txt tells me that: + +Using 'LDFLAGS' from environment with value: '-g -pie -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' + +Where did the `-pie' come from? Answer: the qemu configure script! + +https://git.qemu.org/?p=qemu.git;a=blob;f=configure;h=756447900855e0b886ec6eb4e6b6aecf48c20a97;hb=HEAD#l2250 + +Simply unsetting LDFLAGS allows the build to complete successfully. + +Not only that, qemu is now ignoring my user supplied CFLAGS from the environment. I haven't analysed this one yet but I'm starting to realise this hybrid meson/configure script approach is quite complicated. + + + + + + + + + + +Il dom 20 set 2020, 00:40 Toolybird <email address hidden> ha scritto: + +> Looking deeper into this... I believe there are indeed qemu bugs here. +> + +You're right. + +$ cat test +#! /bin/sh +echo before +env | grep LDFLAGS +LDFLAGS="-pie $LDFLAGS" +echo after +env | grep LDFLAGS + +$ ./test +before +after + +$ LDFLAGS='-Wl,--as-needed' ./test before +LDFLAGS=-Wl,--as-needed +after +LDFLAGS=-pie -Wl,--as-needed + +Because changes to environment variables propagate without having to export +them again. + +So we need to unset CFLAGS and LDFLAGS in the configure script. + +Paolo + + +> So we need to unset CFLAGS and LDFLAGS in the configure script. + +Yes, but is this what you really want? It seems to go against standard practice. The usual expectation is even documented in Meson docs: + +https://mesonbuild.com/howtox.html#set-extra-compiler-and-linker-flags-from-the-outside-when-eg-building-distro-packages + +Yes, qemu is a complex beast and I understand why you want full control over the build. But it certainly will make life harder for downstream distros/users who like to build pkgs with their own preferred options. + +BTW, --extra-ldflags="my additional linker option" seems to work. +But --extra-cflags="my additional compiler switch" seems to also add it to the link line which seems a bit odd? + +From configure script: + +--extra-cflags=*) QEMU_CFLAGS="$QEMU_CFLAGS $optarg" + QEMU_LDFLAGS="$QEMU_LDFLAGS $optarg" + +The whole conversion to Meson is clearly a massive effort and deserves big praise :) But as a clueless end user, I wonder why you didn't just bite the bullet and go full Meson (à la Libvirt) and get rid of the configure script completely? + +> But --extra-cflags="my additional compiler switch" seems to +> also add it to the link line which seems a bit odd? + +That's due to LTO. IIRC autotools do the same (after all +the linking step is a "cc" invocation), but I may be wrong. + +> I wonder why you didn't just bite the bullet and go full Meson +> (à la Libvirt) and get rid of the configure script completely? + +Because that would have been 8000 more lines to convert and +more bugs that would not have been caught before the merge. +The problem with having custom Makefiles is that some rebases +were horrible. When going from 4.2 to 5.1, there were a couple +merge commits that took me one day each! In addition, compared +to Libvirt adding new source files seemed much more common in QEMU. + +Basically the conversion was merged in the "worst possible +state that can already be considered an improvement", in order +to focus on fixing bugs and progressing in the conversion, +rather than on rebases. I must admit it was a bit worse than +expected, but as long as maintainers have not been blocked in +their work it's still more or less going according to plan. + +Posted "[PATCH 0/4] configure: bugfixes and cleanups for CFLAGS". + +> Posted "[PATCH 0/4] configure: bugfixes and cleanups for CFLAGS". + +(sorry for delay) + +Thanks for the patches. They seem to fix the Arch case i.e. build succeeds without hacks and FLAGS in the build env are being respected. + +However, I tested the "unset FLAGS" case and patch 4/4 seems to cause a weird failure I don't understand: + +../qemu/meson.build:1:0: ERROR: Unable to determine dynamic linker + +A full log can be found at /build/qemu-git/src/build-full/meson-logs/meson-log.txt + +ERROR: meson setup failed + +There is nothing in meson-log to indicate the failure reason. Any ideas? + + + +Yes that's a silly mistake that invokes the linker with a dummy empty +argument. I'll fix it and repost, thanks for testing on Arch! + +Paolo + +Il mar 22 set 2020, 23:41 Toolybird <email address hidden> ha scritto: + +> ** Attachment added: "meson-log.txt" +> +> https://bugs.launchpad.net/qemu/+bug/1896096/+attachment/5413347/+files/meson-log.txt +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1896096 +> +> Title: +> Git version: Build process is broken in block_curl.c.o +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1896096/+subscriptions +> +> + + +v2 patches appear to work fine in both test scenarios. Thanks again. + +Just asking: any hope to see this patch added to qemu git source code? + +Yes, of course. + +Il mer 30 set 2020, 21:25 Frederic Bezies <email address hidden> ha +scritto: + +> Just asking: any hope to see this patch added to qemu git source code? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1896096 +> +> Title: +> Git version: Build process is broken in block_curl.c.o +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1896096/+subscriptions +> +> + + +Hi Paolo, + +The CFLAGS patches seem to have missed your last big pull req: + +[PULL v8 00/86] Misc QEMU patches for 2020-09-24 + +Apparently disappeared between v3 and v4. Oversight or intentional? Thanks. + + + +Intentional because they possibly broke one of the build scenarios that are tested pre-pull (even though the GitLab CI was fine, it does not yet cover everything). + +The plan is to flush my queue until there's only the current 5 pending meson patches, and then submit those in isolation. + +New version of the patches posted: + +[PATCH 0/4] Convert remaining submodules to meson, cleanup env var handling + +This will sidestep the issue that broke in the Sep 24 pull request. + diff --git a/results/classifier/zero-shot/108/all/1896298 b/results/classifier/zero-shot/108/all/1896298 new file mode 100644 index 000000000..a8a6ab1e7 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1896298 @@ -0,0 +1,192 @@ +permissions: 0.991 +other: 0.990 +debug: 0.989 +network: 0.987 +device: 0.986 +performance: 0.983 +boot: 0.982 +socket: 0.981 +graphic: 0.981 +PID: 0.979 +semantic: 0.979 +vnc: 0.977 +KVM: 0.967 +files: 0.964 + +TCG memory leak with FreeDOS 'edit' + +qemu trunk as of today leaks memory FAST when freedos' edit is running. + +To reproduce, download: + +https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/cdrom.iso + +Then run: + +$ qemu-system-i386 -cdrom cdrom.iso + +select your language then select "return to DOS", then type + +> edit + +it will consume memory at ~10MB/s + +This does NOT happen when adding -enable-kvm + +Note, this also occurs with freeDOS 1.2, at least. + +Note 2, 4.2 stable does not exhibit the bug. + + +Confirmed, this is still reproducible with the current v5.2-rc4... + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/283 + + +Just to repeat the work around discussed on the GitLab page: -accel tcg,tb-size=32 will prevent the rapid increase of memory due to self modifying code. + +There are two justifications for making this change. The first is that +i386 emulation is typically for smaller machines where having a 1gb of +generated code is overkill for basic emulation. The second is the +propensity of self-modifying code (c.f. Doom/edit) utilised on i386 +systems can trigger a rapid growth in invalidated and re-translated +buffers. This is seen in bug #283. Execution is still inefficient but +at least the host memory isn't so aggressively used up. + +That said it's still really just a sticking plaster for user +convenience. + +Signed-off-by: Alex Bennée <email address hidden> +Cc: Thomas Huth <email address hidden> +Cc: <email address hidden> +--- + accel/tcg/translate-all.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c +index 640ff6e3e7..f442165674 100644 +--- a/accel/tcg/translate-all.c ++++ b/accel/tcg/translate-all.c +@@ -951,9 +951,13 @@ static void page_lock_pair(PageDesc **ret_p1, tb_page_addr_t phys1, + * Users running large scale system emulation may want to tweak their + * runtime setup via the tb-size control on the command line. + */ ++#ifdef TARGET_I386 ++#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (32 * MiB) ++#else + #define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (1 * GiB) + #endif + #endif ++#endif + + #define DEFAULT_CODE_GEN_BUFFER_SIZE \ + (DEFAULT_CODE_GEN_BUFFER_SIZE_1 < MAX_CODE_GEN_BUFFER_SIZE \ +-- +2.20.1 + + + + +Alex Bennée <email address hidden> writes: + +> There are two justifications for making this change. The first is that +> i386 emulation is typically for smaller machines where having a 1gb of +> generated code is overkill for basic emulation. The second is the +> propensity of self-modifying code (c.f. Doom/edit) utilised on i386 +> systems can trigger a rapid growth in invalidated and re-translated +> buffers. This is seen in bug #283. Execution is still inefficient but +> at least the host memory isn't so aggressively used up. +> +> That said it's still really just a sticking plaster for user +> convenience. + +ping? + + +-- +Alex Bennée + + + +Richard Henderson <email address hidden> writes: + +> On 5/25/21 9:45 AM, Alex Bennée wrote: +>> There are two justifications for making this change. The first is that +>> i386 emulation is typically for smaller machines where having a 1gb of +>> generated code is overkill for basic emulation. The second is the +>> propensity of self-modifying code (c.f. Doom/edit) utilised on i386 +>> systems can trigger a rapid growth in invalidated and re-translated +>> buffers. This is seen in bug #283. Execution is still inefficient but +>> at least the host memory isn't so aggressively used up. +>> That said it's still really just a sticking plaster for user +>> convenience. +>> Signed-off-by: Alex Bennée <email address hidden> +>> Cc: Thomas Huth <email address hidden> +>> Cc: <email address hidden> +>> --- +>> accel/tcg/translate-all.c | 4 ++++ +>> 1 file changed, 4 insertions(+) +>> diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c +>> index 640ff6e3e7..f442165674 100644 +>> --- a/accel/tcg/translate-all.c +>> +++ b/accel/tcg/translate-all.c +>> @@ -951,9 +951,13 @@ static void page_lock_pair(PageDesc **ret_p1, tb_page_addr_t phys1, +>> * Users running large scale system emulation may want to tweak their +>> * runtime setup via the tb-size control on the command line. +>> */ +>> +#ifdef TARGET_I386 +>> +#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (32 * MiB) +>> +#else +>> #define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (1 * GiB) +>> #endif +>> #endif +>> +#endif +>> #define DEFAULT_CODE_GEN_BUFFER_SIZE \ +>> (DEFAULT_CODE_GEN_BUFFER_SIZE_1 < MAX_CODE_GEN_BUFFER_SIZE \ +>> +> +> I'm not thrilled, as it is ultra-hacky. + +I don't disagree. + +> (1) I've got a re-org of this code out for review: +> https://<email address hidden>/ + +OK I'll have a look at that. + +> (2) I'm keen to reorg TCG such that it gets compiled once. There's +> currently nothing standing in the way of that except work. But this +> would introduce a use of a target-specific define for the first time +> into tcg/. I guess I could leave the default sizing back in +> accel/tcg/ and pass in the default. +> +> Other options? + +Some random thoughts in no particular order: + + - a separately flushable translation region for code we detect as SMC heavy + + - a front-end interpreter for SMC code + + - smarter code generation that dynamically loads values from codemem + (usually the SMC code is just tweaking an #imm value) + +None of these seem particularly amenable to a clean non-complex +implementation though. A front-end interpreter would be useful for other +things though - it could even be incomplete and handle only common code +patterns falling back to full generation for anything it can't handle. + +> +> +> r~ + + +-- +Alex Bennée + + diff --git a/results/classifier/zero-shot/108/all/1898490 b/results/classifier/zero-shot/108/all/1898490 new file mode 100644 index 000000000..7d2902847 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1898490 @@ -0,0 +1,157 @@ +debug: 0.978 +semantic: 0.970 +other: 0.969 +permissions: 0.968 +boot: 0.965 +performance: 0.961 +socket: 0.958 +device: 0.958 +files: 0.958 +PID: 0.956 +graphic: 0.955 +network: 0.951 +vnc: 0.937 +KVM: 0.902 + +gtk with virtio and opengl black screen + +qemu-system-x86_64 -name manjaro -enable-kvm -cpu host -smp cores=4,threads=1 -M q35 -m 8G -cdrom /mnt/Storage/ISO/manjaro-gnome-20.0.3-minimal-200606-linux56.iso -machine type=pc,accel=kvm -vga virtio -display sdl,gl=on Boots properly and has working 3d acceleration with virgl. + +Running qemu-system-x86_64 -name manjaro -enable-kvm -cpu host -smp cores=4,threads=1 -M q35 -m 8G -cdrom /mnt/Storage/ISO/manjaro-gnome-20.0.3-minimal-200606-linux56.iso -machine type=pc,accel=kvm -vga virtio -display gtk,gl=on however, (difference being gtk instead of sdl), the screen is black, and the vm still starts. + +System Specs +Gentoo Linux 64bit +Gentoo-Sources 5.8.13 Kernel +Qemu 5.10.0-r1 compiled with USE="aio bzip2 caps curl fdt filecaps gtk jpeg ncurses nls opengl oss pin-upstream-blobs png pulseaudio sdl seccomp slirp spice usb usbredir vhost-net virgl vnc xattr xkb" PYTHON_TARGETS="python3_7" QEMU_SOFTMMU_TARGETS="x86_64" QEMU_USER_TARGETS="x86_64" + +Ryzen 7 2700x +Nvidia 1070ti GPU + +I can confirm the same issue when using libvirt with opengl. + + + +Hello Christian, + +I should have pointed that the log is from the Android system, not Qemu or my host system ! + +I got the failure message running the following command in an Android shell : + +logcat '*:F' + +(which means display log entries from all facilities (*), with the Fatal (F) severity) + +It seems indeed that Fosshub has a hosting problem with the Android-x86 images, I'll have to report this to the project maintainer. + +You seem to experience the same crash as I do. Bootloader OK, the GUI is responsive at the beginning, and it crashes after a variable amount of time. + +You're right, the bug #1898490 looks like it could be related, I don't see the virgl=on option, but I suppose it's on by default. + +I normally have those messages on my Qemu instance : +gl_version 45 - core profile enabled +GLSL feature level 430 +virtio_input_hid_handle_status: unknown type 20 +virtio_input_hid_handle_status: unknown type 20 + +The virtio_input_hid messages don't seem to be a problem, and certainly unrelated to the Android 9.0 crashing problem since at the time I tried with other, non-virtio input devices, I didn't have that message but it was still crashing the same way. + +It happens that I have that "stale GL error" from time to time, that almost always corresponds to an app not displaying properly in Android. Generally, quitting and restarting the app solves the problem, but not always, there are cases and Android apps that never worked correctly with virglrenderer, such as Armello. + +So, virglrenderer seems less stable with Android (or is it virtio-vga ?). In particular, switching from the surfaceflinger OpenGL display to a VGA, non-OpenGL console display (Alt+F1) never worked correctly (Alt+F7 to go back to the surfaceflinger display). + +However, as I said before, it seems to me it shouldn't behave differently depending on which display, GTK or SDL, is used. + +Concerning other frontends, I'm not familiar with those since my setup isn't headless : I'm not a server guy, I run the emulator on my laptop, so apart from GTK and SDL, it's not clear to me if I could run something else that would give me 3D acceleration. Moreover, my hardware is more than 6 years old now, and lacks some virtualisation capabilities that could serve as an alternative to virglrenderer. + +Anyway virglrenderer is still pre 1.0 so I guess it's the prime suspect after all. + +I will upgrade to Groovy next month, I'll keep you informed on that (I may even try Qemu 5.0 before upgrading). + +Oops sorry, I misposted, is there any way to remove this ? + +I am having the same issue. Tested on Xubuntu 20.10 (qemu 5.0) and ArchLinux (qemu 5.2). + +Furthermore, SDL is broken too: In principle I get some output with SDL but its broken and not very usable. After some time (after starting the Desktop Env. - as far as I can tell), the screen also turns black as with GTK. + +When redirecting IO to stdio I get the following error message: + +## opengl error ## +gl_version 45 - core profile enabled +vrend_renderer_fill_caps: Entering with stale GL error: 1280 +GLSL feature level 430 + + +## startup command ## +qemu-system-x86_64 \ +-serial stdio \ +-m 8G \ +-enable-kvm \ +-vga virtio \ +-display gtk,gl=on \ +-machine q35 \ +-cpu host \ +-bios /usr/share/OVMF/x64/OVMF_CODE.fd \ +-boot order=d \ +-drive file=test.img,format=raw \ +-cdrom /media/os/xubuntu-20.10-desktop-amd64.iso + + +## hardware of host ## +ryzen 3700x on b450 chipset +geforce 1060 with latest nvidia drivers + + +When setting "-display gtk,gl=off" things work for GTK and SDL. + +## startup command ## +qemu-system-x86_64 \ +-serial stdio \ +-m 8G \ +-enable-kvm \ +-vga none -device virtio-vga,virgl=on \ +-display sdl,gl=off \ +-machine q35 \ +-cpu host \ +-bios /usr/share/OVMF/x64/OVMF_CODE.fd \ +-boot order=d \ +-drive file=test.img,format=raw \ +-cdrom /media/os/xubuntu-20.10-desktop-amd64.iso + +The problem is that Xfwm's built-in compositor and virgl don't play nice together. + +Work-around: Boot the VM with virgl=off (on the video device) or gl=off (on the display), run xfwm4-tweaks-settings in the VM, select the "Compositor" tab, and uncheck "Enable display compositing". Then shut down the VM and re-enable virgl. + +picom works with Xfwm and doesn't seem to have the same issues, so if you want a compositor, install/use picom in the VM instead of using Xfwm's built-in compositor: https://wiki.archlinux.org/index.php/Picom + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1901440 b/results/classifier/zero-shot/108/all/1901440 new file mode 100644 index 000000000..c4fe7c3e2 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1901440 @@ -0,0 +1,139 @@ +permissions: 0.981 +socket: 0.980 +other: 0.972 +debug: 0.971 +semantic: 0.971 +graphic: 0.970 +performance: 0.970 +network: 0.968 +device: 0.966 +PID: 0.959 +files: 0.955 +vnc: 0.940 +boot: 0.938 +KVM: 0.923 + +Instability in IVSHMEM after updating QEMU 4.2 -> 5.0 + +Updating Ubuntu from 20.08 to 20.10 which updates QEMU from 4.2 to 5.0 results in the virtual machines freezing when the IVSHMEM interface is active. This workstation typically runs several windows 10 virtual machines that are accessed locally: two using the spice viewer and one that uses an passthrough assigned GPU accessed through a viewer called Looking Glass. Looking Glass uses the IVSHMEM device interface to pass captured frames from the windows virtual machine to the linux host for display by a viewer application. + +This workstation was 100% stable under Ubuntu 20.08 (QEMU 4.2). It handled a variety of heavy loads all day it never froze or crashed. It became unstable under Ubuntu 20.10 (QEMU 5.0), seemingly triggered by high levels of SHM activity. I was able to reliably reproduce the problem when playing a video in the looking-glass vm while playing another video in a spice vm. Other scenarios would also trigger this problem less reliably, but this video playback scenario would trigger it after 3-5 minutes of playback. + +The result of this new instability would manifest itself by all running vms on the host freezing but the host was not visibly effected. I could find no warnings or errors in any relevant system or QEMU logs. It wasn't just spice, when I accessed the gpu-passthru vm via directly assigned devices it was frozen, still outputting video of the last frame before the crash. All vms would have to be force-shutdown and the host rebooted to regain vm functionality. Just forcing shutdown and restarting a vm would result in showing 'running' status but it would be frozen and inaccessible until system reboot. + +I suspect this is a QEMU host / kernel error for several reasons: Having to reboot the host, insensitivity to VM changes including virtio-win version, etc. I suspect it's related to IVSHMEM due to the correlation of the freeze to the looking-glass related activity. + +This might be kernel / PCIe / power management related in some way. While experimenting to troubleshoot this issue I was able to trigger the error more quickly by disabling PCIe power management in the BIOS. + +The system was 100% stable under QEMU 5.0 when not running the looking-glass vm, quite stable when the looking-glass vm was idle or lightly used, but appeared increasingly unstable as SHM activity increased. + +Sorry if this is a bit anecdotal, this is my work machine and unfortunately today I was forced to rollback restore to Ubuntu 20.08 (QEMU 4.2) from backup so I can work on Monday. The system returned to 100% stability after returning to 20.08. + +If requested I can restore the Ubuntu 20.10 snapshot to reproduce & gather information as directed. + +Can you reproduce this with the latest upstream QEMU release (v5.1)? Or did you only try with the versions that ship with Ubuntu? + +This problem occurred with the QEMU 5.0 version that was distributed with the Ubuntu 20.10 update. + + + +Ok, so I'm moving this to the Ubuntu bug tracker. + +Hi Dave, +there is no Ubuntu 20.08 I'd know of I assume you mean 20.04 (Focal Fossa) as that would have qemu 4.2. +We'd need to start sorting out if this is a kernel or qemu issue. +Since you are know rolled back to 20.04 you might give [1] a try that just bumps the core virt components but keeps everything else on 20.04. + +Report back if that triggers the issue on Focal. If it does you can then go back to the packages of 21.04 one by one e.g. bios first, then libvirt, ... until we can pinpoint if it indeed is qemu or another package. +If instead it works with these builds then that implies we need to look at the kernel, in that case still speak up here please. + +[1]: https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports/ + + Hi Christian, +Thanks of your interest. Yes, meant to say Ubuntu 20.04.1 LTS. +This weekend if I have the time I'm going to install 20.10 on a separate partition and experiment on that. +Would you happen to know if anyone else is reporting similar problems? +If I find anything interesting I'll report back on this email thread. + On Tuesday, October 27, 2020, 08:30:51 AM PDT, Christian Ehrhardt <email address hidden> wrote: + + Hi Dave, +there is no Ubuntu 20.08 I'd know of I assume you mean 20.04 (Focal Fossa) as that would have qemu 4.2. +We'd need to start sorting out if this is a kernel or qemu issue. +Since you are know rolled back to 20.04 you might give [1] a try that just bumps the core virt components but keeps everything else on 20.04. + +Report back if that triggers the issue on Focal. If it does you can then go back to the packages of 21.04 one by one e.g. bios first, then libvirt, ... until we can pinpoint if it indeed is qemu or another package. +If instead it works with these builds then that implies we need to look at the kernel, in that case still speak up here please. + +[1]: https://launchpad.net/~canonical-server/+archive/ubuntu/server- +backports/ + +** Changed in: qemu (Ubuntu) + Status: New => Incomplete + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1901440 + +Title: + Instability in IVSHMEM after updating QEMU 4.2 -> 5.0 + +Status in qemu package in Ubuntu: + Incomplete + +Bug description: + Updating Ubuntu from 20.08 to 20.10 which updates QEMU from 4.2 to 5.0 + results in the virtual machines freezing when the IVSHMEM interface is + active. This workstation typically runs several windows 10 virtual + machines that are accessed locally: two using the spice viewer and + one that uses an passthrough assigned GPU accessed through a viewer + called Looking Glass. Looking Glass uses the IVSHMEM device interface + to pass captured frames from the windows virtual machine to the linux + host for display by a viewer application. + + This workstation was 100% stable under Ubuntu 20.08 (QEMU 4.2). It + handled a variety of heavy loads all day it never froze or crashed. + It became unstable under Ubuntu 20.10 (QEMU 5.0), seemingly triggered + by high levels of SHM activity. I was able to reliably reproduce the + problem when playing a video in the looking-glass vm while playing + another video in a spice vm. Other scenarios would also trigger this + problem less reliably, but this video playback scenario would trigger + it after 3-5 minutes of playback. + + The result of this new instability would manifest itself by all + running vms on the host freezing but the host was not visibly + effected. I could find no warnings or errors in any relevant system + or QEMU logs. It wasn't just spice, when I accessed the gpu-passthru + vm via directly assigned devices it was frozen, still outputting video + of the last frame before the crash. All vms would have to be force- + shutdown and the host rebooted to regain vm functionality. Just + forcing shutdown and restarting a vm would result in showing 'running' + status but it would be frozen and inaccessible until system reboot. + + I suspect this is a QEMU host / kernel error for several reasons: + Having to reboot the host, insensitivity to VM changes including + virtio-win version, etc. I suspect it's related to IVSHMEM due to the + correlation of the freeze to the looking-glass related activity. + + This might be kernel / PCIe / power management related in some way. + While experimenting to troubleshoot this issue I was able to trigger + the error more quickly by disabling PCIe power management in the BIOS. + + The system was 100% stable under QEMU 5.0 when not running the + looking-glass vm, quite stable when the looking-glass vm was idle or + lightly used, but appeared increasingly unstable as SHM activity + increased. + + Sorry if this is a bit anecdotal, this is my work machine and + unfortunately today I was forced to rollback restore to Ubuntu 20.08 + (QEMU 4.2) from backup so I can work on Monday. The system returned + to 100% stability after returning to 20.08. + + If requested I can restore the Ubuntu 20.10 snapshot to reproduce & + gather information as directed. + +To manage notifications about this bug go to: +https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1901440/+subscriptions + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1904206 b/results/classifier/zero-shot/108/all/1904206 new file mode 100644 index 000000000..21d5c117e --- /dev/null +++ b/results/classifier/zero-shot/108/all/1904206 @@ -0,0 +1,89 @@ +debug: 0.970 +permissions: 0.969 +graphic: 0.964 +semantic: 0.961 +PID: 0.955 +socket: 0.955 +device: 0.951 +network: 0.950 +boot: 0.946 +performance: 0.938 +other: 0.936 +files: 0.934 +KVM: 0.930 +vnc: 0.925 + +install QEMU + +I want install QEMU on Kali, I write : + +qemu-system-arm -kernel ~/qemu_vms/kernel-qemu-3.10.25-wheezy -cpu arm1176 -m 256 -M versatilepb -serial stdio -append "root=/dev/sda2 rootfstype=ext4 rw" -hda ~/qemu_vms/2020-08-20-raspios-buster-armhf-full.img -nic user,hostfwd=tcp::5022-:22 -no-reboot + +The answer : + +WARNING: Image format was not specified for '/home/kali/qemu_vms/2020-08-20-raspios-buster-armhf-full.img' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. +pulseaudio: set_sink_input_volume() failed +pulseaudio: Reason: Invalid argument +pulseaudio: set_sink_input_mute() failed +pulseaudio: Reason: Invalid argument +Uncompressing Linux... done, booting the kernel. + +I tried a lot of solutions but nothing worked. Please help + +QEMU is working fine, but your guest kernel has crashed. Either your guest kernel is the wrong one for the "versatilepb" machine type, or the kernel wants a dtb file and you are not passing one via QEMU's -dtb argument. + +Unless you like debugging "board bring-up" issues, I recommend that you find a good tutorial on running an Arm Linux system on QEMU and follow it; that will be faster than trying to diagnose and fix what config/kernel/etc mismatch you've made. + + + Thank you very much for your answer. I have already watched two tutorials, but it does not work. Do you have a tutorial for me? Thank you + +Regard + Le vendredi 13 novembre 2020 à 16:55:40 UTC+1, Peter Maydell <email address hidden> a écrit : + + QEMU is working fine, but your guest kernel has crashed. Either your +guest kernel is the wrong one for the "versatilepb" machine type, or the +kernel wants a dtb file and you are not passing one via QEMU's -dtb +argument. + +Unless you like debugging "board bring-up" issues, I recommend that you +find a good tutorial on running an Arm Linux system on QEMU and follow +it; that will be faster than trying to diagnose and fix what +config/kernel/etc mismatch you've made. + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1904206 + +Title: + install QEMU + +Status in QEMU: + New + +Bug description: + I want install QEMU on Kali, I write : + + qemu-system-arm -kernel ~/qemu_vms/kernel-qemu-3.10.25-wheezy -cpu + arm1176 -m 256 -M versatilepb -serial stdio -append "root=/dev/sda2 + rootfstype=ext4 rw" -hda ~/qemu_vms/2020-08-20-raspios-buster-armhf- + full.img -nic user,hostfwd=tcp::5022-:22 -no-reboot + + The answer : + + WARNING: Image format was not specified for '/home/kali/qemu_vms/2020-08-20-raspios-buster-armhf-full.img' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. + pulseaudio: set_sink_input_volume() failed + pulseaudio: Reason: Invalid argument + pulseaudio: set_sink_input_mute() failed + pulseaudio: Reason: Invalid argument + Uncompressing Linux... done, booting the kernel. + + I tried a lot of solutions but nothing worked. Please help + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1904206/+subscriptions + diff --git a/results/classifier/zero-shot/108/all/1905297 b/results/classifier/zero-shot/108/all/1905297 new file mode 100644 index 000000000..2cd8b4f99 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1905297 @@ -0,0 +1,133 @@ +permissions: 0.975 +other: 0.975 +debug: 0.971 +graphic: 0.968 +semantic: 0.967 +socket: 0.966 +vnc: 0.966 +performance: 0.962 +device: 0.962 +KVM: 0.961 +PID: 0.961 +files: 0.960 +boot: 0.952 +network: 0.947 + +Zynq7000 UART clock reset initialization + +Hello, + +we have come across a strange behavior in the Zynq7000 model of Qemu that seems to have been introduced between 5.0.0 and 5.1.0. + + +The reset values of the SLCR register, in particular those for UART_CLK_CTRL, are such that +the UARTs should find functional clocks. Up to 5.0.0 this was also the behavior that was +implemented in QEMU. + +Starting in 5.1.0, we found that - despite correct reset values [1] - the UARTs are non-functional +upon reset. Some investigation revealed that the cause for that is that the corresponding +clocks are not properly initialized. + +Between 5.0.0 and 5.1.0, there are three commits that touch the Zynq UART clocks [2]. The last of them [3] triggers the faulty behavior. + +Attached is a patch that applies 5.2.0-rc2 and yields a functional UART. We surmise that the +underlying device release issue runs much deeper, so it is only meant to identify the issue. + + + +[1] hw/misc/zynq_slcr.c + static void zynq_slcr_reset_init(Object *obj, ResetType type) + s->regs[R_UART_CLK_CTRL] = 0x00003F03; +[2] 38867cb7ec90..5b49a34c6800 +[3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad) + Author: Damien Hedde <email address hidden> + Date: Mon Apr 6 15:52:50 2020 +0200 + + + +Hi Michael, + +On 11/23/20 5:41 PM, Michael Peter wrote: +> Public bug reported: +> +> Hello, +> +> we have come across a strange behavior in the Zynq7000 model of Qemu +> that seems to have been introduced between 5.0.0 and 5.1.0. +> +> +> The reset values of the SLCR register, in particular those for UART_CLK_CTRL, are such that +> the UARTs should find functional clocks. Up to 5.0.0 this was also the behavior that was +> implemented in QEMU. +> +> Starting in 5.1.0, we found that - despite correct reset values [1] - the UARTs are non-functional +> upon reset. Some investigation revealed that the cause for that is that the corresponding +> clocks are not properly initialized. +> +> Between 5.0.0 and 5.1.0, there are three commits that touch the Zynq +> UART clocks [2]. The last of them [3] triggers the faulty behavior. +> +> Attached is a patch that applies 5.2.0-rc2 and yields a functional UART. We surmise that the +> underlying device release issue runs much deeper, so it is only meant to identify the issue. +> +> +> [1] hw/misc/zynq_slcr.c +> static void zynq_slcr_reset_init(Object *obj, ResetType type) +> s->regs[R_UART_CLK_CTRL] = 0x00003F03; +> [2] 38867cb7ec90..5b49a34c6800 +> [3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad) +> Author: Damien Hedde <email address hidden> +> Date: Mon Apr 6 15:52:50 2020 +0200 +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> ** Patch added: "0001-Initialize-Zynq7000-UART-clocks-on-reset.patch" +> https://bugs.launchpad.net/bugs/1905297/+attachment/5437267/+files/0001-Initialize-Zynq7000-UART-clocks-on-reset.patch +> + +Can you post your patch to the mailing list +please? See: +https://wiki.qemu.org/Contribute/SubmitAPatch#Do_not_send_as_an_attachment + +Note, you must sign your patch with a Signed-off-by: +line, see: +https://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line + +Regards, + +Phil. + + +Hi Phil, + +thanks for your advise and patience. + +I created a new patch (this time with a sign-off) and sent it to <email address hidden>. + +Since I have to use a corporate email system, I hope that the formatting is not gone. + +Best regards, + +Michael + +Has this been fixed in QEMU v6.0? + +[Expired for QEMU because there has been no activity for 60 days.] + +Any update? + +I guess the patch has never been sent to the qemu-devel mailing list and thus was never considered for inclusion. Anyway, let's move this ticket over to the new bug tracker at gitlab.com, maybe it gets more attention there... + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/468 + + +Michael your patch is still missing your Signed-off-tag. Can you re-attach it including it? +You can also use https://sr.ht/ to send the patch directly to the list. + diff --git a/results/classifier/zero-shot/108/all/1906693 b/results/classifier/zero-shot/108/all/1906693 new file mode 100644 index 000000000..d92a7aacd --- /dev/null +++ b/results/classifier/zero-shot/108/all/1906693 @@ -0,0 +1,191 @@ +device: 0.982 +other: 0.981 +permissions: 0.977 +graphic: 0.977 +debug: 0.975 +files: 0.975 +semantic: 0.973 +performance: 0.973 +PID: 0.970 +socket: 0.970 +vnc: 0.969 +boot: 0.966 +network: 0.966 +KVM: 0.964 + +Assertion Failure in bdrv_co_write_req_prepare through megasas + + affects qemu + subscribe <email address hidden> + subscribe <email address hidden> + subscribe <email address hidden> + subscribe <email address hidden> + +=== Stack Trace === +qemu-fuzz-i386: block/io.c:1835: int bdrv_co_write_req_prepare(BdrvChild *, int64_t, uint64_t, BdrvTrackedRequest *, int): Assertion `child->perm & BLK_PERM_WRITE' failed. +==1505128== ERROR: libFuzzer: deadly signal + #0 0x55a083b92cee in __sanitizer_print_stack_trace (qemu-fuzz-i386+0x793cee) + #1 0x55a083b6c1d1 in fuzzer::PrintStackTrace() (qemu-fuzz-i386+0x76d1d1) + #2 0x55a083b4f0d6 in fuzzer::Fuzzer::CrashCallback() (.part.0) (qemu-fuzz-i386+0x7500d6) + #3 0x55a083b4f19b in fuzzer::Fuzzer::StaticCrashSignalCallback() (qemu-fuzz-i386+0x75019b) + #4 0x7f8d24ed6a8f (/lib64/libpthread.so.0+0x14a8f) + #5 0x7f8d24d079e4 in raise (/lib64/libc.so.6+0x3c9e4) + #6 0x7f8d24cf0894 in abort (/lib64/libc.so.6+0x25894) + #7 0x7f8d24cf0768 in __assert_fail_base.cold (/lib64/libc.so.6+0x25768) + #8 0x7f8d24cffe75 in __assert_fail (/lib64/libc.so.6+0x34e75) + #9 0x55a08423763f in bdrv_co_write_req_prepare block/io.c:1835:13 + #10 0x55a0842343a8 in bdrv_aligned_pwritev block/io.c:1915:11 + #11 0x55a084233765 in bdrv_co_pwritev_part block/io.c:2104:11 + #12 0x55a084260d1a in blk_do_pwritev_part block/block-backend.c:1260:11 + #13 0x55a08426163e in blk_aio_write_entry block/block-backend.c:1476:17 + #14 0x55a0843b0d23 in coroutine_trampoline util/coroutine-ucontext.c:173:9 + #15 0x7f8d24d1d22f (/lib64/libc.so.6+0x5222f) + +=== Reproducer=== +cat << EOF | ./qemu-system-i386 -M q35 \ +-device megasas-gen2 -device scsi-cd,drive=null0 \ +-blockdev driver=null-co,read-zeroes=on,node-name=null0 \ +-monitor none -serial none -display none \ +-machine accel=qtest -m 64 -qtest stdio +outl 0xcf8 0x80001804 +outl 0xcfc 0xffffff +outl 0xcf8 0x8000181b +outl 0xcfc 0x7052005 +write 0x5cc0 0x1 0x03 +write 0x5cc7 0x1 0x40 +write 0x5ce0 0x1 0x0a +write 0x5cf3 0x1 0x01 +write 0x5cf7 0x1 0x40 +write 0x5cf8 0x1 0x0a +write 0x5cff 0x1 0x05 +write 0x5d03 0x1 0x5b +write 0x5d06 0x1 0x4f +write 0x5d0b 0x1 0x01 +write 0x5d0f 0x1 0x40 +write 0x5d10 0x1 0x0a +write 0x5d17 0x1 0x05 +write 0x5d1b 0x1 0x5b +write 0x5d1e 0x1 0x4f +write 0x5d23 0x1 0x01 +write 0x5d27 0x1 0x40 +write 0x5d28 0x1 0x0a +write 0x5d2f 0x1 0x05 +write 0x5d33 0x1 0x5b +write 0x5d36 0x1 0x4f +write 0x5d3b 0x1 0x01 +write 0x5d3f 0x1 0x40 +write 0x5d40 0x1 0x0a +write 0x5d47 0x1 0x05 +write 0x5d4b 0x1 0x5b +write 0x5d4e 0x1 0x4f +write 0x5d53 0x1 0x01 +write 0x5d57 0x1 0x40 +write 0x5d58 0x1 0x0a +write 0x5d5f 0x1 0x05 +write 0x5d63 0x1 0x5b +write 0x5d66 0x1 0x4f +write 0x5d6b 0x1 0x01 +write 0x5d6f 0x1 0x40 +write 0x5d70 0x1 0x0a +write 0x5d77 0x1 0x05 +write 0x5d7b 0x1 0x5b +write 0x5d7e 0x1 0x4f +write 0x5d83 0x1 0x01 +write 0x5d87 0x1 0x40 +write 0x5d88 0x1 0x0a +write 0x5d8f 0x1 0x05 +write 0x5d93 0x1 0x5b +write 0x5d96 0x1 0x4f +write 0x5d9b 0x1 0x01 +write 0x5d9f 0x1 0x40 +write 0x5da0 0x1 0x0a +write 0x5da7 0x1 0x05 +write 0x5dab 0x1 0x5b +write 0x5dae 0x1 0x4f +write 0x5db3 0x1 0x01 +write 0x5db7 0x1 0x40 +write 0x5db8 0x1 0x0a +write 0x5dbf 0x1 0x05 +write 0x5dc3 0x1 0x5b +write 0x5dc6 0x1 0x4f +write 0x5dcb 0x1 0x01 +write 0x5dcf 0x1 0x40 +write 0x5dd0 0x1 0x0a +write 0x5dd7 0x1 0x05 +write 0x5ddb 0x1 0x5b +write 0x5dde 0x1 0x4f +write 0x5de3 0x1 0x01 +write 0x5de7 0x1 0x40 +write 0x5de8 0x1 0x0a +write 0x5def 0x1 0x05 +write 0x5df3 0x1 0x5b +write 0x5df6 0x1 0x4f +write 0x5dfb 0x1 0x01 +write 0x5dff 0x1 0x40 +write 0x5e00 0x1 0x0a +write 0x5e07 0x1 0x05 +write 0x5e0b 0x1 0x5b +write 0x5e0e 0x1 0x4f +write 0x5e13 0x1 0x01 +write 0x5e17 0x1 0x40 +write 0x5e18 0x1 0x0a +write 0x5e1f 0x1 0x05 +write 0x5e23 0x1 0x5b +write 0x5e26 0x1 0x4f +write 0x5e2b 0x1 0x01 +write 0x5e2f 0x1 0x40 +write 0x5e30 0x1 0x0a +write 0x5e37 0x1 0x05 +write 0x5e3b 0x1 0x5b +write 0x5e3e 0x1 0x4f +write 0x5e43 0x1 0x01 +write 0x5e47 0x1 0x40 +write 0x5e48 0x1 0x0a +write 0x5e4f 0x1 0x05 +write 0x5e53 0x1 0x5b +write 0x5e56 0x1 0x4f +write 0x5e5b 0x1 0x01 +write 0x5e5f 0x1 0x40 +write 0x5e60 0x1 0x0a +write 0x5e67 0x1 0x05 +write 0x5e6b 0x1 0x5b +write 0x5e6e 0x1 0x4f +write 0x5e73 0x1 0x01 +write 0x5e77 0x1 0x40 +write 0x5e78 0x1 0x0a +write 0x5e7f 0x1 0x05 +write 0x5e83 0x1 0x5b +write 0x5e86 0x1 0x4f +write 0x5e8b 0x1 0x01 +write 0x5e8f 0x1 0x40 +write 0x5e90 0x1 0x0a +write 0x5e97 0x1 0x05 +write 0x5e9b 0x1 0x5b +write 0x5e9e 0x1 0x4f +write 0x5ea3 0x1 0x01 +write 0x5ea7 0x1 0x40 +write 0x5ea8 0x1 0x0a +write 0x5eaf 0x1 0x05 +write 0x5eb3 0x1 0x5b +write 0x5eb6 0x1 0x4f +write 0x5ebb 0x1 0x01 +write 0x5ebf 0x1 0x40 +write 0x5ec0 0x1 0x0a +write 0x5ec7 0x1 0x05 +write 0x5ecb 0x1 0x5b +write 0x5ece 0x1 0x4f +write 0x5ed3 0x1 0x01 +write 0x5ed7 0x1 0x40 +write 0x5ed8 0x1 0x0a +write 0x5edf 0x1 0x05 +write 0x5ee3 0x1 0x5b +write 0x5ee6 0x1 0x4f +write 0x5eeb 0x1 0x01 +write 0x5eef 0x1 0x40 +writeq 0x50000000000003b 0x15cd405b60101c8 +EOF + + + +https://gitlab.com/qemu-project/qemu/-/commit/86b1cf322789b79c8a + diff --git a/results/classifier/zero-shot/108/all/1906694 b/results/classifier/zero-shot/108/all/1906694 new file mode 100644 index 000000000..cd1300e0e --- /dev/null +++ b/results/classifier/zero-shot/108/all/1906694 @@ -0,0 +1,187 @@ +other: 0.984 +device: 0.981 +semantic: 0.976 +permissions: 0.973 +debug: 0.971 +graphic: 0.971 +files: 0.970 +performance: 0.966 +vnc: 0.963 +socket: 0.962 +PID: 0.961 +boot: 0.956 +KVM: 0.956 +network: 0.945 + +Assertion Failure in bdrv_co_write_req_prepare through megasas + + affects qemu + subscribe <email address hidden> + subscribe <email address hidden> + +=== Stack Trace === +qemu-fuzz-i386: block/io.c:1835: int bdrv_co_write_req_prepare(BdrvChild *, int64_t, uint64_t, BdrvTrackedRequest *, int): Assertion `child->perm & BLK_PERM_WRITE' failed. +==1505128== ERROR: libFuzzer: deadly signal + #0 0x55a083b92cee in __sanitizer_print_stack_trace (qemu-fuzz-i386+0x793cee) + #1 0x55a083b6c1d1 in fuzzer::PrintStackTrace() (qemu-fuzz-i386+0x76d1d1) + #2 0x55a083b4f0d6 in fuzzer::Fuzzer::CrashCallback() (.part.0) (qemu-fuzz-i386+0x7500d6) + #3 0x55a083b4f19b in fuzzer::Fuzzer::StaticCrashSignalCallback() (qemu-fuzz-i386+0x75019b) + #4 0x7f8d24ed6a8f (/lib64/libpthread.so.0+0x14a8f) + #5 0x7f8d24d079e4 in raise (/lib64/libc.so.6+0x3c9e4) + #6 0x7f8d24cf0894 in abort (/lib64/libc.so.6+0x25894) + #7 0x7f8d24cf0768 in __assert_fail_base.cold (/lib64/libc.so.6+0x25768) + #8 0x7f8d24cffe75 in __assert_fail (/lib64/libc.so.6+0x34e75) + #9 0x55a08423763f in bdrv_co_write_req_prepare block/io.c:1835:13 + #10 0x55a0842343a8 in bdrv_aligned_pwritev block/io.c:1915:11 + #11 0x55a084233765 in bdrv_co_pwritev_part block/io.c:2104:11 + #12 0x55a084260d1a in blk_do_pwritev_part block/block-backend.c:1260:11 + #13 0x55a08426163e in blk_aio_write_entry block/block-backend.c:1476:17 + #14 0x55a0843b0d23 in coroutine_trampoline util/coroutine-ucontext.c:173:9 + #15 0x7f8d24d1d22f (/lib64/libc.so.6+0x5222f) + +=== Reproducer=== +cat << EOF | ./qemu-system-i386 -M q35 \ +-device megasas-gen2 -device scsi-cd,drive=null0 \ +-blockdev driver=null-co,read-zeroes=on,node-name=null0 \ +-monitor none -serial none -display none \ +-machine accel=qtest -m 64 -qtest stdio +outl 0xcf8 0x80001804 +outl 0xcfc 0xffffff +outl 0xcf8 0x8000181b +outl 0xcfc 0x7052005 +write 0x5cc0 0x1 0x03 +write 0x5cc7 0x1 0x40 +write 0x5ce0 0x1 0x0a +write 0x5cf3 0x1 0x01 +write 0x5cf7 0x1 0x40 +write 0x5cf8 0x1 0x0a +write 0x5cff 0x1 0x05 +write 0x5d03 0x1 0x5b +write 0x5d06 0x1 0x4f +write 0x5d0b 0x1 0x01 +write 0x5d0f 0x1 0x40 +write 0x5d10 0x1 0x0a +write 0x5d17 0x1 0x05 +write 0x5d1b 0x1 0x5b +write 0x5d1e 0x1 0x4f +write 0x5d23 0x1 0x01 +write 0x5d27 0x1 0x40 +write 0x5d28 0x1 0x0a +write 0x5d2f 0x1 0x05 +write 0x5d33 0x1 0x5b +write 0x5d36 0x1 0x4f +write 0x5d3b 0x1 0x01 +write 0x5d3f 0x1 0x40 +write 0x5d40 0x1 0x0a +write 0x5d47 0x1 0x05 +write 0x5d4b 0x1 0x5b +write 0x5d4e 0x1 0x4f +write 0x5d53 0x1 0x01 +write 0x5d57 0x1 0x40 +write 0x5d58 0x1 0x0a +write 0x5d5f 0x1 0x05 +write 0x5d63 0x1 0x5b +write 0x5d66 0x1 0x4f +write 0x5d6b 0x1 0x01 +write 0x5d6f 0x1 0x40 +write 0x5d70 0x1 0x0a +write 0x5d77 0x1 0x05 +write 0x5d7b 0x1 0x5b +write 0x5d7e 0x1 0x4f +write 0x5d83 0x1 0x01 +write 0x5d87 0x1 0x40 +write 0x5d88 0x1 0x0a +write 0x5d8f 0x1 0x05 +write 0x5d93 0x1 0x5b +write 0x5d96 0x1 0x4f +write 0x5d9b 0x1 0x01 +write 0x5d9f 0x1 0x40 +write 0x5da0 0x1 0x0a +write 0x5da7 0x1 0x05 +write 0x5dab 0x1 0x5b +write 0x5dae 0x1 0x4f +write 0x5db3 0x1 0x01 +write 0x5db7 0x1 0x40 +write 0x5db8 0x1 0x0a +write 0x5dbf 0x1 0x05 +write 0x5dc3 0x1 0x5b +write 0x5dc6 0x1 0x4f +write 0x5dcb 0x1 0x01 +write 0x5dcf 0x1 0x40 +write 0x5dd0 0x1 0x0a +write 0x5dd7 0x1 0x05 +write 0x5ddb 0x1 0x5b +write 0x5dde 0x1 0x4f +write 0x5de3 0x1 0x01 +write 0x5de7 0x1 0x40 +write 0x5de8 0x1 0x0a +write 0x5def 0x1 0x05 +write 0x5df3 0x1 0x5b +write 0x5df6 0x1 0x4f +write 0x5dfb 0x1 0x01 +write 0x5dff 0x1 0x40 +write 0x5e00 0x1 0x0a +write 0x5e07 0x1 0x05 +write 0x5e0b 0x1 0x5b +write 0x5e0e 0x1 0x4f +write 0x5e13 0x1 0x01 +write 0x5e17 0x1 0x40 +write 0x5e18 0x1 0x0a +write 0x5e1f 0x1 0x05 +write 0x5e23 0x1 0x5b +write 0x5e26 0x1 0x4f +write 0x5e2b 0x1 0x01 +write 0x5e2f 0x1 0x40 +write 0x5e30 0x1 0x0a +write 0x5e37 0x1 0x05 +write 0x5e3b 0x1 0x5b +write 0x5e3e 0x1 0x4f +write 0x5e43 0x1 0x01 +write 0x5e47 0x1 0x40 +write 0x5e48 0x1 0x0a +write 0x5e4f 0x1 0x05 +write 0x5e53 0x1 0x5b +write 0x5e56 0x1 0x4f +write 0x5e5b 0x1 0x01 +write 0x5e5f 0x1 0x40 +write 0x5e60 0x1 0x0a +write 0x5e67 0x1 0x05 +write 0x5e6b 0x1 0x5b +write 0x5e6e 0x1 0x4f +write 0x5e73 0x1 0x01 +write 0x5e77 0x1 0x40 +write 0x5e78 0x1 0x0a +write 0x5e7f 0x1 0x05 +write 0x5e83 0x1 0x5b +write 0x5e86 0x1 0x4f +write 0x5e8b 0x1 0x01 +write 0x5e8f 0x1 0x40 +write 0x5e90 0x1 0x0a +write 0x5e97 0x1 0x05 +write 0x5e9b 0x1 0x5b +write 0x5e9e 0x1 0x4f +write 0x5ea3 0x1 0x01 +write 0x5ea7 0x1 0x40 +write 0x5ea8 0x1 0x0a +write 0x5eaf 0x1 0x05 +write 0x5eb3 0x1 0x5b +write 0x5eb6 0x1 0x4f +write 0x5ebb 0x1 0x01 +write 0x5ebf 0x1 0x40 +write 0x5ec0 0x1 0x0a +write 0x5ec7 0x1 0x05 +write 0x5ecb 0x1 0x5b +write 0x5ece 0x1 0x4f +write 0x5ed3 0x1 0x01 +write 0x5ed7 0x1 0x40 +write 0x5ed8 0x1 0x0a +write 0x5edf 0x1 0x05 +write 0x5ee3 0x1 0x5b +write 0x5ee6 0x1 0x4f +write 0x5eeb 0x1 0x01 +write 0x5eef 0x1 0x40 +writeq 0x50000000000003b 0x15cd405b60101c8 +EOF + + + diff --git a/results/classifier/zero-shot/108/all/1909261 b/results/classifier/zero-shot/108/all/1909261 new file mode 100644 index 000000000..66b9c4f8d --- /dev/null +++ b/results/classifier/zero-shot/108/all/1909261 @@ -0,0 +1,75 @@ +debug: 0.949 +semantic: 0.946 +device: 0.943 +graphic: 0.942 +PID: 0.941 +permissions: 0.940 +KVM: 0.932 +other: 0.932 +performance: 0.922 +vnc: 0.921 +socket: 0.918 +network: 0.916 +files: 0.906 +boot: 0.905 + +[OSS-Fuzz] Issue 28929 xhci: ASSERT: xfer->packet.status != USB_RET_NAK + +=== Reproducer === + +./qemu-system-i386 -m 512M -machine q35,accel=qtest \ + -drive file=null-co://,if=none,format=raw,id=disk0 \ +-device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 \ +-device usb-bot -device usb-storage,drive=disk0 \ +-chardev null,id=cd0 -chardev null,id=cd1 \ +-device usb-braille,chardev=cd0 -device usb-ccid \ +-device usb-ccid -device usb-kbd -device usb-mouse \ +-device usb-serial,chardev=cd1 -device usb-tablet \ +-device usb-wacom-tablet -device usb-audio \ +-qtest stdio -nographic -nodefaults < attachment + +=== Stack Trace === +#0 raise +#1 abort +#2 libc.so.6 +#3 __assert_fail +#4 xhci_kick_epctx /src/qemu/hw/usb/hcd-xhci.c:1865:13 +#5 xhci_ep_kick_timer /src/qemu/hw/usb/hcd-xhci.c:1034:5 +#6 timerlist_run_timers /src/qemu/util/qemu-timer.c:574:9 +#7 qemu_clock_run_timers /src/qemu/util/qemu-timer.c:588:12 +#8 qtest_clock_warp /src/qemu/softmmu/qtest.c:356:9 +#9 qtest_process_command /src/qemu/softmmu/qtest.c:752:9 +#10 qtest_process_inbuf /src/qemu/softmmu/qtest.c:797:9 +#11 qtest_server_inproc_recv /src/qemu/softmmu/qtest.c:904:9 +#12 send_wrapper /src/qemu/tests/qtest/libqtest.c:1390:5 +#13 qtest_sendf /src/qemu/tests/qtest/libqtest.c:438:5 +#14 qtest_clock_step_next /src/qemu/tests/qtest/libqtest.c:912:5 +#15 op_clock_step /src/qemu/tests/qtest/fuzz/generic_fuzz.c:574:5 + +OSS-Fuzz Report: +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28929 + + + +Full reproducer: +./qemu-system-i386 -m 512M -machine q35,accel=qtest \ + -drive file=null-co://,if=none,format=raw,id=disk0 \ +-device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 \ +-device usb-bot -device usb-storage,drive=disk0 \ +-chardev null,id=cd0 -chardev null,id=cd1 \ +-device usb-braille,chardev=cd0 -device usb-ccid \ +-device usb-ccid -device usb-kbd -device usb-mouse \ +-device usb-serial,chardev=cd1 -device usb-tablet \ +-device usb-wacom-tablet -device usb-audio \ +-qtest stdio -nographic -nodefaults < full_reproducer + +Still reproducible with the current qemu version from git (commit 7fe7fae8b48e3f9c647fd685) + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/544 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/zero-shot/108/all/1910586 b/results/classifier/zero-shot/108/all/1910586 new file mode 100644 index 000000000..d1ac01a5e --- /dev/null +++ b/results/classifier/zero-shot/108/all/1910586 @@ -0,0 +1,181 @@ +semantic: 0.986 +other: 0.985 +permissions: 0.984 +PID: 0.981 +debug: 0.978 +socket: 0.977 +network: 0.976 +performance: 0.976 +files: 0.973 +device: 0.968 +graphic: 0.966 +boot: 0.964 +vnc: 0.950 +KVM: 0.914 + +SD card size constraint conceptually wrong + +The patch discussed here: +https://<email address hidden>/msg720833.html +introduces an artificial size constraint for SD cards +that has no relation to reality. + +I'm trying to use an _actual_ **physical** SD card, +and qemu tells me its size is "invalid". + +Something here appears to be conceptually wrong. + +-------------------------------------------------- +# fdisk -l /dev/sdg +Disk /dev/sdg: 14.84 GiB, 15931539456 bytes, 31116288 sectors +Disk model: USB SD Reader +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes +Disklabel type: dos +Disk identifier: 0x7a0c8bb0 + +Device Boot Start End Sectors Size Id Type +/dev/sdg1 2048 524287 522240 255M c W95 FAT32 (LBA) +/dev/sdg2 524288 31116287 30592000 14.6G 83 Linux +# qemu-system-aarch64 -M raspi3 -m 1G -kernel vmlinuz-5.4.79-v8 -dtb bcm2837-rpi-3-b-plus.dtb -append console=ttyAMA0\ root=/dev/mmcblk0p2\ rw -nographic -serial mon:stdio -drive file=/dev/sdg,format=raw +qemu-system-aarch64: Invalid SD card size: 14.8 GiB +SD card size has to be a power of 2, e.g. 16 GiB. +You can resize disk images with 'qemu-img resize <imagefile> <new-size>' +(note that this will lose data if you make the image smaller than it currently is). +-------------------------------------------------- + +The same invocation with a dump of the actual image +resized to match qemu's odd expectations works fine. + + +This is on QEMU 5.2.0, as evidenced by the following: +-------------------------------------------------- +# qemu-system-aarch64 -version +QEMU emulator version 5.2.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +-------------------------------------------------- + +Is there a simple workaround that disables this rather +arbitrary constraint? + +On 1/7/21 8:24 PM, - wrote: +> Public bug reported: +> +> The patch discussed here: +> https://<email address hidden>/msg720833.html +> introduces an artificial size constraint for SD cards +> that has no relation to reality. +> +> I'm trying to use an _actual_ **physical** SD card, +> and qemu tells me its size is "invalid". +> +> Something here appears to be conceptually wrong. +> +> -------------------------------------------------- +> # fdisk -l /dev/sdg +> Disk /dev/sdg: 14.84 GiB, 15931539456 bytes, 31116288 sectors +> Disk model: USB SD Reader +> Units: sectors of 1 * 512 = 512 bytes +> Sector size (logical/physical): 512 bytes / 512 bytes +> I/O size (minimum/optimal): 512 bytes / 512 bytes +> Disklabel type: dos +> Disk identifier: 0x7a0c8bb0 +> +> Device Boot Start End Sectors Size Id Type +> /dev/sdg1 2048 524287 522240 255M c W95 FAT32 (LBA) +> /dev/sdg2 524288 31116287 30592000 14.6G 83 Linux +> # qemu-system-aarch64 -M raspi3 -m 1G -kernel vmlinuz-5.4.79-v8 -dtb bcm2837-rpi-3-b-plus.dtb -append console=ttyAMA0\ root=/dev/mmcblk0p2\ rw -nographic -serial mon:stdio -drive file=/dev/sdg,format=raw +> qemu-system-aarch64: Invalid SD card size: 14.8 GiB +> SD card size has to be a power of 2, e.g. 16 GiB. + +Your physical card likely is 16GiB. The firmware running +on it is free to reserve some amount to replace broken +blocks. In your case ~7%. + +We choose to restrict the model to the physical layer to +simplify the design and avoid to deal with security issues. + +Patches to improve the model by better matching the real +world are always welcomed! + +> You can resize disk images with 'qemu-img resize <imagefile> <new-size>' +> (note that this will lose data if you make the image smaller than it currently is). + +Indeed, we can remove this warning for block devices. + +> -------------------------------------------------- +> +> The same invocation with a dump of the actual image +> resized to match qemu's odd expectations works fine. +> +> +> This is on QEMU 5.2.0, as evidenced by the following: +> -------------------------------------------------- +> # qemu-system-aarch64 -version +> QEMU emulator version 5.2.0 +> Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +> -------------------------------------------------- +> +> Is there a simple workaround that disables this rather +> arbitrary constraint? + +No, but you can send a patch :) + +Regards, + +Phil. + + +> Indeed, we can remove this warning for block devices. + +Couldn't you simply remove the entire size check logic for block devices? + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +On Wed, May 12, 2021 at 11:08:09AM -0000, Thomas Huth wrote: +> +> If it is not fixed yet and you think that this bug report here is still +> valid, then you have two options: + +Actually, you seem to have forgotten a third option: I simply don't care +enough, especially after the patronizing response to my original report, +to bother. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/297 + + diff --git a/results/classifier/zero-shot/108/all/1911216 b/results/classifier/zero-shot/108/all/1911216 new file mode 100644 index 000000000..daff29398 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1911216 @@ -0,0 +1,103 @@ +other: 0.954 +device: 0.944 +permissions: 0.939 +boot: 0.931 +semantic: 0.930 +graphic: 0.930 +debug: 0.930 +performance: 0.929 +files: 0.923 +socket: 0.919 +vnc: 0.916 +KVM: 0.913 +network: 0.905 +PID: 0.900 + +abort issue locates in hw/usb/hcd-ohci.c:1297:ohci_frame_boundary + +Hello, + +I found an assertion failure in hw/usb/hcd-ohci.c:1297 + +This was found in latest version 5.2.0. + +my reproduced environment is as follows: + Host: ubuntu 18.04 + Guest: ubuntu 18.04 + +QEMU boot command line: +qemu-system-x86_64 -enable-kvm -boot c -m 4G -drive format=qcow2,file=./ubuntu.img -nic user,hostfwd=tcp:0.0.0.0:5555-:22 -display none -device pci-ohci,id=ohci -device usb-tablet,bus=ohci.0,port=1,id=usbdev1 + + +backtrace is as follows +pwndbg> bt +#0 0x00007fdf392aa438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 +#1 0x00007fdf392ac03a in __GI_abort () at abort.c:89 +#2 0x000055c613721118 in ohci_frame_boundary (opaque=0x6270000191f0) at hw/usb/hcd-ohci.c:1297 +#3 0x000055c6140bdf0e in timerlist_run_timers (timer_list=0x60b00005bcc0) at util/qemu-timer.c:572 +#4 0x000055c6140be15a in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at util/qemu-timer.c:586 +#5 0x000055c6140beac7 in qemu_clock_run_all_timers () at util/qemu-timer.c:672 +#6 0x000055c6140a1938 in main_loop_wait (nonblocking=0) at util/main-loop.c:523 +#7 0x000055c6125d87e9 in qemu_main_loop () at /home/dell/qemu5-hypervisor/vm/fuzz-seedpool/hcd-ohci/qemu-5.1.0/softmmu/vl.c:1676 +#8 0x000055c613f216ea in main (argc=7, argv=0x7fff174cdd28, envp=0x7fff174cdd68) at /home/dell/qemu5-hypervisor/vm/fuzz-seedpool/hcd-ohci/qemu-5.1.0/softmmu/main.c:49 +#9 0x00007fdf39295840 in __libc_start_main (main=0x55c613f21699 <main>, argc=7, argv=0x7fff174cdd28, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff174cdd18) at ../csu/libc-start.c:291 +#10 0x000055c6120a4349 in _start () + +The poc is attached. + + + +Seems to be the same as OSS-Fuzz Issue 29224 + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -machine q35 \ +-machine accel=qtest, -m 512M -nodefaults \ +-device pci-ohci -display none -qtest stdio +outl 0xcf8 0x80000801 +outl 0xcfc 0x16000000 +outl 0xcf8 0x80000813 +outl 0xcfc 0x23 +clock_step +write 0x23000004 0x1 0x84 +clock_step +write 0x0 0x1 0x7e +write 0x1 0x1 0xaa +write 0x3 0x1 0x16 +write 0x1600aa8a 0x1 0xa0 +write 0xa1 0x1 0x80 +write 0xa4 0x1 0x20 +clock_step +EOF + +=== Stack Trace === +==6351==ERROR: AddressSanitizer: ABRT on unknown address 0x0539000018cf (pc 0x7f675c885438 bp 0x7fff157e6150 sp 0x7fff157e5e68 T0) +#0 raise +#1 abort +#2 ohci_frame_boundary /src/qemu/hw/usb/hcd-ohci.c:1297:13 +#3 timerlist_run_timers /src/qemu/util/qemu-timer.c:574:9 +#4 qemu_clock_run_timers /src/qemu/util/qemu-timer.c:588:12 +#5 qtest_clock_warp /src/qemu/softmmu/qtest.c:356:9 +#6 qtest_process_command /src/qemu/softmmu/qtest.c:752:9 +#7 qtest_process_inbuf /src/qemu/softmmu/qtest.c:797:9 +#8 qtest_server_inproc_recv /src/qemu/softmmu/qtest.c:904:9 +#9 send_wrapper /src/qemu/tests/qtest/libqtest.c:1388:5 +#10 qtest_sendf /src/qemu/tests/qtest/libqtest.c:438:5 +#11 qtest_clock_step_next /src/qemu/tests/qtest/libqtest.c:910:5 +#12 op_clock_step /src/qemu/tests/qtest/fuzz/generic_fuzz.c:575:5 +#13 generic_fuzz /src/qemu/tests/qtest/fuzz/generic_fuzz.c:681:17 + +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29176 + + +Hi! Can you still reproduce this issue with QEMU v6.0 ? At least Alexander's reproducer does not seem to trigger this issue anymore... + +OSS-Fuzz still has a functioning reproducer. I'll copy this one over to gitlab + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/545 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/zero-shot/108/all/1913012 b/results/classifier/zero-shot/108/all/1913012 new file mode 100644 index 000000000..6cdebf114 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1913012 @@ -0,0 +1,177 @@ +debug: 0.972 +network: 0.963 +device: 0.955 +boot: 0.953 +other: 0.950 +permissions: 0.948 +files: 0.943 +KVM: 0.938 +semantic: 0.938 +graphic: 0.930 +PID: 0.928 +socket: 0.927 +performance: 0.922 +vnc: 0.906 + +Installed firmware descriptor files contain (invalid) relative paths + +Unless the Qemu build is configured using `./configure --datadir=<path> where <path> is some absolute path which is a subdirectory of <prefix>, the resulting installed firmware descriptor files contain relative paths for their `mapping.filename` properties. These relative paths will not be accepted as valid by tools like `virt-install`, resulting in the inability to configure new VMs using these firmware descriptors. + +# QEMU version +$ qemu-system-x86_64 -version +QEMU emulator version 5.2.0 + +(I've also reproduced the issue with QEMU built from Git master @ v5.2.0-1300-g0e32462630, see next comment.) + +# OS version +Void Linux x86_64 (glibc) + +Steps to reproduce (with results on my system): + +# Verify the symptom + +$ virt-install --boot firmware=efi --disk none --memory 2048 +Using default --name vm4 +WARNING No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results. + +Starting install... +ERROR Failed to open file 'share/qemu/edk2-i386-vars.fd': No such file or directory +Domain installation does not appear to have been successful. +If it was, you can restart your domain by running: + virsh --connect qemu:///session start vm4 +otherwise, please restart your installation. + +# Verify most likely cause + +$ grep filename /usr/share/qemu/firmware/*i386*.json +/usr/share/qemu/firmware/50-edk2-i386-secure.json: "filename": "share/qemu/edk2-i386-secure-code.fd", +/usr/share/qemu/firmware/50-edk2-i386-secure.json: "filename": "share/qemu/edk2-i386-vars.fd", +/usr/share/qemu/firmware/60-edk2-i386.json: "filename": "share/qemu/edk2-i386-code.fd", +/usr/share/qemu/firmware/60-edk2-i386.json: "filename": "share/qemu/edk2-i386-vars.fd", + +There is an issue on Void Linux packages issue tracker about this bug[1] + +# Steps to verify the issue on a fresh Git clone of QEMU source + +$ git clone https://github.com/qemu/qemu +$ cd qemu +$ make DEBUG=1 docker-test-misc@alpine +[...] + COPY RUNNER + RUN test-misc in qemu/alpine +* Prepared to run command: + ./test-misc +* Hit Ctrl-D to continue, or type 'exit 1' to abort + +bash-5.1$ . common-rc +[...] +bash-5.1$ configure_qemu --disable-system --disable-user +Configure options: +--enable-werror --prefix=/tmp/qemu-test/install --disable-system --disable-user +cross containers no +The Meson build system +Version: 0.56.2 +Source dir: /tmp/qemu-test/src +Build dir: /tmp/qemu-test/src/tests/docker +Build type: native build +Project name: qemu +Project version: 5.2.50 +[...] +bash-5.1$ grep filename pc-bios/descriptors/* +pc-bios/descriptors/50-edk2-i386-secure.json: "filename": "share/qemu/edk2-i386-secure-code.fd", +pc-bios/descriptors/50-edk2-i386-secure.json: "filename": "share/qemu/edk2-i386-vars.fd", +[...all other matches have relative paths...] +bash-5.1$ exit 1 +[...] + +# Research + +The filename path substitution appears to be done in the file `pc-bios/descriptors/meson.build`. +In particular, occurrences of `@DATADIR@` in the template files get substituted using the value of `qemu_datadir`: + + configure_file(input: files(f), + output: f, + configuration: {'DATADIR': qemu_datadir}, + install: get_option('install_blobs'), + install_dir: qemu_datadir / 'firmware') + +The variable `qemu_datadir` gets initialized from toplevel `meson.build` file using: + + qemu_datadir = get_option('datadir') / get_option('qemu_suffix') + +From the Meson documentation on built-in (build) options[2], `datadir` option gets initialized to `"share"` (note: a relative path!) by default, unless `datadir` build option is configured explicitly, so the value of `qemu_datadir`, as well as the substitution made ends up being a relative path as well. + +I found a commit which I think is relevant to why this choice was made[3]. + +# Test a workaround, try #1: specify `datadir` manually + +$ make DEBUG=1 docker-test-misc@alpine +[...] +bash-5.1$ configure_qemu --datadir=/usr/share --disable-system --disable-user +Configure options: +--enable-werror --prefix=/tmp/qemu-test/install --datadir=/usr/share --disable-system --disable-user +cross containers no +The Meson build system +Version: 0.56.2 +Source dir: /tmp/qemu-test/src +Build dir: /tmp/qemu-test/src/tests/docker +Build type: native build + +../../meson.build:1:0: ERROR: The value of the 'datadir' option is '/usr/share' which must be a subdir of the prefix '/tmp/qemu-test/install'. +Note that if you pass a relative path, it is assumed to be a subdir of prefix. + +A full log can be found at /tmp/qemu-test/src/tests/docker/meson-logs/meson-log.txt + +ERROR: meson setup failed + +Ah! So perhaps `datadir` can be an absolute path, but then it must be a subdir of the (already specified) `prefix`. +Let's try again. + +# Test a workaround, try #2: specify `datadir` as subdir of <prefix> manually + +$ make DEBUG=1 docker-test-misc@alpine +[...] +bash-5.1$ configure_qemu --datadir=/tmp/qemu-test/install/share --disable-system --disable-user +Configure options: +--enable-werror --prefix=/tmp/qemu-test/install --datadir=/tmp/qemu-test/install/share --disable-system --disable-user +[...] +bash-5.1$ grep filename pc-bios/descriptors/* +pc-bios/descriptors/50-edk2-i386-secure.json: "filename": "share/qemu/edk2-i386-secure-code.fd", +pc-bios/descriptors/50-edk2-i386-secure.json: "filename": "share/qemu/edk2-i386-vars.fd", +bash-5.1$ exit 1 + +Getting there, but the paths are still relative, missing the initial `/`. + +[1]: https://github.com/void-linux/void-packages/issues/27965 +[2]: https://mesonbuild.com/Builtin-options.html +[3]: https://github.com/qemu/qemu/commit/ab4c0996f80d43d1fc28c6e76f4ecb27423a7e29 + + + +I think this needs to be fixed in QEMU source. The `configure_file()` action needs both an absolute path for `configuration` (to substitute into the descriptor files) _and_ a relative path for use with the `install_dir` keyword argument. + +Please disregard the `# Test a coworkaround` stuff in comment #1, bad copypasta, too late at night ;-) + +Gentoo also noticed the bug: https://bugs.gentoo.org/766743 + +Jannik Glückert proposed a fix: + +``` +--- a/pc-bios/descriptors/meson.build ++++ b/pc-bios/descriptors/meson.build +@@ -8,7 +8,7 @@ foreach f: [ + ] + configure_file(input: files(f), + output: f, +- configuration: {'DATADIR': qemu_datadir}, ++ configuration: {'DATADIR': get_option('prefix') / qemu_datadir}, + install: get_option('install_blobs'), + install_dir: qemu_datadir / 'firmware') + endforeach +``` + + + +Fixed here: +https://gitlab.com/qemu-project/qemu/-/commit/4b956a399969c0c497a + diff --git a/results/classifier/zero-shot/108/all/1913505 b/results/classifier/zero-shot/108/all/1913505 new file mode 100644 index 000000000..2c956c504 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1913505 @@ -0,0 +1,194 @@ +performance: 0.964 +other: 0.956 +PID: 0.956 +semantic: 0.953 +socket: 0.949 +permissions: 0.948 +boot: 0.943 +vnc: 0.942 +graphic: 0.933 +device: 0.933 +debug: 0.930 +KVM: 0.918 +network: 0.916 +files: 0.912 + +Windows XP slow on Apple M1 + +Qemu installed by using brew install qemu -s on M1 + +QEMU emulator version 5.2.0 +XP image from: https://archive.org/details/WinXPProSP3x86 + +Commands run: +$ qemu-img create -f qcow2 xpsp3.img 10G +$ qemu-system-i386 -m 512 -hda xpsp3.img -cdrom WinXPProSP3x86/en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso -boot d + +It's taken 3 days now with qemu running at around 94% CPU and installation hasn't finished. The mouse pointer moves and occasionally changes between the pointer and hourglass so it doesn't seem to have frozen. + +Is the install that slow on some other hardware (useful comparisons: x86 Mac; x86 Linux; AArch64 Linux) ? + + +On 28/01/2021 10:33, Peter Maydell wrote: + +> Is the install that slow on some other hardware (useful comparisons: x86 +> Mac; x86 Linux; AArch64 Linux) ? + +Could it be related to excess TLB flushing? Possible related bug report here: +https://bugs.launchpad.net/qemu/+bug/1883593. + + +ATB, + +Mark. + + +Did you compile QEMU on your own? If so, which parameters did you use for the "configure" script? + +The bug report says: +"Qemu installed by using brew install qemu -s on M1" +so I think it's whatver options homebrew used: +https://formulae.brew.sh/formula/qemu + + + +I just realised that I was using an x86 build of qemu on my M1. When I run the arm64 version I get "Could not allocate dynamic translator buffer" + + +Try a newer version from git -- the patches to support emulation on the M1 only went into git very recently. (There are still some issues on this hardware with further patches on list and/or testsuite failures being investigated.) + + + + +> On Jan 29, 2021, at 1:20 AM, <email address hidden> wrote: +> +> Message: 14 +> Date: Fri, 29 Jan 2021 06:06:41 -0000 +> From: Thomas Huth <email address hidden> +> To: <email address hidden> +> Subject: [Bug 1913505] Re: Windows XP slow on Apple M1 +> Message-ID: +> <email address hidden> +> +> Content-Type: text/plain; charset="utf-8" +> +> Did you compile QEMU on your own? If so, which parameters did you use +> for the "configure" script? +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1913505 +> +> Title: +> Windows XP slow on Apple M1 +> +> Status in QEMU: +> New +> +> Bug description: +> Qemu installed by using brew install qemu -s on M1 +> +> QEMU emulator version 5.2.0 +> XP image from: https://archive.org/details/WinXPProSP3x86 +> +> Commands run: +> $ qemu-img create -f qcow2 xpsp3.img 10G +> $ qemu-system-i386 -m 512 -hda xpsp3.img -cdrom WinXPProSP3x86/en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso -boot d +> +> It's taken 3 days now with qemu running at around 94% CPU and +> installation hasn't finished. The mouse pointer moves and occasionally +> changes between the pointer and hourglass so it doesn't seem to have +> frozen. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1913505/+subscriptions + + +Hi, I followed your directions on reproducing this issue. My times were very different from yours. + +I used my own patch to make qemu-system-i386 on my M1 Mac running Mac OS 11.1. It is on the list if you want to try it. + +For Windows XP, I used my own copy. It was build 2600 and Service Pack 3. + +Installing Windows XP took about 23 minutes. After the installation was completed Windows tried to start up but probably crashed so I had to reboot the VM. After that it started up without problems. + +Here are some benchmarks I did: + +For my ARM-based QEMU I saw these start up times to the login screen: 1:20, 1:19, 1:16, 1:18 + +For a QEMU binary I made a few years ago that is x86_64-based, I saw these times: 1:09, 1:09 + +The ARM-based QEMU is at version 5.2.50 (git commit 9cd69f1a270235b652766f00b94114f48a2d603f). + +The x86_64-based QEMU is at version 2.10.1. + +I would have bet that the ARM-based QEMU would run circles around the x86_64 version, but the opposite happened. + +These are my theories about what could be wrong: +- A patch somewhere made QEMU slow + -- feature bloat + -- bugs + -- emulated hardware issues +- The ARM TCG isn't as good as the x86_64 version +- Non-optimal command-line options + +Please let me know if you have any ideas or suggestions. + +Thank you. + + + + + + + +Hi John, + +Thank you, this is indeed strange. Do you use homebrew? Could you try the homebrew version and see how that goes? + +I installed QEMU thru home-brew. When I tried to run it I saw this error message: "Could not allocate dynamic translator buffer". + +@John please build from master and apply the patch https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03527.html + +Tried the patch. +Start up time does not appear to be improved. +I used both qemu-system-i386 and qemu-system-x86_64 with the same results. +To compare notes I tried Windows 7. It starts up much faster than Windows XP. + + +Just to note when I tried reinstalling Windows XP, the installation appeared to be stuck at this screen. I restarted QEMU to continue. + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1913669 b/results/classifier/zero-shot/108/all/1913669 new file mode 100644 index 000000000..aa377eeb4 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1913669 @@ -0,0 +1,113 @@ +permissions: 0.991 +other: 0.987 +semantic: 0.979 +performance: 0.976 +PID: 0.975 +device: 0.975 +graphic: 0.975 +socket: 0.974 +debug: 0.973 +files: 0.964 +boot: 0.963 +vnc: 0.961 +KVM: 0.938 +network: 0.933 + +FPE in npcm7xx_adc_convert + +Reproducer: +cat << EOF | ./qemu-system-aarch64 -M npcm750-evb \ +-accel qtest -qtest stdio +write 0xf000c000 0x4 0x02400200 +clock_step +EOF + +Trace: +../hw/adc/npcm7xx_adc.c:60:51: runtime error: division by zero +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/adc/npcm7xx_adc.c:60:51 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==717962==ERROR: AddressSanitizer: FPE on unknown address 0x55901aa6e67a (pc 0x55901aa6e67a bp 0x7fff0ac087e0 sp 0x7fff0ac087a0 T0) +#0 0x55901aa6e67a in npcm7xx_adc_convert /hw/adc/npcm7xx_adc.c:60:51 +#1 0x55901aa6e67a in npcm7xx_adc_convert_done /hw/adc/npcm7xx_adc.c:106:15 +#2 0x55901ceb847e in timerlist_run_timers /util/qemu-timer.c:574:9 +#3 0x55901c05d804 in qtest_clock_warp /softmmu/qtest.c:356:9 +#4 0x55901c059781 in qtest_process_command /softmmu/qtest.c:752:9 +#5 0x55901c051b97 in qtest_process_inbuf /softmmu/qtest.c:797:9 +#6 0x55901c8a2286 in fd_chr_read /chardev/char-fd.c:68:9 +#7 0x7fa5c43f1aae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) +#8 0x55901cefd363 in glib_pollfds_poll /util/main-loop.c:232:9 +#9 0x55901cefd363 in os_host_main_loop_wait /util/main-loop.c:255:5 +#10 0x55901cefd363 in main_loop_wait /util/main-loop.c:531:11 +#11 0x55901bfb8599 in qemu_main_loop /softmmu/runstate.c:721:9 +#12 0x55901a2451fd in main /softmmu/main.c:50:5 +#13 0x7fa5c3e96cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 +#14 0x55901a198bc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: FPE /hw/adc/npcm7xx_adc.c:60:51 in npcm7xx_adc_convert + +Cc'ing supporters: + +$ ./scripts/get_maintainer.pl -f hw/arm/npcm7xx.c +Havard Skinnemoen <email address hidden> (supporter:Nuvoton NPCM7xx) +Tyrone Ting <email address hidden> (supporter:Nuvoton NPCM7xx) + +On 1/29/21 3:36 AM, Alexander Bulekov wrote: +> Public bug reported: +> +> Reproducer: +> cat << EOF | ./qemu-system-aarch64 -M npcm750-evb \ +> -accel qtest -qtest stdio +> write 0xf000c000 0x4 0x02400200 +> clock_step +> EOF +> +> Trace: +> ../hw/adc/npcm7xx_adc.c:60:51: runtime error: division by zero +> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/adc/npcm7xx_adc.c:60:51 in +> AddressSanitizer:DEADLYSIGNAL +> ================================================================= +> ==717962==ERROR: AddressSanitizer: FPE on unknown address 0x55901aa6e67a (pc 0x55901aa6e67a bp 0x7fff0ac087e0 sp 0x7fff0ac087a0 T0) +> #0 0x55901aa6e67a in npcm7xx_adc_convert /hw/adc/npcm7xx_adc.c:60:51 +> #1 0x55901aa6e67a in npcm7xx_adc_convert_done /hw/adc/npcm7xx_adc.c:106:15 +> #2 0x55901ceb847e in timerlist_run_timers /util/qemu-timer.c:574:9 +> #3 0x55901c05d804 in qtest_clock_warp /softmmu/qtest.c:356:9 +> #4 0x55901c059781 in qtest_process_command /softmmu/qtest.c:752:9 +> #5 0x55901c051b97 in qtest_process_inbuf /softmmu/qtest.c:797:9 +> #6 0x55901c8a2286 in fd_chr_read /chardev/char-fd.c:68:9 +> #7 0x7fa5c43f1aae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) +> #8 0x55901cefd363 in glib_pollfds_poll /util/main-loop.c:232:9 +> #9 0x55901cefd363 in os_host_main_loop_wait /util/main-loop.c:255:5 +> #10 0x55901cefd363 in main_loop_wait /util/main-loop.c:531:11 +> #11 0x55901bfb8599 in qemu_main_loop /softmmu/runstate.c:721:9 +> #12 0x55901a2451fd in main /softmmu/main.c:50:5 +> #13 0x7fa5c3e96cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 +> #14 0x55901a198bc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) +> +> AddressSanitizer can not provide additional info. +> SUMMARY: AddressSanitizer: FPE /hw/adc/npcm7xx_adc.c:60:51 in npcm7xx_adc_convert + +The ADC realization in npcm7xx_realize is incomplete, vref/iref +properties are not set, thus 0. + +Looking at the qtests (npcm7xx_adc-test.c) these are set via +'qom-set' QMP calls. + +Assuming vref/iref are constant on a board, shouldn't we have +a npcm7xx_adc_realize() method checking these properties are +set, returning a proper error message if not? + +Thanks, + +Phil. + + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/550 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/zero-shot/108/all/1916344 b/results/classifier/zero-shot/108/all/1916344 new file mode 100644 index 000000000..b5525a7db --- /dev/null +++ b/results/classifier/zero-shot/108/all/1916344 @@ -0,0 +1,120 @@ +other: 0.972 +socket: 0.961 +network: 0.961 +PID: 0.957 +permissions: 0.957 +vnc: 0.956 +KVM: 0.953 +device: 0.943 +debug: 0.942 +performance: 0.936 +semantic: 0.936 +files: 0.934 +graphic: 0.931 +boot: 0.927 + +User mode networking not working properly on QEMU on Mac OS X host + +Steps to reproduce: + +1. Install QEMU using homebrew on Mac OS X (I used Big Sur) +2. Spin up a guest VM (say) Cent OS8 using user mode networking. +3. Install podman inside the guest +4. Run podman pull alpine + +The result is: + +[root@localhost ~]# podman pull alpine +Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf) +Trying to pull docker.io/library/alpine:latest... +Getting image source signatures +Copying blob ba3557a56b15 [======================================] 2.7MiB / 2.7MiB + unexpected EOF +Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF + +This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest. + +This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X. + +This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this. + +I built QEMU from the git repo. My Windows XP and Mac OS 10.4 guests cannot access the internet. I'm on a M1 Mac running Mac OS 11.1. I use qemu-system-i386 and qemu-system-ppc. + +I tried installing slirp from MacPorts but it is broken. It might have been broken for years. See https://trac.macports.org/ticket/41875. So slirp networking probably isn't going to work. + + + + + +I am not sure if a separate slirp installation via macports is necessary. When you install qemu via homebrew, it's supposed to install any slirp related libarries as part of qemu installation. Having said that, I haven't noticed a slirp package installed on my mac when I did a `brew list`. + +So, I don't know how exactly is qemu packing slirp libraries within itself while installing on a mac. I think there's some kinda git option during installation. Perhaps brew uses that. + +This is maybe a duplicate of https://bugs.launchpad.net/qemu/+bug/1914117 + +Yes, I think it's the same issue. So, are you planning to integrate the following patch into the source code? + +https://bugs.launchpad.net/qemu/+bug/1914117/comments/10 + +Or is there a better solution you are working on? + +I'm on Mac OS 11.1 on an M1 Mac. I did some tests with QEMU 2.10.1 and 5.3 and here are the results: + +QEMU 2.10.1: +- Ran Windows XP as a guest +- qemu-system-i386 -m 700 -hda <Windows XP HD file> -netdev user,id=n0 -device rtl8139,netdev=n0 +- Internet Explorer was able to load a web page. + +QEMU 5.3.x: +- Tried to run Windows XP as a guest: +- qemu-system-i386 -m 700 -hda <Windows XP HD file> -netdev user,id=n0 -device rtl8139,netdev=n0 +- QEMU refused to run and displayed this error message: qemu-system-i386: -netdev user,id=n0: Parameter 'type' expects a netdev backend type + +I'm not sure if this message is a bug or something else. + +Different problem here I think John. If you run the following you should the user mode networking that involves Slirp and has the problem. + +``` + qemu-system-i386 -m 700 -hda <Windows XP HD file> -net user -net nic +``` + +It's worth noting however that the problem most regularly manifest itself when a remote server delivers content and THEN closes the TCP socket straight away. When this happens, the return from the Mac's poll() system call seems to tickle Slirp's TCP urgent code, which results in the guest breaking up the received payload, mistakenly believing some of it to be "urgent". (I've no clue if Windows XP supports something SO_OOBINLINE that might alleviate the problem...) + +If you use HTTP/1.1, you might not see this if the HTTP client is using a persistent connection, because the server will not close immediately after transmitting. Not sure what podman does in the opening comment above, and not sure what IE's default mode of operation is either. + +If you're looking for a fix, there is Chris's patch in https://bugs.launchpad.net/qemu/+bug/1914117 + + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1918321 b/results/classifier/zero-shot/108/all/1918321 new file mode 100644 index 000000000..f29662eaf --- /dev/null +++ b/results/classifier/zero-shot/108/all/1918321 @@ -0,0 +1,372 @@ +other: 0.986 +semantic: 0.982 +graphic: 0.979 +debug: 0.978 +permissions: 0.978 +vnc: 0.976 +performance: 0.973 +PID: 0.973 +socket: 0.972 +device: 0.971 +files: 0.970 +boot: 0.970 +KVM: 0.967 +network: 0.954 + +[OSS-Fuzz] Issue 31875 megasas: Null-ptr dereference in megasas_finish_dcmd + +Hello, + +== QTest Reproducer == +/* + * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ + * 512M -machine q35 -nodefaults -device megasas -device \ + * scsi-cd,drive=null0 -blockdev \ + * driver=null-co,read-zeroes=on,node-name=null0 -qtest stdio + * outl 0xcf8 0x80000801 + * outl 0xcfc 0x05000000 + * outl 0xcf8 0x80000816 + * outl 0xcfc 0x19000000 + * write 0x1e1ed300 0x1 0x01 + * write 0x1e1ed307 0x1 0x01 + * write 0x1e1ed316 0x1 0x01 + * write 0x1e1ed328 0x1 0x01 + * write 0x1e1ed32f 0x1 0x01 + * outl 0x1940 0x1e1ed300 + * outl 0x19c0 0x00 + * EOF + */ +static void null_deref_megasas_finish_dcmd(void) +{ + QTestState *s = qtest_init( + "-display none , -m 512M -machine q35 -nodefaults -device megasas -device " + "scsi-cd,drive=null0 -blockdev driver=null-co,read-zeroes=on,node-name=null0 "); + qtest_outl(s, 0xcf8, 0x80000801); + qtest_outl(s, 0xcfc, 0x05000000); + qtest_outl(s, 0xcf8, 0x80000816); + qtest_outl(s, 0xcfc, 0x19000000); + qtest_bufwrite(s, 0x1e1ed300, "\x01", 0x1); + qtest_bufwrite(s, 0x1e1ed307, "\x01", 0x1); + qtest_bufwrite(s, 0x1e1ed316, "\x01", 0x1); + qtest_bufwrite(s, 0x1e1ed328, "\x01", 0x1); + qtest_bufwrite(s, 0x1e1ed32f, "\x01", 0x1); + qtest_outl(s, 0x1940, 0x1e1ed300); + qtest_outl(s, 0x19c0, 0x00); + qtest_quit(s); +} +int main(int argc, char **argv) +{ + const char *arch = qtest_get_arch(); + + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "i386") == 0) { + qtest_add_func("fuzz/null_deref_megasas_finish_dcmd", + null_deref_megasas_finish_dcmd); + } + + return g_test_run(); +} + +== Stack Trace == +../hw/scsi/megasas.c:1884:21: runtime error: member access within null pointer of type 'union mfi_frame' +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/scsi/megasas.c:1884:21 in +../hw/scsi/megasas.c:1884:21: runtime error: member access within null pointer of type 'struct mfi_frame_header' +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/scsi/megasas.c:1884:21 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==314546==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000003 (pc 0x55b1b4f4de73 bp 0x7ffcfc5a8bb0 sp 0x7ffcfc5a8900 T0) +==314546==The signal is caused by a WRITE memory access. +==314546==Hint: address points to the zero page. +#0 0x55b1b4f4de73 in megasas_command_complete build/../hw/scsi/megasas.c:1884:40 +#1 0x55b1b5613914 in scsi_req_complete build/../hw/scsi/scsi-bus.c:1515:5 +#2 0x55b1b5448aeb in scsi_dma_complete_noio build/../hw/scsi/scsi-disk.c:345:9 +#3 0x55b1b5446fc7 in scsi_dma_complete build/../hw/scsi/scsi-disk.c:366:5 +#4 0x55b1b4fffc56 in dma_complete build/../softmmu/dma-helpers.c:121:9 +#5 0x55b1b4fffc56 in dma_blk_cb build/../softmmu/dma-helpers.c:139:9 +#6 0x55b1b6856016 in blk_aio_complete build/../block/block-backend.c:1412:9 +#7 0x55b1b6f48b06 in aio_bh_poll build/../util/async.c:164:13 +#8 0x55b1b6f08cec in aio_dispatch build/../util/aio-posix.c:381:5 +#9 0x55b1b6f4d59c in aio_ctx_dispatch build/../util/async.c:306:5 +#10 0x7fd88c098baa in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51baa) +#11 0x55b1b6f59a3c in glib_pollfds_poll build/../util/main-loop.c:232:9 +#12 0x55b1b6f59a3c in os_host_main_loop_wait build/../util/main-loop.c:255:5 +#13 0x55b1b6f59a3c in main_loop_wait build/../util/main-loop.c:531:11 +#14 0x55b1b61a78a9 in qemu_main_loop build/../softmmu/runstate.c:725:9 +#15 0x55b1b4c751e5 in main build/../softmmu/main.c:50:5 +#16 0x7fd88aec6d09 in __libc_start_main csu/../csu/libc-start.c:308:16 +#17 0x55b1b4bc8bb9 in _start (system-i386+0x2b5fbb9) + +I posted a reproducer for a different bug. Here are the correct +reproducer and stacktrace: + +/* + * Autogenerated Fuzzer Test Case + */ + +#include "qemu/osdep.h" + +#include "libqos/libqtest.h" + +/* + * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest \ + * -m 512M -machine q35 -nodefaults -device megasas -device \ + * scsi-cd,drive=null0 -blockdev \ + * driver=null-co,read-zeroes=on,node-name=null0 -qtest stdio + * outl 0xcf8 0x80000801 + * outl 0xcfc 0x05000000 + * outl 0xcf8 0x80000816 + * outl 0xcfc 0x19000000 + * write 0x1e1ed300 0x1 0x01 + * write 0x1e1ed307 0x1 0x01 + * write 0x1e1ed316 0x1 0x01 + * write 0x1e1ed328 0x1 0x01 + * write 0x1e1ed32f 0x1 0x01 + * outl 0x1940 0x1e1ed300 + * outl 0x1940 0x1e1ed300 + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * clock_step + * outb 0x1940 0x0 + * write 0x0 0x1 0x01 + * write 0x7 0x1 0x01 + * write 0x16 0x1 0x01 + * write 0x28 0x1 0x01 + * write 0x2f 0x1 0x01 + * outb 0x1940 0x0 + * write 0x0 0x1 0x05 + * write 0x7 0x1 0x01 + * write 0x19 0x1 0x02 + * write 0x1a 0x1 0x01 + * write 0x1b 0x1 0x08 + * write 0x2f 0x1 0x01 + * outb 0x1940 0x0 + * EOF + */ +static void +null_deref_megasas_finish_dcmd(void) +{ + QTestState *s = qtest_init( + "-display none , -m 512M -machine q35 -nodefaults -device " + "megasas -device scsi-cd,drive=null0 -blockdev " + "driver=null-co,read-zeroes=on,node-name=null0 "); + qtest_outl(s, 0xcf8, 0x80000801); + qtest_outl(s, 0xcfc, 0x05000000); + qtest_outl(s, 0xcf8, 0x80000816); + qtest_outl(s, 0xcfc, 0x19000000); + qtest_bufwrite(s, 0x1e1ed300, "\x01", 0x1); + qtest_bufwrite(s, 0x1e1ed307, "\x01", 0x1); + qtest_bufwrite(s, 0x1e1ed316, "\x01", 0x1); + qtest_bufwrite(s, 0x1e1ed328, "\x01", 0x1); + qtest_bufwrite(s, 0x1e1ed32f, "\x01", 0x1); + qtest_outl(s, 0x1940, 0x1e1ed300); + qtest_outl(s, 0x1940, 0x1e1ed300); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_clock_step_next(s); + qtest_outb(s, 0x1940, 0x0); + qtest_bufwrite(s, 0x0, "\x01", 0x1); + qtest_bufwrite(s, 0x7, "\x01", 0x1); + qtest_bufwrite(s, 0x16, "\x01", 0x1); + qtest_bufwrite(s, 0x28, "\x01", 0x1); + qtest_bufwrite(s, 0x2f, "\x01", 0x1); + qtest_outb(s, 0x1940, 0x0); + qtest_bufwrite(s, 0x0, "\x05", 0x1); + qtest_bufwrite(s, 0x7, "\x01", 0x1); + qtest_bufwrite(s, 0x19, "\x02", 0x1); + qtest_bufwrite(s, 0x1a, "\x01", 0x1); + qtest_bufwrite(s, 0x1b, "\x08", 0x1); + qtest_bufwrite(s, 0x2f, "\x01", 0x1); + qtest_outb(s, 0x1940, 0x0); + qtest_quit(s); +} +int main(int argc, char **argv) +{ + const char *arch = qtest_get_arch(); + + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "i386") == 0) { + qtest_add_func("fuzz/null_deref_megasas_finish_dcmd", + null_deref_megasas_finish_dcmd); + } + + return g_test_run(); +} + + +=== Stack Trace === +../hw/scsi/megasas.c:726:25: runtime error: member access within null pointer of type 'union mfi_frame' +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/scsi/megasas.c:726:25 in +../hw/scsi/megasas.c:726:25: runtime error: member access within null pointer of type 'struct mfi_dcmd_frame' +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/scsi/megasas.c:726:25 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==966650==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000002c (pc 0x55abf56c7955 bp 0x7fff888f64d0 sp 0x7fff888f6400 T0) +==966650==The signal is caused by a WRITE memory access. +==966650==Hint: address points to the zero page. +#0 0x55abf56c7955 in megasas_finish_dcmd build/../hw/scsi/megasas.c +#1 0x55abf56b97c1 in megasas_handle_dcmd build/../hw/scsi/megasas.c:1601:9 +#2 0x55abf56b97c1 in megasas_handle_frame build/../hw/scsi/megasas.c:1965:24 +#3 0x55abf56b0e54 in megasas_mmio_write build/../hw/scsi/megasas.c:2129:9 +#4 0x55abf6a867f6 in memory_region_write_accessor build/../softmmu/memory.c:491:5 +#5 0x55abf6a86263 in access_with_adjusted_size build/../softmmu/memory.c:552:18 +#6 0x55abf6a85ac0 in memory_region_dispatch_write build/../softmmu/memory.c +#7 0x55abf6696d86 in flatview_write_continue build/../softmmu/physmem.c:2776:23 +#8 0x55abf668c74b in flatview_write build/../softmmu/physmem.c:2816:14 +#9 0x55abf668c74b in address_space_write build/../softmmu/physmem.c:2908:18 +#10 0x55abf67e6571 in cpu_outb build/../softmmu/ioport.c:60:5 +#11 0x55abf6b68ec9 in qtest_process_command build/../softmmu/qtest.c:479:13 +#12 0x55abf6b66d6f in qtest_process_inbuf build/../softmmu/qtest.c:797:9 +#13 0x55abf6d4c65e in fd_chr_read build/../chardev/char-fd.c:68:9 +#14 0x7f976e846aae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) +#15 0x55abf76eba3c in glib_pollfds_poll build/../util/main-loop.c:232:9 +#16 0x55abf76eba3c in os_host_main_loop_wait build/../util/main-loop.c:255:5 +#17 0x55abf76eba3c in main_loop_wait build/../util/main-loop.c:531:11 +#18 0x55abf69398a9 in qemu_main_loop build/../softmmu/runstate.c:725:9 +#19 0x55abf54071e5 in main build/../softmmu/main.c:50:5 +#20 0x7f976d674d09 in __libc_start_main csu/../csu/libc-start.c:308:16 +#21 0x55abf535abb9 in _start (system-i386+0x2b5fbb9) + + + +This is still reproducible with the current qemu git version (commit 7fe7fae8b48e3f9c647f) + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/548 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/zero-shot/108/all/1920784 b/results/classifier/zero-shot/108/all/1920784 new file mode 100644 index 000000000..395824c3a --- /dev/null +++ b/results/classifier/zero-shot/108/all/1920784 @@ -0,0 +1,980 @@ +debug: 0.997 +device: 0.997 +other: 0.996 +semantic: 0.996 +vnc: 0.996 +performance: 0.995 +PID: 0.995 +files: 0.995 +graphic: 0.995 +permissions: 0.994 +KVM: 0.993 +socket: 0.990 +boot: 0.989 +network: 0.989 + +qemu-system-ppc64le fails with kvm acceleration + +(Suspected glibc issue!) + +qemu-system-ppc64(le) fails when invoked with kvm acceleration with error "illegal instruction" + +> qemu-system-ppc64(le) -M pseries,accel=kvm + +Illegal instruction (core dumped) + +In dmesg: + +Facility 'SCV' unavailable (12), exception at 0x7624f8134c0c, MSR=900000000280f033 + + +Version-Release number of selected component (if applicable): +qemu 5.2.0 +Linux kernel 5.11 +glibc 2.33 +all latest updates as of submitting the bug report + +How reproducible: +Always + +Steps to Reproduce: +1. Run qemu with kvm acceleration + +Actual results: +Illegal instruction + +Expected results: +Normal VM execution + +Additional info: +The machine is a Raptor Talos II Lite with a Sforza V1 8-core, but was also observed on a Raptor Blackbird with the same processor. + +This was also observed on Fedora 34 beta, which uses glibc 2.33 +Also tested on ArchPOWER (unofficial port of Arch Linux for ppc64le) with glibc 2.33 +Fedora 33 and Ubuntu 20.10, both using glibc 2.32 do not have this issue, and downgrading the Linux kernel from 5.11 to 5.4 LTS on ArchPOWER solved the problem. Kernel 5.9 and 5.10 have the same issue when combined with glibc2.33 + +ProblemType: Bug +DistroRelease: Ubuntu 21.04 +Package: qemu-system 1:5.2+dfsg-6ubuntu2 +ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0 +Uname: Linux 5.11.0-11-generic ppc64le +.sys.firmware.opal.msglog: Error: [Errno 13] Permission denied: '/sys/firmware/opal/msglog' +ApportVersion: 2.20.11-0ubuntu60 +Architecture: ppc64el +CasperMD5CheckResult: pass +CurrentDesktop: Unity:Unity7:ubuntu +Date: Mon Mar 22 14:48:39 2021 +InstallationDate: Installed on 2021-03-22 (0 days ago) +InstallationMedia: Ubuntu-Server 21.04 "Hirsute Hippo" - Alpha ppc64el (20210321) +KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND +ProcKernelCmdLine: root=UUID=f3d03315-0944-4a02-9c87-09c00eba9fa1 ro +ProcLoadAvg: 1.20 0.73 0.46 1/1054 6071 +ProcSwaps: + Filename Type Size Used Priority + /swap.img file 8388544 0 -2 +ProcVersion: Linux version 5.11.0-11-generic (buildd@bos02-ppc64el-002) (gcc (Ubuntu 10.2.1-20ubuntu1) 10.2.1 20210220, GNU ld (GNU Binutils for Ubuntu) 2.36.1) #12-Ubuntu SMP Mon Mar 1 19:26:20 UTC 2021 +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) +VarLogDump_list: total 0 +acpidump: + +cpu_cores: Number of cores present = 8 +cpu_coreson: Number of cores online = 8 +cpu_smt: SMT=4 + + + +Status changed to 'Confirmed' because the bug affects multiple users. + +Since this seems to be broken on all Distributions as soon as the triggering +combination of kernel/glibc is present I think we'd want to open that up to +upstream qemu for a wider discussion and to also hit the ppc64 architecture +experts. + +Furthermore I'm not entirely sure if this needs to be fixed in qemu, it might instead be the case that instead a fix is needed in glibc. + +Therefore I'm adding a qemu (upstream) bug task for now to have the bug reported there as well (might be worth for awareness anyway) - but chances are that after some debugging it will turn out to become a glibc issue instead. + +If only I could break this test out of kvm ioctl into something simpler, then we could then properly file against glibc .... + +Hi Sadoon, +thanks for the report! +There isn't much to find about this issue yet. +One automatic syscaller crash report [1]. +On the emulation side there is [2][3]. + +On the glibc side we have [4][5] adding the use of it with [6] being a fix. +All those seem to be in glibc 2.33 - so I'd expect with [6] it should only +be issued on power9 which in turn should HW-support the instruction. + +I was trying to recreate this on power8 and power9 machines. +As expected on power8 just nothing happens (the instruction isn't used due to [6]). +TBH I first wondered if these Sforza chips [7][8][9] you mentioned are +fully identical to a classic IBM p9 box - but I was indeed able to reproduce +the issue just fine on an IBM-sold P9 +dmesg: +[ 1516.438442] Facility 'SCV' unavailable (12), exception at 0x76c9f84c49a0, MSR=900000000280f033 +[ 1516.438472] qemu-system-ppc[42884]: illegal instruction (4) at 76c9f84c49a0 nip 76c9f84c49a0 lr 1f12839d9f0 code 1 in libc-2.33.so[76c9f8380000+220000] +[ 1516.438489] qemu-system-ppc[42884]: code: e8010010 7c0803a6 4e800020 60420000 7ca42b78 4bffed65 60000000 38210020 +[ 1516.438493] qemu-system-ppc[42884]: code: e8010010 7c0803a6 4e800020 60420000 <44000001> 4bffffb8 60000000 60420000 + +The chip I used for this test is: +Model: 2.2 (pvr 004e 1202) +Model name: POWER9, altivec supported + +The syscall this crashes in belongs to the ioctl +(gdb) bt +#0 __GI___ioctl (fd=<optimized out>, request=536915584) at ../sysdeps/unix/sysv/linux/powerpc/ioctl.c:56 +#1 0x00000cb63ef7d9f0 in kvm_vcpu_ioctl (cpu=cpu@entry=0x7d0f48010010, type=type@entry=536915584) at ../../accel/kvm/kvm-all.c:2654 +#2 0x00000cb63ef7dbdc in kvm_cpu_exec (cpu=0x7d0f48010010) at ../../accel/kvm/kvm-all.c:2491 +#3 0x00000cb63ee78344 in kvm_vcpu_thread_fn (arg=0x7d0f48010010) at ../../accel/kvm/kvm-cpus.c:49 +#4 0x00000cb63f1d14bc in qemu_thread_start (args=<optimized out>) at ../../util/qemu-thread-posix.c:521 +#5 0x00007d0f4ac69114 in start_thread (arg=0x7d0f23dfe720) at pthread_create.c:473 +#6 0x00007d0f4ab755c0 in clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:103 + +And jumping into the code of the __GI___ioctl we can clearly see +the scv instruction is indeed there in the executed code path: + + 0x7ffff66c4984 <__GI___ioctl+292> bl 0x7ffff66c36e8 <__GI___tcgetattr+8> + 0x7ffff66c4988 <__GI___ioctl+296> nop + 0x7ffff66c498c <__GI___ioctl+300> addi r1,r1,32 + 0x7ffff66c4990 <__GI___ioctl+304> ld r0,16(r1) + 0x7ffff66c4994 <__GI___ioctl+308> mtlr r0 + 0x7ffff66c4998 <__GI___ioctl+312> blr + 0x7ffff66c499c <__GI___ioctl+316> ori r2,r2,0 + >0x7ffff66c49a0 <__GI___ioctl+320> scv 0 + + +[1]: https://webcache.googleusercontent.com/search?q=cache:uS0jhPekyqMJ:https://syzkaller-ppc64.appspot.com/text%3Ftag%3DCrashReport%26x%3D17d99883000000+&cd=2&hl=de&ct=clnk&gl=uk +[2]: https://git.qemu.org/?p=qemu.git;a=commit;h=3c89b8d6ac5b8728cd7620f9885bd953edd18a11 +[3]: https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg05425.html +[4]: https://sourceware.org/git/?p=glibc.git;a=commit;h=68ab82f56690ada86ac1e0c46bad06ba189a10ef +[5]: https://sourceware.org/git/?p=glibc.git;a=commit;h=41f013cef24884604c303435dd1915be2ea5c0e0 +[6]: https://sourceware.org/git/?p=glibc.git;a=commit;h=527c89cd32f8522859f58343be3d3dc8f754b783 +[7]: https://wiki.raptorcs.com/wiki/Sforza +[8]: https://wiki.raptorcs.com/wiki/Talos_II +[9]: https://wiki.raptorcs.com/wiki/POWER9 +[10]: https://lwn.net/Articles/822867/ + +qemu calls this ioctl on ppc64 as: + sysdeps/unix/sysv/linux/powerpc/ioctl.c +result = INLINE_SYSCALL (ioctl, 3, fd, request, arg); + +The mapping of macros in sysdeps/unix/sysv/linux/powerpc/sysdep.h seems to be: +INTERNAL_SYSCALL -> INTERNAL_SYSCALL_NCS -> TRY_SYSCALL_SCV -> SYSCALL_SCV + + 76 #define SYSCALL_SCV(nr) \ + 77 ({ \ + 78 __asm__ __volatile__ \ + 79 (".machine \"push\"\n\t" \ + 80 ".machine \"power9\"\n\t" \ + 81 "scv 0\n\t" \ + 82 ".machine \"pop\"\n\t" \ + 83 "0:" \ + 84 : "=&r" (r0), \ + 85 "=&r" (r3), "=&r" (r4), "=&r" (r5), \ + 86 "=&r" (r6), "=&r" (r7), "=&r" (r8) \ + 87 : ASM_INPUT_##nr \ + 88 : "r9", "r10", "r11", "r12", \ + 89 "lr", "ctr", "memory"); \ + 90 r3; \ + 91 }) + +[10] outlined to use PPC_FEATURE2_SCV but [4] does just that. +In addition [6] added power9 machine settings as only on this ISA it +is available - like: ++ .machine "push" ++ .machine "power9" + scv 0 ++ .machine "pop" + +Maybe there is some generated "scv 0" left that needs the same [6] treatment? + +OTOH In a normal test program I can run "scv 0" just fine. +But not other scv levels (expected). + +# cat test.c +#include <stdio.h> + +int main() { + printf("Hello scv 0\n"); + __asm__( + "scv 0\n\t" + ); + printf("survived\n"); + __asm__( + "scv 1\n\t" + ); + printf("survived level 1\n"); + return 0; +} +# gcc -Wall -o test test.c +./test +Hello scv 0 +survived +Illegal instruction (core dumped) + +IIRC .machine is only a psedo-op for the assembler. +So it is correct that I can't see it in the live disassembly of gdb. + +The failing "svc 0" from glibcs __GI___ioctl is + 0x00007ffff66c49a0 <+320>: 01 00 00 44 scv 0 +And in my test program it is + 0x0000000100000848 <+44>: 01 00 00 44 scv 0 + +Hmm, this is the same opcode but fails in just one of the cases. +This might need someone being more an ppc64/glibc expert than me :-/ + +@Frank - could you modify this bug to become mirrored to IBM for their arch-expertise please? + +As my other repro-code didn't trigger the issue I looked at qemu again and found that before the failing ioctl->scv call there are plenty other even some very similar (same?) calls that work just fine. + +I wonder if on guest setup qemu (or e.g. the rom we load) might set some arch-bits or such which then breaks the next "scv 0" call. + +I attached the full ioctl log here. + +I might be spoiled by the s390x-POP style to define instructions, but in the following doc about the PowerISA unfortunately there is no list of reasons-for-SIGILL. Therefore I'm out of options on this waiting for someone - most likely IBM - to chime in. + +https://wiki.raptorcs.com/w/images/f/f5/PowerISA_public.v3.1.pdf + +You need a kernel with a the following fix for POWER9: + +commit 25edcc50d76c834479d11fcc7de46f3da4d95121 +Author: Fabiano Rosas <email address hidden> +Date: Thu Feb 4 17:05:17 2021 -0300 + + KVM: PPC: Book3S HV: Save and restore FSCR in the P9 path + + The Facility Status and Control Register is a privileged SPR that + defines the availability of some features in problem state. Since it + can be written by the guest, we must restore it to the previous host + value after guest exit. + + This restoration is currently done by taking the value from + current->thread.fscr, which in the P9 path is not enough anymore + because the guest could context switch the QEMU thread, causing the + guest-current value to be saved into the thread struct. + + The above situation manifested when running a QEMU linked against a + libc with System Call Vectored support, which causes scv + instructions to be run by QEMU early during the guest boot (during + SLOF), at which point the FSCR is 0 due to guest entry. After a few + scv calls (1 to a couple hundred), the context switching happens and + the QEMU thread runs with the guest value, resulting in a Facility + Unavailable interrupt. + + This patch saves and restores the host value of FSCR in the inner + guest entry loop in a way independent of current->thread.fscr. The old + way of doing it is still kept in place because it works for the old + entry path. + + Signed-off-by: Fabiano Rosas <email address hidden> + Signed-off-by: Paul Mackerras <email address hidden> + + +This change was made by a bot. + +Thx Laurent, I took the hirsute master-next source and cherry-picked the patch and it applied cleanly. +Now I kicked off a kernel build of this patched kernel in the following PPA: +https://launchpad.net/~fheimes/+archive/ubuntu/lp1920784 +(however, the builds will take some time to complete) + +If it can be proofed that this patched kernel fixes the problem, I can go ahead and work on a patch submission for hirsute/21.04. (kernel freeze is April 8th) + +The guys on the Fedora side seem to have found the patch to fix this: + +https://bugzilla.redhat.com/show_bug.cgi?id=1941652#c6 + +Apparently it will go upstream in Linux 5.11, but earlier versions also need the fix, specifically 5.9 and 5.10 + +Thank you! + +@Sadoon - yes, that is the same fix that Laurent pointed to a few hours before. + +@Frank - the kernel I had before was 5.11.0-11-generic (failing). I've tested "5.11.0-13-generic #14~lp1920784" from your PPA and can confirm that this fixes the issue. + +Thanks Laurent for identifying the fix and thanks Frank for the kernel. +I'll mark bug tasks accordingly and @Frank you'll let me know if there is anything else you need to drive this to completion. + +And gladly this was only added in >=5.9 and we have Groovy (5.8) and Hirsute (5.11) so only the Hirsute kernel is needed to adapt, but further backports are not needed. + +The fix was sent to the kernel teams mailing list: +https://lists.ubuntu.com/archives/kernel-team/2021-March/thread.html#118449 + +This bug was fixed in the package linux - 5.11.0-14.15 + +--------------- +linux (5.11.0-14.15) hirsute; urgency=medium + + * hirsute/linux: 5.11.0-14.15 -proposed tracker (LP: #1923103) + + * Packaging resync (LP: #1786013) + - update dkms package versions + + * Include Infiniband Peer Memory interface (LP: #1923104) + - SAUCE: RDMA/core: Introduce peer memory interface + + * Hirsute update: v5.11.12 upstream stable release (LP: #1923069) + - arm64: mm: correct the inside linear map range during hotplug check + - virtiofs: Fail dax mount if device does not support it + - ext4: shrink race window in ext4_should_retry_alloc() + - ext4: fix bh ref count on error paths + - fs: nfsd: fix kconfig dependency warning for NFSD_V4 + - rpc: fix NULL dereference on kmalloc failure + - iomap: Fix negative assignment to unsigned sis->pages in + iomap_swapfile_activate + - ASoC: rt1015: fix i2c communication error + - ASoC: rt5640: Fix dac- and adc- vol-tlv values being off by a factor of 10 + - ASoC: rt5651: Fix dac- and adc- vol-tlv values being off by a factor of 10 + - ASoC: sgtl5000: set DAP_AVC_CTRL register to correct default value on probe + - ASoC: es8316: Simplify adc_pga_gain_tlv table + - ASoC: soc-core: Prevent warning if no DMI table is present + - ASoC: cs42l42: Fix Bitclock polarity inversion + - ASoC: cs42l42: Fix channel width support + - ASoC: cs42l42: Fix mixer volume control + - ASoC: cs42l42: Always wait at least 3ms after reset + - NFSD: fix error handling in NFSv4.0 callbacks + - ASoC: mediatek: mt8192: fix tdm out data is valid on rising edge + - kernel: freezer should treat PF_IO_WORKER like PF_KTHREAD for freezing + - vhost: Fix vhost_vq_reset() + - io_uring: fix ->flags races by linked timeouts + - io_uring: halt SQO submission on ctx exit + - scsi: st: Fix a use after free in st_open() + - scsi: qla2xxx: Fix broken #endif placement + - staging: comedi: cb_pcidas: fix request_irq() warn + - staging: comedi: cb_pcidas64: fix request_irq() warn + - ASoC: rt5659: Update MCLK rate in set_sysclk() + - ASoC: rt711: add snd_soc_component remove callback + - thermal/core: Add NULL pointer check before using cooling device stats + - locking/ww_mutex: Simplify use_ww_ctx & ww_ctx handling + - locking/ww_mutex: Fix acquire/release imbalance in + ww_acquire_init()/ww_acquire_fini() + - nvmet-tcp: fix kmap leak when data digest in use + - io_uring: imply MSG_NOSIGNAL for send[msg]()/recv[msg]() calls + - Revert "PM: ACPI: reboot: Use S5 for reboot" + - nouveau: Skip unvailable ttm page entries + - static_call: Align static_call_is_init() patching condition + - ext4: do not iput inode under running transaction in ext4_rename() + - io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() with + MSG_WAITALL + - net: mvpp2: fix interrupt mask/unmask skip condition + - mptcp: deliver ssk errors to msk + - mptcp: fix poll after shutdown + - mptcp: init mptcp request socket earlier + - mptcp: add a missing retransmission timer scheduling + - flow_dissector: fix TTL and TOS dissection on IPv4 fragments + - mptcp: fix DATA_FIN processing for orphaned sockets + - mptcp: provide subflow aware release function + - can: dev: move driver related infrastructure into separate subdir + - net: introduce CAN specific pointer in the struct net_device + - mptcp: fix race in release_cb + - net: bonding: fix error return code of bond_neigh_init() + - mptcp: fix bit MPTCP_PUSH_PENDING tests + - can: tcan4x5x: fix max register value + - brcmfmac: clear EAP/association status bits on linkdown events + - ath11k: add ieee80211_unregister_hw to avoid kernel crash caused by NULL + pointer + - netdevsim: dev: Initialize FIB module after debugfs + - iwlwifi: pcie: don't disable interrupts for reg_lock + - ath10k: hold RCU lock when calling ieee80211_find_sta_by_ifaddr() + - net: ethernet: aquantia: Handle error cleanup of start on open + - appletalk: Fix skb allocation size in loopback case + - net: ipa: remove two unused register definitions + - net: ipa: use a separate pointer for adjusted GSI memory + - net: ipa: fix register write command validation + - net: wan/lmc: unregister device when no matching device is found + - net: 9p: advance iov on empty read + - bpf: Remove MTU check in __bpf_skb_max_len + - ACPI: tables: x86: Reserve memory occupied by ACPI tables + - ACPI: processor: Fix CPU0 wakeup in acpi_idle_play_dead() + - ACPI: scan: Fix _STA getting called on devices with unmet dependencies + - ALSA: usb-audio: Apply sample rate quirk to Logitech Connect + - ALSA: hda: Re-add dropped snd_poewr_change_state() calls + - ALSA: hda: Add missing sanity checks in PM prepare/complete callbacks + - ALSA: hda/realtek: call alc_update_headset_mode() in hp_automute_hook + - xtensa: fix uaccess-related livelock in do_page_fault + - xtensa: move coprocessor_flush to the .text section + - KVM: SVM: load control fields from VMCB12 before checking them + - KVM: SVM: ensure that EFER.SVME is set when running nested guest or on + nested vmexit + - PM: runtime: Fix race getting/putting suppliers at probe + - PM: runtime: Fix ordering in pm_runtime_get_suppliers() + - tracing: Fix stack trace event size + - s390/vdso: copy tod_steering_delta value to vdso_data page + - s390/vdso: fix tod_steering_delta type + - drm/ttm: make ttm_bo_unpin more defensive + - mm: fix race by making init_zero_pfn() early_initcall + - drm/amdkfd: dqm fence memory corruption + - drm/amd/pm: no need to force MCLK to highest when no display connected + - drm/amdgpu/vangogh: don't check for dpm in is_dpm_running when in suspend + - drm/amdgpu: fix offset calculation in amdgpu_vm_bo_clear_mappings() + - drm/amdgpu: Set a suitable dev_info.gart_page_size + - drm/amdgpu: check alignment on CPU page for bo map + - reiserfs: update reiserfs_xattrs_initialized() condition + - drm/imx: fix memory leak when fails to init + - drm/tegra: dc: Restore coupling of display controllers + - drm/tegra: sor: Grab runtime PM reference across reset + - vfio/nvlink: Add missing SPAPR_TCE_IOMMU depends + - pinctrl: microchip-sgpio: Fix wrong register offset for IRQ trigger + - pinctrl: rockchip: fix restore error in resume + - pinctrl: qcom: sc7280: Fix SDC_QDSD_PINGROUP and UFS_RESET offsets + - pinctrl: qcom: sc7280: Fix SDC1_RCLK configurations + - pinctrl: qcom: lpass lpi: use default pullup/strength values + - pinctrl: qcom: fix unintentional string concatenation + - extcon: Add stubs for extcon_register_notifier_all() functions + - extcon: Fix error handling in extcon_dev_register + - firmware: stratix10-svc: reset COMMAND_RECONFIG_FLAG_PARTIAL to 0 + - powerpc/pseries/mobility: use struct for shared state + - powerpc/pseries/mobility: handle premature return from H_JOIN + - usb: dwc3: pci: Enable dis_uX_susphy_quirk for Intel Merrifield + - video: hyperv_fb: Fix a double free in hvfb_probe + - powerpc/mm/book3s64: Use the correct storage key value when calling + H_PROTECT + - firewire: nosy: Fix a use-after-free bug in nosy_ioctl() + - usbip: vhci_hcd fix shift out-of-bounds in vhci_hub_control() + - USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem + - usb: musb: Fix suspend with devices connected for a64 + - usb: xhci-mtk: fix broken streams issue on 0.96 xHCI + - cdc-acm: fix BREAK rx code path adding necessary calls + - USB: cdc-acm: untangle a circular dependency between callback and softint + - USB: cdc-acm: downgrade message to debug + - USB: cdc-acm: fix double free on probe failure + - USB: cdc-acm: fix use-after-free after probe failure + - usb: gadget: udc: amd5536udc_pci fix null-ptr-dereference + - usb: dwc2: Fix HPRT0.PrtSusp bit setting for HiKey 960 board. + - usb: dwc2: Prevent core suspend when port connection flag is 0 + - usb: dwc3: qcom: skip interconnect init for ACPI probe + - usb: dwc3: gadget: Clear DEP flags after stop transfers in ep disable + - soc: qcom-geni-se: Cleanup the code to remove proxy votes + - staging: rtl8192e: Fix incorrect source in memcpy() + - staging: rtl8192e: Change state information from u16 to u8 + - driver core: clear deferred probe reason on probe retry + - drivers: video: fbcon: fix NULL dereference in fbcon_cursor() + - riscv: evaluate put_user() arg before enabling user access + - io_uring: do ctx sqd ejection in a clear context + - Revert "kernel: freezer should treat PF_IO_WORKER like PF_KTHREAD for + freezing" + - Revert "net: bonding: fix error return code of bond_neigh_init()" + - Linux 5.11.12 + - [Config] set CONFIG_AD9467=n and CONFIG_ADI_AXI_ADC=n for amd64 + + * CVE-2021-29154 + - SAUCE: bpf, x86: Validate computation of branch displacements for x86-64 + - SAUCE: bpf, x86: Validate computation of branch displacements for x86-32 + + * Update - Fix no screen show on display after S3 on CML-R (LP: #1922768) + - drm/i915/gen9bc: Handle TGP PCH during suspend/resume + + * Hirsute update: v5.11.11 upstream stable release (LP: #1922601) + - mt76: fix tx skb error handling in mt76_dma_tx_queue_skb + - mt76: mt7915: only modify tx buffer list after allocating tx token id + - net: stmmac: fix dma physical address of descriptor when display ring + - net: fec: ptp: avoid register access when ipg clock is disabled + - powerpc/4xx: Fix build errors from mfdcr() + - atm: eni: dont release is never initialized + - atm: lanai: dont run lanai_dev_close if not open + - Revert "r8152: adjust the settings about MAC clock speed down for RTL8153" + - ALSA: hda: ignore invalid NHLT table + - ixgbe: Fix memleak in ixgbe_configure_clsu32 + - scsi: ufs: ufs-qcom: Disable interrupt in reset path + - blk-cgroup: Fix the recursive blkg rwstat + - net: tehuti: fix error return code in bdx_probe() + - net: intel: iavf: fix error return code of iavf_init_get_resources() + - sun/niu: fix wrong RXMAC_BC_FRM_CNT_COUNT count + - gianfar: fix jumbo packets+napi+rx overrun crash + - cifs: ask for more credit on async read/write code paths + - gfs2: fix use-after-free in trans_drain + - cpufreq: blacklist Arm Vexpress platforms in cpufreq-dt-platdev + - gpiolib: acpi: Add missing IRQF_ONESHOT + - nfs: fix PNFS_FLEXFILE_LAYOUT Kconfig default + - NFS: Correct size calculation for create reply length + - net: hisilicon: hns: fix error return code of hns_nic_clear_all_rx_fetch() + - net: wan: fix error return code of uhdlc_init() + - net: davicom: Use platform_get_irq_optional() + - net: enetc: set MAC RX FIFO to recommended value + - atm: uPD98402: fix incorrect allocation + - atm: idt77252: fix null-ptr-dereference + - cifs: change noisy error message to FYI + - irqchip/ingenic: Add support for the JZ4760 + - kbuild: add image_name to no-sync-config-targets + - kbuild: dummy-tools: fix inverted tests for gcc + - umem: fix error return code in mm_pci_probe() + - sparc64: Fix opcode filtering in handling of no fault loads + - habanalabs: Call put_pid() when releasing control device + - habanalabs: Disable file operations after device is removed + - staging: rtl8192e: fix kconfig dependency on CRYPTO + - u64_stats,lockdep: Fix u64_stats_init() vs lockdep + - kselftest: arm64: Fix exit code of sve-ptrace + - regulator: qcom-rpmh: Correct the pmic5_hfsmps515 buck + - regulator: qcom-rpmh: Use correct buck for S1C regulator + - block: Fix REQ_OP_ZONE_RESET_ALL handling + - drm/amd/display: Enable pflip interrupt upon pipe enable + - drm/amd/display: Revert dram_clock_change_latency for DCN2.1 + - drm/amd/display: Enabled pipe harvesting in dcn30 + - drm/amdgpu/display: Use wm_table.entries for dcn301 calculate_wm + - drm/amdgpu: fb BO should be ttm_bo_type_device + - drm/radeon: fix AGP dependency + - nvme: simplify error logic in nvme_validate_ns() + - nvme: add NVME_REQ_CANCELLED flag in nvme_cancel_request() + - nvme-fc: set NVME_REQ_CANCELLED in nvme_fc_terminate_exchange() + - nvme-fc: return NVME_SC_HOST_ABORTED_CMD when a command has been aborted + - nvme-core: check ctrl css before setting up zns + - nvme-rdma: Fix a use after free in nvmet_rdma_write_data_done + - nvme-pci: add the DISABLE_WRITE_ZEROES quirk for a Samsung PM1725a + - nfs: we don't support removing system.nfs4_acl + - block: Suppress uevent for hidden device when removed + - io_uring: cancel deferred requests in try_cancel + - mm/fork: clear PASID for new mm + - ia64: fix ia64_syscall_get_set_arguments() for break-based syscalls + - ia64: fix ptrace(PTRACE_SYSCALL_INFO_EXIT) sign + - static_call: Pull some static_call declarations to the type headers + - static_call: Allow module use without exposing static_call_key + - static_call: Fix the module key fixup + - static_call: Fix static_call_set_init() + - KVM: x86: Protect userspace MSR filter with SRCU, and set atomically-ish + - btrfs: do not initialize dev stats if we have no dev_root + - btrfs: do not initialize dev replace for bad dev root + - btrfs: fix check_data_csum() error message for direct I/O + - btrfs: initialize device::fs_info always + - btrfs: fix sleep while in non-sleep context during qgroup removal + - btrfs: fix subvolume/snapshot deletion not triggered on mount + - selinux: don't log MAC_POLICY_LOAD record on failed policy load + - selinux: fix variable scope issue in live sidtab conversion + - netsec: restore phy power state after controller reset + - platform/x86: intel-vbtn: Stop reporting SW_DOCK events + - psample: Fix user API breakage + - z3fold: prevent reclaim/free race for headless pages + - squashfs: fix inode lookup sanity checks + - squashfs: fix xattr id and id lookup sanity checks + - hugetlb_cgroup: fix imbalanced css_get and css_put pair for shared mappings + - kasan: fix per-page tags for non-page_alloc pages + - gcov: fix clang-11+ support + - mm/highmem: fix CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP + - ACPI: video: Add missing callback back for Sony VPCEH3U1E + - ACPICA: Always create namespace nodes using acpi_ns_create_node() + - arm64: stacktrace: don't trace arch_stack_walk() + - arm64: dts: ls1046a: mark crypto engine dma coherent + - arm64: dts: ls1012a: mark crypto engine dma coherent + - arm64: dts: ls1043a: mark crypto engine dma coherent + - ARM: dts: at91: sam9x60: fix mux-mask for PA7 so it can be set to A, B and C + - ARM: dts: at91: sam9x60: fix mux-mask to match product's datasheet + - ARM: dts: at91-sama5d27_som1: fix phy address to 7 + - integrity: double check iint_cache was initialized + - drm/nouveau/kms/nve4-nv108: Limit cursors to 128x128 + - drm/etnaviv: Use FOLL_FORCE for userptr + - drm/amd/pm: workaround for audio noise issue + - drm/amdgpu/display: restore AUX_DPHY_TX_CONTROL for DCN2.x + - drm/amdgpu: fix the hibernation suspend with s0ix + - drm/amdgpu: Add additional Sienna Cichlid PCI ID + - drm/i915/dsc: fix DSS CTL register usage for ICL DSI transcoders + - drm/i915: Fix the GT fence revocation runtime PM logic + - dm verity: fix DM_VERITY_OPTS_MAX value + - dm: don't report "detected capacity change" on device creation + - dm ioctl: fix out of bounds array access when no devices + - bus: omap_l3_noc: mark l3 irqs as IRQF_NO_THREAD + - soc: ti: omap-prm: Fix reboot issue with invalid pcie reset map for dra7 + - ARM: OMAP2+: Fix smartreflex init regression after dropping legacy data + - soc: ti: omap-prm: Fix occasional abort on reset deassert for dra7 iva + - veth: Store queue_mapping independently of XDP prog presence + - bpf: Dont allow vmlinux BTF to be used in map_create and prog_load. + - bpf: Change inode_storage's lookup_elem return value from NULL to -EBADF + - libbpf: Fix INSTALL flag order + - net/mlx5e: RX, Mind the MPWQE gaps when calculating offsets + - net/mlx5e: Set PTP channel pointer explicitly to NULL + - net/mlx5e: When changing XDP program without reset, take refs for XSK RQs + - net/mlx5e: Revert parameters on errors when changing PTP state without reset + - net/mlx5e: Don't match on Geneve options in case option masks are all zero + - net/mlx5e: E-switch, Fix rate calculation division + - ipv6: fix suspecious RCU usage warning + - drop_monitor: Perform cleanup upon probe registration failure + - macvlan: macvlan_count_rx() needs to be aware of preemption + - net: sched: validate stab values + - net: dsa: bcm_sf2: Qualify phydev->dev_flags based on port + - igc: reinit_locked() should be called with rtnl_lock + - igc: Fix Pause Frame Advertising + - igc: Fix Supported Pause Frame Link Setting + - igc: Fix igc_ptp_rx_pktstamp() + - e1000e: add rtnl_lock() to e1000_reset_task + - e1000e: Fix error handling in e1000_set_d0_lplu_state_82571 + - kunit: tool: Disable PAGE_POISONING under --alltests + - net/qlcnic: Fix a use after free in qlcnic_83xx_get_minidump_template + - net: phy: broadcom: Add power down exit reset state delay + - ice: fix napi work done reporting in xsk path + - ftgmac100: Restart MAC HW once + - clk: qcom: gcc-sc7180: Use floor ops for the correct sdcc1 clk + - net: ipa: terminate message handler arrays + - net: qrtr: fix a kernel-infoleak in qrtr_recvmsg() + - flow_dissector: fix byteorder of dissected ICMP ID + - selftests/bpf: Set gopt opt_class to 0 if get tunnel opt failed + - netfilter: ctnetlink: fix dump of the expect mask attribute + - net: hdlc_x25: Prevent racing between "x25_close" and "x25_xmit"/"x25_rx" + - net: phylink: Fix phylink_err() function name error in phylink_major_config + - tipc: better validate user input in tipc_nl_retrieve_key() + - tcp: relookup sock for RST+ACK packets handled by obsolete req sock + - mptcp: fix ADD_ADDR HMAC in case port is specified + - can: isotp: isotp_setsockopt(): only allow to set low level TX flags for + CAN-FD + - can: isotp: TX-path: ensure that CAN frame flags are initialized + - can: peak_usb: add forgotten supported devices + - can: flexcan: flexcan_chip_freeze(): fix chip freeze for missing bitrate + - can: kvaser_pciefd: Always disable bus load reporting + - can: c_can_pci: c_can_pci_remove(): fix use-after-free + - can: c_can: move runtime PM enable/disable to c_can_platform + - can: m_can: m_can_do_rx_poll(): fix extraneous msg loss warning + - can: m_can: m_can_rx_peripheral(): fix RX being blocked by errors + - mac80211: fix rate mask reset + - mac80211: Allow HE operation to be longer than expected. + - selftests/net: fix warnings on reuseaddr_ports_exhausted + - nfp: flower: fix unsupported pre_tunnel flows + - nfp: flower: add ipv6 bit to pre_tunnel control message + - nfp: flower: fix pre_tun mask id allocation + - ftrace: Fix modify_ftrace_direct. + - drm/msm/dsi: fix check-before-set in the 7nm dsi_pll code + - ionic: linearize tso skb with too many frags + - net/sched: cls_flower: fix only mask bit check in the validate_ct_state + - netfilter: nftables: report EOPNOTSUPP on unsupported flowtable flags + - netfilter: nftables: allow to update flowtable flags + - netfilter: flowtable: Make sure GC works periodically in idle system + - libbpf: Fix error path in bpf_object__elf_init() + - libbpf: Use SOCK_CLOEXEC when opening the netlink socket + - ARM: dts: imx6ull: fix ubi filesystem mount failed + - ipv6: weaken the v4mapped source check + - octeontx2-af: Formatting debugfs entry rsrc_alloc. + - octeontx2-af: Remove TOS field from MKEX TX + - octeontx2-af: Fix irq free in rvu teardown + - octeontx2-pf: Clear RSS enable flag on interace down + - octeontx2-af: fix infinite loop in unmapping NPC counter + - net: check all name nodes in __dev_alloc_name + - net: cdc-phonet: fix data-interface release on probe failure + - igb: check timestamp validity + - sctp: move sk_route_caps check and set into sctp_outq_flush_transports + - r8152: limit the RX buffer size of RTL8153A for USB 2.0 + - net: stmmac: dwmac-sun8i: Provide TX and RX fifo sizes + - selinux: vsock: Set SID for socket returned by accept() + - selftests: forwarding: vxlan_bridge_1d: Fix vxlan ecn decapsulate value + - libbpf: Fix BTF dump of pointer-to-array-of-struct + - bpf: Fix umd memory leak in copy_process() + - can: isotp: tx-path: zero initialize outgoing CAN frames + - platform/x86: dell-wmi-sysman: Fix crash caused by calling kset_unregister + twice + - platform/x86: dell-wmi-sysman: Fix possible NULL pointer deref on exit + - platform/x86: dell-wmi-sysman: Make it safe to call exit_foo_attributes() + multiple times + - platform/x86: dell-wmi-sysman: Fix release_attributes_data() getting called + twice on init_bios_attributes() failure + - platform/x86: dell-wmi-sysman: Cleanup sysman_init() error-exit handling + - platform/x86: dell-wmi-sysman: Make sysman_init() return -ENODEV of the + interfaces are not found + - drm/msm: fix shutdown hook in case GPU components failed to bind + - drm/msm: Fix suspend/resume on i.MX5 + - arm64: kdump: update ppos when reading elfcorehdr + - PM: runtime: Defer suspending suppliers + - net/mlx5: Add back multicast stats for uplink representor + - net/mlx5e: Allow to match on MPLS parameters only for MPLS over UDP + - net/mlx5e: Offload tuple rewrite for non-CT flows + - net/mlx5e: Fix error path for ethtool set-priv-flag + - mfd: intel_quark_i2c_gpio: Revert "Constify static struct resources" + - PM: EM: postpone creating the debugfs dir till fs_initcall + - platform/x86: intel_pmt_crashlog: Fix incorrect macros + - net: bridge: don't notify switchdev for local FDB addresses + - octeontx2-af: Fix memory leak of object buf + - xen/x86: make XEN_BALLOON_MEMORY_HOTPLUG_LIMIT depend on MEMORY_HOTPLUG + - RDMA/cxgb4: Fix adapter LE hash errors while destroying ipv6 listening + server + - mm: memblock: fix section mismatch warning again + - bpf: Don't do bpf_cgroup_storage_set() for kuprobe/tp programs + - net: Consolidate common blackhole dst ops + - net, bpf: Fix ip6ip6 crash with collect_md populated skbs + - igb: avoid premature Rx buffer reuse + - net: axienet: Fix probe error cleanup + - net: phy: introduce phydev->port + - net: phy: broadcom: Avoid forward for bcm54xx_config_clock_delay() + - net: phy: broadcom: Set proper 1000BaseX/SGMII interface mode for BCM54616S + - net: phy: broadcom: Fix RGMII delays for BCM50160 and BCM50610M + - Revert "netfilter: x_tables: Switch synchronization to RCU" + - netfilter: x_tables: Use correct memory barriers. + - bpf: Fix fexit trampoline. + - bpf: Use NOP_ATOMIC5 instead of emit_nops(&prog, 5) for + BPF_TRAMP_F_CALL_ORIG + - platform/x86: dell-wmi-sysman: Cleanup create_attributes_level_sysfs_files() + - dm table: Fix zoned model check and zone sectors check + - mm/mmu_notifiers: ensure range_end() is paired with range_start() + - Revert "netfilter: x_tables: Update remaining dereference to RCU" + - ACPI: scan: Rearrange memory allocation in acpi_device_add() + - ACPI: scan: Use unique number for instance_no + - perf auxtrace: Fix auxtrace queue conflict + - perf synthetic events: Avoid write of uninitialized memory when generating + PERF_RECORD_MMAP* records + - io_uring: fix provide_buffers sign extension + - block: recalculate segment count for multi-segment discards correctly + - scsi: Revert "qla2xxx: Make sure that aborted commands are freed" + - scsi: qedi: Fix error return code of qedi_alloc_global_queues() + - scsi: mpt3sas: Fix error return code of mpt3sas_base_attach() + - smb3: fix cached file size problems in duplicate extents (reflink) + - cifs: Adjust key sizes and key generation routines for AES256 encryption + - locking/mutex: Fix non debug version of mutex_lock_io_nested() + - x86/mem_encrypt: Correct physical address calculation in __set_clr_pte_enc() + - fs/cachefiles: Remove wait_bit_key layout dependency + - ch_ktls: fix enum-conversion warning + - can: dev: Move device back to init netns on owning netns delete + - r8169: fix DMA being used after buffer free if WoL is enabled + - net: dsa: b53: VLAN filtering is global to all users + - mac80211: fix double free in ibss_leave + - ext4: add reclaim checks to xattr code + - fs/ext4: fix integer overflow in s_log_groups_per_flex + - Revert "xen: fix p2m size in dom0 for disabled memory hotplug case" + - nvme: fix the nsid value to print in nvme_validate_or_alloc_ns + - can: peak_usb: Revert "can: peak_usb: add forgotten supported devices" + - selftest/bpf: Add a test to check trampoline freeing logic. + - xen-blkback: don't leak persistent grants from xen_blkbk_map() + - Linux 5.11.11 + - [Config] Update configs for rename of XEN_BALLOON_MEMORY_HOTPLUG_LIMIT to + XEN_MEMORY_HOTPLUG_LIMIT + + * Hirsute update: v5.11.10 upstream stable release (LP: #1922600) + - Revert "drm/ttm: make ttm_bo_unpin more defensive" + - Revert "drm/ttm: Warn on pinning without holding a reference" + - Linux 5.11.10 + + * [FEATURE] Hirsute: support TLS device offload for Bond (LP: #1915717) + - net: netdevice: Add operation ndo_sk_get_lower_dev + - net/bonding: Take IP hash logic into a helper + - net/bonding: Implement ndo_sk_get_lower_dev + - net/bonding: Take update_features call out of XFRM funciton + - net/bonding: Implement TLS TX device offload + - net/bonding: Declare TLS RX device offload support + - net/tls: Device offload to use lowest netdevice in chain + - net/tls: Except bond interface from some TLS checks + + * i915 doesn't support some high pixel clock 4k * 60Hz monitors (LP: #1922372) + - drm/i915/vbt: update DP max link rate table + + * cold boot panics on unmatched board, soft reboot is fine (LP: #1920916) + - Revert "RISC-V: sifive_l2_cache: Update L2 cache driver to support SiFive + FU740" + - Revert "RISC-V: Update l2 cache DT documentation to add support for SiFive + FU740" + - Revert "dt-bindings: riscv: Update DT binding docs to support SiFive FU740 + SoC" + - dt-bindings: riscv: Update l2 cache DT documentation to add support for + SiFive FU740 + - RISC-V: sifive_l2_cache: Update L2 cache driver to support SiFive FU740 + - dt-bindings: riscv: Update DT binding docs to support SiFive FU740 SoC + - dt-bindings: pwm: Update DT binding docs to support SiFive FU740 SoC + - dt-bindings: gpio: Update DT binding docs to support SiFive FU740 SoC + + * Microphone and Mute/Mic-mute LEDs are not work on HP 640 G8 Laptop + (LP: #1922207) + - ALSA: hda/realtek: fix mute/micmute LEDs for HP 640 G8 + + * Enable ath11k debugfs/tracing (LP: #1922033) + - [Config] enable ath11k debugfs/tracing + + * Handle Intel Wifi firmware disconnection (LP: #1922171) + - iwlwifi: mvm: handle CCA-EXT delay firmware notification + + * LRMv4: switch to signing nvidia modules via the Ubuntu Modules signing key + (LP: #1918134) + - [Packaging] convert to v4 autogen form -- pull back updated dkms-build + family + + * [21.04 FEAT] Add kernel debug infos for decompressor stage to kernel-debug + package (LP: #1905020) + - [Debian] include decompressor binary in dbginfo packages + + * qemu-system-ppc64le fails with kvm acceleration (LP: #1920784) + - KVM: PPC: Book3S HV: Save and restore FSCR in the P9 path + + * Fix mic on P620 after S3 resume (LP: #1921757) + - ALSA: usb-audio: Carve out connector value checking into a helper + - ALSA: usb-audio: Check connector value on resume + + * [Regression] Partition not removed after removing the memory cards from card + reader since kernel 5.9.0-rc3+ (LP: #1920874) + - block: clear GD_NEED_PART_SCAN later in bdev_disk_changed + + * Tegra "mmc0: Timeout waiting for hardware interrupt" (LP: #1921140) + - SAUCE: mmc: host: Add required callbacks to set/clear CQE_EN bit + + * Bcache bypasse writeback on caching device with fragmentation (LP: #1900438) + - bcache: consider the fragmentation when update the writeback rate + + * alsa/realtek: extend the delay time in the determine_headset_type for a + Dell AIO (LP: #1920747) + - SAUCE: ALSA: hda/realtek: fix a determine_headset_type issue for a Dell AIO + + * Hirsute update: v5.11.9 upstream stable release (LP: #1921712) + - ASoC: ak4458: Add MODULE_DEVICE_TABLE + - ASoC: ak5558: Add MODULE_DEVICE_TABLE + - spi: cadence: set cqspi to the driver_data field of struct device + - ALSA: dice: fix null pointer dereference when node is disconnected + - ALSA: hda/realtek: apply pin quirk for XiaomiNotebook Pro + - ALSA: hda: generic: Fix the micmute led init state + - ALSA: hda/realtek: Apply headset-mic quirks for Xiaomi Redmibook Air + - Revert "PM: runtime: Update device status before letting suppliers suspend" + - s390/vtime: fix increased steal time accounting + - s390/pci: refactor zpci_create_device() + - s390/pci: remove superfluous zdev->zbus check + - s390/pci: fix leak of PCI device structure + - zonefs: Fix O_APPEND async write handling + - zonefs: prevent use of seq files as swap file + - zonefs: fix to update .i_wr_refcnt correctly in zonefs_open_zone() + - btrfs: fix race when cloning extent buffer during rewind of an old root + - btrfs: fix slab cache flags for free space tree bitmap + - vhost-vdpa: fix use-after-free of v->config_ctx + - vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails + - drm/amd/display: Copy over soc values before bounding box creation + - drm/amd/display: Correct algorithm for reversed gamma + - drm/amd/display: Remove MPC gamut remap logic for DCN30 + - iommu/amd: Don't call early_amd_iommu_init() when AMD IOMMU is disabled + - iommu/amd: Keep track of amd_iommu_irq_remap state + - iommu/amd: Move Stoney Ridge check to detect_ivrs() + - ASoC: fsl_ssi: Fix TDM slot setup for I2S mode + - ASoC: Intel: bytcr_rt5640: Fix HP Pavilion x2 10-p0XX OVCD current threshold + - ASoC: SOF: Intel: unregister DMIC device on probe error + - ASoC: SOF: intel: fix wrong poll bits in dsp power down + - ASoC: qcom: sdm845: Fix array out of bounds access + - ASoC: qcom: sdm845: Fix array out of range on rx slim channels + - ASoC: codecs: wcd934x: add a sanity check in set channel map + - ASoC: qcom: lpass-cpu: Fix lpass dai ids parse + - ASoC: simple-card-utils: Do not handle device clock + - afs: Fix accessing YFS xattrs on a non-YFS server + - afs: Stop listxattr() from listing "afs.*" attributes + - ALSA: usb-audio: Fix unintentional sign extension issue + - nvme: fix Write Zeroes limitations + - nvme-tcp: fix misuse of __smp_processor_id with preemption enabled + - nvme-tcp: fix possible hang when failing to set io queues + - nvme-tcp: fix a NULL deref when receiving a 0-length r2t PDU + - nvmet: don't check iosqes,iocqes for discovery controllers + - nfsd: Don't keep looking up unhashed files in the nfsd file cache + - nfsd: don't abort copies early + - NFSD: Repair misuse of sv_lock in 5.10.16-rt30. + - NFSD: fix dest to src mount in inter-server COPY + - svcrdma: disable timeouts on rdma backchannel + - vfio: IOMMU_API should be selected + - vhost_vdpa: fix the missing irq_bypass_unregister_producer() invocation + - sunrpc: fix refcount leak for rpc auth modules + - i915/perf: Start hrtimer only if sampling the OA buffer + - iommu/tegra-smmu: Make tegra_smmu_probe_device() to handle all IOMMU + phandles + - pstore: Fix warning in pstore_kill_sb() + - io_uring: ensure that SQPOLL thread is started for exit + - net/qrtr: fix __netdev_alloc_skb call + - kbuild: Fix <linux/version.h> for empty SUBLEVEL or PATCHLEVEL again + - cifs: warn and fail if trying to use rootfs without the config option + - cifs: fix allocation size on newly created files + - RISC-V: Fix out-of-bounds accesses in init_resources() + - riscv: Correct SPARSEMEM configuration + - scsi: lpfc: Fix some error codes in debugfs + - scsi: myrs: Fix a double free in myrs_cleanup() + - scsi: ufs: ufs-mediatek: Correct operator & -> && + - scsi: mpt3sas: Do not use GFP_KERNEL in atomic context + - RISC-V: correct enum sbi_ext_rfence_fid + - counter: stm32-timer-cnt: Report count function when SLAVE_MODE_DISABLED + - ASoC: codecs: lpass-va-macro: mute/unmute all active decimators + - ASoC: codecs: lpass-wsa-macro: fix RX MIX input controls + - powerpc/vdso32: Add missing _restgpr_31_x to fix build failure + - drm/ttm: Warn on pinning without holding a reference + - drm/ttm: make ttm_bo_unpin more defensive + - gpiolib: Assign fwnode to parent's if no primary one provided + - nvme-rdma: fix possible hang when failing to set io queues + - powerpc: Force inlining of cpu_has_feature() to avoid build failure + - usb-storage: Add quirk to defeat Kindle's automatic unload + - usbip: Fix incorrect double assignment to udc->ud.tcp_rx + - usb: gadget: configfs: Fix KASAN use-after-free + - usb: typec: Remove vdo[3] part of tps6598x_rx_identity_reg struct + - usb: typec: tcpm: Invoke power_supply_changed for tcpm-source-psy- + - usb: dwc3: gadget: Allow runtime suspend if UDC unbinded + - usb: dwc3: gadget: Prevent EP queuing while stopping transfers + - thunderbolt: Initialize HopID IDAs in tb_switch_alloc() + - thunderbolt: Increase runtime PM reference count on DP tunnel discovery + - iio:adc:stm32-adc: Add HAS_IOMEM dependency + - iio:adc:qcom-spmi-vadc: add default scale to LR_MUX2_BAT_ID channel + - iio: adis16400: Fix an error code in adis16400_initial_setup() + - iio: gyro: mpu3050: Fix error handling in mpu3050_trigger_handler + - iio: adc: ab8500-gpadc: Fix off by 10 to 3 + - iio: adc: ad7949: fix wrong ADC result due to incorrect bit mask + - iio: adc: adi-axi-adc: add proper Kconfig dependencies + - iio: hid-sensor-humidity: Fix alignment issue of timestamp channel + - iio: hid-sensor-prox: Fix scale not correct issue + - iio: hid-sensor-temperature: Fix issues of timestamp channel + - counter: stm32-timer-cnt: fix ceiling write max value + - counter: stm32-timer-cnt: fix ceiling miss-alignment with reload register + - PCI: rpadlpar: Fix potential drc_name corruption in store functions + - perf/x86/intel: Fix a crash caused by zero PEBS status + - perf/x86/intel: Fix unchecked MSR access error caused by VLBR_EVENT + - x86/ioapic: Ignore IRQ2 again + - kernel, fs: Introduce and use set_restart_fn() and arch_set_restart_data() + - x86: Move TS_COMPAT back to asm/thread_info.h + - x86: Introduce TS_COMPAT_RESTART to fix get_nr_restart_syscall() + - efivars: respect EFI_UNSUPPORTED return from firmware + - ext4: fix error handling in ext4_end_enable_verity() + - ext4: find old entry again if failed to rename whiteout + - ext4: stop inode update before return + - ext4: do not try to set xattr into ea_inode if value is empty + - ext4: fix potential error in ext4_do_update_inode + - ext4: fix timer use-after-free on failed mount + - ext4: fix rename whiteout with fast commit + - MAINTAINERS: move some real subsystems off of the staging mailing list + - MAINTAINERS: move the staging subsystem to lists.linux.dev + - static_call: Fix static_call_update() sanity check + - efi: use 32-bit alignment for efi_guid_t literals + - firmware/efi: Fix a use after bug in efi_mem_reserve_persistent + - genirq: Disable interrupts for force threaded handlers + - x86/apic/of: Fix CPU devicetree-node lookups + - cifs: Fix preauth hash corruption + - Linux 5.11.9 + + * Hirsute update: v5.11.8 upstream stable release (LP: #1921710) + - io_uring: don't attempt IO reissue from the ring exit path + - KVM: x86/mmu: Expand on the comment in kvm_vcpu_ad_need_write_protect() + - KVM: x86/mmu: Set SPTE_AD_WRPROT_ONLY_MASK if and only if PML is enabled + - mptcp: send ack for every add_addr + - mptcp: pm: add lockdep assertions + - mptcp: dispose initial struct socket when its subflow is closed + - io_uring: refactor scheduling in io_cqring_wait + - io_uring: refactor io_cqring_wait + - io_uring: don't keep looping for more events if we can't flush overflow + - io_uring: simplify do_read return parsing + - io_uring: clear IOCB_WAITQ for non -EIOCBQUEUED return + - regulator: pca9450: Add SD_VSEL GPIO for LDO5 + - regulator: pca9450: Enable system reset on WDOG_B assertion + - regulator: pca9450: Clear PRESET_EN bit to fix BUCK1/2/3 voltage setting + - gfs2: Add common helper for holding and releasing the freeze glock + - gfs2: move freeze glock outside the make_fs_rw and _ro functions + - gfs2: bypass signal_our_withdraw if no journal + - bpf: Simplify alu_limit masking for pointer arithmetic + - bpf: Add sanity check for upper ptr_limit + - arm64: Unconditionally set virtual cpu id registers + - RDMA/srp: Fix support for unpopulated and unbalanced NUMA nodes + - fuse: fix live lock in fuse_iget() + - Revert "nfsd4: remove check_conflicting_opens warning" + - Revert "nfsd4: a client's own opens needn't prevent delegations" + - net: dsa: b53: Support setting learning on port + - crypto: x86/aes-ni-xts - use direct calls to and 4-way stride + - Linux 5.11.8 + + * Hirsute update: v5.11.7 upstream stable release (LP: #1919492) + - ethernet: alx: fix order of calls on resume + + * Mute/Mic-mute LEDs are not work on HP 850/840/440 G8 Laptops (LP: #1920030) + - ALSA: hda/realtek: fix mute/micmute LEDs for HP 840 G8 + - ALSA: hda/realtek: fix mute/micmute LEDs for HP 440 G8 + - ALSA: hda/realtek: fix mute/micmute LEDs for HP 850 G8 + + * power off stress test will hang on the TGL machines (LP: #1919930) + - [Config] set SND_SOC_SOF_HDA_ALWAYS_ENABLE_DMI_L1 to n + - ASoC: SOF: add .shutdown() callback to snd_sof_dsp_ops + - ASoC: SOF: add snd_sof_device_shutdown() helper for shutdown + - ASoC: SOF: sof-pci-dev: add .shutdown() callback + - ASoC: SOF: Intel: tgl: do thorough remove at .shutdown() callback + - SAUCE: ASoC: SOF: Intel: TGL: set shutdown callback to hda_dsp_shutdown + + * Miscellaneous Ubuntu changes + - [Config] arm64 -- unify build_image and kernel_file values + - SAUCE: apparmor: Fix build error, make sk parameter const + - SAUCE: xr-usb-serial: clean up indentation + - SAUCE: xr-usb-serial: clean up build warnings + + -- Seth Forshee <email address hidden> Thu, 08 Apr 2021 15:48:19 -0500 + diff --git a/results/classifier/zero-shot/108/all/1926111 b/results/classifier/zero-shot/108/all/1926111 new file mode 100644 index 000000000..1e14154d9 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1926111 @@ -0,0 +1,214 @@ +performance: 0.984 +debug: 0.984 +permissions: 0.983 +semantic: 0.982 +device: 0.982 +PID: 0.981 +vnc: 0.980 +other: 0.980 +graphic: 0.978 +socket: 0.973 +network: 0.969 +files: 0.964 +boot: 0.964 +KVM: 0.925 + +Assertion `tx_queue_idx <= s->txq_num' failed in vmxnet3_io_bar0_write + +=== Stacktrace === + +qemu-fuzz-i386: ../hw/net/vmxnet3.c:1096: void vmxnet3_io_bar0_write(void *, hwaddr, uint64_t, unsigned int): Assertion `tx_queue_idx <= s->txq_num' failed. +==602353== ERROR: libFuzzer: deadly signal +#5 0x7fe4b93a7ce0 in raise signal/../sysdeps/unix/sysv/linux/raise.c:48:3 +#6 0x7fe4b9391536 in abort stdlib/abort.c:79:7 +#7 0x7fe4b939140e in __assert_fail_base assert/assert.c:92:3 +#8 0x7fe4b93a0661 in __assert_fail assert/assert.c:101:3 +#9 0x563e6cf5ebb5 in vmxnet3_io_bar0_write hw/net/vmxnet3.c:1096:9 +#10 0x563e6eefdb00 in memory_region_write_accessor softmmu/memory.c:491:5 +#11 0x563e6eefcfdd in access_with_adjusted_size softmmu/memory.c:552:18 +#12 0x563e6eefac90 in memory_region_dispatch_write softmmu/memory.c:1502:16 +#13 0x563e6e834e16 in flatview_write_continue softmmu/physmem.c:2746:23 +#14 0x563e6e81cd38 in flatview_write softmmu/physmem.c:2786:14 +#15 0x563e6e81c868 in address_space_write softmmu/physmem.c:2878:18 + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ +512M -machine q35 -nodefaults -device vmxnet3,netdev=net0 -netdev \ +user,id=net0 -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000814 +outl 0xcf8 0x80000804 +outw 0xcfc 0x7 +outl 0xcf8 0x80000815 +outl 0xcfc 0xffff00b5 +write 0x0 0x1 0xe1 +write 0x1 0x1 0xfe +write 0x2 0x1 0xbe +write 0x3 0x1 0xba +write 0xff00b020 0x4 0x0000feca +write 0xe0000630 0x1 0x00 +EOF + + +=== Testcase === + +/* + * Autogenerated Fuzzer Test Case + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + */ + +#include "qemu/osdep.h" + +#include "libqos/libqtest.h" + +static void test_fuzz(void) { + QTestState *s = qtest_init(" -display none , -m 512M -machine q35 -nodefaults " + "-device vmxnet3,netdev=net0 -netdev user,id=net0"); + qtest_outl(s, 0xcf8, 0x80000810); + qtest_outl(s, 0xcfc, 0xe0000000); + qtest_outl(s, 0xcf8, 0x80000814); + qtest_outl(s, 0xcf8, 0x80000804); + qtest_outw(s, 0xcfc, 0x7); + qtest_outl(s, 0xcf8, 0x80000815); + qtest_outl(s, 0xcfc, 0xffff00b5); + qtest_bufwrite(s, 0x0, "\xe1", 0x1); + qtest_bufwrite(s, 0x1, "\xfe", 0x1); + qtest_bufwrite(s, 0x2, "\xbe", 0x1); + qtest_bufwrite(s, 0x3, "\xba", 0x1); + qtest_bufwrite(s, 0xff00b020, "\x00\x00\xfe\xca", 0x4); + qtest_bufwrite(s, 0xe0000630, "\x00", 0x1); + qtest_quit(s); +} +int main(int argc, char **argv) { + const char *arch = qtest_get_arch(); + + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "i386") == 0) { + qtest_add_func("fuzz/test_fuzz", test_fuzz); + } + + return g_test_run(); +} + + +=== OSS-Fuzz Report === +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33603 +https://oss-fuzz.com/testcase?key=6071483232288768 + +Cc'ing maintainers. + +./scripts/get_maintainer.pl -f hw/net/vmxnet3.c +Dmitry Fleytman <email address hidden> (maintainer:Vmware) +Jason Wang <email address hidden> (odd fixer:Network devices) + +On 4/26/21 5:19 AM, Alexander Bulekov wrote: +> Public bug reported: +> +> === Stacktrace === +> +> qemu-fuzz-i386: ../hw/net/vmxnet3.c:1096: void vmxnet3_io_bar0_write(void *, hwaddr, uint64_t, unsigned int): Assertion `tx_queue_idx <= s->txq_num' failed. +> ==602353== ERROR: libFuzzer: deadly signal +> #5 0x7fe4b93a7ce0 in raise signal/../sysdeps/unix/sysv/linux/raise.c:48:3 +> #6 0x7fe4b9391536 in abort stdlib/abort.c:79:7 +> #7 0x7fe4b939140e in __assert_fail_base assert/assert.c:92:3 +> #8 0x7fe4b93a0661 in __assert_fail assert/assert.c:101:3 +> #9 0x563e6cf5ebb5 in vmxnet3_io_bar0_write hw/net/vmxnet3.c:1096:9 +> #10 0x563e6eefdb00 in memory_region_write_accessor softmmu/memory.c:491:5 +> #11 0x563e6eefcfdd in access_with_adjusted_size softmmu/memory.c:552:18 +> #12 0x563e6eefac90 in memory_region_dispatch_write softmmu/memory.c:1502:16 +> #13 0x563e6e834e16 in flatview_write_continue softmmu/physmem.c:2746:23 +> #14 0x563e6e81cd38 in flatview_write softmmu/physmem.c:2786:14 +> #15 0x563e6e81c868 in address_space_write softmmu/physmem.c:2878:18 +> +> === Reproducer === +> cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ +> 512M -machine q35 -nodefaults -device vmxnet3,netdev=net0 -netdev \ +> user,id=net0 -qtest stdio +> outl 0xcf8 0x80000810 +> outl 0xcfc 0xe0000000 +> outl 0xcf8 0x80000814 +> outl 0xcf8 0x80000804 +> outw 0xcfc 0x7 +> outl 0xcf8 0x80000815 +> outl 0xcfc 0xffff00b5 +> write 0x0 0x1 0xe1 +> write 0x1 0x1 0xfe +> write 0x2 0x1 0xbe +> write 0x3 0x1 0xba +> write 0xff00b020 0x4 0x0000feca +> write 0xe0000630 0x1 0x00 +> EOF +> +> +> === Testcase === +> +> /* +> * Autogenerated Fuzzer Test Case +> * +> * This work is licensed under the terms of the GNU GPL, version 2 or later. +> * See the COPYING file in the top-level directory. +> */ +> +> #include "qemu/osdep.h" +> +> #include "libqos/libqtest.h" +> +> static void test_fuzz(void) { +> QTestState *s = qtest_init(" -display none , -m 512M -machine q35 -nodefaults " +> "-device vmxnet3,netdev=net0 -netdev user,id=net0"); +> qtest_outl(s, 0xcf8, 0x80000810); +> qtest_outl(s, 0xcfc, 0xe0000000); +> qtest_outl(s, 0xcf8, 0x80000814); +> qtest_outl(s, 0xcf8, 0x80000804); +> qtest_outw(s, 0xcfc, 0x7); +> qtest_outl(s, 0xcf8, 0x80000815); +> qtest_outl(s, 0xcfc, 0xffff00b5); +> qtest_bufwrite(s, 0x0, "\xe1", 0x1); +> qtest_bufwrite(s, 0x1, "\xfe", 0x1); +> qtest_bufwrite(s, 0x2, "\xbe", 0x1); +> qtest_bufwrite(s, 0x3, "\xba", 0x1); +> qtest_bufwrite(s, 0xff00b020, "\x00\x00\xfe\xca", 0x4); +> qtest_bufwrite(s, 0xe0000630, "\x00", 0x1); +> qtest_quit(s); +> } +> int main(int argc, char **argv) { +> const char *arch = qtest_get_arch(); +> +> g_test_init(&argc, &argv, NULL); +> +> if (strcmp(arch, "i386") == 0) { +> qtest_add_func("fuzz/test_fuzz", test_fuzz); +> } +> +> return g_test_run(); +> } +> +> +> === OSS-Fuzz Report === +> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33603 +> https://oss-fuzz.com/testcase?key=6071483232288768 +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> +> ** Tags: fuzzer +> +> ** Tags removed: fuzz +> ** Tags added: fuzzer +> + + + +I can reproduce this issue with the latest version of QEMU. Marking as "Confirmed" + +Suggested fix: https://<email address hidden>/ + +Fix has been included here: +https://gitlab.com/qemu-project/qemu/-/commit/6a932c4ed8748b08c58c + diff --git a/results/classifier/zero-shot/108/all/1926231 b/results/classifier/zero-shot/108/all/1926231 new file mode 100644 index 000000000..1c0eeb57b --- /dev/null +++ b/results/classifier/zero-shot/108/all/1926231 @@ -0,0 +1,88 @@ +permissions: 0.970 +other: 0.968 +graphic: 0.967 +semantic: 0.961 +debug: 0.961 +device: 0.960 +performance: 0.958 +files: 0.944 +PID: 0.943 +network: 0.940 +socket: 0.937 +boot: 0.933 +vnc: 0.913 +KVM: 0.909 + +SCSI passthrough of SATA cdrom -> errors & performance issues + +qemu 5.0, compiled from git + +I am passing through a SATA cdrom via SCSI passthrough, with this libvirt XML: + + <hostdev mode='subsystem' type='scsi' managed='no' sgio='unfiltered' rawio='yes'> + <source> + <adapter name='scsi_host3'/> + <address bus='0' target='0' unit='0'/> + </source> + <alias name='hostdev0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </hostdev> + +It seems to mostly work, I have written discs with it, except I am getting errors that cause reads to take about 5x as long as they should, under certain circumstances. It appears to be based on the guest's read block size. + +I found that if on the guest I run, say `dd if=$some_large_file bs=262144|pv > /dev/null`, `iostat` and `pv` disagree about how much is being read by a factor of about 2. Also many kernel messages like this happen on the guest: + +[ 190.919684] sr 0:0:0:0: [sr0] tag#160 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s +[ 190.919687] sr 0:0:0:0: [sr0] tag#160 Sense Key : Aborted Command [current] +[ 190.919689] sr 0:0:0:0: [sr0] tag#160 Add. Sense: I/O process terminated +[ 190.919691] sr 0:0:0:0: [sr0] tag#160 CDB: Read(10) 28 00 00 18 a5 5a 00 00 80 00 +[ 190.919694] blk_update_request: I/O error, dev sr0, sector 6460776 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0 + +If I change to bs=131072 the errors stop and performance is normal. + +(262144 happens to be the block size ultimately used by md5sum, which is how I got here) + +I also ran strace on the qemu process while it was happening, and noticed SG_IO calls like this: + +21748 10:06:29.330910 ioctl(22, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, cmdp="\x28\x00\x00\x12\x95\x5a\x00\x00\x80\x00", mx_sb_len=252, iovec_count=0, dxfer_len=262144, timeout=4294967295, flags=SG_FLAG_DIRECT_IO <unfinished ...> +21751 10:06:29.330976 ioctl(22, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, cmdp="\x28\x00\x00\x12\x94\xda\x00\x00\x02\x00", mx_sb_len=252, iovec_count=0, dxfer_len=4096, timeout=4294967295, flags=SG_FLAG_DIRECT_IO <unfinished ...> +21749 10:06:29.331586 ioctl(22, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, cmdp="\x28\x00\x00\x12\x94\xdc\x00\x00\x02\x00", mx_sb_len=252, iovec_count=0, dxfer_len=4096, timeout=4294967295, flags=SG_FLAG_DIRECT_IO <unfinished ...> +[etc] + +I suspect qemu is the culprit because I have tried a 4.19 guest kernel as well as a 5.9 one, with the same result. + +Just discovered that `hdparm -a 128` works around the issue (it was 256 at boot). + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/1927 b/results/classifier/zero-shot/108/all/1927 new file mode 100644 index 000000000..3e1472436 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1927 @@ -0,0 +1,539 @@ +other: 0.974 +permissions: 0.962 +debug: 0.956 +graphic: 0.955 +device: 0.955 +performance: 0.954 +boot: 0.954 +network: 0.952 +vnc: 0.949 +files: 0.944 +semantic: 0.936 +socket: 0.924 +PID: 0.923 +KVM: 0.920 + +SPARC64 pci-bridge kernel panic +Description of problem: +Kernel panics when a PCI bridge is added. +I wanted to install a number of PCI devices, but never got enough slots from the default PCI bus (pciB, pciA is not open at all). +So, I added a PCI bridge, but the kernel panics during boot: +``` +OpenBIOS for Sparc64 +Cannot manage 'PCI-to-PCI bridge' PCI device type 'pci': + 1b36 1 (6 4 0) +Cannot manage 'misc communication device' PCI device type '<NULL>': + 1af4 1003 (7 80 0) +Cannot manage 'undefined' PCI device type '<NULL>': + 1af4 1005 (0 ff 0) +Cannot manage 'undefined' PCI device type '<NULL>': + 1af4 1009 (0 2 0) +Cannot manage 'SCSI bus controller' PCI device type 'scsi': + 1af4 1004 (1 0 0) +Configuration device id QEMU version 1 machine id 0 +kernel phys 404000 virt 40004000 size 0x11f9290 +kernel cmdline root=/dev/sda rw log_buf_len=8M mitigations=off ktest.dir=/repos/janpieter/ktest ktest.env=/tmp/build-test-kernel-YOUlNpfwIz/env crashkernel=128M console=earlyprom0 loglevel=15 irqpoll kasan.fault=panic +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Mar 7 2023 22:22 + Type 'help' for detailed information +[sparc64] Kernel already loaded + +PROMLIB: Sun IEEE Boot Prom 'OBP 3.10.24 1999/01/01 01:01' +PROMLIB: Root node compatible: sun4u +Linux version 6.5.0-ktest-02812-g4d2faeb4fb58 (janpieter@linuxserver) (sparc64-linux-gnu-gcc (Gentoo 11.3.0 p4) 11.3.0, GNU ld (Gentoo 2.41 p2) 2.41.0) #10 SMP Mon Oct 9 15:55:57 CEST 2023 +printk: bootconsole [earlyprom0] enabled +ARCH: SUN4U +Ethernet address: 52:54:00:12:34:57 +MM: PAGE_OFFSET is 0xfffff80000000000 (max_phys_bits == 40) +MM: VMALLOC [0x0000000100000000 --> 0x0000060000000000] +MM: VMEMMAP [0x0000060000000000 --> 0x00000c0000000000] +Kernel: Using 5 locked TLB entries for main kernel image. +Remapping the kernel... +done. +OF stdout device is: /pci@1fe,0/pci@1,1/ebus@1/su +PROM: Built device tree with 66340 bytes of memory. +Top of RAM: 0x7fe80000, Total RAM: 0x7fe80000 +Memory hole size: 0MB +Allocated 16384 bytes for kernel page tables. +Zone ranges: + Normal [mem 0x0000000000000000-0x000000007fe7ffff] +Movable zone start for each node +Early memory node ranges + node 0: [mem 0x0000000000000000-0x000000007fe7ffff] +Initmem setup node 0 [mem 0x0000000000000000-0x000000007fe7ffff] +On node 0, zone Normal: 192 pages in unavailable ranges +Booting Linux... +CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus] +CPU CAPS: [vis] +percpu: Embedded 16 pages/cpu s93992 r8192 d28888 u4194304 +pcpu-alloc: s93992 r8192 d28888 u4194304 alloc=1*4194304 +pcpu-alloc: [0] 0 +Kernel command line: root=/dev/sda rw log_buf_len=8M mitigations=off ktest.dir=/repos/janpieter/ktest ktest.env=/tmp/build-test-kernel-YOUlNpfwIz/env crashkernel=128M console=earlyprom0 loglevel=15 irqpoll kasan.fault=panic +Misrouted IRQ fixup and polling support enabled +This may significantly impact system performance +Unknown kernel command line parameters "crashkernel=128M", will be passed to user space. +printk: log_buf_len: 8388608 bytes +printk: early log buf free: 128952(98%) +Dentry cache hash table entries: 262144 (order: 8, 2097152 bytes, linear) +Inode-cache hash table entries: 131072 (order: 7, 1048576 bytes, linear) +Sorting __ex_table... +Built 1 zonelists, mobility grouping on. Total pages: 259905 +mem auto-init: stack:off, heap alloc:off, heap free:off +Memory: 2020416K/2095616K available (6609K kernel code, 7566K rwdata, 1640K rodata, 560K init, 1980K bss, 75200K reserved, 0K cma-reserved) +SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 +ftrace: allocating 21433 entries in 42 pages +ftrace: allocated 42 pages with 3 groups +trace event string verifier disabled +rcu: Hierarchical RCU implementation. +rcu: RCU event tracing is enabled. +rcu: RCU restricting CPUs from NR_CPUS=4096 to nr_cpu_ids=1. + Rude variant of Tasks RCU enabled. +rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. +rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 +NR_IRQS: 2048, nr_irqs: 2048, preallocated irqs: 1 +rcu: srcu_init: Setting srcu_struct sizes based on contention. +clocksource: tick: mask: 0xffffffffffffffff max_cycles: 0x171024e7e0, max_idle_ns: 440795205315 ns +clocksource: mult[a000000] shift[24] +clockevent: mult[1999999a] shift[32] +Console: colour dummy device 80x25 +Calibrating delay using timer specific routine.. 201.35 BogoMIPS (lpj=402700) +pid_max: default: 32768 minimum: 301 +Mount-cache hash table entries: 4096 (order: 2, 32768 bytes, linear) +Mountpoint-cache hash table entries: 4096 (order: 2, 32768 bytes, linear) +RCU Tasks Rude: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1. +rcu: Hierarchical SRCU implementation. +rcu: Max phase no-delay instances is 1000. +smp: Bringing up secondary CPUs ... +smp: Brought up 1 node, 1 CPU +devtmpfs: initialized +device: 'platform': device_add +bus: 'platform': registered +bus: 'cpu': registered +device: 'cpu': device_add +bus: 'container': registered +device: 'container': device_add +Performance events: No support for PMU type 'ultra12' +bus: 'workqueue': registered +device: 'workqueue': device_add +clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns +futex hash table entries: 256 (order: 1, 16384 bytes, linear) +bus: 'virtio': registered +NET: Registered PF_NETLINK/PF_ROUTE protocol family +device: 'root': device_add +bus: 'platform': add device root +device: 'ffe1c220': device_add +bus: 'platform': add device ffe1c220 +device: 'ffe1c348': device_add +bus: 'platform': add device ffe1c348 +device: 'ffe26eb0': device_add +bus: 'platform': add device ffe26eb0 +device: 'ffe1c600': device_add +bus: 'platform': add device ffe1c600 +device: 'ffe1c6e0': device_add +bus: 'platform': add device ffe1c6e0 +device: 'ffe1c820': device_add +bus: 'platform': add device ffe1c820 +device: 'ffe1c948': device_add +bus: 'platform': add device ffe1c948 +device: 'ffe26978': device_add +bus: 'platform': add device ffe26978 +device: 'ffe289d0': device_add +bus: 'platform': add device ffe289d0 +device: 'ffe28c20': device_add +bus: 'platform': add device ffe28c20 +device: 'ffe2d168': device_add +bus: 'platform': add device ffe2d168 +device: 'ffe2d780': device_add +bus: 'platform': add device ffe2d780 +device: 'ffe2dd10': device_add +bus: 'platform': add device ffe2dd10 +device: 'ffe2e2a8': device_add +bus: 'platform': add device ffe2e2a8 +device: 'ffe2ba78': device_add +bus: 'platform': add device ffe2ba78 +device: 'ffe2bbd8': device_add +bus: 'platform': add device ffe2bbd8 +device: 'ffe2e478': device_add +bus: 'platform': add device ffe2e478 +device: 'ffe2ef68': device_add +bus: 'platform': add device ffe2ef68 +device: 'ffe2f8d0': device_add +bus: 'platform': add device ffe2f8d0 +device: 'ffe302d0': device_add +bus: 'platform': add device ffe302d0 +device: 'ffe30448': device_add +bus: 'platform': add device ffe30448 +device: 'ffe305f0': device_add +bus: 'platform': add device ffe305f0 +device: 'ffe30b40': device_add +bus: 'platform': add device ffe30b40 +device: 'ffe30ea8': device_add +bus: 'platform': add device ffe30ea8 +device: 'ffe310e8': device_add +bus: 'platform': add device ffe310e8 +device: 'ffe31470': device_add +bus: 'platform': add device ffe31470 +device: 'ffe31990': device_add +bus: 'platform': add device ffe31990 +device: 'ffe31e50': device_add +bus: 'platform': add device ffe31e50 +device: 'ffe323e8': device_add +bus: 'platform': add device ffe323e8 +device: 'ffe32c80': device_add +bus: 'platform': add device ffe32c80 +device: 'ffe332b8': device_add +bus: 'platform': add device ffe332b8 +device: 'ffe33a68': device_add +bus: 'platform': add device ffe33a68 +device: 'ffe33f58': device_add +bus: 'platform': add device ffe33f58 +device: 'ffe34448': device_add +bus: 'platform': add device ffe34448 +device: 'ffe34940': device_add +bus: 'platform': add device ffe34940 +device: 'ffe34f58': device_add +bus: 'platform': add device ffe34f58 +device class 'bdi': registering +device class 'pci_bus': registering +bus: 'pci': registered +bus: 'pci_express': registered +device class 'tty': registering +device class 'vtconsole': registering +device: 'vtcon0': device_add +bus: 'serial': registered +device class 'iommu': registering +device class 'devlink': registering +device class 'dma': registering +bus: 'serial-base': registered +bus: 'serial-base': add driver ctrl +bus: 'serial-base': add driver port +device: 'cpu0': device_add +bus: 'cpu': add device cpu0 +bus: 'platform': add driver psycho +bus: 'platform': add driver sabre +bus: 'platform': __driver_probe_device: matched device ffe2e478 with driver sabre +bus: 'platform': really_probe: probing driver sabre with device ffe2e478 +pci@1f,0: PCI IO [io 0x1fe02000000-0x1fe02ffffff] offset 1fe02000000 +pci@1f,0: PCI MEM [mem 0x1ff00000000-0x1ffefffffff] offset 1ff00000000 +pci@1f,0: SABRE PCI Bus Module ver[0:0] +PCI: Scanning PBM /pci@1f,0 +device: 'pci0000:00': device_add +device: '0000:00': device_add +sabre ffe2e478: PCI host bridge to bus 0000:00 +pci_bus 0000:00: root bus resource [io 0x1fe02000000-0x1fe02ffffff] (bus address [0x0000-0xffffff]) +pci_bus 0000:00: root bus resource [mem 0x1ff00000000-0x1ffefffffff] (bus address [0x00000000-0xefffffff]) +pci_bus 0000:00: root bus resource [bus 00-03] +pci 0000:00:01.1: [108e:5000] type 01 class 0x060400 +device: '0000:00:01.1': device_add +bus: 'pci': add device 0000:00:01.1 +pci_bus 0000:01: extended config space not accessible +device: '0000:01': device_add +pci 0000:01:01.0: [108e:1000] type 00 class 0x068000 +pci 0000:01:01.0: reg 0x10: [mem 0x1ff20000000-0x1ff20ffffff] +pci 0000:01:01.0: reg 0x14: [io 0x1fe02000000-0x1fe02007fff] +device: '0000:01:01.0': device_add +bus: 'pci': add device 0000:01:01.0 +pci 0000:01:03.0: enabling bus mastering +pci 0000:01:03.0: [1095:0646] type 00 class 0x01018f +pci 0000:01:03.0: reg 0x10: [io 0x1fe02008000-0x1fe02008007] +pci 0000:01:03.0: reg 0x14: [io 0x1fe02008080-0x1fe02008083] +pci 0000:01:03.0: reg 0x18: [io 0x1fe02008100-0x1fe02008107] +pci 0000:01:03.0: reg 0x1c: [io 0x1fe02008180-0x1fe02008183] +pci 0000:01:03.0: reg 0x20: [io 0x1fe02008200-0x1fe0200820f] +device: '0000:01:03.0': device_add +bus: 'pci': add device 0000:01:03.0 +pci 0000:00:01.0: [108e:5000] type 01 class 0x060400 +device: '0000:00:01.0': device_add +bus: 'pci': add device 0000:00:01.0 +pci_bus 0000:02: extended config space not accessible +device: '0000:02': device_add +pci 0000:02:00.0: [1af4:1000] type 00 class 0x020000 +pci 0000:02:00.0: reg 0x10: [io 0x1fe02800000-0x1fe0280001f] +pci 0000:02:00.0: reg 0x20: [mem 0x1ff60000000-0x1ff60003fff 64bit pref] +device: '0000:02:00.0': device_add +bus: 'pci': add device 0000:02:00.0 +pci 0000:02:01.0: [1b36:0001] type 00 class 0x060400 +pci 0000:02:01.0: reg 0x10: [mem 0x1ff60080000-0x1ff600800ff 64bit] +device: '0000:02:01.0': device_add +bus: 'pci': add device 0000:02:01.0 +pci 0000:02:02.0: [1af4:1004] type 00 class 0x010000 +pci 0000:02:02.0: reg 0x10: [io 0x1fe02802000-0x1fe0280203f] +pci 0000:02:02.0: reg 0x20: [mem 0x1ff60200000-0x1ff60203fff 64bit pref] +device: '0000:02:02.0': device_add +bus: 'pci': add device 0000:02:02.0 +driver: 'sabre': driver_bound: bound to device 'ffe2e478' +bus: 'platform': really_probe: bound device ffe2e478 to driver sabre +bus: 'platform': add driver schizo +bus: 'platform': add driver pci_sun4v +bus: 'platform': add driver fire +device: 'writeback': device_add +bus: 'workqueue': add device writeback +device class 'block': registering +device class 'misc': registering +iommu: Default domain type: Passthrough +device class 'scsi_host': registering +bus: 'scsi': registered +device class 'scsi_device': registering +SCSI subsystem initialized +device class 'input': registering +device class 'rtc': registering +device class 'pps': registering +pps_core: LinuxPPS API ver. 1 registered +pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> +device class 'ptp': registering +PTP clock support registered +device class 'net': registering +device: 'lo': device_add +bus: 'platform': add driver rtc +bus: 'platform': add driver mostek +bus: 'platform': __driver_probe_device: matched device ffe302d0 with driver mostek +bus: 'platform': really_probe: probing driver mostek with device ffe302d0 +/pci@1f,0/pci@1,1/ebus@1/eeprom@14,2000: Mostek regs at 0x1fe02002000 +Registering platform device 'rtc-m48t59.0'. Parent at platform +device: 'rtc-m48t59.0': device_add +bus: 'platform': add device rtc-m48t59.0 +driver: 'mostek': driver_bound: bound to device 'ffe302d0' +bus: 'platform': really_probe: bound device ffe302d0 to driver mostek +bus: 'platform': add driver bq4802 +bus: 'platform': add driver fhc +bus: 'platform': add driver clock_board +bus: 'platform': add driver auxio +clocksource: Switched to clocksource tick +device class 'mem': registering +device: 'null': device_add +device: 'zero': device_add +device: 'full': device_add +device: 'random': device_add +device: 'urandom': device_add +device: 'kmsg': device_add +device: 'tty': device_add +device: 'console': device_add +device: 'tty0': device_add +device class 'vc': registering +device: 'vcs': device_add +device: 'vcsu': device_add +device: 'vcsa': device_add +device: 'vcs1': device_add +device: 'vcsu1': device_add +device: 'vcsa1': device_add +device: 'tty1': device_add +device: 'tty2': device_add +device: 'tty3': device_add +device: 'tty4': device_add +device: 'tty5': device_add +device: 'tty6': device_add +device: 'tty7': device_add +device: 'tty8': device_add +device: 'tty9': device_add +device: 'tty10': device_add +device: 'tty11': device_add +device: 'tty12': device_add +device: 'tty13': device_add +device: 'tty14': device_add +device: 'tty15': device_add +device: 'tty16': device_add +device: 'tty17': device_add +device: 'tty18': device_add +device: 'tty19': device_add +device: 'tty20': device_add +device: 'tty21': device_add +device: 'tty22': device_add +device: 'tty23': device_add +device: 'tty24': device_add +device: 'tty25': device_add +device: 'tty26': device_add +device: 'tty27': device_add +device: 'tty28': device_add +device: 'tty29': device_add +device: 'tty30': device_add +device: 'tty31': device_add +device: 'tty32': device_add +device: 'tty33': device_add +device: 'tty34': device_add +device: 'tty35': device_add +device: 'tty36': device_add +device: 'tty37': device_add +device: 'tty38': device_add +device: 'tty39': device_add +device: 'tty40': device_add +device: 'tty41': device_add +device: 'tty42': device_add +device: 'tty43': device_add +device: 'tty44': device_add +device: 'tty45': device_add +device: 'tty46': device_add +device: 'tty47': device_add +device: 'tty48': device_add +device: 'tty49': device_add +device: 'tty50': device_add +device: 'tty51': device_add +device: 'tty52': device_add +device: 'tty53': device_add +device: 'tty54': device_add +device: 'tty55': device_add +device: 'tty56': device_add +device: 'tty57': device_add +device: 'tty58': device_add +device: 'tty59': device_add +device: 'tty60': device_add +device: 'tty61': device_add +device: 'tty62': device_add +device: 'tty63': device_add +device: 'hw_random': device_add +NET: Registered PF_INET protocol family +IP idents hash table entries: 32768 (order: 5, 262144 bytes, linear) +tcp_listen_portaddr_hash hash table entries: 1024 (order: 1, 16384 bytes, linear) +Table-perturb hash table entries: 65536 (order: 5, 262144 bytes, linear) +TCP established hash table entries: 16384 (order: 4, 131072 bytes, linear) +TCP bind hash table entries: 16384 (order: 6, 524288 bytes, linear) +TCP: Hash tables configured (established 16384 bind 16384) +UDP hash table entries: 1024 (order: 2, 32768 bytes, linear) +UDP-Lite hash table entries: 1024 (order: 2, 32768 bytes, linear) +NET: Registered PF_UNIX/PF_LOCAL protocol family +PCI: CLS 0 bytes, default 64 +bus: 'platform': add driver power +bus: 'platform': __driver_probe_device: matched device ffe30448 with driver power +bus: 'platform': really_probe: probing driver power with device ffe30448 +power: Control reg at 1fe02007240 +driver: 'power': driver_bound: bound to device 'ffe30448' +bus: 'platform': really_probe: bound device ffe30448 to driver power +device: 'mdesc': device_add +bus: 'clocksource': registered +device: 'clocksource': device_add +device: 'clocksource0': device_add +bus: 'clocksource': add device clocksource0 +bus: 'platform': add driver alarmtimer +bus: 'clockevents': registered +device: 'clockevents': device_add +device: 'clockevent0': device_add +bus: 'clockevents': add device clockevent0 +bus: 'event_source': registered +device: 'uprobe': device_add +bus: 'event_source': add device uprobe +device: 'kprobe': device_add +bus: 'event_source': add device kprobe +device: 'tracepoint': device_add +bus: 'event_source': add device tracepoint +device: 'software': device_add +bus: 'event_source': add device software +workingset: timestamp_bits=62 max_order=18 bucket_order=0 +9p: Installing v9fs 9p2000 file system support +device class 'bsg': registering +Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) +bus: 'platform': add driver simple-pm-bus +bus: 'pci_express': add driver pciehp +pciehp: pcie_port_service_register = 0 +bus: 'pci': add driver pcieport +bus: 'pci': __driver_probe_device: matched device 0000:00:01.1 with driver pcieport +bus: 'pci': really_probe: probing driver pcieport with device 0000:00:01.1 +pcieport 0000:00:01.1: runtime IRQ mapping not provided by arch +pcieport: probe of 0000:00:01.1 rejects match -19 +bus: 'pci': __driver_probe_device: matched device 0000:00:01.0 with driver pcieport +bus: 'pci': really_probe: probing driver pcieport with device 0000:00:01.0 +pcieport 0000:00:01.0: runtime IRQ mapping not provided by arch +pcieport: probe of 0000:00:01.0 rejects match -19 +bus: 'pci': __driver_probe_device: matched device 0000:02:01.0 with driver pcieport +bus: 'pci': really_probe: probing driver pcieport with device 0000:02:01.0 +pcieport 0000:02:01.0: runtime IRQ mapping not provided by arch +pcieport: probe of 0000:02:01.0 rejects match -19 +bus: 'pci': add driver shpchp +bus: 'pci': __driver_probe_device: matched device 0000:00:01.1 with driver shpchp +bus: 'pci': really_probe: probing driver shpchp with device 0000:00:01.1 +shpchp 0000:00:01.1: runtime IRQ mapping not provided by arch +shpchp: probe of 0000:00:01.1 rejects match -19 +bus: 'pci': __driver_probe_device: matched device 0000:00:01.0 with driver shpchp +bus: 'pci': really_probe: probing driver shpchp with device 0000:00:01.0 +shpchp 0000:00:01.0: runtime IRQ mapping not provided by arch +shpchp: probe of 0000:00:01.0 rejects match -19 +bus: 'pci': __driver_probe_device: matched device 0000:02:01.0 with driver shpchp +bus: 'pci': really_probe: probing driver shpchp with device 0000:02:01.0 +shpchp 0000:02:01.0: runtime IRQ mapping not provided by arch +shpchp 0000:02:01.0: HPC vendor_id 1b36 device_id 1 ss_vid 0 ss_did 0 +shpchp 0000:02:01.0: Can't get msi for the hotplug controller +shpchp 0000:02:01.0: Use INTx for the hotplug controller +Unable to handle kernel NULL pointer dereference +tsk->{mm,active_mm}->context = 0000000000000000 +tsk->{mm,active_mm}->pgd = fffff80000402000 + \|/ ____ \|/ + "@'/ .. \`@" + /_| \__/ |_\ + \__U_/ +swapper/0(1): Oops [#1] +CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-ktest-02812-g4d2faeb4fb58 #10 +TSTATE: 0000004411001601 TPC: 00000000007e5f98 TNPC: 00000000007e5fbc Y: 00000000 Not tainted +TPC: <shpc_init+0x638/0x900> +g0: fffff8000228ca18 g1: 0000000000000000 g2: 0000000000001f00 g3: 0000000000000000 +g4: fffff80002148000 g5: fffff8007e410000 g6: fffff800021a4000 g7: 0000000000000001 +o0: 0000000000000000 o1: 00000000007e4da0 o2: 0000000000000000 o3: 0000000000000000 +o4: 0000000000b9b950 o5: 0000000000000000 sp: fffff800021a6b01 ret_pc: 00000000007e607c +RPC: <shpc_init+0x71c/0x900> +l0: 00000000015ef800 l1: 00000000ff1f7fff l2: 0000000000b78440 l3: 0000000000b9c6b0 +l4: 000000000000001f l5: 000000007f000000 l6: fffff80002553280 l7: fffff800022f7680 +i0: fffff8000254ea00 i1: fffff800021f6000 i2: 00000000015ef800 i3: 0000000000000000 +i4: 0000000000b9b800 i5: 0000000000000000 i6: fffff800021a6bc1 i7: 00000000007e29f0 +I7: <shpc_probe+0x70/0x3a0> +Call Trace: +[<00000000007e29f0>] shpc_probe+0x70/0x3a0 +[<00000000007c5bf8>] pci_device_probe+0x78/0x100 +[<0000000000a6b70c>] really_probe+0x16c/0x41c +[<0000000000a6ba68>] __driver_probe_device.part.0+0xac/0xc0 +[<0000000000846b28>] driver_probe_device+0x88/0x120 +[<0000000000846d64>] __driver_attach+0x84/0x1c0 +[<0000000000844bb4>] bus_for_each_dev+0x54/0xc0 +[<000000000084659c>] driver_attach+0x1c/0x40 +[<0000000000845e24>] bus_add_driver+0xe4/0x1e0 +[<0000000000847cfc>] driver_register+0x7c/0x140 +[<00000000007c5028>] __pci_register_driver+0x48/0x60 +[<0000000001398e64>] shpcd_init+0x18/0x68 +[<0000000000427c90>] do_one_initcall+0x30/0x240 +[<000000000137eea4>] kernel_init_freeable+0x1d4/0x22c +[<0000000000a6d824>] kernel_init+0x1c/0x138 +[<00000000004060c8>] ret_from_fork+0x1c/0x2c +Disabling lock debugging due to kernel taint +Caller[00000000007e29f0]: shpc_probe+0x70/0x3a0 +Caller[00000000007c5bf8]: pci_device_probe+0x78/0x100 +Caller[0000000000a6b70c]: really_probe+0x16c/0x41c +Caller[0000000000a6ba68]: __driver_probe_device.part.0+0xac/0xc0 +Caller[0000000000846b28]: driver_probe_device+0x88/0x120 +Caller[0000000000846d64]: __driver_attach+0x84/0x1c0 +Caller[0000000000844bb4]: bus_for_each_dev+0x54/0xc0 +Caller[000000000084659c]: driver_attach+0x1c/0x40 +Caller[0000000000845e24]: bus_add_driver+0xe4/0x1e0 +Caller[0000000000847cfc]: driver_register+0x7c/0x140 +Caller[00000000007c5028]: __pci_register_driver+0x48/0x60 +Caller[0000000001398e64]: shpcd_init+0x18/0x68 +Caller[0000000000427c90]: do_one_initcall+0x30/0x240 +Caller[000000000137eea4]: kernel_init_freeable+0x1d4/0x22c +Caller[0000000000a6d824]: kernel_init+0x1c/0x138 +Caller[00000000004060c8]: ret_from_fork+0x1c/0x2c +Caller[0000000000000000]: 0x0 +Instruction DUMP: + c20c2219 + 80a06000 + 0240000a +<d628e0da> + d25e2048 + 15002e71 + 11002de1 + 960ae0ff + 9412a3a0 + +Kernel panic - not syncing: Fatal exception +Press Stop-A (L1-A) from sun keyboard or send break +twice on console to return to the boot prom +---[ end Kernel panic - not syncing: Fatal exception ]--- +qemu-system-sparc64: terminating on signal 2 + +``` +Steps to reproduce: +1. compile a sparc64 kernel (config file included) +2. add a config where a pci-bridge is installed in slot 1,2 or 3 (virtio-slot-pci takes the first slot) +3. create a empty file using fallocate +Additional information: +attached: tar.xz file: +- linux arch/sparc64/boot/image (uncompressed) as vmlinuz +- linux .config file as config +- linux modules in the lib directory + +[sparckernelinfo.tar.xz](/uploads/55f1475c5c811cd56d1374386e8f9e6e/sparckernelinfo.tar.xz) diff --git a/results/classifier/zero-shot/108/all/1971 b/results/classifier/zero-shot/108/all/1971 new file mode 100644 index 000000000..a1358a76c --- /dev/null +++ b/results/classifier/zero-shot/108/all/1971 @@ -0,0 +1,163 @@ +graphic: 0.988 +permissions: 0.982 +performance: 0.976 +semantic: 0.976 +other: 0.976 +vnc: 0.969 +debug: 0.967 +device: 0.965 +PID: 0.964 +KVM: 0.959 +files: 0.944 +socket: 0.942 +network: 0.927 +boot: 0.923 + +Cannot build QEMU on MSYS2 on Windows 10 22H2 +Description of problem: +I have followed build instructions on Wiki, section Native builds with MSYS2. MSYS2 and other tools are installed without any errors. But when run `./configure --enable-sdl --enable-gtk`, I have this error that I have never seen before: + +``` +# ./configure --enable-sdl --enable-gtk +Using './build' as the directory for build output +ln: failed to create symbolic link 'aarch64-softmmu/qemu-system-aarch64.exe': No such file or directory +ln: failed to create symbolic link 'alpha-softmmu/qemu-system-alpha.exe': No such file or directory +ln: failed to create symbolic link 'arm-softmmu/qemu-system-arm.exe': No such file or directory +ln: failed to create symbolic link 'avr-softmmu/qemu-system-avr.exe': No such file or directory +ln: failed to create symbolic link 'cris-softmmu/qemu-system-cris.exe': No such file or directory +ln: failed to create symbolic link 'hppa-softmmu/qemu-system-hppa.exe': No such file or directory +ln: failed to create symbolic link 'i386-softmmu/qemu-system-i386.exe': No such file or directory +ln: failed to create symbolic link 'loongarch64-softmmu/qemu-system-loongarch64.exe': No such file or directory +ln: failed to create symbolic link 'm68k-softmmu/qemu-system-m68k.exe': No such file or directory +ln: failed to create symbolic link 'microblaze-softmmu/qemu-system-microblaze.exe': No such file or directory +ln: failed to create symbolic link 'microblazeel-softmmu/qemu-system-microblazeel.exe': No such file or directory +ln: failed to create symbolic link 'mips-softmmu/qemu-system-mips.exe': No such file or directory +ln: failed to create symbolic link 'mips64-softmmu/qemu-system-mips64.exe': No such file or directory +ln: failed to create symbolic link 'mips64el-softmmu/qemu-system-mips64el.exe': No such file or directory +ln: failed to create symbolic link 'mipsel-softmmu/qemu-system-mipsel.exe': No such file or directory +ln: failed to create symbolic link 'nios2-softmmu/qemu-system-nios2.exe': No such file or directory +ln: failed to create symbolic link 'or1k-softmmu/qemu-system-or1k.exe': No such file or directory +ln: failed to create symbolic link 'ppc-softmmu/qemu-system-ppc.exe': No such file or directory +ln: failed to create symbolic link 'ppc64-softmmu/qemu-system-ppc64.exe': No such file or directory +ln: failed to create symbolic link 'riscv32-softmmu/qemu-system-riscv32.exe': No such file or directory +ln: failed to create symbolic link 'riscv64-softmmu/qemu-system-riscv64.exe': No such file or directory +ln: failed to create symbolic link 'rx-softmmu/qemu-system-rx.exe': No such file or directory +ln: failed to create symbolic link 's390x-softmmu/qemu-system-s390x.exe': No such file or directory +ln: failed to create symbolic link 'sh4-softmmu/qemu-system-sh4.exe': No such file or directory +ln: failed to create symbolic link 'sh4eb-softmmu/qemu-system-sh4eb.exe': No such file or directory +ln: failed to create symbolic link 'sparc-softmmu/qemu-system-sparc.exe': No such file or directory +ln: failed to create symbolic link 'sparc64-softmmu/qemu-system-sparc64.exe': No such file or directory +ln: failed to create symbolic link 'tricore-softmmu/qemu-system-tricore.exe': No such file or directory +ln: failed to create symbolic link 'x86_64-softmmu/qemu-system-x86_64.exe': No such file or directory +ln: failed to create symbolic link 'xtensa-softmmu/qemu-system-xtensa.exe': No such file or directory +ln: failed to create symbolic link 'xtensaeb-softmmu/qemu-system-xtensaeb.exe': No such file or directory +The Meson build system +Version: 1.2.3 +Source dir: C:/msys64/home/DuyThanh/qemu-ios +Build dir: C:/msys64/home/DuyThanh/qemu-ios/build +Build type: native build +Project name: qemu +Project version: 7.2.50 +C compiler for the host machine: cc -m64 -mcx16 (gcc 13.2.0 "cc (Rev2, Built by MSYS2 project) 13.2.0") +C linker for the host machine: cc -m64 -mcx16 ld.bfd 2.41 +Host machine cpu family: x86_64 +Host machine cpu: x86_64 +Program scripts/symlink-install-tree.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/DuyThanh/qemu-ios/scripts/symlink-install-tree.py) +Program sh found: YES (C:\msys64\usr\bin/sh.EXE) +Program python3 found: YES (C:/msys64/mingw64/bin/python.exe) +Program bzip2 found: YES (C:\msys64\mingw64\bin/bzip2.EXE) +Program iasl found: NO +Compiler for C supports link arguments -Wl,-z,relro: NO +Compiler for C supports link arguments -Wl,-z,now: NO +Compiler for C supports link arguments -Wl,--no-seh: YES +Compiler for C supports link arguments -Wl,--nxcompat: YES +C++ compiler for the host machine: c++ -m64 -mcx16 (gcc 13.2.0 "c++ (Rev2, Built by MSYS2 project) 13.2.0") +C++ linker for the host machine: c++ -m64 -mcx16 ld.bfd 2.41 +Compiler for C++ supports link arguments -Wl,--warn-common: YES +Program cgcc found: NO +Library m found: YES +Run-time dependency threads found: YES +Traceback (most recent call last): + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/mesonmain.py", line 194, in run + return options.run_func(options) + ^^^^^^^^^^^^^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/msetup.py", line 358, in run + app.generate() + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/msetup.py", line 183, in generate + return self._generate(env, capture, vslite_ctx) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/msetup.py", line 228, in _generate + intr.run() + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreter/interpreter.py", line 3002, in run + super().run() + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 164, in run + self.evaluate_codeblock(self.ast, start=1) + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 190, in evaluate_codeblock + raise e + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 182, in evaluate_codeblock + self.evaluate_statement(cur) + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 198, in evaluate_statement + self.assignment(cur) + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 635, in assignment + value = self.evaluate_statement(node.value) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 200, in evaluate_statement + return self.method_call(cur) + ^^^^^^^^^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 550, in method_call + res = obj.method_call(method_name, args, kwargs) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/baseobjects.py", line 94, in method_call + return method(args, kwargs) + ^^^^^^^^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/decorators.py", line 109, in wrapped + ret = f(*wrapped_args, **wrapped_kwargs) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/decorators.py", line 277, in wrapper + return f(*nargs, **wrapped_kwargs) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreterbase/decorators.py", line 596, in wrapper + return f(*wrapped_args, **wrapped_kwargs) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/interpreter/compiler.py", line 635, in find_library_method + linkargs = self.compiler.find_library(libname, self.environment, search_dirs, libtype) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/compilers/mixins/clike.py", line 1191, in find_library + return self._find_library_impl(libname, env, extra_dirs, code, libtype, lib_prefix_warning) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/compilers/mixins/clike.py", line 1180, in _find_library_impl + value = self._find_library_real(libname, env, extra_dirs, code, libtype, lib_prefix_warning) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/compilers/mixins/clike.py", line 1158, in _find_library_real + for d in itertools.chain(extra_dirs, self.get_library_dirs(env, elf_class)): + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/compilers/mixins/clike.py", line 261, in get_library_dirs + return self._get_library_dirs(env, elf_class).copy() + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/compilers/mixins/clike.py", line 220, in _get_library_dirs + dirs = self.get_compiler_dirs(env, 'libraries') + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/compilers/mixins/gnu.py", line 515, in get_compiler_dirs + return self._split_fetch_real_dirs(line.split('=', 1)[1]) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/site-packages/mesonbuild/compilers/mixins/gnu.py", line 497, in _split_fetch_real_dirs + if pobj.exists(): + ^^^^^^^^^^^^^ + File "C:/msys64/mingw64/lib/python3.11/pathlib.py", line 1237, in exists + self.stat() + File "C:/msys64/mingw64/lib/python3.11/pathlib.py", line 1015, in stat + return os.stat(self, follow_symlinks=follow_symlinks) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +OSError: [WinError 1005] The volume does not contain a recognized file system. +Please make sure that all required file system drivers are loaded and that the volume is not corrupted: 'D:/a/msys64/mingw64/lib/x86_64-w64-mingw32/13.2.0' + +ERROR: Unhandled python OSError. This is probably not a Meson bug, but an issue with your build environment. + +ERROR: meson setup failed +``` +Steps to reproduce: +1. Install MSYS2 and follow the wiki page +2. Git clone +3. Run configure then error +Additional information: +No diff --git a/results/classifier/zero-shot/108/all/1994002 b/results/classifier/zero-shot/108/all/1994002 new file mode 100644 index 000000000..a99906e46 --- /dev/null +++ b/results/classifier/zero-shot/108/all/1994002 @@ -0,0 +1,1841 @@ +graphic: 0.973 +device: 0.970 +other: 0.970 +performance: 0.965 +vnc: 0.964 +permissions: 0.962 +files: 0.961 +debug: 0.959 +KVM: 0.958 +semantic: 0.954 +socket: 0.949 +PID: 0.944 +network: 0.931 +boot: 0.905 + +[SRU] migration was active, but no RAM info was set + +While live-migrating many instances concurrently, libvirt sometimes return internal error: migration was active, but no RAM info was set: +~~~ +2022-03-30 06:08:37.197 7 WARNING nova.virt.libvirt.driver [req-5c3296cf-88ee-4af6-ae6a-ddba99935e23 - - - - -] [instance: af339c99-1182-4489-b15c-21e52f50f724] Error monitoring migration: internal error: migration was active, but no RAM info was set: libvirt.libvirtError: internal error: migration was active, but no RAM info was set +~~~ + +From upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2074205 + +[Impact] + + * Effects of this bug are mostly observed in large scale clusters with a lot of live migration activity. + * Has second order effects for consumers of migration monitor such as libvirt and openstack. + +[Test Case] +Steps to Reproduce: +1. live evacuate a compute +2. live migration of one or more instances fails with the above error + +N.B Due to the nature of this bug it is difficult consistently reproduce. + +[Where problems could occur] + * In the event of a regression the migration monitor may report an inconsistent state. + + + +The attachment "lp1994002-qemu-ussuri.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. + +[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] + +If you need something from upstream QEMU, please use the new bug tracker here: https://gitlab.com/qemu-project/qemu/-/issues + + + + + + + +Hi Brett, + +Thanks for the debdiffs! + +I just reviewed them, and there are changes that should be made. + +I could do those myself, but that wouldn't be an opportunity to +learn/practice some details for SRUs for you, so I'll add notes. + +*However*, if you're too busy and can't do that, do let me know. + +cheers, +Mauricio + +... + +qemu.git + +$ git describe --contains 552de79bfdd5e9e53847eb3c6d6e4cd898a4370e +v7.1.0-rc0~136^2 + +ubuntu archive: + +$ rmadison -a source qemu +... + qemu | 1:2.11+dfsg-1ubuntu7 | bionic | source + qemu | 1:2.11+dfsg-1ubuntu7.40 | bionic-security | source + qemu | 1:2.11+dfsg-1ubuntu7.40 | bionic-updates | source + qemu | 1:4.2-3ubuntu6 | focal | source + qemu | 1:4.2-3ubuntu6.23 | focal-security | source + qemu | 1:4.2-3ubuntu6.23 | focal-updates | source + qemu | 1:6.2+dfsg-2ubuntu6 | jammy | source + qemu | 1:6.2+dfsg-2ubuntu6.2 | jammy-security | source + qemu | 1:6.2+dfsg-2ubuntu6.5 | jammy-updates | source + qemu | 1:7.0+dfsg-7ubuntu2 | kinetic | source + qemu | 1:7.0+dfsg-7ubuntu2 | lunar | source + +0) Development release + +The development release (lunar) still doesn't have the patch. +That is required for SRU / stable releases. + +We'll need a debdiff for lunar, slightly different than kinetic +(release name and greater version string for the upgrade path). + +I just checked w/ Christian and we shouldn't wait on qemu 7.1 +merge from Debian (sid), which would include the patch, since +the merge from Debian should happen in January to get qemu 7.2. + + +1) Oldest LTS in standard support + +Would Bionic benefit from this fix on the long run as well, +just before it goes into expanded/out of standard- support? + +Apparently, some deployments/clouds still use Bionic on kvm +compute nodes. + +If so, the backport targets qmp_query_migrate()/same file, +per commit 65ace0604551 ("migration: add postcopy total blocktime into query-migrate"). + + +2) Debdiffs: + +- version strings: the 'lp*' version suffix is fine for +test builds, but for official packages usually (see [1]): +just increment '.1' on stable releases, and '1' on dev. + +example: +kinetic (sru): 1:7.0+dfsg-7ubuntu2 -> ubuntu2.1 +luanr (devel): 1:7.0+dfsg-7ubuntu2 -> ubuntu3 + +- changelog: mostly good! (d/p/file.patch; LP: #number?; releases). + +The LP bug number 1982284 refers to another/openstack bug, +but the Ubuntu SRUs are coming through this bug, apparently. + +Since this is the bug where Ubuntu Archive/Cloud Archive +have packages/series on, to be closed when SRUs land in +-proposed and -updates (and UCA), we should change: +1) the LP bug number in the changelog +2) and patch file names +3) also, it's a good idea to link to other LP bug +in the SRU template '[Other Info]' section. + +(you could also just move the SRU template/packages/ +series/tracks to the other LP bug, I guess. Up to you.) + +- quilt patch: add DEP3 headers [2] (Origin:/Bug-Ubuntu:) + +- quilt series: missing 'ubuntu/' dir on k/j (not on f) + +- duplications: jammy has duplicated messages, and focal +has that plus duplicated changelog entries? -- for HA? x) + +[1] https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging +[2] https://dep-team.pages.debian.net/deps/dep3/ + +Brett, per our email conversation, please ignore this: +> - quilt series: missing 'ubuntu/' dir on k/j (not on f) + +I missed that focal uses `d/p/ubuntu/` too (it just wasn't present in `d/p/series` context lines in the debdiff, for CVEs). +Sorry for the confusion, and thanks for checking! + + +Hi Mauricio, + +Thanks for your review. +I've made the changes you've requested. +Looking forward to your feedback. + + + + + + + + + + +Thanks, Brett! + +Very minor nitpicks left (changelog entry/release for lunar, +and URL for Origin:), I can handle those. + +For Lunar/devel release, I'll send a MR for Christian to +review/upload (my upload rights are for stable releases). + +This includes a fix to FTBFS per a package change in the +last 24 hours :) happy to catch it now! + +It's currently (re)build-testing on all supported archs. +If all goes well now, I'll send the MR for Lunar, and +once it lands, we'll proceed w/ SRUs. + +... + +I also played with GDB for a synthetic reproducer. +It seems to be possible, but needs a little more study +on the monitor path. We can sync on that later! + + +All archs finished building successfully on ppa:mfo/lp1994002v2. + +Just sent the MR for Lunar. If/once it lands, I can do the SRUs. + +https://code.launchpad.net/~mfo/ubuntu/+source/qemu/+git/qemu/+merge/434118 + +For documentation purposes, + +The qemu package in lunar-proposed has its migration blocked to lunar(-release) +because of autopkgtests failures (sbuild), which have been analyzed/understood. + +We're waiting on the autopkgtests queue to run sbuild w/ triggers on qemu _and_ +sbuild from lunar-proposed, which should address the error w/ sbuild/unshare +(lack of adduser command in the sbuild chroot, as apt no longer deps on that). + +Once that runs, we'll check if any other errors happen, and address those. + +cheers, +Mauricio + +The sbuild autopkgtest failure on the 'unshare' test +is indeed fixed w/ sbuild in lunar-proposed; however, +now the test 'unshare-qemuwrapper' timed out. + +autopkgtest [23:36:43]: @@@@@@@@@@@@@@@@@@@@ summary +build-procenv PASS +unshare-qemuwrapper FAIL timed out +unshare PASS + +It timed out on the 'guestfish' command, so I enabled +`export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1` there, +and run autopkgtests against its build in a PPA [1]. + +Then it finished successfully w/out timing out! x) + +autopkgtest [16:17:39]: @@@@@@@@@@@@@@@@@@@@ summary +build-procenv PASS +unshare-qemuwrapper PASS +unshare PASS + +Not a very useful result, but it did show that an +step in guestfish took ~25 minutes; 30 mins total: + +autopkgtest [15:22:52]: test unshare-qemuwrapper: [----------------------- +... ++ export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 ++ guestfish <...> +... +libguestfs: trace: tar_in "/tmp/.../ubuntu-lunar-host.tar" "/" +... +tar -C /sysroot/ -xf - 2> /tmp/tarSfYHJX +... +guestfsd: => tar_in (0x45) took 1489.08 secs +... +autopkgtest [15:52:27]: test unshare-qemuwrapper: -----------------------] +unshare-qemuwrapper PASS + +So, well, it might have been due to load in the +autopkgtest infrastructure at the time tests ran, +so just triggered retries on sbuild and sbuild+qemu. + +Hopefully they will pass and unblock proposed migration +for both sbuild & qemu. + +[1] https://autopkgtest.ubuntu.com/results/autopkgtest-lunar-mfo-build/lunar/amd64/s/sbuild/20221215_161801_a2772@/log.gz + + + +The sbuild autopkgtests need a fix for lunar-proposed; +reported bug 2000015 w/ analysis and debdiff attached. + +This bug was fixed in the package qemu - 1:7.0+dfsg-7ubuntu3 + +--------------- +qemu (1:7.0+dfsg-7ubuntu3) lunar; urgency=medium + + [ Brett Milford ] + * d/p/u/lp1994002-migration-Read-state-once.patch: Fix for libvirt + error 'migration was active, but no RAM info was set' (LP: #1994002) + + [ Mauricio Faria de Oliveira ] + * d/p/u/ebpf-replace-deprecated-bpf_program__set_socket_filt.patch: + Fix FTBFS with libbpf 1.0.1-2. + + -- Mauricio Faria de Oliveira <email address hidden> Wed, 30 Nov 2022 12:17:51 -0300 + +These are the steps for a synthetic reproducer with GDB and QEMU. + +It's sufficient to validate the change on QEMU and move forward with SRUs. +(We can add libvirt for reaching the error message too, but it's a plus.) + +I'll check/coordinate on the QEMU uploads next week. + +cheers, +Mauricio + +... + + +Original code. + +The race condition is, one thread can read 's->state' as SETUP (line 1078/1083/1086), +and another thread changes it to ACTIVE _before_ this thread assigns (the different) +'s->state' to 'info->status' (line 1123), which will NOT have RAM info expected for +the ACTIVE status (line 1087/1096). + + 1056 static void fill_source_migration_info(MigrationInfo *info) + 1057 { + 1058 MigrationState *s = migrate_get_current(); + ... + 1078 switch (s->state) { + ... + 1083 case MIGRATION_STATUS_SETUP: + ... + 1086 break; + 1087 case MIGRATION_STATUS_ACTIVE: + ... + 1096 populate_ram_info(info, s); + ... + 1123 info->status = s->state; + 1124 } + +We'll break on this function that changes migration states. + + void migrate_set_state(int *state, int old_state, int new_state) + + +Terminal 1) + +QEMU process for incoming migration (ie, destination) + +qemu-system-x86_64 -nodefaults -nographic -S -incoming tcp:0:4444 + +Terminal 2) + +QEMU process for outgoing migration (ie, source) +with QEMU monitor on port 3333, +with GDB in non-stop threads mode +(and debuginfod for debug symbols), + + +gdb \ + -ex 'set non-stop on' -ex 'set pagination off' -ex 'set confirm off' \ + -iex 'set debuginfod enabled on' -iex 'set debuginfod urls "https://debuginfod.ubuntu.com"' \ + qemu-system-x86_64 + +Set breakpoints on the functions above +(and line number of the 'break' statement under 'case MIGRATION_STATUS_SETUP'): + +b migrate_set_state +b migration/migration.c:1086 + +run -nodefaults -nographic -S -monitor tcp:0:3333,server,wait=off +... + +Terminal 3) + +Connect to QEMU monitor with netcat, +and start the the migration: + +nc 127.0.0.1 3333 +... +(qemu) migrate -d tcp:127.0.0.1:4444 + + +Terminal 2) + +GDB breaks on change from migration status NONE to SETUP. + +Thread 1 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x5555566f8628, old_state=0, new_state=1) at ../../migration/migration.c:1746 + +(gdb) p (MigrationStatus) 0 +$1 = MIGRATION_STATUS_NONE + +(gdb) p (MigrationStatus) 1 +$2 = MIGRATION_STATUS_SETUP + +Just continue. + +(gdb) c + +GDB breaks on change from migration status SETUP to ACTIVE. + +Thread 5 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x5555566f8628, old_state=1, new_state=4) at ../../migration/migration.c:1746 + +(gdb) p (MigrationStatus) 1 +$2 = MIGRATION_STATUS_SETUP + +(gdb) p (MigrationStatus) 4 +$3 = MIGRATION_STATUS_ACTIVE + +Let's explore the race condition. + + +Terminal 2) + +Check the migration information: + +(qemu) info migrate + + +Terminal 3) + +GDB breaks on the migration information function. + +The status is now observed as SETUP (not yet ACTIVE), +and is not yet propagated to the migration information +to be returned to the monitor. + +Thread 1 "qemu-system-x86" hit Breakpoint 2, fill_source_migration_info (info=0x555556d65c70) at ../../migration/migration.c:1086 + +(gdb) p (MigrationStatus) s.state +$4 = MIGRATION_STATUS_SETUP + +(gdb) p info.status +$5 = MIGRATION_STATUS_NONE + + +Now, allow the other thread to continue and change status to ACTIVE. + +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x7ffff6c21e80 (LWP 995) "qemu-system-x86" fill_source_migration_info (info=0x555556d65c70) at ../../migration/migration.c:1123 + 2 Thread 0x7ffff65ff640 (LWP 998) "qemu-system-x86" (running) + 3 Thread 0x7ffff5d7c640 (LWP 999) "qemu-system-x86" (running) + 5 Thread 0x7ffff49ff640 (LWP 1002) "qemu-system-x86" migrate_set_state (state=0x5555566f8628, old_state=1, new_state=4) at ../../migration/migration.c:1746 + +(gdb) thread 5 +[Switching to thread 5 (Thread 0x7ffff49ff640 (LWP 1002))] +#0 migrate_set_state (state=0x5555566f8628, old_state=1, new_state=4) at ../../migration/migration.c:1746 +1746 in ../../migration/migration.c + +(gdb) continue & +Continuing. + +The first thread now observes the ACTIVE status. + +(gdb) info threads + Id Target Id Frame + 1 Thread 0x7ffff6c21e80 (LWP 995) "qemu-system-x86" fill_source_migration_info (info=0x555556d65c70) at ../../migration/migration.c:1123 + 2 Thread 0x7ffff65ff640 (LWP 998) "qemu-system-x86" (running) + 3 Thread 0x7ffff5d7c640 (LWP 999) "qemu-system-x86" (running) +* 5 Thread 0x7ffff49ff640 (LWP 1002) "qemu-system-x86" (running) +(gdb) + +(gdb) thread 1 +[Switching to thread 1 (Thread 0x7ffff6c21e80 (LWP 995))] +#0 fill_source_migration_info (info=0x555556d65c70) at ../../migration/migration.c:1123 +1123 in ../../migration/migration.c + +(gdb) p (MigrationStatus) s.state +$7 = MIGRATION_STATUS_ACTIVE + + +Done, the next statement in the code assigns the ACTIVE +status to the migration information, but it did NOT add +any RAM statistics (as it executed for the SETUP status). + +Just continue, and check the resulting migration info: + +(gdb) c + + +Terminal 2) +... info migrate +... +Migration status: active +total time: 0 ms +(qemu) + +Migration status is active, without any RAM statistics. + + +... +... +... + +Note that, normally, without exploring the race condition, +the status is 'active' and there _is_ memory statistics: + +[just a summary from gdb/monitor steps] + +... +(qemu) migrate -d tcp:127.0.0.1:4444 + +... +Thread 1 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x5555566f8628, old_state=0, new_state=1) at ../../migration/migration.c:1746 +(gdb) c +Thread 5 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x5555566f8628, old_state=1, new_state=4) at ../../migration/migration.c:1746 +(gdb) thread 5 +(gdb) c +Thread 5 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x5555566f8628, old_state=4, new_state=8) at ../../migration/migration.c:1746 + +(qemu) info migrate +... +Migration status: active +total time: 41387 ms +expected downtime: 300 ms +setup: 22590 ms +transferred ram: 485 kbytes +throughput: 0.18 mbps +remaining ram: 0 kbytes +total ram: 131592 kbytes +duplicate: 32849 pages +skipped: 0 pages +normal: 49 pages +normal bytes: 196 kbytes +dirty sync count: 3 +page size: 4 kbytes +multifd bytes: 0 kbytes +pages-per-second: 1453 +(qemu) + +(gdb) c +... + + +Uploaded to k/j/f/b. + +Hello Brett, or anyone else affected, + +Accepted qemu into kinetic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:7.0+dfsg-7ubuntu2.2 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-kinetic to verification-done-kinetic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-kinetic. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +All autopkgtests for the newly accepted qemu (1:7.0+dfsg-7ubuntu2.2) for kinetic have finished running. +The following regressions have been reported in tests triggered by the package: + +sbuild/0.83.1ubuntu1 (amd64) +ubuntu-image/2.2+22.04ubuntu3 (ppc64el) +dropbear/2022.82-4 (armhf) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/kinetic/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +Autopkgtests regressions cleared for kinetic. + +Verification done on kinetic-proposed. + +The migration status during the race condition is +not 'active' (which is expected to have RAM info, but didn't) +but 'setup' (which is not, thus no issues). + +(qemu) info migrate + +-updates: +... +Migration status: active +total time: 0 ms + +-proposed: +... +Migration status: setup +total time: 0 ms + +Detailed steps: +============== + +$ lxc launch ubuntu:kinetic qemu-k +$ lxc exec qemu-k -- su - ubuntu + + +Packages from -updates: FAIL +---------------------- + +$ sudo apt install --yes --no-install-recommends qemu-system-x86 gdb dpkg-dev + +$ dpkg -s qemu-system-x86 | grep Version: +Version: 1:7.0+dfsg-7ubuntu2.1 + +... + +Source: get line number for breakpoint. + +$ sudo add-apt-repository -ys +$ apt source qemu + +$ head -n1 qemu-*/debian/changelog +qemu (1:7.0+dfsg-7ubuntu2.1) kinetic-security; urgency=medium + +$ vim qemu-*/migration/migration.c + +1073 static void fill_source_migration_info(MigrationInfo *info) +1074 { +... +1100 case MIGRATION_STATUS_SETUP: +... +1103 break; +... + +... + +Terminal 1) + +$ qemu-system-x86_64 -nodefaults -nographic -S -incoming tcp:0:4444 + +Terminal 2) + +gdb \ + -ex 'set non-stop on' -ex 'set pagination off' -ex 'set confirm off' \ + -iex 'set debuginfod enabled on' -iex 'set debuginfod urls https://debuginfod.ubuntu.com' \ + qemu-system-x86_64 + +(gdb) b migrate_set_state +... +Breakpoint 1 at 0x47ed10: migrate_set_state. (2 locations) +(gdb) b migration/migration.c:1103 +... +Breakpoint 2 at 0x47dba0: file ../../migration/migration.c, line 1103. + +(gdb) run -nodefaults -nographic -S -monitor tcp:0:3333,server,wait=off + + +Terminal 3) + +nc 127.0.0.1 3333 + +(qemu) migrate -d tcp:127.0.0.1:4444 + +Terminal 2) + +Thread 1 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x555556779618, old_state=0, new_state=1) at ../../migration/migration.c:1763 + +(gdb) p (MigrationStatus) 0 +$1 = MIGRATION_STATUS_NONE +(gdb) p (MigrationStatus) 1 +$2 = MIGRATION_STATUS_SETUP +(gdb) c + +Thread 5 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x555556779618, old_state=1, new_state=4) at ../../migration/migration.c:1763 + +(gdb) p (MigrationStatus) 1 +$3 = MIGRATION_STATUS_SETUP +(gdb) p (MigrationStatus) 4 +$4 = MIGRATION_STATUS_ACTIVE + +Terminal 3) + +(qemu) info migrate + +Terminal 2) + +Thread 1 "qemu-system-x86" hit Breakpoint 2, fill_source_migration_info (info=0x555556dc6c60) at ../../migration/migration.c:1103 + +(gdb) p (MigrationStatus) s.state +$6 = MIGRATION_STATUS_SETUP +(gdb) p info.status +$7 = MIGRATION_STATUS_NONE + +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x7ffff6c32340 (LWP 2368) "qemu-system-x86" fill_source_migration_info (info=0x555556dc6c60) at ../../migration/migration.c:1103 + 2 Thread 0x7ffff65ff6c0 (LWP 2369) "qemu-system-x86" (running) + 3 Thread 0x7ffff5d7c6c0 (LWP 2370) "qemu-system-x86" (running) + 5 Thread 0x7ffff49ff6c0 (LWP 2373) "qemu-system-x86" migrate_set_state (state=0x555556779618, old_state=1, new_state=4) at ../../migration/migration.c:1763 + +(gdb) thread 5 +(gdb) continue & + +(gdb) info threads + Id Target Id Frame + 1 Thread 0x7ffff6c32340 (LWP 2368) "qemu-system-x86" fill_source_migration_info (info=0x555556dc6c60) at ../../migration/migration.c:1103 + 2 Thread 0x7ffff65ff6c0 (LWP 2369) "qemu-system-x86" (running) + 3 Thread 0x7ffff5d7c6c0 (LWP 2370) "qemu-system-x86" (running) +* 5 Thread 0x7ffff49ff6c0 (LWP 2373) "qemu-system-x86" (running) + +(gdb) thread 1 + +(gdb) p (MigrationStatus) s.state +$8 = MIGRATION_STATUS_ACTIVE +(gdb) c + +Terminal 3) + +... +Migration status: active +total time: 0 ms +(qemu) + +Migration status is active, without any RAM statistics. + +(qemu) quit +(gdb) quit + +Terminal 1) + +Ctrl-C + +... + + +Packages from -proposed: PASS +----------------------- + +$ sudo add-apt-repository -yp proposed +$ sudo add-apt-repository -ys # didn't work for proposed +$ echo 'deb-src http://archive.ubuntu.com/ubuntu kinetic-proposed main' | sudo tee -a /etc/apt/sources.list + +$ sudo apt install --yes --no-install-recommends qemu-system-x86 + +$ dpkg -s qemu-system-x86 | grep Version: +Version: 1:7.0+dfsg-7ubuntu2.2 + +$ rm -rf qemu-* +a$ apt source qemu + +$ head -n1 qemu-*/debian/changelog +qemu (1:7.0+dfsg-7ubuntu2.2) kinetic; urgency=medium + +$ vim qemu-*/migration/migration.c + +1073 static void fill_source_migration_info(MigrationInfo *info) +1074 { +... +1076 int state = qatomic_read(&s->state); +... +1101 case MIGRATION_STATUS_SETUP: +... +1104 break; + + +Terminal 1) + +$ qemu-system-x86_64 -nodefaults -nographic -S -incoming tcp:0:4444 + +Terminal 2) + +$ gdb -ex 'set non-stop on' -ex 'set pagination off' -ex 'set confirm off' -iex 'set debuginfod enabled on' -iex 'set debuginfod urls https://debuginfod.ubuntu.com' qemu-system-x86_64 + +(gdb) b migrate_set_state +... +Breakpoint 1 at 0x47ed20: migrate_set_state. (2 locations) +(gdb) b migration/migration.c:1104 +... +Breakpoint 2 at 0x47dbc3: file ../../migration/migration.c, line 1104. + +Terminal 3) + +$ nc 127.0.0.1 3333 +(qemu) migrate -d tcp:127.0.0.1:4444 + +Terminal 2) + +Thread 1 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x555556779618, old_state=0, new_state=1) at ../../migration/migration.c:1764 + +(gdb) p (MigrationStatus) 0 +$1 = MIGRATION_STATUS_NONE +(gdb) p (MigrationStatus) 1 +$2 = MIGRATION_STATUS_SETUP +(gdb) c + +Thread 5 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x555556779618, old_state=1, new_state=4) at ../../migration/migration.c:1764 +1764 in ../../migration/migration.c +(gdb) p (MigrationStatus) 1 +$3 = MIGRATION_STATUS_SETUP +(gdb) p (MigrationStatus) 4 +$4 = MIGRATION_STATUS_ACTIVE + +(qemu) info migrate + +Terminal 2) + +Thread 1 "qemu-system-x86" hit Breakpoint 2, fill_source_migration_info (info=0x555556dc6c60) at ../../migration/migration.c:1141 + +(gdb) p (MigrationStatus) s.state +$6 = MIGRATION_STATUS_SETUP +(gdb) p info.status +$7 = MIGRATION_STATUS_NONE + +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x7ffff6c32340 (LWP 7562) "qemu-system-x86" fill_source_migration_info (info=0x555556dc6c60) at ../../migration/migration.c:1141 + 2 Thread 0x7ffff65ff6c0 (LWP 7565) "qemu-system-x86" (running) + 3 Thread 0x7ffff5d7c6c0 (LWP 7566) "qemu-system-x86" (running) + 5 Thread 0x7fffa7dff6c0 (LWP 7569) "qemu-system-x86" migrate_set_state (state=0x555556779618, old_state=1, new_state=4) at ../../migration/migration.c:1764 + +(gdb) thread 5 +(gdb) continue & + +(gdb) info threads + Id Target Id Frame + 1 Thread 0x7ffff6c32340 (LWP 7562) "qemu-system-x86" fill_source_migration_info (info=0x555556dc6c60) at ../../migration/migration.c:1141 + 2 Thread 0x7ffff65ff6c0 (LWP 7565) "qemu-system-x86" (running) + 3 Thread 0x7ffff5d7c6c0 (LWP 7566) "qemu-system-x86" (running) +* 5 Thread 0x7fffa7dff6c0 (LWP 7569) "qemu-system-x86" (running) + +(gdb) thread 1 +(gdb) p (MigrationStatus) s.state +$8 = MIGRATION_STATUS_ACTIVE + +(gdb) c + +Terminal 3) + +Status is now still 'SETUP' (which is not expected to have RAM statistics), not 'ACTIVE' (which is, and caused the issue). + +... +Migration status: setup +total time: 0 ms + + +This bug was fixed in the package qemu - 1:7.0+dfsg-7ubuntu2.2 + +--------------- +qemu (1:7.0+dfsg-7ubuntu2.2) kinetic; urgency=medium + + [ Brett Milford ] + * d/p/u/lp1994002-migration-Read-state-once.patch: Fix for libvirt + error 'migration was active, but no RAM info was set' (LP: #1994002) + + [ Mauricio Faria de Oliveira ] + * d/p/u/lp2009048-vfio_map_dma_einval_amd_iommu_1tb.patch: Add hint + to VFIO_MAP_DMA error on AMD IOMMU for VMs with ~1TB+ RAM (LP: #2009048) + + -- Mauricio Faria de Oliveira <email address hidden> Thu, 02 Mar 2023 17:29:05 -0300 + +The verification of the Stable Release Update for qemu has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + +Hello Brett, or anyone else affected, + +Accepted qemu into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:6.2+dfsg-2ubuntu6.7 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +Hello Brett, or anyone else affected, + +Accepted qemu into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:4.2-3ubuntu6.25 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +Hello Brett, or anyone else affected, + +Accepted qemu into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.11+dfsg-1ubuntu7.42 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +All autopkgtests for the newly accepted qemu (1:6.2+dfsg-2ubuntu6.7) for jammy have finished running. +The following regressions have been reported in tests triggered by the package: + +initramfs-tools/0.140ubuntu13.1 (amd64) +ubuntu-image/2.2+22.04ubuntu3 (amd64, arm64, ppc64el) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +All autopkgtests for the newly accepted qemu (1:4.2-3ubuntu6.25) for focal have finished running. +The following regressions have been reported in tests triggered by the package: + +livecd-rootfs/2.664.46 (amd64) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +All autopkgtests for the newly accepted qemu (1:2.11+dfsg-1ubuntu7.42) for bionic have finished running. +The following regressions have been reported in tests triggered by the package: + +systemd/237-3ubuntu10.57 (i386) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +autopkgtests regressions cleared; unrelated to these changes. + +Verification done on jammy-proposed. + +Followed the instructions as per: https://bugs.launchpad.net/cloud-archive/+bug/1994002/comments/26 + +With the exception that I had to install the debug symbols package as per https://wiki.ubuntu.com/Debug%20Symbol%20Packages for -proposed. + +jammy-updates -- Fail: +ubuntu@qemu-j:~$ nc 127.0.0.1 3333 +QEMU 6.2.0 monitor - type 'help' for more information +(qemu) migrate -d tcp:127.0.0.1:4444 +migrate -d tcp:127.0.0.1:4444 + +(qemu) +(qemu) info migrate +info migrate + +globals: +store-global-state: on +only-migratable: off +send-configuration: on +send-section-footer: on +decompress-error-check: on +clear-bitmap-shift: 18 +Migration status: active +total time: 0 ms +(qemu) +(qemu) quit +quit + +jammy-proposed - Pass: +ubuntu@qemu-j2:~$ nc 127.0.0.1 3333 +QEMU 6.2.0 monitor - type 'help' for more information +(qemu) migrate -d tcp:127.0.0.1:4444 +migrate -d tcp:127.0.0.1:4444 +(qemu) info migrate +info migrate +globals: +store-global-state: on +only-migratable: off +send-configuration: on +send-section-footer: on +decompress-error-check: on +clear-bitmap-shift: 18 +Migration status: setup +total time: 0 ms +(qemu) + +Full gdb session output: https://pastebin.ubuntu.com/p/mkhQzCXKdk/ + +Verification done for focal-proposed. + +focal-updates: FAIL (status: active) + + (qemu) info migrate + ... + Migration status: active + total time: 0 milliseconds + +focal-proposed: PASS (status: setup) + + (qemu) info migrate + ... + Migration status: setup + total time: 0 milliseconds + +Details: +======= + +$ lsb_release -cs +focal + +focal-updates: FAIL +------------- + +$ curl http://ddebs.ubuntu.com/dbgsym-release-key.asc | sudo apt-key add - +$ sudo add-apt-repository -y 'deb http://ddebs.ubuntu.com/ubuntu focal-updates main' + +$ sudo apt install --yes qemu-system-x86 qemu-system-x86-dbgsym + +$ dpkg -s qemu-system-x86 | grep Version: +Version: 1:4.2-3ubuntu6.24 + +$ dpkg -s qemu-system-x86-dbgsym | grep Version: +Version: 1:4.2-3ubuntu6.24 + +... + +$ sudo add-apt-repository -ys 'deb http://archive.ubuntu.com/ubuntu focal-updates main' + +$ apt source qemu +$ head -n1 qemu-*/debian/changelog +qemu (1:4.2-3ubuntu6.24) focal-security; urgency=medium + +$ vim qemu-*/migration/migration.c + + 915 static void fill_source_migration_info(MigrationInfo *info) +... + 925 case MIGRATION_STATUS_SETUP: + 926 info->has_status = true; + 927 info->has_total_time = false; + 928 break; + +... + +T1) + +$ qemu-system-x86_64 -nodefaults -nographic -S -incoming tcp:0:4444 + +T2) + +gdb \ + -ex 'set non-stop on' -ex 'set pagination off' -ex 'set confirm off' \ + qemu-system-x86_64 + +(gdb) b migrate_set_state +Breakpoint 1 at 0x6d3aa0: migrate_set_state. (2 locations) + +(gdb) b migration/migration.c:928 +Breakpoint 2 at 0x6d317b: file ./migration/migration.c, line 928. + +(gdb) run -nodefaults -nographic -S -monitor tcp:0:3333,server,wait=off + +T3) + +nc 127.0.0.1 3333 + +(qemu) migrate -d tcp:127.0.0.1:4444 + +T2) + +Thread 1 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x5555566949d8, old_state=0, new_state=1) at ./migration/migration.c:1463 +1463 ./migration/migration.c: No such file or directory. +(gdb) p (MigrationStatus) 0 +$1 = MIGRATION_STATUS_NONE +(gdb) p (MigrationStatus) 1 +$2 = MIGRATION_STATUS_SETUP +(gdb) c + +Thread 5 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x5555566949d8, old_state=1, new_state=4) at ./migration/migration.c:1463 +1463 in ./migration/migration.c +(gdb) p (MigrationStatus) 1 +$3 = MIGRATION_STATUS_SETUP +(gdb) p (MigrationStatus) 4 +$4 = MIGRATION_STATUS_ACTIVE +(gdb) + +T3) + +(qemu) info migrate + +T2) + +Thread 1 "qemu-system-x86" hit Breakpoint 2, fill_source_migration_info (info=0x555556850590) at ./migration/migration.c:928 +928 in ./migration/migration.c + +(gdb) p (MigrationStatus) s.state +$6 = MIGRATION_STATUS_SETUP +(gdb) p info.status +$7 = MIGRATION_STATUS_NONE + +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x7ffff5ee55c0 (LWP 5066) "qemu-system-x86" fill_source_migration_info (info=0x555556850590) at ./migration/migration.c:928 + 2 Thread 0x7ffff5ee1700 (LWP 5070) "qemu-system-x86" (running) + 3 Thread 0x7ffff565f700 (LWP 5071) "qemu-system-x86" (running) + 5 Thread 0x7fffedfff700 (LWP 5075) "qemu-system-x86" migrate_set_state (state=0x5555566949d8, old_state=1, new_state=4) at ./migration/migration.c:1463 +(gdb) thread 5 +[Switching to thread 5 (Thread 0x7fffedfff700 (LWP 5075))] +#0 migrate_set_state (state=0x5555566949d8, old_state=1, new_state=4) at ./migration/migration.c:1463 +1463 in ./migration/migration.c + +(gdb) continue & +Continuing. +(gdb) info threads + Id Target Id Frame + 1 Thread 0x7ffff5ee55c0 (LWP 5066) "qemu-system-x86" fill_source_migration_info (info=0x555556850590) at ./migration/migration.c:928 + 2 Thread 0x7ffff5ee1700 (LWP 5070) "qemu-system-x86" (running) + 3 Thread 0x7ffff565f700 (LWP 5071) "qemu-system-x86" (running) +* 5 Thread 0x7fffedfff700 (LWP 5075) "qemu-system-x86" (running) + +(gdb) thread 1 +[Switching to thread 1 (Thread 0x7ffff5ee55c0 (LWP 5066))] +#0 fill_source_migration_info (info=0x555556850590) at ./migration/migration.c:928 +928 in ./migration/migration.c +(gdb) p (MigrationStatus) s.state +$8 = MIGRATION_STATUS_ACTIVE +(gdb) c + +T3) + +(qemu) info migrate +info migrate +globals: +store-global-state: on +only-migratable: off +send-configuration: on +send-section-footer: on +decompress-error-check: on +clear-bitmap-shift: 18 +Migration status: active +total time: 0 milliseconds +(qemu) + +Migration status is active, without any RAM statistics. + +(qemu) quit +(gdb) quit + +Terminal 1) + +Ctrl-C + + + + +focal-proposed: PASS +-------------- + + +$ sudo add-apt-repository -ys 'deb http://archive.ubuntu.com/ubuntu focal-proposed main' +$ sudo add-apt-repository -y 'deb http://ddebs.ubuntu.com/ubuntu focal-proposed main' + +$ sudo apt install --yes qemu-system-x86 qemu-system-x86-dbgsym + + +$ dpkg -s qemu-system-x86 | grep Version: +Version: 1:4.2-3ubuntu6.25 + +$ dpkg -s qemu-system-x86-dbgsym | grep Version: +Version: 1:4.2-3ubuntu6.25 + +... + +$ apt source qemu + +$ head -n1 qemu-*/debian/changelog +qemu (1:4.2-3ubuntu6.25) focal; urgency=medium + +$ vim qemu-*/migration/migration.c + + 915 static void fill_source_migration_info(MigrationInfo *info) +... + 926 case MIGRATION_STATUS_SETUP: + 927 info->has_status = true; + 928 info->has_total_time = false; + 929 break; + +... + + + + +T1) + +$ qemu-system-x86_64 -nodefaults -nographic -S -incoming tcp:0:4444 + +T2) + +gdb \ + -ex 'set non-stop on' -ex 'set pagination off' -ex 'set confirm off' \ + qemu-system-x86_64 + +(gdb) b migrate_set_state +Breakpoint 1 at 0x6d3b80: migrate_set_state. (2 locations) +(gdb) b migration/migration.c:928 +Breakpoint 2 at 0x6d32ad: file ./migration/migration.c, line 928. + +(gdb) run -nodefaults -nographic -S -monitor tcp:0:3333,server,wait=off + +T3) + +nc 127.0.0.1 3333 + +(qemu) migrate -d tcp:127.0.0.1:4444 + +T2) + +Thread 1 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x5555566949d8, old_state=0, new_state=1) at ./migration/migration.c:1464 +1464 ./migration/migration.c: No such file or directory. +(gdb) p (MigrationStatus) 0 +$1 = MIGRATION_STATUS_NONE +(gdb) p (MigrationStatus) 1 +$2 = MIGRATION_STATUS_SETUP +(gdb) c +Continuing. +[New Thread 0x7fffedfff700 (LWP 6990)] +[New Thread 0x7fffed7fe700 (LWP 6991)] +[Thread 0x7fffedfff700 (LWP 6990) exited] + +Thread 5 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x5555566949d8, old_state=1, new_state=4) at ./migration/migration.c:1464 +1464 in ./migration/migration.c +(gdb) p (MigrationStatus) 1 +$3 = MIGRATION_STATUS_SETUP +(gdb) p (MigrationStatus) 4 +$4 = MIGRATION_STATUS_ACTIVE +(gdb) + +T3) + +(qemu) info migrate + +T2) + +Thread 1 "qemu-system-x86" hit Breakpoint 2, fill_source_migration_info (info=0x555556850590) at ./migration/migration.c:928 +928 in ./migration/migration.c + +(gdb) p (MigrationStatus) s.state +$6 = MIGRATION_STATUS_SETUP +(gdb) p info.status +$7 = MIGRATION_STATUS_NONE + +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x7ffff5ee55c0 (LWP 6983) "qemu-system-x86" fill_source_migration_info (info=0x555556850590) at ./migration/migration.c:928 + 2 Thread 0x7ffff5ee1700 (LWP 6987) "qemu-system-x86" (running) + 3 Thread 0x7ffff565f700 (LWP 6988) "qemu-system-x86" (running) + 5 Thread 0x7fffed7fe700 (LWP 6991) "qemu-system-x86" migrate_set_state (state=0x5555566949d8, old_state=1, new_state=4) at ./migration/migration.c:1464 +(gdb) thread 5 +[Switching to thread 5 (Thread 0x7fffed7fe700 (LWP 6991))] +#0 migrate_set_state (state=0x5555566949d8, old_state=1, new_state=4) at ./migration/migration.c:1464 +1464 in ./migration/migration.c + +(gdb) continue & +Continuing. + +(gdb) info threads + Id Target Id Frame + 1 Thread 0x7ffff5ee55c0 (LWP 6983) "qemu-system-x86" fill_source_migration_info (info=0x555556850590) at ./migration/migration.c:928 + 2 Thread 0x7ffff5ee1700 (LWP 6987) "qemu-system-x86" (running) + 3 Thread 0x7ffff565f700 (LWP 6988) "qemu-system-x86" (running) +* 5 Thread 0x7fffed7fe700 (LWP 6991) "qemu-system-x86" (running) +(gdb) thread 1 +[Switching to thread 1 (Thread 0x7ffff5ee55c0 (LWP 6983))] +#0 fill_source_migration_info (info=0x555556850590) at ./migration/migration.c:928 +928 in ./migration/migration.c +(gdb) p (MigrationStatus) s.state +$8 = MIGRATION_STATUS_ACTIVE +(gdb) c + +T3) + +(qemu) info migrate +info migrate +globals: +store-global-state: on +only-migratable: off +send-configuration: on +send-section-footer: on +decompress-error-check: on +clear-bitmap-shift: 18 +Migration status: setup +total time: 0 milliseconds + +Status is now still 'SETUP' (which is not expected to have RAM statistics), not 'ACTIVE' (which is, and caused the issue). + +(qemu) quit +(gdb) quit + +Terminal 1) + +Ctrl-C + +Verification done for bionic-proposed. + +bionic-updates: FAIL (status: active) + + (qemu) info migrate + info migrate + globals: store-global-state=1, only_migratable=0, send-configuration=1, send-section-footer=1 + capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off postcopy-ram: off x-colo: off release-ram: off block: off return-path: off pause-before-switchover: off x-multifd: off + Migration status: active + total time: 0 milliseconds + +bionic-proposed: PASS (status: setup) + + (qemu) info migrate + info migrate + globals: store-global-state=1, only_migratable=0, send-configuration=1, send-section-footer=1 + capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off postcopy-ram: off x-colo: off release-ram: off block: off return-path: off pause-before-switchover: off x-multifd: off + Migration status: setup + total time: 0 milliseconds + +Details: +======= + +$ lsb_release -cs +bionic + +bionic-updates: FAIL +-------------- + +$ curl http://ddebs.ubuntu.com/dbgsym-release-key.asc | sudo apt-key add - +OK +$ sudo add-apt-repository -y 'deb http://ddebs.ubuntu.com/ubuntu bionic-updates main' + +$ sudo apt install --yes qemu-system-x86 qemu-system-x86-dbgsym + +$ dpkg -s qemu-system-x86 | grep Version: +Version: 1:2.11+dfsg-1ubuntu7.41 + +$ dpkg -s qemu-system-x86-dbgsym | grep Version: +Version: 1:2.11+dfsg-1ubuntu7.41 + +... + +$ sudo add-apt-repository -ys 'deb http://archive.ubuntu.com/ubuntu bionic-updates main' +$ apt source qemu +$ head -n1 qemu-*/debian/changelog +qemu (1:2.11+dfsg-1ubuntu7.41) bionic-security; urgency=medium + +$ vim qemu-*/migration/migration.c + 594 MigrationInfo *qmp_query_migrate(Error **errp) + ... + 603 case MIGRATION_STATUS_SETUP: + 604 info->has_status = true; + 605 info->has_total_time = false; + 606 break; +... + +T1) + +$ qemu-system-x86_64 -nodefaults -nographic -S -incoming tcp:0:4444 + +T2) + +(gdb) b migrate_set_state +Breakpoint 1 at 0x58dd60: file ./migration/migration.c, line 1025. + +(gdb) b migration/migration.c:603 +Breakpoint 2 at 0x58d670: file ./migration/migration.c, line 603. + +# Using 603 vs 606 as the code didn't break on 606 for some reason. + +(gdb) run -nodefaults -nographic -S -monitor tcp:0:3333,server,wait=off + +T3) + +$ nc 127.0.0.1 3333 + +(qemu) migrate -d tcp:127.0.0.1:4444 + +T2) + +Thread 1 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x5555566ac6f0, old_state=0, new_state=1) at ./migration/migration.c:1025 +1025 ./migration/migration.c: No such file or directory. +(gdb) p (MigrationStatus) 0 +$1 = MIGRATION_STATUS_NONE +(gdb) p (MigrationStatus) 1 +$2 = MIGRATION_STATUS_SETUP +(gdb) c +Continuing. +[New Thread 0x7fffcf9ff700 (LWP 4909)] +[New Thread 0x7fffcf1fe700 (LWP 4910)] +[Thread 0x7fffcf9ff700 (LWP 4909) exited] + +Thread 5 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x5555566ac6f0, old_state=1, new_state=4) at ./migration/migration.c:1025 +1025 in ./migration/migration.c +(gdb) p (MigrationStatus) 1 +$3 = MIGRATION_STATUS_SETUP +(gdb) p (MigrationStatus) 4 +$4 = MIGRATION_STATUS_ACTIVE + +T3) + +(qemu) info migrate + +T2) + +Thread 1 "qemu-system-x86" hit Breakpoint 2, qmp_query_migrate (errp=errp@entry=0x0) at ./migration/migration.c:604 +604 in ./migration/migration.c +(gdb) p (MigrationStatus) s.state +value has been optimized out +(gdb) p info.status +$1 = MIGRATION_STATUS_NONE + +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x7ffff7fc1cc0 (LWP 4916) "qemu-system-x86" qmp_query_migrate (errp=errp@entry=0x0) at ./migration/migration.c:604 + 2 Thread 0x7fffdf7ff700 (LWP 4920) "qemu-system-x86" (running) + 3 Thread 0x7fffdcffe700 (LWP 4921) "qemu-system-x86" (running) + 5 Thread 0x7fffcf9ff700 (LWP 4924) "qemu-system-x86" migrate_set_state (state=0x5555566ac6f0, old_state=1, new_state=4) at ./migration/migration.c:1025 + +(gdb) thread 5 +[Switching to thread 5 (Thread 0x7fffcf9ff700 (LWP 4924))] +#0 migrate_set_state (state=0x5555566ac6f0, old_state=1, new_state=4) at ./migration/migration.c:1025 +1025 in ./migration/migration.c +(gdb) continue & +Continuing. + +(gdb) info threads + Id Target Id Frame + 1 Thread 0x7ffff7fc1cc0 (LWP 4916) "qemu-system-x86" qmp_query_migrate (errp=errp@entry=0x0) at ./migration/migration.c:604 + 2 Thread 0x7fffdf7ff700 (LWP 4920) "qemu-system-x86" (running) + 3 Thread 0x7fffdcffe700 (LWP 4921) "qemu-system-x86" (running) +* 5 Thread 0x7fffcf9ff700 (LWP 4924) "qemu-system-x86" (running) + +(gdb) thread 1 +[Switching to thread 1 (Thread 0x7ffff7fc1cc0 (LWP 4916))] +#0 qmp_query_migrate (errp=errp@entry=0x0) at ./migration/migration.c:604 +604 in ./migration/migration.c +(gdb) p (MigrationStatus) s.state +value has been optimized out +(gdb) c + +T3) + +(qemu) info migrate +info migrate +globals: store-global-state=1, only_migratable=0, send-configuration=1, send-section-footer=1 +capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off postcopy-ram: off x-colo: off release-ram: off block: off return-path: off pause-before-switchover: off x-multifd: off +Migration status: active +total time: 0 milliseconds + +Migration status is active, without any RAM statistics. + + + +bionic-proposed: PASS +--------------- + +$ sudo add-apt-repository -ys 'deb http://archive.ubuntu.com/ubuntu bionic-proposed main' +$ sudo add-apt-repository -y 'deb http://ddebs.ubuntu.com/ubuntu bionic-proposed main' + +$ sudo apt install --yes qemu-system-x86 qemu-system-x86-dbgsym + +$ dpkg -s qemu-system-x86 | grep Version: +Version: 1:2.11+dfsg-1ubuntu7.42 + +$ dpkg -s qemu-system-x86-dbgsym | grep Version: +Version: 1:2.11+dfsg-1ubuntu7.42 + +$ rm -rf qemu* +$ apt source qemu + +$ head -n1 qemu-*/debian/changelog +qemu (1:2.11+dfsg-1ubuntu7.42) bionic; urgency=medium + +$ vim qemu-*/migration/migration.c + 594 MigrationInfo *qmp_query_migrate(Error **errp) +... + 604 case MIGRATION_STATUS_SETUP: + 605 info->has_status = true; + 606 info->has_total_time = false; + 607 break; + + +T1) + +$ qemu-system-x86_64 -nodefaults -nographic -S -incoming tcp:0:4444 + +T2) + +gdb \ + -ex 'set non-stop on' -ex 'set pagination off' -ex 'set confirm off' \ + qemu-system-x86_64 + +(gdb) b migrate_set_state +Breakpoint 1 at 0x58de30: file ./migration/migration.c, line 1026. + +(gdb) b migration/migration.c:604 +Breakpoint 2 at 0x58d748: file ./migration/migration.c, line 604. + +(gdb) run -nodefaults -nographic -S -monitor tcp:0:3333,server,wait=off + + +T3) + +nc 127.0.0.1 3333 + +(qemu) migrate -d tcp:127.0.0.1:4444 + +T2) + +Thread 1 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x5555566ac6f0, old_state=0, new_state=1) at ./migration/migration.c:1026 +1026 ./migration/migration.c: No such file or directory. +(gdb) p (MigrationStatus) 0 +$1 = MIGRATION_STATUS_NONE +(gdb) p (MigrationStatus) 1 +$2 = MIGRATION_STATUS_SETUP +(gdb) c +Continuing. +[New Thread 0x7fffcf9ff700 (LWP 6525)] +[New Thread 0x7fffcf1fe700 (LWP 6526)] +[Thread 0x7fffcf9ff700 (LWP 6525) exited] + +Thread 5 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x5555566ac6f0, old_state=1, new_state=4) at ./migration/migration.c:1026 +1026 in ./migration/migration.c +(gdb) p (MigrationStatus) 1 +$3 = MIGRATION_STATUS_SETUP +(gdb) p (MigrationStatus) 4 +$4 = MIGRATION_STATUS_ACTIVE + +T3) + +(qemu) info migrate + +T2) + +Thread 1 "qemu-system-x86" hit Breakpoint 2, qmp_query_migrate (errp=errp@entry=0x0) at ./migration/migration.c:605 +605 in ./migration/migration.c +(gdb) p (MigrationStatus) s.state +value has been optimized out +(gdb) p info.status +$5 = MIGRATION_STATUS_NONE + +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x7ffff7fc1cc0 (LWP 6518) "qemu-system-x86" qmp_query_migrate (errp=errp@entry=0x0) at ./migration/migration.c:605 + 2 Thread 0x7fffdf7ff700 (LWP 6522) "qemu-system-x86" (running) + 3 Thread 0x7fffdcffe700 (LWP 6523) "qemu-system-x86" (running) + 5 Thread 0x7fffcf1fe700 (LWP 6526) "qemu-system-x86" migrate_set_state (state=0x5555566ac6f0, old_state=1, new_state=4) at ./migration/migration.c:1026 +(gdb) thread 5 +[Switching to thread 5 (Thread 0x7fffcf1fe700 (LWP 6526))] +#0 migrate_set_state (state=0x5555566ac6f0, old_state=1, new_state=4) at ./migration/migration.c:1026 +1026 in ./migration/migration.c +(gdb) continue & +Continuing. +(gdb) info threads + Id Target Id Frame + 1 Thread 0x7ffff7fc1cc0 (LWP 6518) "qemu-system-x86" qmp_query_migrate (errp=errp@entry=0x0) at ./migration/migration.c:605 + 2 Thread 0x7fffdf7ff700 (LWP 6522) "qemu-system-x86" (running) + 3 Thread 0x7fffdcffe700 (LWP 6523) "qemu-system-x86" (running) +* 5 Thread 0x7fffcf1fe700 (LWP 6526) "qemu-system-x86" (running) + +(gdb) thread 1 +[Switching to thread 1 (Thread 0x7ffff7fc1cc0 (LWP 6518))] +#0 qmp_query_migrate (errp=errp@entry=0x0) at ./migration/migration.c:605 +605 in ./migration/migration.c +(gdb) p (MigrationStatus) s.state +value has been optimized out + +(gdb) c + +T3) + +(qemu) info migrate +info migrate +globals: store-global-state=1, only_migratable=0, send-configuration=1, send-section-footer=1 +capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off postcopy-ram: off x-colo: off release-ram: off block: off return-path: off pause-before-switchover: off x-multifd: off +Migration status: setup +total time: 0 milliseconds + +Status is now still 'SETUP' (which is not expected to have RAM statistics), not 'ACTIVE' (which is, and caused the issue). + +(qemu) quit +(gdb) quit + +Terminal 1) + +Ctrl-C + + +I verified the test results and am satisfied that they show the executed planned test case, and that the results are correct. + +The package built correctly in all architectures and Ubuntu releases it was meant for. + +There are no DEP8 regressions at the moment. + +There is no SRU freeze ongoing at the moment. + +There is no halted phasing on the previous update. + + +This bug was fixed in the package qemu - 1:6.2+dfsg-2ubuntu6.7 + +--------------- +qemu (1:6.2+dfsg-2ubuntu6.7) jammy; urgency=medium + + [ Brett Milford ] + * d/p/u/lp1994002-migration-Read-state-once.patch: Fix for libvirt + error 'migration was active, but no RAM info was set' (LP: #1994002) + + [ Mauricio Faria de Oliveira ] + * d/p/u/lp2009048-vfio_map_dma_einval_amd_iommu_1tb.patch: Add hint + to VFIO_MAP_DMA error on AMD IOMMU for VMs with ~1TB+ RAM (LP: #2009048) + * d/rules: move "Disable LTO on non-amd64" before buildflags.mk on Jammy. + + [ Michal Maloszewski ] + * d/rules: Disable LTO on non-amd 64 architectures to prevent QEMU + coroutines from failing (LP: #1921664) + + -- Mauricio Faria de Oliveira <email address hidden> Mon, 06 Mar 2023 17:00:46 -0300 + +This bug was fixed in the package qemu - 1:4.2-3ubuntu6.25 + +--------------- +qemu (1:4.2-3ubuntu6.25) focal; urgency=medium + + [ Brett Milford ] + * d/p/u/lp1994002-migration-Read-state-once.patch: Fix for libvirt + error 'migration was active, but no RAM info was set' (LP: #1994002) + + [ Mauricio Faria de Oliveira ] + * d/p/u/lp2009048-vfio_map_dma_einval_amd_iommu_1tb.patch: Add hint + to VFIO_MAP_DMA error on AMD IOMMU for VMs with ~1TB+ RAM (LP: #2009048) + + -- Mauricio Faria de Oliveira <email address hidden> Thu, 02 Mar 2023 18:07:21 -0300 + +This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu7.42 + +--------------- +qemu (1:2.11+dfsg-1ubuntu7.42) bionic; urgency=medium + + [ Brett Milford ] + * d/p/u/lp1994002-migration-Read-state-once.patch: Fix for libvirt + error 'migration was active, but no RAM info was set' (LP: #1994002) + + [ Mauricio Faria de Oliveira ] + * d/p/u/lp2009048-vfio_map_dma_einval_amd_iommu_1tb.patch: Add hint + to VFIO_MAP_DMA error on AMD IOMMU for VMs with ~1TB+ RAM (LP: #2009048) + + -- Mauricio Faria de Oliveira <email address hidden> Thu, 02 Mar 2023 18:26:12 -0300 + +Marking the UCA tasks as Invalid, as apparently not needed; please revert otherwise. + +Hello Brett, or anyone else affected, + +Accepted qemu into ussuri-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. To enable the -proposed repository: + + sudo add-apt-repository cloud-archive:ussuri-proposed + sudo apt-get update + +Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-ussuri-needed to verification-ussuri-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-ussuri-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Verification done on ussuri-proposed. +Steps explained in previous comments. + +The migration status with the synthetic reproducer in GDB +is now still 'SETUP' (which is not expected to have RAM statistics), +instead of 'ACTIVE' (which is, and caused the issue): + +(qemu) info migrate +... +Migration status: setup + +... + +$ lsb_release -cs +bionic + +$ apt policy qemu-system-x86 +qemu-system-x86: + Installed: 1:4.2-3ubuntu6.27~cloud0 + Candidate: 1:4.2-3ubuntu6.27~cloud0 + Version table: + *** 1:4.2-3ubuntu6.27~cloud0 500 + 500 http://ubuntu-cloud.archive.canonical.com/ubuntu bionic-proposed/ussuri/main amd64 Packages + 100 /var/lib/dpkg/status +... + +$ file $(which qemu-system-x86_64) | grep -o 'BuildID.*,' +BuildID[sha1]=82a4159294ae653e770be24bbcfbb35703e60005, + +(Corey provided the .ddeb packages which is not yet exposed/published in PPAs/archive.) + +$ dpkg-deb -c qemu-system-x86-dbgsym_4.2-3ubuntu6.27~cloud0_amd64.ddeb | fgrep .debug +-rw-r--r-- root/root 21271712 2023-10-26 14:08 ./usr/lib/debug/.build-id/48/bd78ceee4a669d37efd9ac8d851947205de4f7.debug +-rw-r--r-- root/root 21321832 2023-10-26 14:08 ./usr/lib/debug/.build-id/82/a4159294ae653e770be24bbcfbb35703e60005.debug + +$ sudo apt install ./qemu-system-x86-dbgsym_4.2-3ubuntu6.27~cloud0_amd64.ddeb + +$ apt source qemu + +$ head -n1 qemu-4.2/debian/changelog +qemu (1:4.2-3ubuntu6.27~cloud0) bionic-ussuri; urgency=medium + + 915 static void fill_source_migration_info(MigrationInfo *info) +... + 926 case MIGRATION_STATUS_SETUP: + 927 info->has_status = true; + 928 info->has_total_time = false; + 929 break; + +Terminal 1) + +$ qemu-system-x86_64 -nodefaults -nographic -S -incoming tcp:0:4444 + +Terminal 2) + +$ gdb \ + -ex 'set non-stop on' -ex 'set pagination off' -ex 'set confirm off' \ + qemu-system-x86_64 +... +Reading symbols from qemu-system-x86_64...Reading symbols from /usr/lib/debug/.build-id/82/a4159294ae653e770be24bbcfbb35703e60005.debug...done. +done. + +(gdb) b migrate_set_state +Breakpoint 1 at 0x6ba8c0: file ./migration/migration.c, line 1464. + +(gdb) b migration/migration.c:928 +Breakpoint 2 at 0x6b9fb3: file ./migration/migration.c, line 928. + +(gdb) run -nodefaults -nographic -S -monitor tcp:0:3333,server,wait=off +... + +Terminal 3) + +$ nc 127.0.0.1 3333 +QEMU 4.2.1 monitor - type 'help' for more information +(qemu) migrate -d tcp:127.0.0.1:4444 + +Terminal 2) + +Thread 1 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x5555566a11d8, old_state=0, new_state=1) at ./migration/migration.c:1464 +1464 ./migration/migration.c: No such file or directory. + +(gdb) p (MigrationStatus) 0 +$1 = MIGRATION_STATUS_NONE + +(gdb) p (MigrationStatus) 1 +$2 = MIGRATION_STATUS_SETUP + +(gdb) c +Continuing. +... + +Thread 5 "qemu-system-x86" hit Breakpoint 1, migrate_set_state (state=0x5555566a11d8, old_state=1, new_state=4) at ./migration/migration.c:1464 +1464 in ./migration/migration.c + +(gdb) p (MigrationStatus) 1 +$3 = MIGRATION_STATUS_SETUP + +(gdb) p (MigrationStatus) 4 +$4 = MIGRATION_STATUS_ACTIVE + +(gdb) + +Terminal 3) + +(qemu) info migrate + +Terminal 2) + +Thread 1 "qemu-system-x86" hit Breakpoint 2, fill_source_migration_info (info=0x5555572d29b0) at ./migration/migration.c:928 +928 in ./migration/migration.c + +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x7ffff7fcdcc0 (LWP 1477) "qemu-system-x86" fill_source_migration_info (info=0x5555572d29b0) at ./migration/migration.c:928 + 2 Thread 0x7fffe61ff700 (LWP 1481) "qemu-system-x86" (running) + 3 Thread 0x7fffe59fe700 (LWP 1482) "qemu-system-x86" (running) + 5 Thread 0x7fffdd7fe700 (LWP 1485) "qemu-system-x86" migrate_set_state (state=0x5555566a11d8, old_state=1, new_state=4) at ./migration/migration.c:1464 + +(gdb) thread 5 +[Switching to thread 5 (Thread 0x7fffdd7fe700 (LWP 1485))] +#0 migrate_set_state (state=0x5555566a11d8, old_state=1, new_state=4) at ./migration/migration.c:1464 +1464 in ./migration/migration.c + +(gdb) continue & +Continuing. + +(gdb) info threads + Id Target Id Frame + 1 Thread 0x7ffff7fcdcc0 (LWP 1477) "qemu-system-x86" fill_source_migration_info (info=0x5555572d29b0) at ./migration/migration.c:928 + 2 Thread 0x7fffe61ff700 (LWP 1481) "qemu-system-x86" (running) + 3 Thread 0x7fffe59fe700 (LWP 1482) "qemu-system-x86" (running) +* 5 Thread 0x7fffdd7fe700 (LWP 1485) "qemu-system-x86" (running) + +(gdb) thread 1 +[Switching to thread 1 (Thread 0x7ffff7fcdcc0 (LWP 1477))] +#0 fill_source_migration_info (info=0x5555572d29b0) at ./migration/migration.c:928 +928 in ./migration/migration.c + +(gdb) c +Continuing. + +Terminal 3) + +(qemu) info migrate +info migrate +globals: +store-global-state: on +only-migratable: off +send-configuration: on +send-section-footer: on +decompress-error-check: on +clear-bitmap-shift: 18 +Migration status: setup +total time: 0 milliseconds + +Status is now still 'SETUP' (which is not expected to have RAM statistics), not 'ACTIVE' (which is, and caused the issue). + +The verification of the Stable Release Update for qemu has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + + +This bug was fixed in the package qemu - 1:4.2-3ubuntu6.27~cloud0 +--------------- + + qemu (1:4.2-3ubuntu6.27~cloud0) bionic-ussuri; urgency=medium + . + * New update for the Ubuntu Cloud Archive. + . + qemu (1:4.2-3ubuntu6.27) focal-security; urgency=medium + . + * SECURITY UPDATE: user-after-free issue + - debian/patches/CVE-2022-1050.patch: Protect against buggy or + malicious guest driver + - CVE-2022-1050 + * SECURITY UPDATE: Out-of-bounds read + - debian/patches/CVE-2022-4144-*.patch: Have qxl_log_command Return + early if no log_cmd handler; Document qxl_phys2virt(); Pass requested + buffer size to qxl_phys2virt(); Avoid buffer overrun in qxl_phys2virt; + Assert memory slot fits in preallocated MemoryRegion + - CVE-2022-4144 + * SECURITY UPDATE: reentrancy problem + - debian/patches/CVE-2023-0330.patch: Fix reentrancy issues in the LSI + controller + - CVE-2023-0330 + . + qemu (1:4.2-3ubuntu6.26) focal; urgency=medium + . + * d/p/u/lp-1999885-s390x-tod-kvm-don-t-save-restore-the-TOD-in-PV-guest.patch: + avoid timer issues in s390x secure execution guests (LP: #1999885) + . + qemu (1:4.2-3ubuntu6.25) focal; urgency=medium + . + [ Brett Milford ] + * d/p/u/lp1994002-migration-Read-state-once.patch: Fix for libvirt + error 'migration was active, but no RAM info was set' (LP: #1994002) + . + [ Mauricio Faria de Oliveira ] + * d/p/u/lp2009048-vfio_map_dma_einval_amd_iommu_1tb.patch: Add hint + to VFIO_MAP_DMA error on AMD IOMMU for VMs with ~1TB+ RAM (LP: #2009048) + + diff --git a/results/classifier/zero-shot/108/all/2058 b/results/classifier/zero-shot/108/all/2058 new file mode 100644 index 000000000..3804e583c --- /dev/null +++ b/results/classifier/zero-shot/108/all/2058 @@ -0,0 +1,67 @@ +other: 0.978 +debug: 0.964 +device: 0.962 +network: 0.961 +performance: 0.960 +permissions: 0.959 +graphic: 0.957 +semantic: 0.955 +vnc: 0.951 +PID: 0.947 +socket: 0.947 +KVM: 0.947 +files: 0.947 +boot: 0.940 + +QEMU should pad Ethernet frames from vmnet.framework on macOS hosts +Description of problem: +When using a `vmnet` network device on a macOS host, the host’s [ARP](https://en.wikipedia.org/wiki/Address_Resolution_Protocol) replies are smaller than the 64-octet minimum frame size defined for Ethernet in IEEE Std 802.3-2022 (subclause 4.2.3.3 and Table 4–2). + +When QEMU presents such frames to a guest, the guest’s Ethernet device driver may drop them with “frame too short” or “runt” errors, since they are smaller than actual Ethernet frames should ever be. This prevents the guest from resolving the host’s MAC address, so the guest and host can’t communicate as expected. + +I observed this problem with a Mac OS X 10.4.11 guest using a `sungem` or `rtl8139` virtual network device, but it might also affect other guests and virtual network devices. +Additional information: +To prevent this problem, QEMU should pad Ethernet frames received from `vmnet` to the minimum size, 60 bytes before the frame check sequence, before handing them off to a guest. (QEMU’s virtual network devices used to add such padding, but that was changed earlier this year in commits such as 63b901bf and aee87b43.) + +Here is a patch for `net/vmnet-common.m` that calls `eth_pad_short_frame()` for this, as `net/tap.c` and `net/slirp.c` already do: + +``` +--- net/vmnet-common.m.orig 2023-12-19 13:24:34.000000000 -0800 ++++ net/vmnet-common.m 2023-12-27 13:30:15.000000000 -0800 +@@ -18,6 +18,7 @@ + #include "qemu/error-report.h" + #include "qapi/error.h" + #include "sysemu/runstate.h" ++#include "net/eth.h" + + #include <vmnet/vmnet.h> + #include <dispatch/dispatch.h> +@@ -150,10 +151,23 @@ + */ + static void vmnet_write_packets_to_qemu(VmnetState *s) + { ++ uint8_t *pkt; ++ size_t pktsz; ++ uint8_t min_pkt[ETH_ZLEN]; ++ size_t min_pktsz = sizeof(min_pkt); ++ + while (s->packets_send_current_pos < s->packets_send_end_pos) { +- ssize_t size = qemu_send_packet_async(&s->nc, +- s->iov_buf[s->packets_send_current_pos].iov_base, +- s->packets_buf[s->packets_send_current_pos].vm_pkt_size, ++ pkt = s->iov_buf[s->packets_send_current_pos].iov_base; ++ pktsz = s->packets_buf[s->packets_send_current_pos].vm_pkt_size; ++ ++ if (net_peer_needs_padding(&s->nc)) { ++ if (eth_pad_short_frame(min_pkt, &min_pktsz, pkt, pktsz)) { ++ pkt = min_pkt; ++ pktsz = min_pktsz; ++ } ++ } ++ ++ ssize_t size = qemu_send_packet_async(&s->nc, pkt, pktsz, + vmnet_send_completed); + + if (size == 0) { + +``` diff --git a/results/classifier/zero-shot/108/all/21221931 b/results/classifier/zero-shot/108/all/21221931 new file mode 100644 index 000000000..a925c3002 --- /dev/null +++ b/results/classifier/zero-shot/108/all/21221931 @@ -0,0 +1,338 @@ +permissions: 0.982 +other: 0.979 +network: 0.976 +device: 0.971 +debug: 0.971 +files: 0.967 +semantic: 0.967 +performance: 0.966 +socket: 0.957 +graphic: 0.948 +boot: 0.947 +PID: 0.945 +vnc: 0.944 +KVM: 0.913 + +[BUG] qemu git error with virgl + +Hello, + +i can't start any system if i use virgl. I get the following error: +qemu-x86_64: ../ui/console.c:1791: dpy_gl_ctx_create: Assertion +`con->gl' failed. +./and.sh: line 27: 3337167 Aborted                qemu-x86_64 -m 4096 +-smp cores=4,sockets=1 -cpu host -machine pc-q35-4.0,accel=kvm -device +virtio-vga,virgl=on,xres=1280,yres=800 -display sdl,gl=on -device +intel-hda,id=sound0,msi=on -device +hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 -device qemu-xhci,id=xhci +-device usb-tablet,bus=xhci.0 -net +nic,macaddr=52:54:00:12:34:62,model=e1000 -net +tap,ifname=$INTERFACE,script=no,downscript=no -drive +file=/media/daten2/image/lineageos.qcow2,if=virtio,index=1,media=disk,cache=none,aio=threads +Set 'tap3' nonpersistent + +i have bicected the issue: + +towo:Defiant> git bisect good +b4e1a342112e50e05b609e857f38c1f2b7aafdc4 is the first bad commit +commit b4e1a342112e50e05b609e857f38c1f2b7aafdc4 +Author: Paolo Bonzini <pbonzini@redhat.com> +Date:  Tue Oct 27 08:44:23 2020 -0400 + +   vl: remove separate preconfig main_loop +   Move post-preconfig initialization to the x-exit-preconfig. If +preconfig +   is not requested, just exit preconfig mode immediately with the QMP +   command. + +   As a result, the preconfig loop will run with accel_setup_post +   and os_setup_post restrictions (xen_restrict, chroot, etc.) +   already done. + +   Reviewed-by: Igor Mammedov <imammedo@redhat.com> +   Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + + include/sysemu/runstate.h | 1 - + monitor/qmp-cmds.c       | 9 ----- + softmmu/vl.c             | 95 +++++++++++++++++++++--------------------------- + 3 files changed, 41 insertions(+), 64 deletions(-) + +Regards, + +Torsten Wohlfarth + +Cc'ing Gerd + patch author/reviewer. + +On 1/2/21 2:11 PM, Torsten Wohlfarth wrote: +> +Hello, +> +> +i can't start any system if i use virgl. I get the following error: +> +> +qemu-x86_64: ../ui/console.c:1791: dpy_gl_ctx_create: Assertion +> +`con->gl' failed. +> +./and.sh: line 27: 3337167 Aborted                qemu-x86_64 -m 4096 +> +-smp cores=4,sockets=1 -cpu host -machine pc-q35-4.0,accel=kvm -device +> +virtio-vga,virgl=on,xres=1280,yres=800 -display sdl,gl=on -device +> +intel-hda,id=sound0,msi=on -device +> +hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 -device qemu-xhci,id=xhci +> +-device usb-tablet,bus=xhci.0 -net +> +nic,macaddr=52:54:00:12:34:62,model=e1000 -net +> +tap,ifname=$INTERFACE,script=no,downscript=no -drive +> +file=/media/daten2/image/lineageos.qcow2,if=virtio,index=1,media=disk,cache=none,aio=threads +> +> +Set 'tap3' nonpersistent +> +> +i have bicected the issue: +> +> +towo:Defiant> git bisect good +> +b4e1a342112e50e05b609e857f38c1f2b7aafdc4 is the first bad commit +> +commit b4e1a342112e50e05b609e857f38c1f2b7aafdc4 +> +Author: Paolo Bonzini <pbonzini@redhat.com> +> +Date:  Tue Oct 27 08:44:23 2020 -0400 +> +> +   vl: remove separate preconfig main_loop +> +> +   Move post-preconfig initialization to the x-exit-preconfig. If +> +preconfig +> +   is not requested, just exit preconfig mode immediately with the QMP +> +   command. +> +> +   As a result, the preconfig loop will run with accel_setup_post +> +   and os_setup_post restrictions (xen_restrict, chroot, etc.) +> +   already done. +> +> +   Reviewed-by: Igor Mammedov <imammedo@redhat.com> +> +   Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> +> +> + include/sysemu/runstate.h | 1 - +> + monitor/qmp-cmds.c       | 9 ----- +> + softmmu/vl.c             | 95 +> +++++++++++++++++++++--------------------------- +> + 3 files changed, 41 insertions(+), 64 deletions(-) +> +> +Regards, +> +> +Torsten Wohlfarth +> +> +> + +On Sun, 3 Jan 2021 18:28:11 +0100 +Philippe Mathieu-Daudé <philmd@redhat.com> wrote: + +> +Cc'ing Gerd + patch author/reviewer. +> +> +On 1/2/21 2:11 PM, Torsten Wohlfarth wrote: +> +> Hello, +> +> +> +> i can't start any system if i use virgl. I get the following error: +> +> +> +> qemu-x86_64: ../ui/console.c:1791: dpy_gl_ctx_create: Assertion +> +> `con->gl' failed. +Does following fix issue: + [PULL 12/55] vl: initialize displays _after_ exiting preconfiguration + +> +> ./and.sh: line 27: 3337167 Aborted                qemu-x86_64 -m 4096 +> +> -smp cores=4,sockets=1 -cpu host -machine pc-q35-4.0,accel=kvm -device +> +> virtio-vga,virgl=on,xres=1280,yres=800 -display sdl,gl=on -device +> +> intel-hda,id=sound0,msi=on -device +> +> hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 -device qemu-xhci,id=xhci +> +> -device usb-tablet,bus=xhci.0 -net +> +> nic,macaddr=52:54:00:12:34:62,model=e1000 -net +> +> tap,ifname=$INTERFACE,script=no,downscript=no -drive +> +> file=/media/daten2/image/lineageos.qcow2,if=virtio,index=1,media=disk,cache=none,aio=threads +> +> +> +> Set 'tap3' nonpersistent +> +> +> +> i have bicected the issue: +> +> +> +> towo:Defiant> git bisect good +> +> b4e1a342112e50e05b609e857f38c1f2b7aafdc4 is the first bad commit +> +> commit b4e1a342112e50e05b609e857f38c1f2b7aafdc4 +> +> Author: Paolo Bonzini <pbonzini@redhat.com> +> +> Date:  Tue Oct 27 08:44:23 2020 -0400 +> +> +> +>    vl: remove separate preconfig main_loop +> +> +> +>    Move post-preconfig initialization to the x-exit-preconfig. If +> +> preconfig +> +>    is not requested, just exit preconfig mode immediately with the QMP +> +>    command. +> +> +> +>    As a result, the preconfig loop will run with accel_setup_post +> +>    and os_setup_post restrictions (xen_restrict, chroot, etc.) +> +>    already done. +> +> +> +>    Reviewed-by: Igor Mammedov <imammedo@redhat.com> +> +>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> +> +> +> +>  include/sysemu/runstate.h | 1 - +> +>  monitor/qmp-cmds.c       | 9 ----- +> +>  softmmu/vl.c             | 95 +> +> ++++++++++++++++++++--------------------------- +> +>  3 files changed, 41 insertions(+), 64 deletions(-) +> +> +> +> Regards, +> +> +> +> Torsten Wohlfarth +> +> +> +> +> +> +> +> + +Hi Igor, + +yes, that fixes my issue. + +Regards, Torsten + +Am 04.01.21 um 19:50 schrieb Igor Mammedov: +On Sun, 3 Jan 2021 18:28:11 +0100 +Philippe Mathieu-Daudé <philmd@redhat.com> wrote: +Cc'ing Gerd + patch author/reviewer. + +On 1/2/21 2:11 PM, Torsten Wohlfarth wrote: +Hello, + +i can't start any system if i use virgl. I get the following error: + +qemu-x86_64: ../ui/console.c:1791: dpy_gl_ctx_create: Assertion +`con->gl' failed. +Does following fix issue: + [PULL 12/55] vl: initialize displays _after_ exiting preconfiguration +./and.sh: line 27: 3337167 Aborted                qemu-x86_64 -m 4096 +-smp cores=4,sockets=1 -cpu host -machine pc-q35-4.0,accel=kvm -device +virtio-vga,virgl=on,xres=1280,yres=800 -display sdl,gl=on -device +intel-hda,id=sound0,msi=on -device +hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 -device qemu-xhci,id=xhci +-device usb-tablet,bus=xhci.0 -net +nic,macaddr=52:54:00:12:34:62,model=e1000 -net +tap,ifname=$INTERFACE,script=no,downscript=no -drive +file=/media/daten2/image/lineageos.qcow2,if=virtio,index=1,media=disk,cache=none,aio=threads + +Set 'tap3' nonpersistent + +i have bicected the issue: +towo:Defiant> git bisect good +b4e1a342112e50e05b609e857f38c1f2b7aafdc4 is the first bad commit +commit b4e1a342112e50e05b609e857f38c1f2b7aafdc4 +Author: Paolo Bonzini <pbonzini@redhat.com> +Date:  Tue Oct 27 08:44:23 2020 -0400 + +    vl: remove separate preconfig main_loop + +    Move post-preconfig initialization to the x-exit-preconfig. If +preconfig +    is not requested, just exit preconfig mode immediately with the QMP +    command. + +    As a result, the preconfig loop will run with accel_setup_post +    and os_setup_post restrictions (xen_restrict, chroot, etc.) +    already done. + +    Reviewed-by: Igor Mammedov <imammedo@redhat.com> +    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + +  include/sysemu/runstate.h | 1 - +  monitor/qmp-cmds.c       | 9 ----- +  softmmu/vl.c             | 95 +++++++++++++++++++++--------------------------- +  3 files changed, 41 insertions(+), 64 deletions(-) + +Regards, + +Torsten Wohlfarth + diff --git a/results/classifier/zero-shot/108/all/2264 b/results/classifier/zero-shot/108/all/2264 new file mode 100644 index 000000000..ff284ee88 --- /dev/null +++ b/results/classifier/zero-shot/108/all/2264 @@ -0,0 +1,72 @@ +graphic: 0.950 +semantic: 0.948 +device: 0.947 +debug: 0.946 +performance: 0.945 +other: 0.943 +permissions: 0.942 +PID: 0.935 +files: 0.931 +boot: 0.929 +network: 0.925 +KVM: 0.925 +vnc: 0.923 +socket: 0.923 + +tests fail in staging-7.2 after "fix direction of "32-bit MMU" patch +Description of problem: +Running the tests with current staging-7.2 sources after compiling, it results in failing some tests after introduction of the following patches: + +- [target/i386: introduce function to query MMU indices](https://gitlab.com/qemu-project/qemu/-/commit/6332f3c12f7fc6c01fae1eaa59d661fef280f499) + +- [target/i386: use separate MMU indexes for 32-bit accesses](https://gitlab.com/qemu-project/qemu/-/commit/6b9875b03c81351c5f0268f571e011cf5f2fd9d2) + +- [target/i386: fix direction of "32-bit MMU" test](https://gitlab.com/qemu-project/qemu/-/commit/64e5fffe523daee23b06f3fd0f31721b137901b5) + +- [target/i386: Revert monitor_puts() in do_inject_x86_mce()](https://gitlab.com/qemu-project/qemu/-/commit/1d024cdc49a9ebc4d51142d2c33668bba1d31c89) + +in particular is the fix: + +- [target/i386: fix direction of "32-bit MMU" test](https://gitlab.com/qemu-project/qemu/-/commit/64e5fffe523daee23b06f3fd0f31721b137901b5) + +that causes the tests failing (removing such fix, tests passes). The failing tests are: + +``` +Summary of Failures: + + 92/689 qemu:qtest+qtest-i386 / qtest-i386/boot-serial-test ERROR 0.10s killed by signal 6 SIGABRT +127/689 qemu:qtest+qtest-x86_64 / qtest-x86_64/boot-serial-test ERROR 0.12s killed by signal 6 SIGABRT + 48/689 qemu:qtest+qtest-i386 / qtest-i386/bios-tables-test ERROR 40.95s killed by signal 6 SIGABRT + 71/689 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test ERROR 40.45s killed by signal 6 SIGABRT +``` + +In particular we have: + +``` + 92/689 qemu:qtest+qtest-i386 / qtest-i386/boot-serial-test ERROR 0.10s killed by signal 6 SIGABRT +――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― +stderr: +Broken pipe +../tests/qtest/libqtest.c:188: kill_qemu() detected QEMU death from signal 11 (Segmentation fault) (core dumped) + +(test program exited with status code -6) +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +``` + +and + + +``` +127/689 qemu:qtest+qtest-x86_64 / qtest-x86_64/boot-serial-test ERROR 0.12s killed by signal 6 SIGABRT +――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― +stderr: +Broken pipe +../tests/qtest/libqtest.c:188: kill_qemu() detected QEMU death from signal 11 (Segmentation fault) (core dumped) + +(test program exited with status code -6) + +TAP parsing error: Too few tests run (expected 2, got 0) +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +``` + +and so on. diff --git a/results/classifier/zero-shot/108/all/2267 b/results/classifier/zero-shot/108/all/2267 new file mode 100644 index 000000000..5ae33580a --- /dev/null +++ b/results/classifier/zero-shot/108/all/2267 @@ -0,0 +1,567 @@ +other: 0.994 +debug: 0.979 +permissions: 0.978 +performance: 0.978 +semantic: 0.975 +PID: 0.974 +device: 0.974 +graphic: 0.974 +boot: 0.970 +files: 0.968 +network: 0.966 +socket: 0.965 +vnc: 0.962 +KVM: 0.955 + +Out of bounds access in tx_fifo_push() +Description of problem: +I detected an out-of-bounds access in tx_fifo_push with my fuzzer. + +Stack trace (part):\ +`hw/net/lan9118.c:798:17: runtime error: index 2048 out of bounds for`\ +`type 'uint8_t[2048]' (aka 'unsigned char[2048]')`\ + `#0 0x563ec9a057b1 in tx_fifo_push hw/net/lan9118.c:798:43`\ + `#1 0x563ec99fbb28 in lan9118_writel hw/net/lan9118.c:1042:9`\ + `#2 0x563ec99f2de2 in lan9118_16bit_mode_write hw/net/lan9118.c:1205:9`\ + `#3 0x563ecbf78013 in memory_region_write_accessor system/memory.c:497:5`\ + `#4 0x563ecbf776f5 in access_with_adjusted_size system/memory.c:573:18`\ + `#5 0x563ecbf75643 in memory_region_dispatch_write system/memory.c:1521:16`\ + `#6 0x563ecc01bade in flatview_write_continue_step system/physmem.c:2713:18`\ + `#7 0x563ecc01b374 in flatview_write_continue system/physmem.c:2743:19`\ + `#8 0x563ecbff1c9b in flatview_write system/physmem.c:2774:12`\ + `#9 0x563ecbff1768 in address_space_write system/physmem.c:2894:18`\ +`...` +Steps to reproduce: +Reproducer:\ +export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine smdkc210"\ +cat \<\< EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio\ +outl 0xcf8 0x80000010\ +outl 0xcfc 0x5000000\ +outl 0xcf8 0x80000004\ +outl 0xcfc 0x07\ +writew 0x5000030 0x4918237b\ +writew 0x5000030 0x4918237b\ +writel 0x500003c 0x223bd37f\ +writel 0x500003c 0x223bd37f\ +writel 0x500003c 0x223bd37f\ +writew 0x500003c 0x223bd37f\ +writel 0x500003c 0x223bd37f\ +writew 0x500003c 0x223bd37f\ +writel 0x500003c 0x223bd37f\ +writel 0x500003c 0x223bd37f\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000024 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000024 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000024 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +EOF +Additional information: +Ack: Chuhong Yuan (hslester96@gmail.com) diff --git a/results/classifier/zero-shot/108/all/23448582 b/results/classifier/zero-shot/108/all/23448582 new file mode 100644 index 000000000..4cb453f2e --- /dev/null +++ b/results/classifier/zero-shot/108/all/23448582 @@ -0,0 +1,275 @@ +other: 0.990 +debug: 0.989 +permissions: 0.988 +semantic: 0.987 +graphic: 0.987 +performance: 0.985 +PID: 0.983 +socket: 0.982 +files: 0.979 +device: 0.979 +network: 0.973 +vnc: 0.973 +boot: 0.967 +KVM: 0.958 + +[BUG REPORT] cxl process in infinity loop + +Hi, all + +When I did the cxl memory hot-plug test on QEMU, I accidentally connected +two memdev to the same downstream port, the command like below: + +> +-object memory-backend-ram,size=262144k,share=on,id=vmem0 \ +> +-object memory-backend-ram,size=262144k,share=on,id=vmem1 \ +> +-device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \ +> +-device cxl-rp,port=0,bus=cxl.1,id=root_port0,chassis=0,slot=0 \ +> +-device cxl-upstream,bus=root_port0,id=us0 \ +> +-device cxl-downstream,port=0,bus=us0,id=swport00,chassis=0,slot=5 \ +> +-device cxl-downstream,port=0,bus=us0,id=swport01,chassis=0,slot=7 \ +same downstream port but has different slot! + +> +-device cxl-type3,bus=swport00,volatile-memdev=vmem0,id=cxl-vmem0 \ +> +-device cxl-type3,bus=swport01,volatile-memdev=vmem1,id=cxl-vmem1 \ +> +-M +> +cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=64G,cxl-fmw.0.interleave-granularity=4k +> +\ +There is no error occurred when vm start, but when I executed the âcxl listâ +command to view +the CXL objects info, the process can not end properly. + +Then I used strace to trace the process, I found that the process is in +infinity loop: +# strace cxl list +...... +clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 +openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 +write(3, "1\n\0", 3) = 3 +close(3) = 0 +access("/run/udev/queue", F_OK) = 0 +clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 +openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 +write(3, "1\n\0", 3) = 3 +close(3) = 0 +access("/run/udev/queue", F_OK) = 0 +clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 +openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 +write(3, "1\n\0", 3) = 3 +close(3) = 0 +access("/run/udev/queue", F_OK) = 0 +clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 +openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 +write(3, "1\n\0", 3) = 3 +close(3) = 0 +access("/run/udev/queue", F_OK) = 0 +clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 +openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 +write(3, "1\n\0", 3) = 3 +close(3) = 0 +access("/run/udev/queue", F_OK) = 0 +clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 +openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 +write(3, "1\n\0", 3) = 3 +close(3) = 0 +access("/run/udev/queue", F_OK) = 0 +clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 +openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 +write(3, "1\n\0", 3) = 3 +close(3) = 0 +access("/run/udev/queue", F_OK) = 0 +clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 +openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 +write(3, "1\n\0", 3) = 3 +close(3) = 0 +access("/run/udev/queue", F_OK) = 0 + +[Environment]: +linux: V6.10-rc3 +QEMU: V9.0.0 +ndctl: v79 + +I know this is because of the wrong use of the QEMU command, but I think we +should +be aware of this error in one of the QEMU, OS or ndctl side at least. + +Thanks +Xingtao + +On Tue, 2 Jul 2024 00:30:06 +0000 +"Xingtao Yao (Fujitsu)" <yaoxt.fnst@fujitsu.com> wrote: + +> +Hi, all +> +> +When I did the cxl memory hot-plug test on QEMU, I accidentally connected +> +two memdev to the same downstream port, the command like below: +> +> +> -object memory-backend-ram,size=262144k,share=on,id=vmem0 \ +> +> -object memory-backend-ram,size=262144k,share=on,id=vmem1 \ +> +> -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \ +> +> -device cxl-rp,port=0,bus=cxl.1,id=root_port0,chassis=0,slot=0 \ +> +> -device cxl-upstream,bus=root_port0,id=us0 \ +> +> -device cxl-downstream,port=0,bus=us0,id=swport00,chassis=0,slot=5 \ +> +> -device cxl-downstream,port=0,bus=us0,id=swport01,chassis=0,slot=7 \ +> +same downstream port but has different slot! +> +> +> -device cxl-type3,bus=swport00,volatile-memdev=vmem0,id=cxl-vmem0 \ +> +> -device cxl-type3,bus=swport01,volatile-memdev=vmem1,id=cxl-vmem1 \ +> +> -M +> +> cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=64G,cxl-fmw.0.interleave-granularity=4k +> +> \ +> +> +There is no error occurred when vm start, but when I executed the âcxl listâ +> +command to view +> +the CXL objects info, the process can not end properly. +I'd be happy to look preventing this on QEMU side if you send one, +but in general there are are lots of ways to shoot yourself in the +foot with CXL and PCI device emulation in QEMU so I'm not going +to rush to solve this specific one. + +Likewise, some hardening in kernel / userspace probably makes sense but +this is a non compliant switch so priority of a fix is probably fairly low. + +Jonathan + +> +> +Then I used strace to trace the process, I found that the process is in +> +infinity loop: +> +# strace cxl list +> +...... +> +clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 +> +openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 +> +write(3, "1\n\0", 3) = 3 +> +close(3) = 0 +> +access("/run/udev/queue", F_OK) = 0 +> +clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 +> +openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 +> +write(3, "1\n\0", 3) = 3 +> +close(3) = 0 +> +access("/run/udev/queue", F_OK) = 0 +> +clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 +> +openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 +> +write(3, "1\n\0", 3) = 3 +> +close(3) = 0 +> +access("/run/udev/queue", F_OK) = 0 +> +clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 +> +openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 +> +write(3, "1\n\0", 3) = 3 +> +close(3) = 0 +> +access("/run/udev/queue", F_OK) = 0 +> +clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 +> +openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 +> +write(3, "1\n\0", 3) = 3 +> +close(3) = 0 +> +access("/run/udev/queue", F_OK) = 0 +> +clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 +> +openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 +> +write(3, "1\n\0", 3) = 3 +> +close(3) = 0 +> +access("/run/udev/queue", F_OK) = 0 +> +clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 +> +openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 +> +write(3, "1\n\0", 3) = 3 +> +close(3) = 0 +> +access("/run/udev/queue", F_OK) = 0 +> +clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=1000000}, NULL) = 0 +> +openat(AT_FDCWD, "/sys/bus/cxl/flush", O_WRONLY|O_CLOEXEC) = 3 +> +write(3, "1\n\0", 3) = 3 +> +close(3) = 0 +> +access("/run/udev/queue", F_OK) = 0 +> +> +[Environment]: +> +linux: V6.10-rc3 +> +QEMU: V9.0.0 +> +ndctl: v79 +> +> +I know this is because of the wrong use of the QEMU command, but I think we +> +should +> +be aware of this error in one of the QEMU, OS or ndctl side at least. +> +> +Thanks +> +Xingtao + diff --git a/results/classifier/zero-shot/108/all/2346 b/results/classifier/zero-shot/108/all/2346 new file mode 100644 index 000000000..e48f4bd86 --- /dev/null +++ b/results/classifier/zero-shot/108/all/2346 @@ -0,0 +1,87 @@ +other: 0.970 +graphic: 0.968 +device: 0.956 +files: 0.948 +semantic: 0.945 +KVM: 0.943 +debug: 0.934 +permissions: 0.932 +performance: 0.931 +socket: 0.926 +PID: 0.909 +boot: 0.905 +vnc: 0.902 +network: 0.902 + +Undefined behavior error: call to function visit_type_InetSocketAddress_members through pointer to incorrect function type +Description of problem: +When compiling QEMU with --extra-cflags=-fsanitize=undefined and --extra-cflags=-fno-sanitize-recover=undefined on a system that has Clang v17 or newer (e.g. on Fedora 39 or Fedora 40), the unit tests abort with an undefined behavior error. +Steps to reproduce: +1. ``./configure --cc=clang --extra-cflags=-fsanitize=undefined --extra-cflags=-fno-sanitize-recover=undefined --target-list=x86_64-softmmu`` +2. ``make -j$(nproc)`` +3. ``make check-unit`` +Additional information: +test-io-channel-socket aborts with: + +``` + 74/103 qemu:unit / test-io-channel-socket ERROR 0.15s killed by signal 6 SIGABRT +>>> G_TEST_BUILDDIR=/tmp/qemu-ubsan/tests/unit ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MALLOC_PERTURB_=163 G_TEST_SRCDIR=tests/unit /tmp/qemu-ubsan/tests/unit/test-io-channel-socket --tap -k +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +stderr: +qapi/qapi-clone-visitor.c:188:5: runtime error: call to function visit_type_SocketAddress through pointer to incorrect function type 'bool (*)(struct Visitor *, const char *, void **, struct Error **)' +/tmp/qemu-ubsan/qapi/qapi-visit-sockets.c:487: note: visit_type_SocketAddress defined here + #0 0x5642aa2f7f3b in qapi_clone qapi/qapi-clone-visitor.c:188:5 + #1 0x5642aa2c8ce5 in qio_channel_socket_listen_async io/channel-socket.c:285:18 + #2 0x5642aa2b8903 in test_io_channel_setup_async tests/unit/test-io-channel-socket.c:116:5 + #3 0x5642aa2b8204 in test_io_channel tests/unit/test-io-channel-socket.c:179:9 + #4 0x5642aa2b8129 in test_io_channel_ipv4 tests/unit/test-io-channel-socket.c:323:5 + #5 0x7f01212c0bbf (/lib64/libglib-2.0.so.0+0x8bbbf) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df) + #6 0x7f01212c0b2f (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df) + #7 0x7f01212c0b2f (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df) + #8 0x7f01212c0b2f (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df) + #9 0x7f01212c10c9 in g_test_run_suite (/lib64/libglib-2.0.so.0+0x8c0c9) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df) + #10 0x7f01212c115f in g_test_run (/lib64/libglib-2.0.so.0+0x8c15f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df) + #11 0x5642aa2b72ec in main tests/unit/test-io-channel-socket.c:613:12 + #12 0x7f0120d2d087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06) + #13 0x7f0120d2d14a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06) + #14 0x5642aa28cd04 in _start (tests/unit/test-io-channel-socket+0x69d04) (BuildId: eeaee2b8d62ce3aa77ab8b447916a40defd78dc6) + +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior qapi/qapi-clone-visitor.c:188:5 + +(test program exited with status code -6) +``` + +And ``test-char`` aborts with: + +``` + 99/103 qemu:unit / test-char ERROR 0.12s killed by signal 6 SIGABRT +>>> G_TEST_BUILDDIR=/tmp/qemu-ubsan/tests/unit ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MALLOC_PERTURB_=197 G_TEST_SRCDIR=tests/unit /tmp/qemu-ubsan/tests/unit/test-char --tap -k +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +stderr: +qapi/qapi-clone-visitor.c:202:5: runtime error: call to function visit_type_InetSocketAddress_members through pointer to incorrect function type 'bool (*)(struct Visitor *, void *, struct Error **)' +/tmp/qemu-ubsan/qapi/qapi-visit-sockets.c:65: note: visit_type_InetSocketAddress_members defined here + #0 0x55ee1d20ad60 in qapi_clone_members qapi/qapi-clone-visitor.c:202:5 + #1 0x55ee1d24a993 in socket_address_flattenutil/qemu-sockets.c + #2 0x55ee1d1f26f6 in qmp_chardev_open_udp chardev/char-udp.c:199:34 + #3 0x55ee1d1f5254 in qemu_char_open chardev/char.c:271:9 + #4 0x55ee1d1f5254 in chardev_new chardev/char.c:968:5 + #5 0x55ee1d1f45fd in qemu_chardev_new chardev/char.c:998:11 + #6 0x55ee1d1f45fd in qemu_chr_new_from_opts chardev/char.c:657:11 + #7 0x55ee1d1f49ac in qemu_chr_new_noreplay chardev/char.c:703:11 + #8 0x55ee1d1f4aed in qemu_chr_new_permit_mux_mon chardev/char.c:731:11 + #9 0x55ee1d1b45b8 in char_udp_test_internal tests/unit/test-char.c:590:15 + #10 0x7f3dd421abbf (/lib64/libglib-2.0.so.0+0x8bbbf) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df) + #11 0x7f3dd421ab2f (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df) + #12 0x7f3dd421b0c9 in g_test_run_suite (/lib64/libglib-2.0.so.0+0x8c0c9) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df) + #13 0x7f3dd421b15f in g_test_run (/lib64/libglib-2.0.so.0+0x8c15f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df) + #14 0x55ee1d1af6bd in main tests/unit/test-char.c:1579:12 + #15 0x7f3dd3c3d087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06) + #16 0x7f3dd3c3d14a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06) + #17 0x55ee1d184e34 in _start (/tmp/qemu-ubsan/tests/unit/test-char+0x78e34) (BuildId: afdf2ec9875e3011d3ff99174ec137dc79fff74e) + +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior .qapi/qapi-clone-visitor.c:202:5 + +(test program exited with status code -6) +``` + +This undefined behavior could likely also trigger issues with CFI or certain compilers/architectures like emscripten, so we should try to avoid this. See also https://github.com/systemd/systemd/issues/29972 or https://github.com/python/cpython/issues/111178 for discussions in other projects, and https://gitlab.com/qemu-project/qemu/-/issues/2345 for a similar problem in the QEMU lockable code. diff --git a/results/classifier/zero-shot/108/all/2353 b/results/classifier/zero-shot/108/all/2353 new file mode 100644 index 000000000..5059667fa --- /dev/null +++ b/results/classifier/zero-shot/108/all/2353 @@ -0,0 +1,71 @@ +permissions: 0.985 +other: 0.981 +graphic: 0.979 +semantic: 0.979 +debug: 0.978 +device: 0.977 +PID: 0.974 +performance: 0.972 +vnc: 0.972 +boot: 0.969 +files: 0.963 +socket: 0.953 +network: 0.939 +KVM: 0.937 + +linux-user: may map interpreter at address 0 with nonzero guest_base +Description of problem: +QEMU's user-mode emulation will, under certain conditions, map the ELF interpreter at guest address 0. This is not only a violation of Linux's policy never to map anything at the first page of any virtual address space, but also a cause of confusion (and segfaults) within certain libcs; though I only tested with musl. Musl [interprets a NULL base address](https://elixir.bootlin.com/musl/v1.2.4/source/ldso/dlstart.c#L105) as the dynamic linker being invoked directly, causing it to compute its base address incorrectly. + +The problem arises in `load_elf_image()`, which chooses a `load_addr` of 0 for the ELF interpreter (i.e. the musl dynamic loader). This is passed to `target_mmap()`. I do not know whether `target_mmap()` is meant to follow the POSIX rule that (in absence of `MAP_FIXED`) "All implementations interpret an *addr* value of 0 as granting the implementation complete freedom in selecting *pa*" or if 0 is requesting 0. + +QEMU's usermode mmap() implementation translates the guest address to a host address (this is effectively a no-op with `guest_base == 0`) and passes it along to the host Linux. This means that, when `guest_base == 0`, a NULL input address means "put it anywhere," but when `guest_base != 0`, NULL means "put it at (guest address) 0." +Steps to reproduce: +1. Download a rootfs of Alpine Linux AArch64. +2. Install `gcc` (with `apk add gcc`) in the rootfs. `gcc` is not compiled as PIC, making QEMU use a nonzero `guest_base`. +3. Attempt to run `gcc` within the rootfs via QEMU. +Additional information: +I am interested in submitting a MR that fixes this issue, but I do not know which of 4 possible solutions is preferred: + +1. Modify `load_elf_image()` to ensure that `load_addr` is never NULL. +2. Modify `target_mmap()` so that NULLs are passed to the kernel as NULLs. +3. Modify the guest<->host translation facilities (`g2h_untagged` et al) to translate NULL as NULL. Overwhelmingly, a NULL pointer semantically means "there is no pointer here" and not "a pointer to the zeroth address," so treating these as valid addresses in the translation functions is arguably going against the grain. +4. When a nonzero `guest_base` is selected, reserve the first page of the guest VA space, so that the host kernel cannot accidentally put anything there. + +Here is my local patch that implements item 2 above, which indeed stops the segfaults for me: +<details><summary>Patch</summary> + +```diff +diff --git a/linux-user/mmap.c b/linux-user/mmap.c +index be3b9a6..dad29ef 100644 +--- a/linux-user/mmap.c ++++ b/linux-user/mmap.c +@@ -559,7 +559,7 @@ static abi_long mmap_h_eq_g(abi_ulong start, abi_ulong len, + int host_prot, int flags, int page_flags, + int fd, off_t offset) + { +- void *p, *want_p = g2h_untagged(start); ++ void *p, *want_p = start ? g2h_untagged(start) : 0; + abi_ulong last; + + p = mmap(want_p, len, host_prot, flags, fd, offset); +@@ -609,7 +609,7 @@ static abi_long mmap_h_lt_g(abi_ulong start, abi_ulong len, int host_prot, + int mmap_flags, int page_flags, int fd, + off_t offset, int host_page_size) + { +- void *p, *want_p = g2h_untagged(start); ++ void *p, *want_p = start ? g2h_untagged(start) : 0; + off_t fileend_adj = 0; + int flags = mmap_flags; + abi_ulong last, pass_last; +@@ -739,7 +739,7 @@ static abi_long mmap_h_gt_g(abi_ulong start, abi_ulong len, + int flags, int page_flags, int fd, + off_t offset, int host_page_size) + { +- void *p, *want_p = g2h_untagged(start); ++ void *p, *want_p = start ? g2h_untagged(start) : 0; + off_t host_offset = offset & -host_page_size; + abi_ulong last, real_start, real_last; + bool misaligned_offset = false; +``` +</details> diff --git a/results/classifier/zero-shot/108/all/2375 b/results/classifier/zero-shot/108/all/2375 new file mode 100644 index 000000000..8244818b6 --- /dev/null +++ b/results/classifier/zero-shot/108/all/2375 @@ -0,0 +1,100 @@ +graphic: 0.982 +debug: 0.979 +permissions: 0.979 +other: 0.978 +performance: 0.976 +device: 0.971 +semantic: 0.971 +files: 0.968 +PID: 0.960 +network: 0.956 +socket: 0.950 +vnc: 0.948 +boot: 0.948 +KVM: 0.932 + +A bug in AArch64 FJCVTZS instruction +Description of problem: +fjcvtzs instruction converts a double-precision floating-point value in the source register into a 32-bit signed integer, and stores the result in the destination register. The contents of the FPCR register influence the exception result. Especially, when FPCR.FZ (Flushing denormalized numbers to Zero) is set and an input is a denormalized number, the PSTATE.Z flag should be cleared even if the conversion result is zero. + +However, because the helper function for this instruction does not properly check the denormalized case, the Z flag will have an incorrect value: +``` +// target/arm/vfp_helper.c +uint64_t HELPER(fjcvtzs)(float64 value, void *vstatus) +{ + float_status *status = vstatus; + uint32_t inexact, frac; + uint32_t e_old, e_new; + + e_old = get_float_exception_flags(status); + set_float_exception_flags(0, status); + frac = float64_to_int32_modulo(value, float_round_to_zero, status); + e_new = get_float_exception_flags(status); + set_float_exception_flags(e_old | e_new, status); + + if (value == float64_chs(float64_zero)) { + /* While not inexact for IEEE FP, -0.0 is inexact for JavaScript. */ + inexact = 1; + } else { + /* Normal inexact or overflow or NaN */ + inexact = e_new & (float_flag_inexact | float_flag_invalid); // float_flag_input_denormal should also be checked. + } + + /* Pack the result and the env->ZF representation of Z together. */ + return deposit64(frac, 32, 32, inexact); +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdint.h> +#include <stdio.h> +#include <string.h> + +char i_D27[8] = { 0x0, 0xff, 0xfc, 0x0, 0x0, 0x0, 0x0, 0x0 }; +uint64_t i_fpcr = 0x01000000; // FZ = 1; +char o_X28[8]; +uint64_t o_nzcv; + +void __attribute__ ((noinline)) show_state() { + char Z = ((o_nzcv >> 30) & 1); + + printf("PSTATE.Z: %d\n", Z); + printf("X28: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_X28[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + "adrp x29, i_D27\n" + "add x29, x29, :lo12:i_D27\n" + "ldr d27, [x29]\n" + "adrp x29, i_fpcr\n" + "add x29, x29, :lo12:i_fpcr\n" + "ldr x29, [x29]\n" + "msr fpcr, x29\n" + ".inst 0x1e7e037c\n" // fjcvtzs w28, d27 + "mrs x26, nzcv\n" + "adrp x29, o_nzcv\n" + "add x29, x29, :lo12:o_nzcv\n" + "str x26, [x29]\n" + "adrp x29, o_X28\n" + "add x29, x29, :lo12:o_X28\n" + "str x28, [x29]\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints the value of Z as `01`. It should print `00` after the bug is fixed. +Additional information: + diff --git a/results/classifier/zero-shot/108/all/2632 b/results/classifier/zero-shot/108/all/2632 new file mode 100644 index 000000000..0bcc8b2af --- /dev/null +++ b/results/classifier/zero-shot/108/all/2632 @@ -0,0 +1,98 @@ +other: 0.967 +graphic: 0.963 +permissions: 0.961 +debug: 0.954 +KVM: 0.950 +vnc: 0.949 +files: 0.948 +performance: 0.946 +socket: 0.941 +semantic: 0.939 +PID: 0.936 +device: 0.933 +network: 0.916 +boot: 0.909 + +tcg optimization breaking memory access ordering +Description of problem: +The following code creates register dependency between 2 loads, which forces the first load to finish before the second: +``` +movz w0, #0x2 +str w0, [x1] +ldr w2, [x1] +eor w3, w2, w2 +ldr w4, [x5, w3, sxtw] +``` + +While translating it to tcg IR, it keeps this dependency correctly. +But after running tcg optimizations, it optimized the tcg sequence for `eor w3, w2, w2` at `0000000000000144` to `mov_i64 x3,$0x0`. which then removes the dependency between the loads. + +It results in incorrect behavior on the host on a multiple threaded program +Steps to reproduce: +1. +2. +3. +Additional information: +``` +OP: + ld_i32 loc0,env,$0xfffffffffffffff0 + brcond_i32 loc0,$0x0,lt,$L0 + st8_i32 $0x0,env,$0xfffffffffffffff4 + + ---- 0000000000000134 0000000000000000 0000000000000000 + add_i64 x28,x28,$0x2 + + ---- 0000000000000138 0000000000000000 0000000000000000 + mov_i64 x0,$0x2 + + ---- 000000000000013c 0000000000000000 0000000000001c00 + mov_i64 loc3,x1 + mov_i64 loc4,loc3 + qemu_st_a64_i64 x0,loc4,w16+un+leul,2 + + ---- 0000000000000140 0000000000000000 0000000000001c10 + mov_i64 loc5,x1 + mov_i64 loc6,loc5 + qemu_ld_a64_i64 x2,loc6,w16+un+leul,2 + + ---- 0000000000000144 0000000000000000 0000000000000000 + and_i64 loc7,x2,$0xffffffff + xor_i64 x3,x2,loc7 + and_i64 x3,x3,$0xffffffff + + ---- 0000000000000148 0000000000000000 0000000000001c20 + mov_i64 loc9,x5 + mov_i64 loc10,x3 + ext32s_i64 loc10,loc10 + add_i64 loc9,loc9,loc10 + mov_i64 loc11,loc9 + qemu_ld_a64_i64 x4,loc11,w16+un+leul,2 + st8_i32 $0x1,env,$0xfffffffffffffff4 +``` + + +``` +OP after optimization and liveness analysis: + ld_i32 tmp0,env,$0xfffffffffffffff0 pref=0xffffffff + brcond_i32 tmp0,$0x0,lt,$L0 dead: 0 + st8_i32 $0x0,env,$0xfffffffffffffff4 dead: 0 + + ---- 0000000000000134 0000000000000000 0000000000000000 + add_i64 x28,x28,$0x2 sync: 0 dead: 0 1 pref=0xffffffff + + ---- 0000000000000138 0000000000000000 0000000000000000 + mov_i64 x0,$0x2 sync: 0 dead: 0 pref=0xffffffff + + ---- 000000000000013c 0000000000000000 0000000000001c00 + qemu_st_a64_i64 $0x2,x1,w16+un+leul,2 dead: 0 + + ---- 0000000000000140 0000000000000000 0000000000001c10 + qemu_ld_a64_i64 x2,x1,w16+un+leul,2 sync: 0 dead: 0 1 pref=0xffffffff + + ---- 0000000000000144 0000000000000000 0000000000000000 + mov_i64 x3,$0x0 sync: 0 dead: 0 1 pref=0xffffffff + + ---- 0000000000000148 0000000000000000 0000000000001c20 + qemu_ld_a64_i64 x4,x5,w16+un+leul,2 sync: 0 dead: 0 1 pref=0xffffffff + st8_i32 $0x1,env,$0xfffffffffffffff4 dead: 0 +``` diff --git a/results/classifier/zero-shot/108/all/2643 b/results/classifier/zero-shot/108/all/2643 new file mode 100644 index 000000000..c38ec0c9a --- /dev/null +++ b/results/classifier/zero-shot/108/all/2643 @@ -0,0 +1,67 @@ +graphic: 0.987 +permissions: 0.986 +other: 0.985 +debug: 0.984 +semantic: 0.983 +performance: 0.980 +device: 0.978 +socket: 0.976 +PID: 0.975 +network: 0.973 +files: 0.961 +boot: 0.956 +vnc: 0.944 +KVM: 0.939 + +gtk initialization failed +Description of problem: +I compiled latest qemu version from sources with gtk enabled like below but still there is an issue of gtk initialization failed + ``` + ./configure --enable-gtk --enable-slirp + ``` +Steps to reproduce: +1. building qemu from sources or installing from packages results with gtk initialization failed message +Additional information: +``` + # virt-host-validate + QEMU: Checking for hardware virtualization : PASS + QEMU: Checking if device /dev/kvm exists : PASS + QEMU: Checking if device /dev/kvm is accessible : PASS + QEMU: Checking if device /dev/vhost-net exists : PASS + QEMU: Checking if device /dev/net/tun exists : PASS + QEMU: Checking for cgroup 'cpu' controller support : PASS + QEMU: Checking for cgroup 'cpuacct' controller support : PASS + QEMU: Checking for cgroup 'cpuset' controller support : PASS + QEMU: Checking for cgroup 'memory' controller support : PASS + QEMU: Checking for cgroup 'devices' controller support : PASS + QEMU: Checking for cgroup 'blkio' controller support : PASS + QEMU: Checking for device assignment IOMMU support : WARN (No ACPI IVRS table found, IOMMU either disabled in BIOS or not supported by this hardware platform) + QEMU: Checking for secure guest support : WARN (Unknown if this platform has Secure Guest support) + LXC: Checking for Linux >= 2.6.26 : PASS + LXC: Checking for namespace ipc : PASS + LXC: Checking for namespace mnt : PASS + LXC: Checking for namespace pid : PASS + LXC: Checking for namespace uts : PASS + LXC: Checking for namespace net : PASS + LXC: Checking for namespace user : PASS + LXC: Checking for cgroup 'cpu' controller support : PASS + LXC: Checking for cgroup 'cpuacct' controller support : PASS + LXC: Checking for cgroup 'cpuset' controller support : PASS + LXC: Checking for cgroup 'memory' controller support : PASS + LXC: Checking for cgroup 'devices' controller support : PASS + LXC: Checking for cgroup 'freezer' controller support : FAIL (Enable 'freezer' in kernel Kconfig file or mount/enable cgroup controller in your system) + LXC: Checking for cgroup 'blkio' controller support : PASS + LXC: Checking if device /sys/fs/fuse/connections exists : PASS + ``` + ``` +# apt list --installed | grep gtk +gir1.2-gtk-3.0/noble-updates,now 3.24.41-4ubuntu1.2 amd64 [installed,automatic] +gtk-update-icon-cache/noble-updates,now 3.24.41-4ubuntu1.2 amd64 [installed,automatic] +libavahi-ui-gtk3-0/noble,now 0.8-13ubuntu6 amd64 [installed,automatic] +libavahi-ui-gtk3-dev/noble,now 0.8-13ubuntu6 amd64 [installed] +libdecor-0-plugin-1-gtk/noble,now 0.2.2-1build2 amd64 [installed,automatic] +libgtk-3-0t64/noble-updates,now 3.24.41-4ubuntu1.2 amd64 [installed,automatic] +libgtk-3-bin/noble-updates,now 3.24.41-4ubuntu1.2 amd64 [installed,automatic] +libgtk-3-common/noble-updates,now 3.24.41-4ubuntu1.2 all [installed,automatic] +libgtk-3-dev/noble-updates,now 3.24.41-4ubuntu1.2 amd64 [installed,automatic] + ``` diff --git a/results/classifier/zero-shot/108/all/2667 b/results/classifier/zero-shot/108/all/2667 new file mode 100644 index 000000000..729a150cf --- /dev/null +++ b/results/classifier/zero-shot/108/all/2667 @@ -0,0 +1,227 @@ +permissions: 0.984 +other: 0.979 +graphic: 0.974 +performance: 0.973 +debug: 0.971 +semantic: 0.967 +device: 0.961 +PID: 0.958 +boot: 0.955 +socket: 0.950 +files: 0.949 +KVM: 0.945 +vnc: 0.925 +network: 0.914 + +Heavy graphic glitches when using Virtio with 3D acceleration +Description of problem: +Virtio with 3D acceleration enabled under "Video" and the corresponding OpenGL activated under "Display" with Spice leads to heavy artifacts in the graphical console. + +This error has been observed on Arch Linux with Intel Meteor Lake CPU (Intel Arc Graphics iGPU) as well as on OpenSuse Tumbleweed with Intel Kaby Lake CPU (Intel HD 630 iGPU) +Steps to reproduce: +1. Enable Virtio Graphics with 3D acceleration under "Video". +2. Activate the corresponding OpenGL under "Spice". +3. Start the VM and open the graphical console. +Additional information: + +(virtio without acceleration enabled) + + +(Same VM, same settings, but with 3D acceleration and OpenGL enabled) + + +(Same issue on a fresh install of OpenSuse Tumbleweed on a system that is in no way linked to the first one) + +``` +<domain type='kvm'> + <name>debian12</name> + <uuid>1d39d86a-b341-47bb-9847-4c78da9df863</uuid> + <metadata> + <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> + <libosinfo:os id="http://debian.org/debian/12"/> + </libosinfo:libosinfo> + </metadata> + <memory unit='KiB'>4194304</memory> + <currentMemory unit='KiB'>4194304</currentMemory> + <vcpu placement='static'>4</vcpu> + <os firmware='efi'> + <type arch='x86_64' machine='pc-q35-9.1'>hvm</type> + <firmware> + <feature enabled='no' name='enrolled-keys'/> + <feature enabled='no' name='secure-boot'/> + </firmware> + <loader readonly='yes' type='pflash'>/usr/share/edk2/x64/OVMF_CODE.4m.fd</loader> + <nvram template='/usr/share/edk2/x64/OVMF_VARS.4m.fd'>/var/lib/libvirt/qemu/nvram/debian12_VARS.fd</nvram> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <vmport state='off'/> + </features> + <cpu mode='host-passthrough' check='none' migratable='on'/> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' discard='unmap'/> + <source file='/var/lib/libvirt/images/debian12.qcow2'/> + <target dev='vda' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <target dev='sda' bus='sata'/> + <readonly/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0' model='qemu-xhci' ports='15'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> + </controller> + <controller type='pci' index='0' model='pcie-root'/> + <controller type='pci' index='1' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='1' port='0x10'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='2' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='2' port='0x11'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> + </controller> + <controller type='pci' index='3' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='3' port='0x12'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/> + </controller> + <controller type='pci' index='4' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='4' port='0x13'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> + </controller> + <controller type='pci' index='5' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='5' port='0x14'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/> + </controller> + <controller type='pci' index='6' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='6' port='0x15'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/> + </controller> + <controller type='pci' index='7' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='7' port='0x16'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/> + </controller> + <controller type='pci' index='8' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='8' port='0x17'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x7'/> + </controller> + <controller type='pci' index='9' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='9' port='0x18'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='10' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='10' port='0x19'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/> + </controller> + <controller type='pci' index='11' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='11' port='0x1a'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x2'/> + </controller> + <controller type='pci' index='12' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='12' port='0x1b'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x3'/> + </controller> + <controller type='pci' index='13' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='13' port='0x1c'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x4'/> + </controller> + <controller type='pci' index='14' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='14' port='0x1d'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x5'/> + </controller> + <controller type='sata' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> + </controller> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> + </controller> + <interface type='network'> + <mac address='52:54:00:d6:22:67'/> + <source network='default'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </interface> + <serial type='pty'> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <channel type='unix'> + <target type='virtio' name='org.qemu.guest_agent.0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <channel type='spicevmc'> + <target type='virtio' name='com.redhat.spice.0'/> + <address type='virtio-serial' controller='0' bus='0' port='2'/> + </channel> + <input type='tablet' bus='usb'> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='spice'> + <listen type='none'/> + <image compression='off'/> + <gl enable='yes'/> + </graphics> + <sound model='ich9'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/> + </sound> + <audio id='1' type='spice'/> + <video> + <model type='virtio' heads='1' primary='yes'> + <acceleration accel3d='yes'/> + </model> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> + </video> + <redirdev bus='usb' type='spicevmc'> + <address type='usb' bus='0' port='2'/> + </redirdev> + <redirdev bus='usb' type='spicevmc'> + <address type='usb' bus='0' port='3'/> + </redirdev> + <watchdog model='itco' action='reset'/> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> + </memballoon> + <rng model='virtio'> + <backend model='random'>/dev/urandom</backend> + <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> + </rng> + </devices> +</domain> +``` diff --git a/results/classifier/zero-shot/108/all/2702 b/results/classifier/zero-shot/108/all/2702 new file mode 100644 index 000000000..3379d964b --- /dev/null +++ b/results/classifier/zero-shot/108/all/2702 @@ -0,0 +1,68 @@ +other: 0.978 +KVM: 0.962 +boot: 0.961 +graphic: 0.961 +vnc: 0.960 +permissions: 0.960 +debug: 0.960 +performance: 0.958 +semantic: 0.958 +device: 0.958 +socket: 0.957 +network: 0.956 +files: 0.955 +PID: 0.952 + +qtest-arm/sse-timer-test sometimes fails on s390x host +Description of problem: +The sse-timer-test sometimes fails on the s390x runner in Travis, see: + +https://app.travis-ci.com/github/huth/qemu/jobs/628508770#L6337 : + +``` +>>> G_TEST_DBUS_DAEMON=/home/travis/build/huth/qemu/tests/dbus-vmstate-daemon.sh MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MESON_TEST_ITERATION=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 PYTHON=/home/travis/build/huth/qemu/build/pyvenv/bin/python3 MALLOC_PERTURB_=165 QTEST_QEMU_BINARY=./qemu-system-arm /home/travis/build/huth/qemu/build/tests/qtest/sse-timer-test --tap -k + +▶ 70/287 ERROR:../tests/qtest/sse-timer-test.c:91:test_counter: assertion failed (readl(COUNTER_BASE + CNTCV_LO) == 100): (0 == 100) ERROR + + 70/287 qemu:qtest+qtest-arm / qtest-arm/sse-timer-test ERROR 0.71s killed by signal 6 SIGABRT + +――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― + +stderr: + +** + +ERROR:../tests/qtest/sse-timer-test.c:91:test_counter: assertion failed (readl(COUNTER_BASE + CNTCV_LO) == 100): (0 == 100) + +(test program exited with status code -6) + +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +``` + +https://app.travis-ci.com/github/huth/qemu/jobs/628373181#L6336 : + +``` +>>> G_TEST_DBUS_DAEMON=/home/travis/build/huth/qemu/tests/dbus-vmstate-daemon.sh PYTHON=/home/travis/build/huth/qemu/build/pyvenv/bin/python3 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 QTEST_QEMU_BINARY=./qemu-system-arm MALLOC_PERTURB_=250 MESON_TEST_ITERATION=1 /home/travis/build/huth/qemu/build/tests/qtest/sse-timer-test --tap -k + +▶ 70/287 ERROR:../tests/qtest/sse-timer-test.c:91:test_counter: assertion failed (readl(COUNTER_BASE + CNTCV_LO) == 100): (0 == 100) ERROR + + 70/287 qemu:qtest+qtest-arm / qtest-arm/sse-timer-test ERROR 0.95s killed by signal 6 SIGABRT + +――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― + +stderr: + +** + +ERROR:../tests/qtest/sse-timer-test.c:91:test_counter: assertion failed (readl(COUNTER_BASE + CNTCV_LO) == 100): (0 == 100) + +(test program exited with status code -6) + +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +``` +Steps to reproduce: +1. Run the QEMU CI on Travis +Additional information: +It seems to be a new or intermittent problem, two weeks ago it was still working fine: + +https://app.travis-ci.com/github/huth/qemu/jobs/627999506#L6325 diff --git a/results/classifier/zero-shot/108/all/2718 b/results/classifier/zero-shot/108/all/2718 new file mode 100644 index 000000000..8d981c6ea --- /dev/null +++ b/results/classifier/zero-shot/108/all/2718 @@ -0,0 +1,117 @@ +other: 0.989 +files: 0.986 +graphic: 0.986 +permissions: 0.986 +semantic: 0.979 +device: 0.974 +debug: 0.973 +performance: 0.969 +PID: 0.967 +network: 0.962 +socket: 0.949 +vnc: 0.947 +KVM: 0.937 +boot: 0.926 + +9.2.0 build failure: FAILED: libcommon.a.p/hw_intc_arm_gicv3_its.c.o +Description of problem: +Unable to build 9.2.0 via our docker container based builder inside a ChromeOS M97 based Docker container (using glibc 2.32). +Steps to reproduce: +1. See build logs. (I thought this was a vte issue, but libvte is the current version, `0.78.2`.) +Additional information: +``` +FAILED: libcommon.a.p/hw_intc_arm_gicv3_its.c.o +cc -m64 -Ilibcommon.a.p -I../common-user/host/x86_64 -I../linux-user/include/host/x86_64 -I../linux-user/include -Isubprojects/dtc/libfdt -I../subprojects/dtc/libfdt -Isubprojects/libvduse -I../subprojects/libvduse -I/usr/local/include/p11-kit-1 -I/usr/local/include/pixman-1 -I/usr/local/include/libpng16 -I/usr/local/include/libusb-1.0 -I/usr/local/include/SDL2 -I/usr/local/include/libmount -I/usr/local/include/blkid -I/usr/local/include/glib-2.0 -I/usr/local/lib64/glib-2.0/include -I/usr/local/include/gio-unix-2.0 -I/usr/local/include/slirp -I/usr/local/include/ncursesw -I/usr/local/include/gtk-3.0 -I/usr/local/include/at-spi2-atk/2.0 -I/usr/local/include/at-spi-2.0 -I/usr/local/include/dbus-1.0 -I/usr/local/lib64/dbus-1.0/include -I/usr/local/include/pango-1.0 -I/usr/local/include/harfbuzz -I/usr/local/include/fribidi -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/freetype2 -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/webp -I/usr/local/include/vte-2.91 -I/usr/local/include/pipewire-0.3 -I/usr/local/include/spa-0.2 -flto=auto -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -fstack-protector-strong -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit-fallthrough=2 -Winit-self -Wmissing-format-attribute -Wmissing-prototypes -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wredundant-decls -Wshadow=local -Wstrict-prototypes -Wtype-limits -Wundef -Wvla -Wwrite-strings -Wno-missing-include-dirs -Wno-psabi -Wno-shift-negative-value -isystem /usr/local/tmp/crew/qemu.20241211185452.dir/linux-headers -isystem linux-headers -iquote . -iquote /usr/local/tmp/crew/qemu.20241211185452.dir -iquote /usr/local/tmp/crew/qemu.20241211185452.dir/include -iquote /usr/local/tmp/crew/qemu.20241211185452.dir/host/include/x86_64 -iquote /usr/local/tmp/crew/qemu.20241211185452.dir/host/include/generic -iquote /usr/local/tmp/crew/qemu.20241211185452.dir/tcg/i386 -pthread -mcx16 -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -ftrivial-auto-var-init=zero -fzero-call-used-regs=used-gpr -O3 -pipe -ffat-lto-objects -fPIC -fuse-ld=mold -flto=auto -fPIE -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DNCURSES_WIDECHAR=1 -D_REENTRANT -DSTRUCT_IOVEC_DEFINED -MD -MQ libcommon.a.p/hw_intc_arm_gicv3_its.c.o -MF libcommon.a.p/hw_intc_arm_gicv3_its.c.o.d -o libcommon.a.p/hw_intc_arm_gicv3_its.c.o -c ../hw/intc/arm_gicv3_its.c +In file included from ../hw/intc/trace.h:1, + from ../hw/intc/arm_gicv3_its.c:16: +In function ‘_nocheck__trace_gicv3_its_dte_read’, + inlined from ‘trace_gicv3_its_dte_read’ at trace/trace-hw_intc.h:6634:9, + inlined from ‘get_dte’ at ../hw/intc/arm_gicv3_its.c:312:9, + inlined from ‘process_vmapti’ at ../hw/intc/arm_gicv3_its.c:680:9: +../hw/intc/trace-events:222:13: error: ‘dte.ittaddr’ may be used uninitialized [-Werror=maybe-uninitialized] + 222 | gicv3_its_dte_read(uint32_t devid, int valid, uint32_t size, uint64_t ittaddr) "GICv3 ITS: Device Table read for DeviceID 0x%x: valid %d size 0x%x ITTaddr 0x%" PRIx64 + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../hw/intc/arm_gicv3_its.c: In function ‘process_vmapti’: +../hw/intc/arm_gicv3_its.c:654:13: note: ‘dte.ittaddr’ was declared here + 654 | DTEntry dte; + | ^~~ +In function ‘_nocheck__trace_gicv3_its_dte_read’, + inlined from ‘trace_gicv3_its_dte_read’ at trace/trace-hw_intc.h:6634:9, + inlined from ‘get_dte’ at ../hw/intc/arm_gicv3_its.c:312:9, + inlined from ‘process_vmapti’ at ../hw/intc/arm_gicv3_its.c:680:9: +../hw/intc/trace-events:222:13: error: ‘dte.size’ may be used uninitialized [-Werror=maybe-uninitialized] + 222 | gicv3_its_dte_read(uint32_t devid, int valid, uint32_t size, uint64_t ittaddr) "GICv3 ITS: Device Table read for DeviceID 0x%x: valid %d size 0x%x ITTaddr 0x%" PRIx64 + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../hw/intc/arm_gicv3_its.c: In function ‘process_vmapti’: +../hw/intc/arm_gicv3_its.c:654:13: note: ‘dte.size’ was declared here + 654 | DTEntry dte; + | ^~~ +In function ‘_nocheck__trace_gicv3_its_dte_read’, + inlined from ‘trace_gicv3_its_dte_read’ at trace/trace-hw_intc.h:6634:9, + inlined from ‘get_dte’ at ../hw/intc/arm_gicv3_its.c:312:9, + inlined from ‘process_mapti’ at ../hw/intc/arm_gicv3_its.c:608:9: +../hw/intc/trace-events:222:13: error: ‘dte.ittaddr’ may be used uninitialized [-Werror=maybe-uninitialized] + 222 | gicv3_its_dte_read(uint32_t devid, int valid, uint32_t size, uint64_t ittaddr) "GICv3 ITS: Device Table read for DeviceID 0x%x: valid %d size 0x%x ITTaddr 0x%" PRIx64 + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../hw/intc/arm_gicv3_its.c: In function ‘process_mapti’: +../hw/intc/arm_gicv3_its.c:586:13: note: ‘dte.ittaddr’ was declared here + 586 | DTEntry dte; + | ^~~ +In function ‘_nocheck__trace_gicv3_its_dte_read’, + inlined from ‘trace_gicv3_its_dte_read’ at trace/trace-hw_intc.h:6634:9, + inlined from ‘get_dte’ at ../hw/intc/arm_gicv3_its.c:312:9, + inlined from ‘process_mapti’ at ../hw/intc/arm_gicv3_its.c:608:9: +../hw/intc/trace-events:222:13: error: ‘dte.size’ may be used uninitialized [-Werror=maybe-uninitialized] + 222 | gicv3_its_dte_read(uint32_t devid, int valid, uint32_t size, uint64_t ittaddr) "GICv3 ITS: Device Table read for DeviceID 0x%x: valid %d size 0x%x ITTaddr 0x%" PRIx64 + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../hw/intc/arm_gicv3_its.c: In function ‘process_mapti’: +../hw/intc/arm_gicv3_its.c:586:13: note: ‘dte.size’ was declared here + 586 | DTEntry dte; + | ^~~ +In function ‘lookup_vte’, + inlined from ‘vmovp_callback’ at ../hw/intc/arm_gicv3_its.c:1036:14: +../hw/intc/arm_gicv3_its.c:459:8: error: ‘vte.rdbase’ may be used uninitialized [-Werror=maybe-uninitialized] + 459 | if (vte->rdbase >= s->gicv3->num_cpu) { + | ^ +../hw/intc/arm_gicv3_its.c: In function ‘vmovp_callback’: +../hw/intc/arm_gicv3_its.c:1033:13: note: ‘vte.rdbase’ was declared here + 1033 | VTEntry vte; + | ^~~ +In function ‘_nocheck__trace_gicv3_its_vte_write’, + inlined from ‘trace_gicv3_its_vte_write’ at trace/trace-hw_intc.h:6789:9, + inlined from ‘update_vte’ at ../hw/intc/arm_gicv3_its.c:944:5, + inlined from ‘vmovp_callback’ at ../hw/intc/arm_gicv3_its.c:1051:10: +../hw/intc/trace-events:227:13: error: ‘vte.vptaddr’ may be used uninitialized [-Werror=maybe-uninitialized] + 227 | gicv3_its_vte_write(uint32_t vpeid, int valid, uint32_t vptsize, uint64_t vptaddr, uint32_t rdbase) "GICv3 ITS: vPE Table write for vPEID 0x%x: valid %d VPTsize 0x%x VPTaddr 0x%" PRIx64 " RDbase 0x%x" + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../hw/intc/arm_gicv3_its.c: In function ‘vmovp_callback’: +../hw/intc/arm_gicv3_its.c:1033:13: note: ‘vte.vptaddr’ was declared here + 1033 | VTEntry vte; + | ^~~ +In function ‘_nocheck__trace_gicv3_its_vte_write’, + inlined from ‘trace_gicv3_its_vte_write’ at trace/trace-hw_intc.h:6789:9, + inlined from ‘update_vte’ at ../hw/intc/arm_gicv3_its.c:944:5, + inlined from ‘vmovp_callback’ at ../hw/intc/arm_gicv3_its.c:1051:10: +../hw/intc/trace-events:227:13: error: ‘vte.vptsize’ may be used uninitialized [-Werror=maybe-uninitialized] + 227 | gicv3_its_vte_write(uint32_t vpeid, int valid, uint32_t vptsize, uint64_t vptaddr, uint32_t rdbase) "GICv3 ITS: vPE Table write for vPEID 0x%x: valid %d VPTsize 0x%x VPTaddr 0x%" PRIx64 " RDbase 0x%x" + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../hw/intc/arm_gicv3_its.c: In function ‘vmovp_callback’: +../hw/intc/arm_gicv3_its.c:1033:13: note: ‘vte.vptsize’ was declared here + 1033 | VTEntry vte; + | ^~~ +In function ‘lookup_vte’, + inlined from ‘vmovp_callback’ at ../hw/intc/arm_gicv3_its.c:1036:14: +../hw/intc/arm_gicv3_its.c:453:13: error: ‘MEM <unsigned char> [(struct VTEntry *)&vte]’ may be used uninitialized [-Werror=maybe-uninitialized] + 453 | if (!vte->valid) { + | ~~~^~~~~~~ +../hw/intc/arm_gicv3_its.c: In function ‘vmovp_callback’: +../hw/intc/arm_gicv3_its.c:1033:13: note: ‘MEM <unsigned char> [(struct VTEntry *)&vte]’ was declared here + 1033 | VTEntry vte; + | ^~~ +cc1: all warnings being treated as errors + +``` + +Full Build log: + +[qemu-build-log.zip](/uploads/db227e4a6bbbcfccd0e1e3ccaacf1aec/qemu-build-log.zip) diff --git a/results/classifier/zero-shot/108/all/2731 b/results/classifier/zero-shot/108/all/2731 new file mode 100644 index 000000000..aa0e347da --- /dev/null +++ b/results/classifier/zero-shot/108/all/2731 @@ -0,0 +1,359 @@ +graphic: 0.991 +other: 0.988 +debug: 0.981 +performance: 0.979 +device: 0.977 +permissions: 0.975 +KVM: 0.974 +vnc: 0.972 +semantic: 0.972 +boot: 0.968 +socket: 0.962 +files: 0.959 +PID: 0.957 +network: 0.939 + +test_kvm_xen_guest_novector_noapic sometimes fails +Description of problem: +The test_kvm_xen_guest_novector_noapic test of tests/avocado/kvm_xen_guest.py (soon to be moved to tests/functional/test_x86_64_kvm_xen.py ) is sometimes (maybe 1 time out of 50) failing to boot to the shell prompt. The messages on the serial console are: + +``` +Linux version 6.3.0-rc3-00031-g1e760fa3596e (alex@zen) (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #21 SMP PREEMPT_DYNAMIC Fri Mar 24 15:04:37 GMT 2023 +Command line: printk.time=0 root=/dev/xvda console=ttyS0 xen_emul_unplug=ide-disks xen_no_vector_callback noapic +x86/fpu: x87 FPU will use FXSAVE +signal: max sigframe size: 1440 +BIOS-provided physical RAM map: +BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable +BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved +BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved +BIOS-e820: [mem 0x0000000000100000-0x0000000007fdffff] usable +BIOS-e820: [mem 0x0000000007fe0000-0x0000000007ffffff] reserved +BIOS-e820: [mem 0x00000000feff8000-0x00000000feffffff] reserved +BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved +NX (Execute Disable) protection: active +SMBIOS 2.8 present. +DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 +Hypervisor detected: Xen HVM +Xen version 4.10. +last_pfn = 0x7fe0 max_arch_pfn = 0x400000000 +x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +found SMP MP-table at [mem 0x000f5470-0x000f547f] +ACPI: Early table checksum verification disabled +ACPI: RSDP 0x00000000000F5290 000014 (v00 BOCHS ) +ACPI: RSDT 0x0000000007FE237F 000034 (v01 BOCHS BXPC 00000001 BXPC 00000001) +ACPI: FACP 0x0000000007FE222B 000074 (v01 BOCHS BXPC 00000001 BXPC 00000001) +ACPI: DSDT 0x0000000007FE0040 0021EB (v01 BOCHS BXPC 00000001 BXPC 00000001) +ACPI: FACS 0x0000000007FE0000 000040 +ACPI: APIC 0x0000000007FE229F 000080 (v03 BOCHS BXPC 00000001 BXPC 00000001) +ACPI: HPET 0x0000000007FE231F 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +ACPI: WAET 0x0000000007FE2357 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001) +ACPI: Reserving FACP table memory at [mem 0x7fe222b-0x7fe229e] +ACPI: Reserving DSDT table memory at [mem 0x7fe0040-0x7fe222a] +ACPI: Reserving FACS table memory at [mem 0x7fe0000-0x7fe003f] +ACPI: Reserving APIC table memory at [mem 0x7fe229f-0x7fe231e] +ACPI: Reserving HPET table memory at [mem 0x7fe231f-0x7fe2356] +ACPI: Reserving WAET table memory at [mem 0x7fe2357-0x7fe237e] +Zone ranges: + DMA [mem 0x0000000000001000-0x0000000000ffffff] + DMA32 [mem 0x0000000001000000-0x0000000007fdffff] + Normal empty + Device empty +Movable zone start for each node +Early memory node ranges + node 0: [mem 0x0000000000001000-0x000000000009efff] + node 0: [mem 0x0000000000100000-0x0000000007fdffff] +Initmem setup node 0 [mem 0x0000000000001000-0x0000000007fdffff] +On node 0, zone DMA: 1 pages in unavailable ranges +On node 0, zone DMA: 97 pages in unavailable ranges +On node 0, zone DMA32: 32 pages in unavailable ranges +ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) +ACPI: Skipping IOAPIC probe due to 'noapic' option. +ACPI: Using ACPI for processor (LAPIC) configuration information +ACPI: HPET id: 0x8086a201 base: 0xfed00000 +Intel MultiProcessor Specification v1.4 +MPTABLE: OEM ID: BOCHSCPU +MPTABLE: Product ID: 0.1 +MPTABLE: APIC at: 0xFEE00000 +IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23 +Processors: 2 +smpboot: Allowing 2 CPUs, 0 hotplug CPUs +[mem 0x08000000-0xfeff7fff] available for PCI devices +Booting paravirtualized kernel on Xen HVM +clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns +setup_percpu: NR_CPUS:64 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 +percpu: Embedded 44 pages/cpu s149304 r0 d30920 u1048576 +Built 1 zonelists, mobility grouping on. Total pages: 31968 +Kernel command line: printk.time=0 root=/dev/xvda console=ttyS0 xen_emul_unplug=ide-disks xen_no_vector_callback noapic +Dentry cache hash table entries: 16384 (order: 5, 131072 bytes, linear) +Inode-cache hash table entries: 8192 (order: 4, 65536 bytes, linear) +mem auto-init: stack:off, heap alloc:off, heap free:off +Memory: 102364K/130552K available (12288K kernel code, 1699K rwdata, 3004K rodata, 1040K init, 2632K bss, 27928K reserved, 0K cma-reserved) +SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 +Dynamic Preempt: full +rcu: Preemptible hierarchical RCU implementation. +rcu: RCU event tracing is enabled. +rcu: RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=2. +rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies. +rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2 +NR_IRQS: 4352, nr_irqs: 440, preallocated irqs: 16 +xen:events: Using 2-level ABI +rcu: srcu_init: Setting srcu_struct sizes based on contention. +Console: colour *CGA 80x25 +Cannot get hvm parameter CONSOLE_EVTCHN (18): -22! +printk: console [ttyS0] enabled +ACPI: Core revision 20221020 +ACPI: setting ELCR to 0200 (from 0c00) +clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns +APIC: Switch to symmetric I/O mode setup +Not enabling interrupt remapping due to skipped IO-APIC setup +tsc: Unable to calibrate against PIT +tsc: using HPET reference calibration +tsc: Detected 2496.010 MHz processor +clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x23fa80a809f, max_idle_ns: 440795273818 ns +Calibrating delay loop (skipped), value calculated using timer frequency.. 4992.02 BogoMIPS (lpj=2496010) +pid_max: default: 32768 minimum: 301 +LSM: initializing lsm=capability,yama,integrity,selinux +Yama: becoming mindful. +SELinux: Initializing. +Mount-cache hash table entries: 512 (order: 0, 4096 bytes, linear) +Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes, linear) +Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0 +Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0 +Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +Spectre V2 : Kernel not compiled with retpoline; no mitigation available! +Spectre V2 : Vulnerable +Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +Speculative Store Bypass: Vulnerable +MDS: Vulnerable: Clear CPU buffers attempted, no microcode +MMIO Stale Data: Unknown: No mitigations +Freeing SMP alternatives memory: 24K +APIC timer disabled due to verification failure +smpboot: CPU0: Intel QEMU Virtual CPU version 2.5+ (family: 0xf, model: 0x6b, stepping: 0x1) +Performance Events: unsupported Netburst CPU model 107 no PMU driver, software events only. +rcu: Hierarchical SRCU implementation. +rcu: Max phase no-delay instances is 400. +NMI watchdog: Perf NMI watchdog permanently disabled +smp: Bringing up secondary CPUs ... +x86: Booting SMP configuration: +.... node #0, CPUs: #1 +smp: Brought up 1 node, 2 CPUs +smpboot: Max logical packages: 1 +smpboot: Total of 2 processors activated (9984.04 BogoMIPS) +devtmpfs: initialized +x86/mm: Memory block size: 128MB +clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns +futex hash table entries: 512 (order: 3, 32768 bytes, linear) +PM: RTC time: 12:02:16, date: 2024-12-19 +NET: Registered PF_NETLINK/PF_ROUTE protocol family +audit: initializing netlink subsys (disabled) +audit: type=2000 audit(1734609736.239:1): state=initialized audit_enabled=0 res=1 +thermal_sys: Registered thermal governor 'step_wise' +thermal_sys: Registered thermal governor 'user_space' +cpuidle: using governor ladder +cpuidle: using governor menu +PCI: Using configuration type 1 for base access +HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages +HugeTLB: 28 KiB vmemmap can be freed for a 2.00 MiB page +cryptd: max_cpu_qlen set to 1000 +ACPI: Added _OSI(Module Device) +ACPI: Added _OSI(Processor Device) +ACPI: Added _OSI(3.0 _SCP Extensions) +ACPI: Added _OSI(Processor Aggregator Device) +ACPI: 1 ACPI AML tables successfully acquired and loaded +ACPI: Interpreter enabled +ACPI: PM: (supports S0 S3 S5) +ACPI: Using PIC for interrupt routing +PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug +PCI: Using E820 reservations for host bridge windows +ACPI: Enabled 2 GPEs in block 00 to 0F +ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) +acpi PNP0A03:00: _OSC: OS supports [ASPM ClockPM Segments MSI HPX-Type3] +acpi PNP0A03:00: PCIe port services disabled; not requesting _OSC control +acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended configuration space under this bridge +PCI host bridge to bus 0000:00 +pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +pci_bus 0000:00: root bus resource [mem 0x08000000-0xfebfffff window] +pci_bus 0000:00: root bus resource [mem 0x100000000-0x17fffffff window] +pci_bus 0000:00: root bus resource [bus 00-ff] +pci 0000:00:00.0: [8086:1237] type 00 class 0x060000 +pci 0000:00:01.0: [8086:7000] type 00 class 0x060100 +pci 0000:00:01.1: [8086:7010] type 00 class 0x010180 +pci 0000:00:01.1: reg 0x20: [io 0xc120-0xc12f] +pci 0000:00:01.1: legacy IDE quirk: reg 0x10: [io 0x01f0-0x01f7] +pci 0000:00:01.1: legacy IDE quirk: reg 0x14: [io 0x03f6] +pci 0000:00:01.1: legacy IDE quirk: reg 0x18: [io 0x0170-0x0177] +pci 0000:00:01.1: legacy IDE quirk: reg 0x1c: [io 0x0376] +pci 0000:00:01.3: [8086:7113] type 00 class 0x068000 +pci 0000:00:01.3: quirk: [io 0x0600-0x063f] claimed by PIIX4 ACPI +pci 0000:00:01.3: quirk: [io 0x0700-0x070f] claimed by PIIX4 SMB +pci 0000:00:02.0: [5853:0001] type 00 class 0xff8000 +pci 0000:00:02.0: reg 0x10: [io 0xc000-0xc0ff] +pci 0000:00:02.0: reg 0x14: [mem 0xfd000000-0xfdffffff pref] +pci 0000:00:03.0: [1af4:1000] type 00 class 0x020000 +pci 0000:00:03.0: reg 0x10: [io 0xc100-0xc11f] +pci 0000:00:03.0: reg 0x14: [mem 0xfebc0000-0xfebc0fff] +pci 0000:00:03.0: reg 0x20: [mem 0xfe000000-0xfe003fff 64bit pref] +pci 0000:00:03.0: reg 0x30: [mem 0xfeb80000-0xfebbffff pref] +ACPI: PCI: Interrupt link LNKA configured for IRQ 10 +ACPI: PCI: Interrupt link LNKB configured for IRQ 10 +ACPI: PCI: Interrupt link LNKC configured for IRQ 11 +ACPI: PCI: Interrupt link LNKD configured for IRQ 11 +ACPI: PCI: Interrupt link LNKS configured for IRQ 9 +xen:balloon: Initialising balloon driver +iommu: Default domain type: Translated +iommu: DMA domain TLB invalidation policy: lazy mode +SCSI subsystem initialized +ACPI: bus type USB registered +usbcore: registered new interface driver usbfs +usbcore: registered new interface driver hub +usbcore: registered new device driver usb +pps_core: LinuxPPS API ver. 1 registered +pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> +PTP clock support registered +Advanced Linux Sound Architecture Driver Initialized. +PCI: Using ACPI for IRQ routing +hpet: 3 channels of 0 reserved for per-cpu timers +clocksource: Switched to clocksource tsc-early +FS-Cache: Loaded +pnp: PnP ACPI init +pnp: PnP ACPI: found 6 devices +NET: Registered PF_INET protocol family +IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear) +tcp_listen_portaddr_hash hash table entries: 128 (order: 0, 4096 bytes, linear) +Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear) +TCP established hash table entries: 1024 (order: 1, 8192 bytes, linear) +TCP bind hash table entries: 1024 (order: 4, 65536 bytes, linear) +TCP: Hash tables configured (established 1024 bind 1024) +UDP hash table entries: 256 (order: 2, 24576 bytes, linear) +UDP-Lite hash table entries: 256 (order: 2, 24576 bytes, linear) +NET: Registered PF_UNIX/PF_LOCAL protocol family +RPC: Registered named UNIX socket transport module. +RPC: Registered udp transport module. +RPC: Registered tcp transport module. +RPC: Registered tcp NFSv4.1 backchannel transport module. +pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window] +pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window] +pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] +pci_bus 0000:00: resource 7 [mem 0x08000000-0xfebfffff window] +pci_bus 0000:00: resource 8 [mem 0x100000000-0x17fffffff window] +pci 0000:00:01.0: PIIX3: Enabling Passive Release +pci 0000:00:00.0: Limiting direct PCI/PCI transfers +PCI: CLS 0 bytes, default 64 +kvm_intel: VMX not supported by CPU 0 +workingset: timestamp_bits=46 max_order=15 bucket_order=0 +squashfs: version 4.0 (2009/01/31) Phillip Lougher +fuse: init (API version 7.38) +9p: Installing v9fs 9p2000 file system support +Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245) +io scheduler mq-deadline registered +io scheduler kyber registered +ACPI: \_SB_.LNKC: Enabled at IRQ 11 +xen:xen_evtchn: Event-channel device installed +ACPI: \_SB_.LNKB: Enabled at IRQ 10 +xen:grant_table: Grant tables using version 1 layout +Grant table initialized +Cannot get hvm parameter CONSOLE_EVTCHN (18): -22! +Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled +00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A +Non-volatile memory driver v1.3 +ACPI: bus type drm_connector registered +loop: module loaded +Invalid max_queues (4), will use default max: 2. +tun: Universal TUN/TAP device driver, 1.6 +e100: Intel(R) PRO/100 Network Driver +e100: Copyright(c) 1999-2006 Intel Corporation +e1000: Intel(R) PRO/1000 Network Driver +e1000: Copyright (c) 1999-2006 Intel Corporation. +e1000e: Intel(R) PRO/1000 Network Driver +e1000e: Copyright(c) 1999 - 2015 Intel Corporation. +igb: Intel(R) Gigabit Ethernet Network Driver +igb: Copyright (c) 2007-2014 Intel Corporation. +igbvf: Intel(R) Gigabit Virtual Function Network Driver +igbvf: Copyright (c) 2009 - 2012 Intel Corporation. +VMware vmxnet3 virtual NIC driver - version 1.7.0.0-k-NAPI +xen_netfront: Initialising Xen virtual ethernet driver +usbcore: registered new interface driver cdc_ether +usbcore: registered new interface driver cdc_eem +usbcore: registered new interface driver cdc_ncm +usbcore: registered new interface driver r8153_ecm +usbcore: registered new interface driver cdc_acm +cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters +usbcore: registered new interface driver usb-storage +usbcore: registered new interface driver usbserial_generic +usbserial: USB Serial support registered for generic +usbcore: registered new interface driver ch341 +usbserial: USB Serial support registered for ch341-uart +usbcore: registered new interface driver cp210x +usbserial: USB Serial support registered for cp210x +usbcore: registered new interface driver ftdi_sio +usbserial: USB Serial support registered for FTDI USB Serial Device +usbcore: registered new interface driver keyspan +usbserial: USB Serial support registered for Keyspan - (without firmware) +usbserial: USB Serial support registered for Keyspan 1 port adapter +usbserial: USB Serial support registered for Keyspan 2 port adapter +usbserial: USB Serial support registered for Keyspan 4 port adapter +usbcore: registered new interface driver pl2303 +usbserial: USB Serial support registered for pl2303 +usbcore: registered new interface driver usb_serial_simple +usbserial: USB Serial support registered for carelink +usbserial: USB Serial support registered for zio +usbserial: USB Serial support registered for funsoft +usbserial: USB Serial support registered for flashloader +usbserial: USB Serial support registered for google +usbserial: USB Serial support registered for libtransistor +usbserial: USB Serial support registered for vivopay +usbserial: USB Serial support registered for moto_modem +usbserial: USB Serial support registered for motorola_tetra +usbserial: USB Serial support registered for nokia +usbserial: USB Serial support registered for novatel_gps +usbserial: USB Serial support registered for hp4x +usbserial: USB Serial support registered for suunto +usbserial: USB Serial support registered for siemens_mpi +rtc_cmos 00:05: RTC can wake from S4 +rtc_cmos 00:05: registered as rtc0 +rtc_cmos 00:05: alarms up to one day, y3k, 242 bytes nvram, hpet irqs +fail to initialize ptp_kvm +intel_pstate: CPU model not supported +usbcore: registered new interface driver usbhid +usbhid: USB HID core driver +GACT probability NOT on +xt_time: kernel timezone is -0000 +IPVS: Registered protocols (TCP, UDP) +IPVS: Connection hash table configured (size=4096, memory=32Kbytes) +IPVS: ipvs loaded. +IPVS: [rr] scheduler registered. +Initializing XFRM netlink socket +NET: Registered PF_INET6 protocol family +Segment Routing with IPv6 +In-situ OAM (IOAM) with IPv6 +NET: Registered PF_PACKET protocol family +8021q: 802.1Q VLAN Support v1.8 +9pnet: Installing 9P2000 support +NET: Registered PF_VSOCK protocol family +IPI shorthand broadcast: enabled +sched_clock: Marking stable (402156364, -4933103)->(420983909, -23760648) +Clockevents: could not switch to one-shot mode: lapic is not functional. +Could not switch to high resolution mode on CPU 0 +Clockevents: could not switch to one-shot mode: lapic is not functional. +Could not switch to high resolution mode on CPU 1 +tsc: Refined TSC clocksource calibration: 2495.955 MHz +clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x23fa4cd42c8, max_idle_ns: 440795310990 ns +clocksource: Switched to clocksource tsc +Clockevents: could not switch to one-shot mode: lapic is not functional. +Could not switch to high resolution mode on CPU 1 +Clockevents: could not switch to one-shot mode: lapic is not functional. +Could not switch to high resolution mode on CPU 0 +xenbus_probe_frontend: Waiting for devices to initialise: 25s...20s...15s... +random: crng init done +10s...5s...0s... +``` +Steps to reproduce: +Either run the mentioned avocado/functional test, or directly the mentioned QEMU command line >= 50 times +Additional information: +I think it reproduces more easily if the host machine is under load (not quite sure about it, though). + +See this discussion on the mailing list for some more details: + +https://lore.kernel.org/qemu-devel/999a8203f0c800f1305aacdb500dbf6038ebf147.camel@infradead.org/ diff --git a/results/classifier/zero-shot/108/all/2934 b/results/classifier/zero-shot/108/all/2934 new file mode 100644 index 000000000..b957a52f3 --- /dev/null +++ b/results/classifier/zero-shot/108/all/2934 @@ -0,0 +1,79 @@ +permissions: 0.960 +other: 0.942 +debug: 0.936 +semantic: 0.931 +device: 0.929 +KVM: 0.928 +socket: 0.928 +network: 0.928 +files: 0.927 +graphic: 0.926 +vnc: 0.918 +PID: 0.914 +performance: 0.912 +boot: 0.902 + +RSS eBPF failed to load +Description of problem: +I am seeing a failure to load the eBPF program for rss steering. +Steps to reproduce: +1. Using libvirt, enable rss='on' for the vhost driver. +2. +3. +Additional information: +Libvirt log: +``` +libbpf: prog 'tun_rss_steering_prog': BPF program load failed: Invalid argument +libbpf: prog 'tun_rss_steering_prog': -- BEGIN PROG LOAD LOG -- +back-edge from insn 587 to 501 +processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 +-- END PROG LOAD LOG -- +libbpf: prog 'tun_rss_steering_prog': failed to load: -22 +libbpf: failed to load object 'rss_bpf' +libbpf: failed to load BPF skeleton 'rss_bpf': -22 +2025-04-26T09:22:19.054471Z qemu-system-x86_64: -device {"driver":"virtio-net-pci","packed":true,"tx":"bh","ioeventfd":true,"event_idx":true,"host_ecn":true,"mrg_rxbuf":true,"guest_ecn":true,"mq":true,"vectors":14,"rx_queue_size":1024,"tx_queue_size":256,"rss":true,"netdev":"hostnet0","id":"net0","mac":"52:54:00:c3:6f:c2","bus":"pci.1","addr":"0x0"}: warning: Unable to load eBPF program +``` +[qemu-log.txt](/uploads/2d5e49a38a54297586a4b1f16423fc27/qemu-log.txt) + +XML: +```xml + <interface type='bridge'> + <mac address='52:54:00:be:49:ff'/> + <source bridge='inet'/> + <model type='virtio'/> + <driver name='vhost' txmode='iothread' ioeventfd='on' event_idx='on' queues='6' rx_queue_size='1024' tx_queue_size='256' rss='on' packed='on'> + <host ecn='on' mrg_rxbuf='on'/> + <guest ecn='on'/> + </driver> + <link state='up'/> + <address type='pci' domain='0x0000' bus='0x08' slot='0x00' function='0x0'/> + </interface> +``` + +Host kernel .config: +``` +❯ zcat /proc/config.gz |grep -i bpf +CONFIG_BPF=y +CONFIG_HAVE_EBPF_JIT=y +CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y +# BPF subsystem +CONFIG_BPF_SYSCALL=y +CONFIG_BPF_JIT=y +CONFIG_BPF_JIT_ALWAYS_ON=y +CONFIG_BPF_JIT_DEFAULT_ON=y +CONFIG_BPF_UNPRIV_DEFAULT_OFF=y +# CONFIG_BPF_PRELOAD is not set +# CONFIG_BPF_LSM is not set +# end of BPF subsystem +CONFIG_CGROUP_BPF=y +CONFIG_NETFILTER_BPF_LINK=y +CONFIG_NETFILTER_XT_MATCH_BPF=m +CONFIG_NET_CLS_BPF=m +CONFIG_NET_ACT_BPF=m +CONFIG_BPF_STREAM_PARSER=y +CONFIG_LWTUNNEL_BPF=y +# HID-BPF support +CONFIG_HID_BPF=y +# end of HID-BPF support +CONFIG_BPF_EVENTS=y +``` diff --git a/results/classifier/zero-shot/108/all/51610399 b/results/classifier/zero-shot/108/all/51610399 new file mode 100644 index 000000000..2e420e72d --- /dev/null +++ b/results/classifier/zero-shot/108/all/51610399 @@ -0,0 +1,318 @@ +permissions: 0.988 +debug: 0.986 +boot: 0.986 +graphic: 0.986 +other: 0.985 +semantic: 0.984 +device: 0.984 +performance: 0.983 +files: 0.981 +PID: 0.978 +socket: 0.978 +KVM: 0.975 +vnc: 0.974 +network: 0.973 + +[BUG][powerpc] KVM Guest Boot Failure – Hangs at "Booting Linux via __start()” + +Bug Description: +Encountering a boot failure when launching a KVM guest with +qemu-system-ppc64. The guest hangs at boot, and the QEMU monitor +crashes. +Reproduction Steps: +# qemu-system-ppc64 --version +QEMU emulator version 9.2.50 (v9.2.0-2799-g0462a32b4f) +Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers +# /usr/bin/qemu-system-ppc64 -name avocado-vt-vm1 -machine +pseries,accel=kvm \ +-m 32768 -smp 32,sockets=1,cores=32,threads=1 -nographic \ + -device virtio-scsi-pci,id=scsi \ +-drive +file=/home/kvmci/tests/data/avocado-vt/images/rhel8.0devel-ppc64le.qcow2,if=none,id=drive0,format=qcow2 +\ +-device scsi-hd,drive=drive0,bus=scsi.0 \ + -netdev bridge,id=net0,br=virbr0 \ + -device virtio-net-pci,netdev=net0 \ + -serial pty \ + -device virtio-balloon-pci \ + -cpu host +QEMU 9.2.50 monitor - type 'help' for more information +char device redirected to /dev/pts/2 (label serial0) +(qemu) +(qemu) qemu-system-ppc64: warning: kernel_irqchip allowed but +unavailable: IRQ_XIVE capability must be present for KVM +Falling back to kernel-irqchip=off +** Qemu Hang + +(In another ssh session) +# screen /dev/pts/2 +Preparing to boot Linux version 6.10.4-200.fc40.ppc64le +(mockbuild@c23cc4e677614c34bb22d54eeea4dc1f) (gcc (GCC) 14.2.1 20240801 +(Red Hat 14.2.1-1), GNU ld version 2.41-37.fc40) #1 SMP Sun Aug 11 +15:20:17 UTC 2024 +Detected machine type: 0000000000000101 +command line: +BOOT_IMAGE=(ieee1275/disk,msdos2)/vmlinuz-6.10.4-200.fc40.ppc64le +root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root crashkernel=1024M +Max number of cores passed to firmware: 2048 (NR_CPUS = 2048) +Calling ibm,client-architecture-support... done +memory layout at init: + memory_limit : 0000000000000000 (16 MB aligned) + alloc_bottom : 0000000008200000 + alloc_top : 0000000030000000 + alloc_top_hi : 0000000800000000 + rmo_top : 0000000030000000 + ram_top : 0000000800000000 +instantiating rtas at 0x000000002fff0000... done +prom_hold_cpus: skipped +copying OF device tree... +Building dt strings... +Building dt structure... +Device tree strings 0x0000000008210000 -> 0x0000000008210bd0 +Device tree struct 0x0000000008220000 -> 0x0000000008230000 +Quiescing Open Firmware ... +Booting Linux via __start() @ 0x0000000000440000 ... +** Guest Console Hang + + +Git Bisect: +Performing git bisect points to the following patch: +# git bisect bad +e8291ec16da80566c121c68d9112be458954d90b is the first bad commit +commit e8291ec16da80566c121c68d9112be458954d90b (HEAD) +Author: Nicholas Piggin <npiggin@gmail.com> +Date: Thu Dec 19 13:40:31 2024 +1000 + + target/ppc: fix timebase register reset state +(H)DEC and PURR get reset before icount does, which causes them to +be +skewed and not match the init state. This can cause replay to not +match the recorded trace exactly. For DEC and HDEC this is usually +not +noticable since they tend to get programmed before affecting the + target machine. PURR has been observed to cause replay bugs when + running Linux. + + Fix this by resetting using a time of 0. + + Message-ID: <20241219034035.1826173-2-npiggin@gmail.com> + Signed-off-by: Nicholas Piggin <npiggin@gmail.com> + + hw/ppc/ppc.c | 11 ++++++++--- + 1 file changed, 8 insertions(+), 3 deletions(-) + + +Reverting the patch helps boot the guest. +Thanks, +Misbah Anjum N + +Thanks for the report. + +Tricky problem. A secondary CPU is hanging before it is started by the +primary via rtas call. + +That secondary keeps calling kvm_cpu_exec(), which keeps exiting out +early with EXCP_HLT because kvm_arch_process_async_events() returns +true because that cpu has ->halted=1. That just goes around he run +loop because there is an interrupt pending (DEC). + +So it never runs. It also never releases the BQL, and another CPU, +the primary which is actually supposed to be running, is stuck in +spapr_set_all_lpcrs() in run_on_cpu() waiting for the BQL. + +This patch just exposes the bug I think, by causing the interrupt. +although I'm not quite sure why it's okay previously (-ve decrementer +values should be causing a timer exception too). The timer exception +should not be taken as an interrupt by those secondary CPUs, and it +doesn't because it is masked, until set_all_lpcrs sets an LPCR value +that enables powersave wakeup on decrementer interrupt. + +The start_powered_off sate just sets ->halted, which makes it look +like a powersaving state. Logically I think it's not the same thing +as far as spapr goes. I don't know why start_powered_off only sets +->halted, and not ->stop/stopped as well. + +Not sure how best to solve it cleanly. I'll send a revert if I can't +get something working soon. + +Thanks, +Nick + +On Tue Mar 18, 2025 at 7:09 AM AEST, misanjum wrote: +> +Bug Description: +> +Encountering a boot failure when launching a KVM guest with +> +qemu-system-ppc64. The guest hangs at boot, and the QEMU monitor +> +crashes. +> +> +> +Reproduction Steps: +> +# qemu-system-ppc64 --version +> +QEMU emulator version 9.2.50 (v9.2.0-2799-g0462a32b4f) +> +Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers +> +> +# /usr/bin/qemu-system-ppc64 -name avocado-vt-vm1 -machine +> +pseries,accel=kvm \ +> +-m 32768 -smp 32,sockets=1,cores=32,threads=1 -nographic \ +> +-device virtio-scsi-pci,id=scsi \ +> +-drive +> +file=/home/kvmci/tests/data/avocado-vt/images/rhel8.0devel-ppc64le.qcow2,if=none,id=drive0,format=qcow2 +> +> +\ +> +-device scsi-hd,drive=drive0,bus=scsi.0 \ +> +-netdev bridge,id=net0,br=virbr0 \ +> +-device virtio-net-pci,netdev=net0 \ +> +-serial pty \ +> +-device virtio-balloon-pci \ +> +-cpu host +> +QEMU 9.2.50 monitor - type 'help' for more information +> +char device redirected to /dev/pts/2 (label serial0) +> +(qemu) +> +(qemu) qemu-system-ppc64: warning: kernel_irqchip allowed but +> +unavailable: IRQ_XIVE capability must be present for KVM +> +Falling back to kernel-irqchip=off +> +** Qemu Hang +> +> +(In another ssh session) +> +# screen /dev/pts/2 +> +Preparing to boot Linux version 6.10.4-200.fc40.ppc64le +> +(mockbuild@c23cc4e677614c34bb22d54eeea4dc1f) (gcc (GCC) 14.2.1 20240801 +> +(Red Hat 14.2.1-1), GNU ld version 2.41-37.fc40) #1 SMP Sun Aug 11 +> +15:20:17 UTC 2024 +> +Detected machine type: 0000000000000101 +> +command line: +> +BOOT_IMAGE=(ieee1275/disk,msdos2)/vmlinuz-6.10.4-200.fc40.ppc64le +> +root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root crashkernel=1024M +> +Max number of cores passed to firmware: 2048 (NR_CPUS = 2048) +> +Calling ibm,client-architecture-support... done +> +memory layout at init: +> +memory_limit : 0000000000000000 (16 MB aligned) +> +alloc_bottom : 0000000008200000 +> +alloc_top : 0000000030000000 +> +alloc_top_hi : 0000000800000000 +> +rmo_top : 0000000030000000 +> +ram_top : 0000000800000000 +> +instantiating rtas at 0x000000002fff0000... done +> +prom_hold_cpus: skipped +> +copying OF device tree... +> +Building dt strings... +> +Building dt structure... +> +Device tree strings 0x0000000008210000 -> 0x0000000008210bd0 +> +Device tree struct 0x0000000008220000 -> 0x0000000008230000 +> +Quiescing Open Firmware ... +> +Booting Linux via __start() @ 0x0000000000440000 ... +> +** Guest Console Hang +> +> +> +Git Bisect: +> +Performing git bisect points to the following patch: +> +# git bisect bad +> +e8291ec16da80566c121c68d9112be458954d90b is the first bad commit +> +commit e8291ec16da80566c121c68d9112be458954d90b (HEAD) +> +Author: Nicholas Piggin <npiggin@gmail.com> +> +Date: Thu Dec 19 13:40:31 2024 +1000 +> +> +target/ppc: fix timebase register reset state +> +> +(H)DEC and PURR get reset before icount does, which causes them to +> +be +> +skewed and not match the init state. This can cause replay to not +> +match the recorded trace exactly. For DEC and HDEC this is usually +> +not +> +noticable since they tend to get programmed before affecting the +> +target machine. PURR has been observed to cause replay bugs when +> +running Linux. +> +> +Fix this by resetting using a time of 0. +> +> +Message-ID: <20241219034035.1826173-2-npiggin@gmail.com> +> +Signed-off-by: Nicholas Piggin <npiggin@gmail.com> +> +> +hw/ppc/ppc.c | 11 ++++++++--- +> +1 file changed, 8 insertions(+), 3 deletions(-) +> +> +> +Reverting the patch helps boot the guest. +> +Thanks, +> +Misbah Anjum N + diff --git a/results/classifier/zero-shot/108/all/545089 b/results/classifier/zero-shot/108/all/545089 new file mode 100644 index 000000000..01b682d9c --- /dev/null +++ b/results/classifier/zero-shot/108/all/545089 @@ -0,0 +1,89 @@ +other: 0.965 +graphic: 0.963 +semantic: 0.962 +network: 0.959 +device: 0.958 +permissions: 0.955 +debug: 0.952 +socket: 0.949 +PID: 0.946 +vnc: 0.946 +boot: 0.941 +performance: 0.932 +files: 0.928 +KVM: 0.926 + +qemu-img should be able to create scsi based vmdk images + +qemu-img can create vmdk disk images. These are always created as "ide" disks; that is, the paramter ddb.adapterType is set to "ide" in the .vmdk file. + +I needed to create a scsi style vmdk image, in which ddb.adapterType is set to "lsilogic". + +The attached patch (against qemu-0.12.3) allows me to convert a raw image into a scsi vmdk image: + + qemu-img convert -O vmdk -o scsi rootfs.raw rootfs.vmdk + +The "scsi" option works also for the "create" command. + +I hope very much that this change can be rolled into qemu. + +best, + +Seb James + + + +This has been presented on qemu-devel before. We didn't feel this was appropriate for qemu because 1) it's an invasive change 2) these images are not useful when using qemu--only useful for creating images for use with VMware. + +I'll leave this as wishlist, but at this time, we're not interested in supporting this feature. + +So it has - by Soren Hansen: http://<email address hidden>/msg15054.html + +In what sense is the change invasive, in your opinion? It seems like a fairly minor addition of a command line option to me. + +I, at least, find this patch very useful. My company builds network print appliances and our build scripts use qemu-img to create both qcow2 images for Linux KVM/qemu platforms and also vmdk disk images for those of our customers who insist on using vmware ;) + +Thanks for your reply. + +Block flags are a limited space. We should have never taken the COMPAT6 support for the same reason. + +If the change could be entirely contained to the vmdk driver, it would be more palatable. + +Thanks for the explanation. There's an int for the block flags, so I guess there are nominally 32 flags available and 3 in use (including the compat6 flag)... unless qemu-img needs to be compilable on 16 or 8 bit machines? + +It looks like a fair amount of work to make this change entirely contained in the vmdk driver. I'll continue to maintain the patch against qemu. + +Those of us who have vmdk images bestowed upon us and would prefer to run them under qemu would very like to have a way to convert the images in both directions. + +On Wed, Nov 9, 2011 at 1:09 AM, Rob White <email address hidden> wrote: +> The attached patch (against qemu-0.12.3) allows me to convert a raw +> image into a scsi vmdk image: +> +> qemu-img convert -O vmdk -o scsi rootfs.raw rootfs.vmdk + +Please rebase onto qemu.git/master. + +Please see this wiki page on how to submit patches to QEMU: +http://wiki.qemu.org/Contribute/SubmitAPatch + +Stefan + + +Modern qemu has this and more: +qemu-img convert -O vmdk -o ? source dest.vmdk +Supported options: +size Virtual disk size +adapter_type Virtual adapter type, can be one of ide (default), lsilogic, buslogic or legacyESX +backing_file File name of a base image +compat6 VMDK version 6 image +subformat VMDK flat extent format, can be one of {monolithicSparse (default) | monolithicFlat | twoGbMaxExtentSparse | twoGbMaxExtentFlat | streamOptimized} +zeroed_grain Enable efficient zero writes using the zeroed-grain GTE feature + +So perhaps this patch went mainstream after all? + +This seems to be fixed by this commit here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7f2039f61113f11be9211 +==> Setting status to "Fix released" + +Great news! + diff --git a/results/classifier/zero-shot/108/all/586175 b/results/classifier/zero-shot/108/all/586175 new file mode 100644 index 000000000..580f9260d --- /dev/null +++ b/results/classifier/zero-shot/108/all/586175 @@ -0,0 +1,462 @@ +debug: 0.952 +boot: 0.951 +permissions: 0.951 +device: 0.951 +performance: 0.949 +graphic: 0.949 +other: 0.949 +files: 0.948 +vnc: 0.945 +socket: 0.944 +semantic: 0.944 +PID: 0.942 +KVM: 0.939 +network: 0.936 + +Windows XP/2003 doesn't boot + +Hello everyone, + +my qemu doesn't boot any Windows XP/2003 installations if I try to boot the image. +If I boot the install cd first, it's boot manager counts down and triggers the boot on it's own. That's kinda stupid. + +I'm using libvirt, but even by a simple +> qemu-kvm -drive file=image.img,media=disk,if=ide,boot=on +it won't boot. Qemu hangs at the message "Booting from Hard Disk..." + +I'm using qemu-kvm-0.12.4 with SeaBIOS 0.5.1 on Gentoo (No-Multilib and AMD64). It's a server, that means I'm using VNC as the primary graphic output but i don't think it should be an issue. + +There's a fedora rawhide bug about this as well: + +https://bugzilla.redhat.com/show_bug.cgi?id=579348 + +Which points to a qemu-devel posting talking about disk geometry confusion: + +http://article.gmane.org/gmane.comp.emulators.qemu/66135 + +Can someone try to reproduce this without ,boot=on? + +It's possible that extboot is screwing up the disk geometry. + +I don't have any problem using TCG. + +Tested with Windows XP Home Update in 0.12.4 and Windows 2003 Enterprise Server in 0.12.3. + +It's a very strange bug. + +Starting qemu without boot=on results in the same dilemma. + +But: I've used a .vdi image (because qcow2 is terribly slow). +Just now I tried a raw image. Now I can boot neither directly from the image nor with the install cd. Both ways boot finally NTLDR, but now the loader has a problem with the drive. (I don't know how this message is called in the english version, but the german version says: "An error occurred while reading the drive. Restart with Ctrl+Alt+Del.") + +Now I'll try to install Windows Server 2008 R2... + +Can someone post the exact qemu command line that gets generated so we can test without libvirt? + +Do you mean, I should try to install and boot Win2k3 without libvirt? + +If I install Windows through libvirt and boot it with a simple command line like +> qemu-kvm -hda /someimage.img -enable-kvm +it doesn't boot. + +It's in fact this bug, just like Cole meant: +https://bugzilla.redhat.com/show_bug.cgi?id=579348 + +Also interesting, if I use a raw image instead of a vdi image, the workaround (booting the install cd and let it hand over to the installed windows) doesn't work anymore. + +Now I'll set up another machine with gentoo and try all combinations of image file types, Windozes (< NT 6.0) and qemu options and I'll report the results. + +It sounds like this is an existing image that you can't boot from. I can create a new 2k3 VM with upstream qemu and boot it again after install with no issues. So I'm wondering if you can also do this. If so, then something happened to your existing image (maybe some sort of corruption of the boot sector ?). + +I can reproduce with qemu-kvm 0.12.4 like the original reporter. I cannot reproduce with qemu-kvm upstream, qemu stable, or qemu upstream. So boot=on could be the culprit. Libvirt generated command line: + +LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -S -M pc-0.12 -no-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name winxp_test -uuid 634dff56-8c5a-fdbb-b5fc-091bcf78e586 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/winxp_test.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=localtime -boot c -drive file=/var/lib/libvirt/images/winxp_test.img,if=none,id=drive-ide0-0-0,boot=on,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/mnt/data/media/win_xp_sp3_32.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -device rtl8139,vlan=0,id=net0,mac=52:54:00:ac:e8:ca,bus=pci.0,addr=0x4 -net tap,fd=20,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:1 -k en-us -vga std -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 + +Markus has a patch internally against an older qemu-kvm release that apparently fixes the issue, however the upstream code is different so it doesn't cleanly apply. Maybe this will give someone a hint for a proper upstream solution: + + hw/pc.c | 4 ++++ + 1 files changed, 4 insertions(+), 0 deletions(-) + +diff --git a/hw/pc.c b/hw/pc.c +index d142282..c60a79a 100644 +--- a/hw/pc.c ++++ b/hw/pc.c +@@ -271,12 +271,16 @@ static void cmos_init(ram_addr_t ram_size, ram_addr_t above_4g_mem_size, + */ + for (i = 0; i < 4; i++) { + char id[32]; ++ int cylinders, heads, secs; + + if (hd_table[i]) + continue; + snprintf(id, sizeof(id), "drive-ide0-%d-%d", + i / MAX_IDE_DEVS, i % MAX_IDE_DEVS); + hd_table[i] = drive_get_by_id(id); ++ if (hd_table[i]) { ++ bdrv_guess_geometry(hd_table[i]->bdrv, &cylinders, &heads, &secs); ++ } + } + + /* various important CMOS locations needed by PC/Bochs bios */ + + + +Long time no post, i tried to install Win2k3 through RIS/PXE this time. I still get the same error at boot time: "A disk read error occurred. Press Ctrl + Alt + Del to restart". + +Neither the Win2k3 install source nor the VirtIO drivers are defective. Something's just wrong with QEMU. + +Currently qemu.git is able to compile itself properly, so I'll check it out. Without libvirt (because it can't parse "qemu-kvm-devel" as version string :/ https://bugzilla.redhat.com/show_bug.cgi?id=609741 ) + +Ran into this problem today with fresh Windows 2003 R2 install on a IDE boot drive. Because the CD-ROM boot bypasses this problem the install completes just fine, until I tell it to boot from the hard disk (via libvirt). + +Latest available packages from Debian testing; + +qemu 0.12.4+dfsg-3 +qemu-kvm 0.12.4+dfsg-1 +qemu-system 0.12.4+dfsg-3 +qemu-user 0.12.4+dfsg-3 +qemu-utils 0.12.4+dfsg-3 +seabios 0.5.1-3 + +The only thing I've been able to find so far is an odd character in the SeaBIOS string when booting from the hard disk, which isn't there when booting from the CD-ROM image. + +I agree to #10. Today I installed qemu-kvm-0.12.4-r3 and I still can't boot Windows XP/2003 without booting the install cd at first. + +But now: After I tried to boot the Windows installation I get the same odd char in the screen as described by #10. Plus, I can install Windows without problems, but it doesn't boot AFTER the setup, whether I use IDE or VirtIO as hard disk bus. + +Ergo: Booting from install cd, the setup copies the files on the hard disk, reboot, booting from hard disk, the setup installs Windows, reboot, and then: it hangs. Seems to be an BIOS issue. + +P.S.: Of course I can't boot Windows XP/2003 from a VirtIO drive at all, because the install cd only checks the IDE bus for an existing Windows installation... + +I'm not sure all experience the same as me, but it may be worth having a look at the workaround I found, described here : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579166#17 + +Hth. + +I have to correct myself. + +Booting from Windows XP/2003 after the first reboot of the Windows setup is still impossible (without booting from the install CD at first). + +I tried both the command line used by libvirt and the following one: + +> qemu-kvm -hda thisfile -cdrom thatfile -boot c + +Also, I tested these command lines on qemu-kvm-0.12.4, qemu-kvm-0.12.4-r3 and qemu.git with SeaBIOS 0.5.1, 0.6.0 and seabios.git respectively. Windows always hangs at boot time. (But Windows Server 2008 R2 boots up. I assume Windows 7 and Vista will do fine as well.) + +I have this problem as well. I'm installing using a slightly different situation -- I'm restoring a WinXP/Win2k3 backup that was made with fsarchiver -- but essentially I run across the same issue namely that boot fails when mbr tries to boot the first partition. In my case I use install-mbr from the mbr package but have also tried to install the windows mbr from the boot cd without success. Here are the steps I've taken and the partial fix I've discovered. + +First, let me say that these steps worked perfectly in 9.10. In fact, I can move the raw image from 9.10 to 10.04 and boot it without problem. That was initially how I got these restores to work; I installed on a Karmic laptop and moved the raw image to Lucid. + +Install Notes: + +Install Procedure (for karmic or lucid): + +1. boot system to image to rescuecd and backup xp or win2k3 using fsarchiver: + fsarchiver savefs /some/remote/location/win.fsa /dev/sda1 +2. on kvm host create restore disk: + lvcreate -L10GB -n win vg +3. boot virt with rescuecd + kvm -m 1024 -cdrom rescuecd.iso -hda /dev/vg/win -boot d +3. partition disk (entire disk, one partition, active): + fdisk /dev/sda + commands: o n p 1 [] [] t 7 a 1 w +4. restore archive: + fsarchiver restfs win.fsa id=0,dest=/dev/mapper/vg-winp1 +5. install mbr: + install-mbr /dev/sda +6. halt virt and reboot to image: + kvm -m 1024 -hda /dev/vg/win + +At this point, the image will boot in 9.10. But following the same steps in lucid it will hang after the mbr boots the first partition. + +I tried everything I could think of and all the different steps found on the web including repairing the mbr changing disk types and boot options to no avail. What was odd for me is that the resulting image created on karmic would boot on lucid which indicated to me that once the install was completed successfully whatever kvm was doing didn't matter -- it was just the creation of the mbr or file system in the kvm boot that was at fault. + +My next step at this point was to install hexedit and compare the two resulting images. Specifically, the mbr at the beginning of the disk and the ntfs partition starting at sector 63. On the net there is some talk about changing 0x7E1A to 'FF' -- which is supposed to indicate disk geometry of the ntfs partition. There were three values that were different at this point in the ntfs file region -- 0x8E18, 0x7E1A, and 0x7E1C. The first two did not seem to have any effect. But changing 0x7E1C to the value of '3F' would result in the image booting properly. Evidently this is the part of the NTFS file system that records the starting sector of the partition. This change successfully booted all my test cases restores with a single partition. + +OK, so at this point I backtracked and did just steps 1-4 on both Karmic and Lucid but instead of booting to a rescuecd in the virt I used kpartx to mount the raw file system: + +1. make backup + fsarchiver savefs win.fsa /dev/sda1 +2. create disk + lvcreate -L10GB -n win vg +3. partition + fdisk /dev/vg/win +4. mount to loop, restore, detach + kpartx -av /dev/vg/win + fsarchiver restfs win.fsa id=0,dest=/dev/mapper/vg-winp1 + kpartx -dv /dev/loop0 +5. install mbr + install-mbr /dev/vg/win + +At this point, unfortunately, these steps will not boot on either karmic or lucid -- the boot section of the ntfs partition does not seem to write correctly (0x8E18, 0x7E1A, and 0x7E1C are all '00'). However, if you change 0x7E1C to '3F', these resulting images will boot fine: + +6. after hexedit, boot, success + kvm -m 1024 -hda /dev/vg/win + +Hope this helps track down this issue. My feeling here is that this is not an issue with the mbr but rather the creation of the ntfs file system. And it does seem that the disk geometry presented by the version of kvm in lucid is different enough from karmic to cause the ntfs file system incorrectly write sector 0x7E1C thus causing the resulting image to hang at boot. + + +I am struggling with the same problem with a WIndows 2003 install under virt-manager/virsh The byte at 7e1c was already set to 3F. hexediting the byte at offset 7e1a to FF allowed the system to boot OK. + + + +I'm getting the same error with restoring an Acronis based image to KVM on Scientific Linux 5.4. The image is known good, and I just tested to physical hardware and it boots fine. I hope this can be fixed... + +How are people hex editing the disk? + +I run into the same problem, but the workaround regarding editing the number of heads in the ntfs partition boot sector did it for me. Little Howto: + +Asume: A raw complete harddisc image within a bootable NTFS partition with XP or 2k3 on it + +Incident: when using these image with kvm based qemu, the system wan't boot anymore + +solution: + +1) set up the whole discimage as a loop device +- losetup /dev/loop0 /path/to/my/diskimage.raw + +2) let kpartx create drive mappings for all partitions within the loop device +- kpartx -a /dev/loop0 + +3) you need to know on which partition your NTFS partition resides +- fdisk -l /dev/loop0 + +4) use the right partition mapping with hex-edit (eg. partition 1) +- hexedit /dev/mapper/loop0p1 + +5) look on hex position 0x1a, for the count of heads NTFS asumes +- in hexedit type enter and then 1A + +6) change the value to 0xFF +- in hexedit type FF + +7) save and exit hexedit +- press Ctrl+X to end + +8) remove the partition mappings +- kpartx -d /dev/loop0 + +9) remove loop device +- losetup -d /dev/loop0 + +Hope that helps + +Cheers Andreas + +Great solution Andreas, it worked for a Win2k image which I could only boot previously using an iso from http://www.resoo.org/docs/ntldr/files/ + +However, I have a w7 image that I have never managed to boot, apart from its installation cd image using virt-install + +20Gb w7 image: + +# losetup /dev/loop0 /vm/w7.img; kpartx -a /dev/loop0 +# fdisk -l /dev/loop0 + +Disk /dev/loop0: 21.5 GB, 21474836480 bytes +255 heads, 63 sectors/track, 2610 cylinders +Units = cylinders of 16065 * 512 = 8225280 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes +Disk identifier: 0xaf12c11f + + Device Boot Start End Blocks Id System +/dev/loop0p1 * 1 13 102400 7 HPFS/NTFS +Partition 1 does not end on cylinder boundary. +/dev/loop0p2 13 2611 20867072 7 HPFS/NTFS +Partition 2 does not end on cylinder boundary. + +# hexedit /dev/mapper/loop0p1 +00000000 EB 52 90 4E 54 46 53 20 20 20 20 00 02 08 00 00 00 00 00 00 00 F8 00 00 3F 00 10 00 00 08 00 00 .R.NTFS .............?....... +00000020 00 00 00 00 80 00 80 00 FF 1F 03 00 00 00 00 00 55 21 00 00 00 00 00 00 02 00 00 00 00 00 00 00 ................U!.............. + + +# hexedit /dev/mapper/loop0p2 +00000000 EB 52 90 4E 54 46 53 20 20 20 20 00 02 08 00 00 00 00 00 00 00 F8 00 00 3F 00 10 00 00 28 03 00 .R.NTFS .............?....(.. +00000020 00 00 00 00 80 00 80 00 FF CF 7C 02 00 00 00 00 00 00 0C 00 00 00 00 00 02 00 00 00 00 00 00 00 ..........|..................... + + +# kpartx -d /dev/loop0; losetup -d /dev/loop0 + +I changed location 0x1a to 0xFF on one or other or both partitions and it still will not boot in virt-manager. + +Cheers, +Andy. + +Hi Andy + +When i look at your w7 partition table output, then there seems to be a problem with start/end cylinders. + +Your first partitions last cylinder is 13, but also the start cylinder of your second partition is 13. two partitions should not share the same cylinder/sector! Something seems to be messed up. + +I would create a loop device and then use a deep scan with "testdisk" on that loop device. May be it's possible to correct the wrong entrys in the partition table. + +Cheers Andreas + +I had the same problem. + +I.ve tried with VirtualBox and KVM: Win Xp SP3 hang on the same point (mup.sys when "safe mode")... +Both has the same problem I believe the libvirt maybe the cause. + +So I use "Raw Access" with VirtualBox that solved my problem.... + +00:00:01.385 [/Devices/piix3ide/0/LUN#0/AttachedDriver/Config/] (level 6) +00:00:01.385 Format <string> = "VMDK" (cb=5) +00:00:01.385 Path <string> = "/home/jtloni/.VirtualBox/HardDisks/xp3.vmdk" (cb=45) + +hope will help.. + +Andreas, + +The program that created the disk image seems confused, but it worked for creating a VM for FC11. +Windows install seems to run fine, until wanting to boot from the drive it created. +I don't know what creates the drive image and geometry, but it is broken. + +I think this is what I used to create the VM, but I have messed around with so many configurations and methods, I'm not sure what is what anymore. + +virt-install --connect qemu:///system -n w7 -r 2048 --vcpus=2 \ +--disk path=/vm/w7.img,size=20,sparse=false,format=qcow2 \ +-c /vm/w7cd.iso --vnc --noautoconsole \ +--os-type windows --os-variant win7 --accelerate --network=bridge:br0 --hvm + +How many thousands of people have struggled with this and also got nowhere? +It just looks like the virt-install developers have not tasted their own dogfood! + +LVM is supposed to be easy - just select vm image and boot, but the more +I read about VMs, kvm, qemu, virtualbox, virsh etc, the more confused I get on how they +relate to each other. + +testdisk reports this: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Disk /dev/loop0 - 21 GB / 20 GiB - CHS 41943040 1 1 (wtf ??) + + Partition Start End Size in sectors + 1 * HPFS - NTFS 2048 206847 204800 [System Reserved] + 2 P HPFS - NTFS 206848 41940991 41734144 + + +Select 1: +Disk /dev/loop0 - 21 GB / 20 GiB - CHS 41943040 1 1 + Partition Start End Size in sectors + 1 * HPFS - NTFS 2048 206847 204800 [System Reserved] + +Boot sector +Warning: Incorrect number of heads/cylinder 16 (NTFS) != 1 (HD) +Warning: Incorrect number of sectors per track 63 (NTFS) != 1 (HD) +Status: OK + +Backup boot sector +Warning: Incorrect number of heads/cylinder 16 (NTFS) != 1 (HD) +Warning: Incorrect number of sectors per track 63 (NTFS) != 1 (HD) +Status: OK + +Sectors are identical. + +A valid NTFS Boot sector must be present in order to access +any data; even if the partition is not bootable. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + + +Rebuild BS: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Disk /dev/loop0 - 21 GB / 20 GiB - CHS 41943040 1 1 + Partition Start End Size in sectors + 1 * HPFS - NTFS 2048 206847 204800 [System Reserved] + +filesystem size 204800 204800 +sectors_per_cluster 8 8 +mft_lcn 8533 8533 +mftmirr_lcn 2 2 +clusters_per_mft_record -10 -10 +clusters_per_index_record 1 1 +Extrapolated boot sector and current boot sector are different. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Q + +Select 2: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Disk /dev/loop0 - 21 GB / 20 GiB - CHS 41943040 1 1 + Partition Start End Size in sectors + 2 P HPFS - NTFS 206848 41940991 41734144 + +Boot sector +Warning: Incorrect number of heads/cylinder 16 (NTFS) != 1 (HD) +Warning: Incorrect number of sectors per track 63 (NTFS) != 1 (HD) +Status: OK + +Backup boot sector +Warning: Incorrect number of heads/cylinder 16 (NTFS) != 1 (HD) +Warning: Incorrect number of sectors per track 63 (NTFS) != 1 (HD) +Status: OK + +Sectors are identical. + +A valid NTFS Boot sector must be present in order to access +any data; even if the partition is not bootable. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Rebuild BS: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Disk /dev/loop0 - 21 GB / 20 GiB - CHS 41943040 1 1 + Partition Start End Size in sectors + 2 P HPFS - NTFS 206848 41940991 41734144 + +filesystem size 41734144 41734144 +sectors_per_cluster 8 8 +mft_lcn 786432 786432 +mftmirr_lcn 2 2 +clusters_per_mft_record -10 -10 +clusters_per_index_record 1 1 +Extrapolated boot sector and current boot sector are different. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It looks a mess. + + + + +This appears to be fixed in 0.13-tobe by this patch: +http://lists.gnu.org/archive/html/qemu-devel/2010-07/msg00152.html +(hence it's "fix released" in debian which now has 0.13 in experimental). + +(and it is also filed agains debian qemu-kvm package, not just qemu -- http://bugs.debian.org/588739 ) + +This is fixed by a backport of the mentioned patchset to stable-0.12 branch, in qemu git tree, see http://git.savannah.gnu.org/gitweb/?p=qemu.git;a=commit;h=6394bd0e05441c363ebb73597c74c951378810e6 + +This bug is annoying. I don't know who patched what but: + +1. I finally was able (with version 0.12.5) to set up a WinXP installation which is able to boot on its own. + +2. But this works only with IDE, if I try to use VirtIO I still can't boot the installation. + +3. I just updated from 0.12.5 to 0.12.5-r1 and again I can't boot the WinXP installation on IDE. + +What the hell are you doing? + +I don't know what's wrong but qemu-kvm works with Windows Vista and above much better than with Windows XP atm. Windows Server 2008 boots on it's own even with the non-signed viostor drivers. + +P.S.: I just read the link posted by Michael. + +I have also to mention that this boot problem not only appears by using the -drive parameter, even the good old -hda got this bug. + +I've also tried to correct some funny offsets in the NTFS header, but all offsets were already set to the right values. And it doesn't boot at all. + +Does anyone else has similar problem? With 0.12.4 I were able to repeat it. With 0.12.5 all winxp and win2003 installations, existing and new, just work with either -drive or -hda or with virtio... + +This bug was fixed in the package qemu-kvm - 0.12.5+noroms-0ubuntu6 + +--------------- +qemu-kvm (0.12.5+noroms-0ubuntu6) maverick; urgency=low + + * debian/fix-CMOS-info-for-drives-defined-with--device.patch: make sure + the CMOS knows about the correct geometry so Windows XP installs + properly. (LP: #586175) + -- Marc Deslauriers <email address hidden> Wed, 15 Sep 2010 19:48:15 -0400 + +In qemu-kvm-0.12.5-r1 Windows XP/2003 is booting fine on IDE, but it hangs directly after the first reboot of the Windows setup if you try to install it on a viostor drive. Windows Vista and higher never had any problems in any version of qemu-kvm with any drive (IDE and viostor)... + +I'm using the binaries of viostor-1.11.1, which I got from this site: http://www.linux-kvm.com/content/latest-windows-virtio-drivers + +virtio disk is entrely different story, unrelated to this issue. + diff --git a/results/classifier/zero-shot/108/all/59540920 b/results/classifier/zero-shot/108/all/59540920 new file mode 100644 index 000000000..85d1e913a --- /dev/null +++ b/results/classifier/zero-shot/108/all/59540920 @@ -0,0 +1,386 @@ +other: 0.989 +files: 0.987 +permissions: 0.986 +graphic: 0.985 +debug: 0.985 +device: 0.985 +semantic: 0.985 +socket: 0.983 +performance: 0.983 +PID: 0.982 +network: 0.981 +boot: 0.980 +vnc: 0.977 +KVM: 0.970 + +[BUG] No irqchip created after commit 11bc4a13d1f4 ("kvm: convert "-machine kernel_irqchip" to an accelerator property") + +I apologize if this was already reported, + +I just noticed that with the latest updates QEMU doesn't start with the +following configuration: + +qemu-system-x86_64 -name guest=win10 -machine pc,accel=kvm -cpu +host,hv_vpindex,hv_synic ... + +qemu-system-x86_64: failed to turn on HyperV SynIC in KVM: Invalid argument +qemu-system-x86_64: kvm_init_vcpu failed: Invalid argument + +If I add 'kernel-irqchip=split' or ',kernel-irqchip=on' it starts as +usual. I bisected this to the following commit: + +commit 11bc4a13d1f4b07dafbd1dda4d4bf0fdd7ad65f2 (HEAD, refs/bisect/bad) +Author: Paolo Bonzini <address@hidden> +Date: Wed Nov 13 10:56:53 2019 +0100 + + kvm: convert "-machine kernel_irqchip" to an accelerator property + +so aparently we now default to 'kernel_irqchip=off'. Is this the desired +behavior? + +-- +Vitaly + +No, absolutely not. I was sure I had tested it, but I will take a look. +Paolo +Il ven 20 dic 2019, 15:11 Vitaly Kuznetsov < +address@hidden +> ha scritto: +I apologize if this was already reported, +I just noticed that with the latest updates QEMU doesn't start with the +following configuration: +qemu-system-x86_64 -name guest=win10 -machine pc,accel=kvm -cpu host,hv_vpindex,hv_synic ... +qemu-system-x86_64: failed to turn on HyperV SynIC in KVM: Invalid argument +qemu-system-x86_64: kvm_init_vcpu failed: Invalid argument +If I add 'kernel-irqchip=split' or ',kernel-irqchip=on' it starts as +usual. I bisected this to the following commit: +commit 11bc4a13d1f4b07dafbd1dda4d4bf0fdd7ad65f2 (HEAD, refs/bisect/bad) +Author: Paolo Bonzini < +address@hidden +> +Date:  Wed Nov 13 10:56:53 2019 +0100 +  kvm: convert "-machine kernel_irqchip" to an accelerator property +so aparently we now default to 'kernel_irqchip=off'. Is this the desired +behavior? +-- +Vitaly + +Commit 11bc4a13d1f4 ("kvm: convert "-machine kernel_irqchip" to an +accelerator property") moves kernel_irqchip property from "-machine" to +"-accel kvm", but it forgets to set the default value of +kernel_irqchip_allowed and kernel_irqchip_split. + +Also cleaning up the three useless members (kernel_irqchip_allowed, +kernel_irqchip_required, kernel_irqchip_split) in struct MachineState. + +Fixes: 11bc4a13d1f4 ("kvm: convert "-machine kernel_irqchip" to an accelerator +property") +Signed-off-by: Xiaoyao Li <address@hidden> +--- + accel/kvm/kvm-all.c | 3 +++ + include/hw/boards.h | 3 --- + 2 files changed, 3 insertions(+), 3 deletions(-) + +diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c +index b2f1a5bcb5ef..40f74094f8d3 100644 +--- a/accel/kvm/kvm-all.c ++++ b/accel/kvm/kvm-all.c +@@ -3044,8 +3044,11 @@ bool kvm_kernel_irqchip_split(void) + static void kvm_accel_instance_init(Object *obj) + { + KVMState *s = KVM_STATE(obj); ++ MachineClass *mc = MACHINE_GET_CLASS(current_machine); + + s->kvm_shadow_mem = -1; ++ s->kernel_irqchip_allowed = true; ++ s->kernel_irqchip_split = mc->default_kernel_irqchip_split; + } + + static void kvm_accel_class_init(ObjectClass *oc, void *data) +diff --git a/include/hw/boards.h b/include/hw/boards.h +index 61f8bb8e5a42..fb1b43d5b972 100644 +--- a/include/hw/boards.h ++++ b/include/hw/boards.h +@@ -271,9 +271,6 @@ struct MachineState { + + /*< public >*/ + +- bool kernel_irqchip_allowed; +- bool kernel_irqchip_required; +- bool kernel_irqchip_split; + char *dtb; + char *dumpdtb; + int phandle_start; +-- +2.19.1 + +Il sab 28 dic 2019, 09:48 Xiaoyao Li < +address@hidden +> ha scritto: +Commit 11bc4a13d1f4 ("kvm: convert "-machine kernel_irqchip" to an +accelerator property") moves kernel_irqchip property from "-machine" to +"-accel kvm", but it forgets to set the default value of +kernel_irqchip_allowed and kernel_irqchip_split. +Also cleaning up the three useless members (kernel_irqchip_allowed, +kernel_irqchip_required, kernel_irqchip_split) in struct MachineState. +Fixes: 11bc4a13d1f4 ("kvm: convert "-machine kernel_irqchip" to an accelerator property") +Signed-off-by: Xiaoyao Li < +address@hidden +> +Please also add a Reported-by line for Vitaly Kuznetsov. +--- + accel/kvm/kvm-all.c | 3 +++ + include/hw/boards.h | 3 --- + 2 files changed, 3 insertions(+), 3 deletions(-) +diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c +index b2f1a5bcb5ef..40f74094f8d3 100644 +--- a/accel/kvm/kvm-all.c ++++ b/accel/kvm/kvm-all.c +@@ -3044,8 +3044,11 @@ bool kvm_kernel_irqchip_split(void) + static void kvm_accel_instance_init(Object *obj) + { +   KVMState *s = KVM_STATE(obj); ++  MachineClass *mc = MACHINE_GET_CLASS(current_machine); +   s->kvm_shadow_mem = -1; ++  s->kernel_irqchip_allowed = true; ++  s->kernel_irqchip_split = mc->default_kernel_irqchip_split; +Can you initialize this from the init_machine method instead of assuming that current_machine has been initialized earlier? +Thanks for the quick fix! +Paolo + } + static void kvm_accel_class_init(ObjectClass *oc, void *data) +diff --git a/include/hw/boards.h b/include/hw/boards.h +index 61f8bb8e5a42..fb1b43d5b972 100644 +--- a/include/hw/boards.h ++++ b/include/hw/boards.h +@@ -271,9 +271,6 @@ struct MachineState { +   /*< public >*/ +-  bool kernel_irqchip_allowed; +-  bool kernel_irqchip_required; +-  bool kernel_irqchip_split; +   char *dtb; +   char *dumpdtb; +   int phandle_start; +-- +2.19.1 + +On Sat, 2019-12-28 at 10:02 +0000, Paolo Bonzini wrote: +> +> +> +Il sab 28 dic 2019, 09:48 Xiaoyao Li <address@hidden> ha scritto: +> +> Commit 11bc4a13d1f4 ("kvm: convert "-machine kernel_irqchip" to an +> +> accelerator property") moves kernel_irqchip property from "-machine" to +> +> "-accel kvm", but it forgets to set the default value of +> +> kernel_irqchip_allowed and kernel_irqchip_split. +> +> +> +> Also cleaning up the three useless members (kernel_irqchip_allowed, +> +> kernel_irqchip_required, kernel_irqchip_split) in struct MachineState. +> +> +> +> Fixes: 11bc4a13d1f4 ("kvm: convert "-machine kernel_irqchip" to an +> +> accelerator property") +> +> Signed-off-by: Xiaoyao Li <address@hidden> +> +> +Please also add a Reported-by line for Vitaly Kuznetsov. +Sure. + +> +> --- +> +> accel/kvm/kvm-all.c | 3 +++ +> +> include/hw/boards.h | 3 --- +> +> 2 files changed, 3 insertions(+), 3 deletions(-) +> +> +> +> diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c +> +> index b2f1a5bcb5ef..40f74094f8d3 100644 +> +> --- a/accel/kvm/kvm-all.c +> +> +++ b/accel/kvm/kvm-all.c +> +> @@ -3044,8 +3044,11 @@ bool kvm_kernel_irqchip_split(void) +> +> static void kvm_accel_instance_init(Object *obj) +> +> { +> +> KVMState *s = KVM_STATE(obj); +> +> + MachineClass *mc = MACHINE_GET_CLASS(current_machine); +> +> +> +> s->kvm_shadow_mem = -1; +> +> + s->kernel_irqchip_allowed = true; +> +> + s->kernel_irqchip_split = mc->default_kernel_irqchip_split; +> +> +Can you initialize this from the init_machine method instead of assuming that +> +current_machine has been initialized earlier? +OK, will do it in v2. + +> +Thanks for the quick fix! +BTW, it seems that this patch makes kernel_irqchip default on to workaround the +bug. +However, when explicitly configuring kernel_irqchip=off, guest still fails +booting due to "KVM: failed to send PV IPI: -95" with a latest upstream kernel +ubuntu guest. Any idea about this? + +> +Paolo +> +> } +> +> +> +> static void kvm_accel_class_init(ObjectClass *oc, void *data) +> +> diff --git a/include/hw/boards.h b/include/hw/boards.h +> +> index 61f8bb8e5a42..fb1b43d5b972 100644 +> +> --- a/include/hw/boards.h +> +> +++ b/include/hw/boards.h +> +> @@ -271,9 +271,6 @@ struct MachineState { +> +> +> +> /*< public >*/ +> +> +> +> - bool kernel_irqchip_allowed; +> +> - bool kernel_irqchip_required; +> +> - bool kernel_irqchip_split; +> +> char *dtb; +> +> char *dumpdtb; +> +> int phandle_start; + +Il sab 28 dic 2019, 10:24 Xiaoyao Li < +address@hidden +> ha scritto: +BTW, it seems that this patch makes kernel_irqchip default on to workaround the +bug. +However, when explicitly configuring kernel_irqchip=off, guest still fails +booting due to "KVM: failed to send PV IPI: -95" with a latest upstream kernel +ubuntu guest. Any idea about this? +We need to clear the PV IPI feature for userspace irqchip. Are you using -cpu host by chance? +Paolo +> Paolo +> > } +> > +> > static void kvm_accel_class_init(ObjectClass *oc, void *data) +> > diff --git a/include/hw/boards.h b/include/hw/boards.h +> > index 61f8bb8e5a42..fb1b43d5b972 100644 +> > --- a/include/hw/boards.h +> > +++ b/include/hw/boards.h +> > @@ -271,9 +271,6 @@ struct MachineState { +> > +> >   /*< public >*/ +> > +> > -  bool kernel_irqchip_allowed; +> > -  bool kernel_irqchip_required; +> > -  bool kernel_irqchip_split; +> >   char *dtb; +> >   char *dumpdtb; +> >   int phandle_start; + +On Sat, 2019-12-28 at 10:57 +0000, Paolo Bonzini wrote: +> +> +> +Il sab 28 dic 2019, 10:24 Xiaoyao Li <address@hidden> ha scritto: +> +> BTW, it seems that this patch makes kernel_irqchip default on to workaround +> +> the +> +> bug. +> +> However, when explicitly configuring kernel_irqchip=off, guest still fails +> +> booting due to "KVM: failed to send PV IPI: -95" with a latest upstream +> +> kernel +> +> ubuntu guest. Any idea about this? +> +> +We need to clear the PV IPI feature for userspace irqchip. Are you using -cpu +> +host by chance? +Yes, I used -cpu host. + +After using "-cpu host,-kvm-pv-ipi" with kernel_irqchip=off, it can boot +successfully. + +> +Paolo +> +> +> > Paolo +> +> > > } +> +> > > +> +> > > static void kvm_accel_class_init(ObjectClass *oc, void *data) +> +> > > diff --git a/include/hw/boards.h b/include/hw/boards.h +> +> > > index 61f8bb8e5a42..fb1b43d5b972 100644 +> +> > > --- a/include/hw/boards.h +> +> > > +++ b/include/hw/boards.h +> +> > > @@ -271,9 +271,6 @@ struct MachineState { +> +> > > +> +> > > /*< public >*/ +> +> > > +> +> > > - bool kernel_irqchip_allowed; +> +> > > - bool kernel_irqchip_required; +> +> > > - bool kernel_irqchip_split; +> +> > > char *dtb; +> +> > > char *dumpdtb; +> +> > > int phandle_start; +> +> + diff --git a/results/classifier/zero-shot/108/all/607204 b/results/classifier/zero-shot/108/all/607204 new file mode 100644 index 000000000..875ae9e9d --- /dev/null +++ b/results/classifier/zero-shot/108/all/607204 @@ -0,0 +1,59 @@ +semantic: 0.975 +permissions: 0.973 +performance: 0.972 +other: 0.972 +graphic: 0.972 +debug: 0.971 +boot: 0.971 +network: 0.970 +socket: 0.970 +device: 0.968 +PID: 0.967 +vnc: 0.966 +KVM: 0.957 +files: 0.955 + +New qemu instances often cannot be started if host system is under load + +I've got a problem where I cannot start any new VMs with qemu-kvm if the host machine is under high CPU load. The problem is not 100% reproducible (it works sometimes), but under load conditions, it happens most of the time - roughly 95%. + +I'm usually using libvirt to start and stop KVM VMs. When using virsh to start a new VM under those conditions, the output looks like this: + +virsh # start testserver-a +error: Failed to start domain testserver-a +error: monitor socket did not show up.: Connection refused + +(There is a very long wait after the command has been sent until the error message shows up.) + +This is (an example of) the command line that libvirtd uses to start up qemu: + +----- snip ----- +LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/root USER=root LOGNAME=root QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -S -M pc-0.12 -enable-kvm -m 256 -smp 1,sockets=1,cores=1,threads=1 -name testserver-a -uuid 7cbb3665-4d58-86b8-ce8f-20541995a99c -nodefaults -chardev socket,id=monitor,path=/usr/local/var/lib/libvirt/qemu/testserver-a.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=utc -no-acpi -boot c -device lsi,id=scsi0,bus=pci.0,addr=0x7 -drive file=/data/testserver-a-system.img,if=none,id=drive-scsi0-0-1,boot=on -device scsi-disk,bus=scsi0.0,scsi-id=1,drive=drive-scsi0-0-1,id=scsi0-0-1 -drive file=/data/testserver-a-data1.img,if=none,id=drive-virtio-disk1 -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/data/testserver-a-data2.img,if=none,id=drive-virtio-disk2 -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk2,id=virtio-disk2 -drive file=/data/gentoo-install-amd64-minimal-20100408.iso,if=none,media=cdrom,id=drive-ide0-0-0,readonly=on -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/data/testserver-a_configfloppy.img,if=none,id=drive-fdc0-0-0 -global isa-fdc.driveA=drive-fdc0-0-0 -device e1000,vlan=0,id=net0,mac=52:54:00:84:6d:69,bus=pci.0,addr=0x6 -net tap,fd=24,vlan=0,name=hostnet0 -usb -vnc 127.0.0.1:1,password -k de -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 +----- snip ----- + +Copy-pasting this to a commandline on the host to start qemu manually leads to a non-functional qemu process that "just sits there" with nothing happening. The monitor socket /usr/local/var/lib/libvirt/qemu/testserver-a.monitor will, indeed, not show up. + +I've tried starting qemu with the same commandline but without the parameters for redirecting the monitor to a socket, without the fd parameter for the network interface and without the vnc parameter. This resulted in a black window with the title "QEMU (testserver-a) [Stopped]". I could not access the monitor console in graphical mode either. When I press Ctrl-Alt-2 in graphical mode to access the monitor console, qemu will sometimes (but not always) crash with a segfault about 2 seconds after. + +Some experimentation I've done suggests that this problem only happens if the high cpu load is caused by another qemu process, not if it is caused by something else running on the machine. + +The bug appears much less often if I leave off the -nodefaults parameter. + +The bug will still appear if I start qemu as qemu-system-x86_64 instead of qemu-kvm and replace the -enable-kvm parameter with -no-kvm. + +The host machine I'm running this on has got 16 cores in total. It looks like it is sufficient for this bug to surface if at least one of these cores is brought to near 100% use by a qemu process. + +The version of qemu I'm using is qemu-kvm 0.12.4, built from source. Libvirt is version 0.8.1, built from source as well. The host OS is Fedora 12. The Kernel version is 2.6.32.12-115.fc12.x86_64. + +Attached is an strace of attempting to start qemu which I hope will help someone with a better understanding of qemu's internals see what's actually going on there. + + + +Forgot to mention: + +The bug is still present in the latest git-version as of this writing. + +Can you still reproduce this problem with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/624 b/results/classifier/zero-shot/108/all/624 new file mode 100644 index 000000000..067a3b1c3 --- /dev/null +++ b/results/classifier/zero-shot/108/all/624 @@ -0,0 +1,352 @@ +other: 0.966 +graphic: 0.961 +debug: 0.955 +semantic: 0.955 +device: 0.950 +performance: 0.947 +permissions: 0.945 +boot: 0.945 +files: 0.944 +KVM: 0.940 +socket: 0.938 +vnc: 0.935 +PID: 0.932 +network: 0.922 + +powerpc: halt and reboot via firmware via cuda fail +Description of problem: +Both shutdown and reboot cause errors preventing the action from occuring. With logging turned on as above, it can be seen that the issue is with CUDA. If the option `-M mac99,via=pmu` is given the action happens as expected. + +``` +# qemu-system-ppc -trace 'cuda_*' -d unimp,guest_errors -serial file:/dev/stdout -hda /tmp/grub-shell.CdAU68FI6P/grub.iso -boot c +WARNING: Image format was not specified for '/tmp/grub-shell.CdAU68FI6P/grub.iso' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. +cuda_delay_set_sr_int +cuda_data_send send: 0x00 +cuda_delay_set_sr_int +cuda_data_send send: 0x00 +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_packet_receive length 2 +cuda_packet_receive_data [0] 0x00 +cuda_packet_receive_data [1] 0x00 +cuda_packet_send length 3 +cuda_packet_send_data [0] 0x00 +cuda_packet_send_data [1] 0x00 +cuda_packet_send_data [2] 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_data_send send: 0x00 +cuda_delay_set_sr_int +cuda_data_send send: 0x1f +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_packet_receive length 2 +cuda_packet_receive_data [0] 0x00 +cuda_packet_receive_data [1] 0x1f +cuda_packet_send length 3 +cuda_packet_send_data [0] 0x00 +cuda_packet_send_data [1] 0x02 +cuda_packet_send_data [2] 0x1f +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x02 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x1f +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_data_send send: 0x00 +cuda_delay_set_sr_int +cuda_data_send send: 0x2f +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_packet_receive length 2 +cuda_packet_receive_data [0] 0x00 +cuda_packet_receive_data [1] 0x2f +cuda_packet_send length 4 +cuda_packet_send_data [0] 0x00 +cuda_packet_send_data [1] 0x00 +cuda_packet_send_data [2] 0x02 +cuda_packet_send_data [3] 0x01 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x02 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x01 +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_data_send send: 0x00 +cuda_delay_set_sr_int +cuda_data_send send: 0x2b +cuda_delay_set_sr_int +cuda_data_send send: 0x28 +cuda_delay_set_sr_int +cuda_data_send send: 0xfe +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_packet_receive length 4 +cuda_packet_receive_data [0] 0x00 +cuda_packet_receive_data [1] 0x2b +cuda_packet_receive_data [2] 0x28 +cuda_packet_receive_data [3] 0xfe +cuda_packet_send length 3 +cuda_packet_send_data [0] 0x00 +cuda_packet_send_data [1] 0x00 +cuda_packet_send_data [2] 0x2b +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x2b +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_data_send send: 0x00 +cuda_delay_set_sr_int +cuda_data_send send: 0x81 +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_packet_receive length 2 +cuda_packet_receive_data [0] 0x00 +cuda_packet_receive_data [1] 0x81 +cuda_packet_send length 3 +cuda_packet_send_data [0] 0x00 +cuda_packet_send_data [1] 0x00 +cuda_packet_send_data [2] 0x81 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x81 +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_data_send send: 0x00 +cuda_delay_set_sr_int +cuda_data_send send: 0x2f +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_packet_receive length 2 +cuda_packet_receive_data [0] 0x00 +cuda_packet_receive_data [1] 0x2f +cuda_packet_send length 3 +cuda_packet_send_data [0] 0x00 +cuda_packet_send_data [1] 0x02 +cuda_packet_send_data [2] 0x2f +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x02 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x2f +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_data_send send: 0x00 +cuda_delay_set_sr_int +cuda_data_send send: 0x3f +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_packet_receive length 2 +cuda_packet_receive_data [0] 0x00 +cuda_packet_receive_data [1] 0x3f +cuda_packet_send length 4 +cuda_packet_send_data [0] 0x00 +cuda_packet_send_data [1] 0x00 +cuda_packet_send_data [2] 0x03 +cuda_packet_send_data [3] 0x02 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x03 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x02 +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_data_send send: 0x00 +cuda_delay_set_sr_int +cuda_data_send send: 0x3b +cuda_delay_set_sr_int +cuda_data_send send: 0x29 +cuda_delay_set_sr_int +cuda_data_send send: 0xfe +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_packet_receive length 4 +cuda_packet_receive_data [0] 0x00 +cuda_packet_receive_data [1] 0x3b +cuda_packet_receive_data [2] 0x29 +cuda_packet_receive_data [3] 0xfe +cuda_packet_send length 3 +cuda_packet_send_data [0] 0x00 +cuda_packet_send_data [1] 0x00 +cuda_packet_send_data [2] 0x3b +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x3b +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_data_send send: 0x00 +cuda_delay_set_sr_int +cuda_data_send send: 0x91 +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_packet_receive length 2 +cuda_packet_receive_data [0] 0x00 +cuda_packet_receive_data [1] 0x91 +cuda_packet_send length 3 +cuda_packet_send_data [0] 0x00 +cuda_packet_send_data [1] 0x00 +cuda_packet_send_data [2] 0x91 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x91 +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_data_send send: 0x00 +cuda_delay_set_sr_int +cuda_data_send send: 0x3f +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_packet_receive length 2 +cuda_packet_receive_data [0] 0x00 +cuda_packet_receive_data [1] 0x3f +cuda_packet_send length 3 +cuda_packet_send_data [0] 0x00 +cuda_packet_send_data [1] 0x02 +cuda_packet_send_data [2] 0x3f +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x02 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x3f +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_data_send send: 0x00 +cuda_delay_set_sr_int +cuda_data_send send: 0x4f +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_packet_receive length 2 +cuda_packet_receive_data [0] 0x00 +cuda_packet_receive_data [1] 0x4f +cuda_packet_send length 3 +cuda_packet_send_data [0] 0x00 +cuda_packet_send_data [1] 0x02 +cuda_packet_send_data [2] 0x4f +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x02 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x4f +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_data_send send: 0x00 +cuda_delay_set_sr_int +cuda_data_send send: 0x5f +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_packet_receive length 2 +cuda_packet_receive_data [0] 0x00 +cuda_packet_receive_data [1] 0x5f +cuda_packet_send length 3 +cuda_packet_send_data [0] 0x00 +cuda_packet_send_data [1] 0x02 +cuda_packet_send_data [2] 0x5f +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x02 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x5f +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_data_send send: 0x00 +cuda_delay_set_sr_int +cuda_data_send send: 0x7f +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_packet_receive length 2 +cuda_packet_receive_data [0] 0x00 +cuda_packet_receive_data [1] 0x7f +cuda_packet_send length 3 +cuda_packet_send_data [0] 0x00 +cuda_packet_send_data [1] 0x02 +cuda_packet_send_data [2] 0x7f +cuda_delay_set_sr_int +cuda_data_recv recv: 0x00 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x02 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x7f +cuda_delay_set_sr_int +cuda_delay_set_sr_int + +>> ============================================================= +>> OpenBIOS 1.1 [Aug 12 2021 13:35] +>> Configuration device id QEMU version 1 machine id 2 +>> CPUs: 1 +>> Memory: 128M +>> UUID: 00000000-0000-0000-0000-000000000000 +>> CPU type PowerPC,750 +milliseconds isn't unique. +>> switching to new context: +>> call-method block-size failed with error ffffffdf +>> call-method block-size failed with error ffffffdf +cuda_data_send send: 0x01 +cuda_delay_set_sr_int +cuda_data_send send: 0x0a +cuda_delay_set_sr_int +cuda_data_send send: 0xfa +cuda_delay_set_sr_int +cuda_delay_set_sr_int +cuda_packet_receive length 3 +cuda_packet_receive_data [0] 0x01 +cuda_packet_receive_data [1] 0x0a +cuda_packet_receive_data [2] 0xfa +cuda_receive_packet_cmd handling command POWERDOWN +CUDA: POWERDOWN: wrong parameters 2 +cuda_packet_send length 4 +cuda_packet_send_data [0] 0x02 +cuda_packet_send_data [1] 0x05 +cuda_packet_send_data [2] 0x01 +cuda_packet_send_data [3] 0x0a +cuda_delay_set_sr_int +cuda_data_recv recv: 0x02 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x05 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x01 +cuda_delay_set_sr_int +cuda_data_recv recv: 0x0a +cuda_delay_set_sr_int +cuda_delay_set_sr_int +>> interpret shut-down failed with error ffffffed +>> interpret poweroff failed with error ffffffed +``` +Steps to reproduce: +1. Download attached iso file: [grub.iso.xz](/uploads/dea8f2bde4d90b9928f54bb9b73d76e9/grub.iso.xz) +2. Decompress iso +3. Run qemu as specified above +Additional information: + diff --git a/results/classifier/zero-shot/108/all/660366 b/results/classifier/zero-shot/108/all/660366 new file mode 100644 index 000000000..626ccf40e --- /dev/null +++ b/results/classifier/zero-shot/108/all/660366 @@ -0,0 +1,137 @@ +permissions: 0.987 +device: 0.985 +other: 0.984 +vnc: 0.982 +debug: 0.982 +performance: 0.982 +semantic: 0.979 +graphic: 0.978 +socket: 0.975 +PID: 0.975 +files: 0.975 +KVM: 0.974 +network: 0.968 +boot: 0.959 + +"qemu-img convert -O qcow2 -o backing_file" makes huge images + +$ dd if=/dev/urandom bs=1M of=1.img count=4 +4+0 records in +4+0 records out +4194304 bytes (4,2 MB) copied, 1,0413 s, 4,0 MB/s +$ qemu-img create -f qcow2 -b 1.img 2.img +Formatting '2.img', fmt=qcow2 size=4194304 backing_file='1.img' encryption=off cluster_size=0 +$ qemu-img convert -O qcow2 -o backing_file=1.img 2.img 3.img +$ du -h ?.img +4,1M 1.img +144K 2.img +4,3M 3.img + +The conversion result is bigger then the source! + +It appears that "-o backing_file" is not applied to data (as expected). I.e. all data is put into the resulting image: both from source image and "backing" image. + +Expected behavior is to put only data that is not present in backing_file. + +It is possible to chain backing files. As a workaround you could do the following: + +$ qemu-img create -f qcow2 -b 2.img 4.img # from now on don't modify 2.img, instead use 4.img +$ qemu-img create -f qcow2 -b 2.img 3.img # here is the 3.img you tried to create with qemu-convert + +Images 1.img and 2.img should never be modified, they are immutable snapshots. + +Images 3.img and 4.img can be modified and will contain only changes against 2.img. + +Perhaps qemu-img needs a command to drop data that is duplicated in the base image. This could be a new flag to commit: qemu-img commit --dedup 3.img. + +Do you confirm this as a bug? + +Sorry I'm not a frequent Launchpad user and will leave it up to someone more familiar to decide which status to place it in. + +On Thu, Oct 14, 2010 at 1:26 PM, Anthony Liguori <email address hidden> wrote: +> ** Changed in: qemu +> Importance: Undecided => Wishlist +> +> ** Changed in: qemu +> Status: New => Confirmed + +Thanks for doing this Anthony. Can I set the status myself next time +or do we have rules on who handles bugs? + +Stefan + +On 10/14/2010 07:51 AM, Stefan Hajnoczi wrote: +> On Thu, Oct 14, 2010 at 1:26 PM, Anthony Liguori<email address hidden> wrote: +> +>> ** Changed in: qemu +>> Importance: Undecided => Wishlist +>> +>> ** Changed in: qemu +>> Status: New => Confirmed +>> +> Thanks for doing this Anthony. Can I set the status myself next time +> or do we have rules on who handles bugs? +> + +I'm pretty sure anyone can do it. If not, I'm certainly willing to give +people extra rights on the project if they want to help with bug triage. + +Regards, + +Anthony Liguori + +> Stefan +> + + +I guess the problem is solved already. +qemu-img version 1.4.0 + +Is this reintroduced? I am on version 2.3.0 + +$ dd if=/dev/urandom of=disk bs=1M count=1024 + +$ qemu-img convert -f raw -O qcow2 disk disk.qcow + +$ qemu-img convert -f raw -O qcow2 -o backing_file=disk.qcow disk disk1.qcow + +$ ls -l +total 3146388 +-rw-r--r-- 1 sakis sakis 1073741824 10 авг 15,29 disk +-rw-r--r-- 1 sakis sakis 1074135040 10 авг 15,30 disk.qcow +-rw-r--r-- 1 sakis sakis 1074135040 10 авг 15,31 disk1.qcow + +All the data is copied again. + +$ qemu-img info disk1.qcow +image: disk1.qcow +file format: qcow2 +virtual size: 1.0G (1073741824 bytes) +disk size: 1.0G +cluster_size: 65536 +*backing file: disk.qcow* +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +Qemu-img works as expected though. + +$ qemu-img create -f qcow2 -o backing_file=disk1.qcow disk2.qcow + +$ ls -l +total 3146584 +-rw-r--r-- 1 sakis sakis 1073741824 10 авг 15,29 disk +-rw-r--r-- 1 sakis sakis 1074135040 10 авг 15,30 disk.qcow +-rw-r--r-- 1 sakis sakis 1074135040 10 авг 15,31 disk1.qcow +-rw-r--r-- 1 sakis sakis 197120 10 авг 15,33 disk2.qcow + +This is a different case. The original report used "qemu-img create" in step 2, which results in a sparse image that refers to the backing file for all data. Your sequence has "qemu-img convert" instead, which fully populates disk.qcow. Therefore, in step 3, "qemu-img convert" leaves the full allocation intact. + +My mistake. It's different case than mine. Above sequence (original report) works fine. + +But I do not really understand why the same is not achieved in my case. I use the convert instead of the create to get a full image in qcow format. From that point, the desired behaviour is to create a qcow that is based on the one created from the first convert and contain only the changes. Why would the second convert populate the whole image again? + +Thanks in advance. + diff --git a/results/classifier/zero-shot/108/all/676 b/results/classifier/zero-shot/108/all/676 new file mode 100644 index 000000000..b7ebbeb01 --- /dev/null +++ b/results/classifier/zero-shot/108/all/676 @@ -0,0 +1,69 @@ +graphic: 0.989 +other: 0.988 +debug: 0.988 +semantic: 0.986 +permissions: 0.981 +performance: 0.978 +device: 0.973 +PID: 0.971 +socket: 0.971 +files: 0.970 +boot: 0.967 +vnc: 0.964 +network: 0.960 +KVM: 0.956 + +Throws a PF when it should throw a GF/SS +Description of problem: +QEMU misreports what should be a #GP as a #PF +``` +check_exception old: 0xffffffff new 0xe + 0: v=0e e=0001 i=0 cpl=0 IP=0028:ffffffffb28fa53b pc=ffffffffb28fa53b SP=0030:ffffffffb2901210 CR2=1fbf7020000772a4 +RAX=1fbf7020000772a4 RBX=0000000000000000 RCX=ffff80000006a0a8 RDX=ffff80000006a038 +RSI=1fbff0200000d26c RDI=0000000000000080 RBP=ffffffffb2901230 RSP=ffffffffb2901210 +R8 =ffffffffb28fb37f R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000 +R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000 +RIP=ffffffffb28fa53b RFL=00000007 [-----PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0030 0000000000000000 00000000 00009300 DPL=0 DS [-WA] +CS =0028 0000000000000000 00000000 00209a00 DPL=0 CS64 [-R-] +SS =0030 0000000000000000 00000000 00009300 DPL=0 DS [-WA] +DS =0030 0000000000000000 00000000 00009300 DPL=0 DS [-WA] +FS =0030 0000000000000000 00000000 00009300 DPL=0 DS [-WA] +GS =0030 0000000000000000 00000000 00009300 DPL=0 DS [-WA] +LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT +TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy +GDT= 000000000000edc0 00000037 +IDT= 000000000002e6a0 000000ff +CR0=80000013 CR2=1fbf7020000772a4 CR3=0000000000058000 CR4=000006a0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=3f7fe0400001a4d9 CCD=1fbff0200000d26c CCO=SARQ +EFER=0000000000000501 +``` + +Now, `CR2=1fbf7020000772a4` is of course a non-canonical address, and therefore should not generate a #PF, rather it should generate a #GP. I also tried to generate a #SS by dereferencing a non-canonical address through the stack, and that also throws a #PF instead of a #SS + +``` +check_exception old: 0xffffffff new 0xe + 0: v=0e e=0001 i=0 cpl=0 IP=0028:fffffffff4bda92a pc=fffffffff4bda92a SP=0030:1fbf7020000772a4 CR2=1fbf70200007729c +RAX=0000000000000000 RBX=0000000000000000 RCX=0000000000000000 RDX=fffffffff4bdb998 +RSI=0000000000000000 RDI=fffffffff4bdb998 RBP=fffffffff4bdf290 RSP=1fbf7020000772a4 +R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000 +R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000 +RIP=fffffffff4bda92a RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0030 0000000000000000 00000000 00009300 DPL=0 DS [-WA] +CS =0028 0000000000000000 00000000 00209a00 DPL=0 CS64 [-R-] +SS =0030 0000000000000000 00000000 00009300 DPL=0 DS [-WA] +DS =0030 0000000000000000 00000000 00009300 DPL=0 DS [-WA] +FS =0030 0000000000000000 00000000 00009300 DPL=0 DS [-WA] +GS =0030 0000000000000000 00000000 00009300 DPL=0 DS [-WA] +LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT +TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy +GDT= 000000000000edc0 00000037 +IDT= 000000000002e6a0 000000ff +CR0=80000011 CR2=1fbf70200007729c CR3=00000000bffa5000 CR4=00000020 +``` +Steps to reproduce: +1. Dereference a non-canonical address +2. QEMU gives you a page fault instead of a gpf +3. reconsider life diff --git a/results/classifier/zero-shot/108/all/685096 b/results/classifier/zero-shot/108/all/685096 new file mode 100644 index 000000000..912fbc27a --- /dev/null +++ b/results/classifier/zero-shot/108/all/685096 @@ -0,0 +1,349 @@ +permissions: 0.990 +debug: 0.989 +semantic: 0.985 +performance: 0.981 +graphic: 0.979 +other: 0.977 +device: 0.977 +PID: 0.971 +network: 0.968 +boot: 0.966 +KVM: 0.954 +files: 0.952 +vnc: 0.952 +socket: 0.942 + +USB Passthrough not working for Windows 7 guest + +USB Passthrough from host to guest is not working for a 32-bit Windows 7 guest, while it works perfectly for a 32-bit Windows XP guest. + +The device appears in the device manager of Windows 7, but with "Error code 10: device cannot start". I have tried this with numerous USB thumbdrives and a USB wireless NIC, all with the same result. The device name and functionality is recognized, so at least some USB negotiation is taking place. + +I am trying this with the latest git-pull of QEMU-KVM. + +The command line to launch qemu-kvm for win7 is: +sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 -smp 2 -vga std -hda ./disk_images/win7.qcow -vnc :1 -boot c -usb -usbdevice tablet -usbdevice host:0781:5150 + +The command line to launch qemu-kvm for winxp is: +sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 -smp 2 -usb -vga std -hda ./winxpsp3.qcow -vnc :0 -boot c -usbdevice tablet -usbdevice host:0781:5150 + +Any help is appreciated. + +I suffer from the same issue using QEMU 1.1. I tried 5 different USB thumbdrives and none of them worked. Interesting was that a USB 1.1 mouse was working though. + +Same problem here, using: +qemu-kvm 0.13 +kernel 2.6.36.2 +kvm-intel + +Guest: +Windows 7 Enterprise x64 + +INFO USBHOST: + Device 2.2, speed 480 Mb/s + Class 00: USB device 054c:02a5, Storage Media + +INFO USB: +Device 0.3, Speed 480 Mb/s, Product Storage Media + +Device appears in Windows 7 but in Error Code 10. + + +Ugh... I have just realized that KVM only supports UHCI, so not USB 2.0 support + + +two years passed... nothihg changed.... +qemu 0.14.1+win7(32/64) the problem persist + +Just found this problem with Win7 guest, both 32 and 64-bit, using qemu-kvm 1.01. WinXP is absolutely fine. + +How can this /possibly/ not be a priority to fix? + +This is an issue for me with Win7 SP1 64-bit guest on Ubuntu 12.10 (qemu-kvm 1.2.0+noroms) + +Waiting on a microsoft license, hoping to be able to test this in the next 2 weeks. + +This is also affecting Windows Server 2008 and happens with all usb storage devices I tested. + +Bug #1033727 is specifically about qemu-kvm 1.2.0 and higher, see comment #8 on that bug for example. This bug is about earlier versions, including the version in 12.04 LTS. + +This maybe not a duplicate as we're using 1.3.1 and Windows 7 isn't working there either. All other Operating systems are working though. + +@Wessel: I believe the bug you pointed out as duplicate is saying that USB passthrough isnt working on any guest OS, but this bug is specifically targeted about Windows 7 not working. + +I don't recall saying there was a duplicate of this bug? I merely objected to #1033727 being marked a duplicate. + +Lol weird it's not marked as duplicate anymore anyway, guess it was not you then. Don't know what happened. + +Can this bug be fixed in KVM or is it really to Windows specific? Else I may have a look at it, never did any KVM development though, should be fun. + +@Serge: Did you get the license already and had a look at this bug? + +@Sam, + +I have the license now, but haven't had a chance to reproduce yet, sorry. It's on my list. + +Upstream git head still gives me this problem, as does back to 0.14.0. + +Note however that the same qemu builds, with the same usb stick, work fine using a linux guest. + +The same stick, inserted to the same windows version on native hardware also works. + +So it's not bad hardware, it's not hardware unsupported by windows, and qemu *is* passing the usb device through sufficiently that windows SHOULD be able to make use of it. + +So this appears to be something specific that windows wants. + +I've seen mention of windows registry tricks involving removal of top and bottom filters for the device... I haven't tested that to see if that would be a workaround. + +Is there any workaround? + +We're currently evaluating different RTOS systems. One is Linux RT with KVM/QEMU with Windows 7. This bug breaks the latency measurement setup and Linux RT is out of race. It there anyway to fix the issue? + +Hi Jens, + +could you tell us exactly what you are trying to pass through, what commands you've tried, and with what version of qemu (and, if hand-built, which options were passed to configure). + +1.5 came with a new passthrough implementation, but alongside the old. So I wonder whether choosing the libusb based implementation would help. + +Hi Serge, + +for your information. I sent a mail to the devel mailing list. See below. + +I've tried to passthrough special Vector automotive usb in house devices. +Look here: http://vector.com/vi_vn1600_en.html. + +What do you mean with "what commands you've tried"? + +I've tried three QEMU versions: + +1. Ubuntu 13.04 64-bit prebuild qemu-kvm package (qemu 1.4.0) +2. Ubuntu 13.10 64-bit prebuild qemu-kvm package (qemu 1.5.0) +3. Hand builded QEMU 1.6.1 with standard configure call + $ ./configure --prefix=/opt/kvm && make -j + +Next, I want to build qemu from git? + +I use virt-manager or virsh to start/stop my guest. The QEMU command line is: + +qemu-system-x86_64 -machine accel=kvm:tcg -name VRTP1_win -S -M pc- +i440fx-1.4 -cpu SandyBridge -m 3072 -smp 2,sockets=1,cores=2,threads=1 +-uuid 8ee5add7-f1a9-d697-9c18-2c1b4967c00e -no-user-config -nodefaults +-chardev +socket,id=charmonitor,path=/var/lib/libvirt/qemu/VRTP1_win.monitor,server,nowait +-mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime +-no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 +-device ahci,id=ahci0,bus=pci.0,addr=0x6 -drive +file=/var/lib/libvirt/images/VN8912_Development_0.9.2.bin,if=none,id +=drive-sata0-0-0,format=raw -device ide-hd,bus=ahci0.0,drive=drive- +sata0-0-0,id=sata0-0-0,bootindex=1 -netdev +tap,fd=27,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net- +pci,netdev=hostnet0,id=net0,mac=52:54:00:71:f5:45,bus=pci.0,addr=0x3 +-chardev pty,id=charserial0 -device isa- +serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc +127.0.0.1:0 -vga std -device intel-hda,id=sound0,bus=pci.0,addr=0x4 +-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb- +host,hostbus=3,hostaddr=18,id=hostdev0 -device virtio-balloon- +pci,id=balloon0,bus=pci.0,addr=0x5 + + +Mail to devel list: + +Hi all, + +we're currently evaluating different RTOS systems (Windows CE, Intime, RTX, etc.). +One system is Linux RT + KVM/QEMU with a Windows 7 guest. Up to now all +works fine, Linux RT has good latency and KVM/Qemu setup was easy. But one QEMU bug +breaks my measurement setup and evaluation. + +I've some usb devices for the Windows 7 guest. I configure them as USB passthrough. +The devices appears in the device manager of Windows 7, but with +"Error code 10": device cannot start". The Windows driver fails on USB set configuration. +The driver creates a IRP and send it via IOCTRL to lower layer. The IOCTRL fails with +invalid parameter. + +driver log: +00000009 0.65470564 vnCDrvUsbControlRequestSetConfiguration, WdfUsbTargetDeviceSelectConfig single interface failed 0xc000000d +00000010 0.65472370 vnCDrvUsbIFPrepareHardwareState, vnCDrvUsbControlRequestSetConfiguration failed: 0xc000000d +00000011 0.65473646 vnCDrvDevConPrepareHardware, vnCDrvUsbIFPrepareHardwareState failed 0xc000000d +00000012 0.65474838 vnCDrvEvtDevicePrepareHardware, vnCDrvDevConPrepareHardware failed 0xc0000001 +00000013 0.6547 + +This bug breaks my latency measurement setup and Linux RT is out of the evaluationg +race. Windows CE should not win :-), it there anyway workaround or hack to fix the issue? + +My setup: + +Ubuntu 64-bit +Windows 7 Embedded Guest +Linux Kernel: 3.10.10-rt7 +QEMU: 1.4.0, 1.6.1 + +thanks, +Jens + + +All devices work on other hypervisors like VMware Workstation etc... + +I have the same problem. I tried it with qemu 1.4 and the last 1.6.0-dfsg-2 on a debian testing system. Win 7 says always "This device cannot start. (Code 10)". I tried a lot of usb sticks but always the same... +I hope there will be sometime a solution for this :( I wait over a year in the hope that this will work. + +I also have this issue. USB pass-through didn't work on windows 8. I try to use "virt-mamanger", and set USB interface to USB 2.0. Then everything works well. The default one would be USB 1.0. + +I don't know how to transform virt-manager's configuration to QEMU's command line arguments. Hope this help. + +@FanFan, + +if you start such a vm and do 'ps -ef | grep kvm' should see the kvm command line which is working for you. + +I think you should appoint the usb bus which according to your usb type, such as: +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 + -device usb-ehci,id=usb1,bus=pci.0,addr=0x4 + -device usb-hub,id=hub0,bus=usb.0,port=2 + -device usb-tablet,id=input0,bus=usb.0,port=1 + -device usb-host,hostbus=2,hostport=2,id=hostdev0,bus=usb1.0 + +Hi, I had the same problem. Tested a lot. My solution to passthrough usb devices to a windows 7 x64 guest: + +parameter part: + +-device usb-ehci,id=usb,bus=pci.0,addr=0x4 -device usb-host,vendorid=0x{},productid=0x{},id=hostdev0,bus=usb.0 + +I also tried the device +piix4-usb-uhci + +instead of usb-ehci + +piix4-usb-uhci caused the Code 10 error in the windows device manager. + +lsusb will give you a list of plugged in usb devices. eg. + +Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub + +1d6b:0002 +and +1d6b:0003 + +are vendorid:prouctid + +replace {} with the ids and it should work. I tested it with + +- ssd usb 3.0 drive +- retail usb seagate usb 2.0 hdd drive. + +followup: + +my understanding is there are a bunch of usb interfaces: + +uhci is usb 1.0 +ehci is usb 2.0 +xhci is usb 3.0 +… + +-device piix3-usb-uhci will create an usb 1.0 interface. I guess usb 1.0 is insufficent for modern usb devices so windows errors with code 10. ehci have enough to bring full support for modern usb devices. + +qemu is like LEGO where you can wire it all together :-) + +refference: +https://github.com/qemu/qemu/blob/master/docs/usb2.txt +https://en.wikipedia.org/wiki/Host_controller_interface_(USB,_Firewire)#USB + +Quoting Manuel Baesler (<email address hidden>): +> followup: +> +> my understanding is there are a bunch of usb interfaces: +> +> uhci is usb 1.0 +> ehci is usb 2.0 +> xhci is usb 3.0 +> … +> +> -device piix3-usb-uhci will create an usb 1.0 interface. I guess usb 1.0 +> is insufficent for modern usb devices so windows errors with code 10. +> ehci have enough to bring full support for modern usb devices. +> +> qemu is like LEGO where you can wire it all together :-) +> +> refference: +> https://github.com/qemu/qemu/blob/master/docs/usb2.txt +> https://en.wikipedia.org/wiki/Host_controller_interface_(USB,_Firewire)#USB + +Thanks - so (this isn't documented in the qemu man page) am I to assume +that given " -usbdevice host:0781:5150" as the original bug submitter is +doing means "give me usb 1.0" ? + +Max, does it work for you if you use (...taking a wild guess) : + + -device usb-ehci,id=usb,bus=pci.0,addr=0x4 \ + -device usb-host,vendorid=0x0781,productid=0x5150,id=hostdev0,bus=usb.0 + +or perhaps + + -device usb-ehci,id=usb,bus=pci.0,addr=0x4 \ + -usbdevice tablet \ + -device usb-host,vendorid=0x0781,productid=0x5150,id=hostdev0,bus=usb.0 + +You also might try xhci in place of ehci. + +(If this does turn out to be the answer, then the bug title should be +changed to include 'usb2.0 and usb3.0 devices', to aid people in +finding this gem in the future) + + status: incomplete + + +RIght, with '-usb' qemu creates then 'piix3-usb-uhci' device: + +00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01) + +I can connect to network with qemu 2.0 with and win 7 pro 64bit guest. + +qemu-system-x86_64 -machine accel=kvm -smp 2 -m 1024 -net none -device usb-ehci,id=usb,bus=pci.0,addr=0x4 -device usb-host,vendorid=0x0b95,productid=0x772b,id=hostdev0,bus=usb.0 -usb -usbdevice tablet -hda /srv/rhev/virtual.qcow -soundhw hda -boot c + +Bus 007 Device 014: ID 0b95:772b ASIX Electronics Corp. + + +Unfortunately there is lack of automation and documentation. Ideally you would use something like +qemu-system-x86_64 -machine accel=kvm -smp 2 -m 1024 -net none -usb2 -usbdevice host:0b95:772b -usbdevice tablet -hda /srv/rhev/virtual.qcow -soundhw hda -boot c + +Tthe usb device info from Linux should be enough to determine if the device is to be connected to usb1 or usb2, right? + +So the RightWay(tm) to fix this is to download http://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/ich9-ehci-uhci.cfg;hb=HEAD + +and run + +qemu-system-x86_64 -net none -readconfig ich9-ehci-uhci.cfg -device usb-host,vendorid=0x0b95,productid=0x772b -device usb-tablet <extra options here> + +Thanks Michal, + +so at sounds like at least that file should be distributed with the qemu package. I don't know the best place for that, or how cleanly we can integrate it to make it easiest on the end-user... + +Actually, in qemu 2.0.0 the file is packaged. However, it is packaged in the qemu package rather than qemu-system package so users are unlikely to have the file. + +The file seems to be in qemu-system-common (at least in Ubuntu 14.10). + +The next question is how to best help the user to run the right command. Should it go into the manpage? + +Comment No. 23 by Manuel Baesler worked for me in Windows 10. +lsusb gave me: +Bus 001 Device 040: ID 8564:1000 Transcend Information, Inc. JetFlash +Qemu Flags used: +-device usb-ehci,id=usb,bus=pci.0,addr=0x4 -device usb-host,vendorid=0x8564,productid=0x1000,id=hostdev0,bus=usb.0 + +The only way to see my iPhone (or any USB device) in the Windows guest is to have it redirected via "Spice", not with libvirt xml capture elements. + +Select Redirect USB device in virt-viewer and it just works. + +I have upgraded to Qemu 2.4, libvirt 1.2.21 and upgraded the qemu machine to "q35" as I tried hard to make it work via xml. +Now that I have it working, I don't plan to check if it works with less current software / machines. + +If I get the previous comments right, this is just about using the right configuration, and not a real bug? If so, I assume we can close this ticket nowadays? + +Closing this bug for QEMU, since there haven't been any replies within the last 7 months. + +Also marking the ubuntu task as incomplete. It looks like it's sorted, but let's give it some time for people to comment if they still have an issue. + +Doing the same for the debian task, which doesn't have an upstream bug anyway. + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/686 b/results/classifier/zero-shot/108/all/686 new file mode 100644 index 000000000..6c985d44d --- /dev/null +++ b/results/classifier/zero-shot/108/all/686 @@ -0,0 +1,54 @@ +graphic: 0.978 +debug: 0.975 +performance: 0.974 +device: 0.974 +permissions: 0.974 +other: 0.972 +network: 0.969 +socket: 0.968 +semantic: 0.966 +files: 0.962 +boot: 0.959 +PID: 0.953 +vnc: 0.944 +KVM: 0.941 + +Qemu crashes if it is paused and migrated twice +Description of problem: +If the vm is in PAUSED state (in Openstack parlance) (I think libvirt calls that paused as well but uses the command `virsh suspend`), and live-migrated twice, the second time the Qemu process terminates. + +This is perfectly repeatable. + +If the VM is unpaused and re-paused after the first migration, then the problem does not occur on the next migration. +Steps to reproduce: +See also the referenced bug report to openstack, above. +1. `$ openstack stack create ....` +2. `$ openstack server pause <UUID>` +(wait until done) +3. `$ openstack server migrate --live-migration <UUID>` +(wait until done) +4. `$ openstack server migrate --live-migration <UUID>` + +The VM is now in ERROR state because it has disappeared: `libvirt.libvirtError: Domain not found: no domain with matching uuid '<UUID>'` +Additional information: +The last few lines from the instance-00000ba2.log seem pertinent (this is from the receiving Qemu instance): +``` +2021-10-22 15:32:53.829+0000: initiating migration +qemu-system-x86_64: /build/qemu-lb4V37/qemu-4.2/block.c:5523: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed. +2021-10-22 15:32:59.122+0000: shutting down, reason=crashed +``` +This is logged by libvirt (also on the receiving side): +``` +Oct 22 15:29:04 ybk140931 ovs-vsctl[20174]: ovs|00001|vsctl|INFO|Called as ovs-vsctl --timeout=5 -- --if-exists del-port tap3a71aa63-6a +Oct 22 15:31:31 ybk140931 ovs-vsctl[21412]: ovs|00001|vsctl|INFO|Called as ovs-vsctl --timeout=5 -- --if-exists del-port tap3a71aa63-6a -- add-port br-int tap3a71aa63-6a -- set Interface tap3a71aa63-6a "external-ids:attached-mac=\"fa:16:3e:da:03:56\"" -- set Interface tap3a71aa63-6a "external-ids:iface-id=\"3a71aa63-6a39-41d8-9602-04b84834db9e\"" -- set Interface tap3a71aa63-6a "external-ids:vm-id=\"de2b27d2-345c-45fc-8f37-2fa0ed1a1151\"" -- set Interface tap3a71aa63-6a external-ids:iface-status=active +Oct 22 15:32:58 ybk140931 libvirtd[3237]: Unable to read from monitor: Connection reset by peer +Oct 22 15:32:59 ybk140931 ovs-vsctl[22001]: ovs|00001|vsctl|INFO|Called as ovs-vsctl --timeout=5 -- --if-exists del-port tap3a71aa63-6a +Oct 22 15:32:59 ybk140931 libvirtd[3237]: operation failed: domain is not running +Oct 22 15:32:59 ybk140931 libvirtd[3237]: internal error: qemu unexpectedly closed the monitor: 2021-10-22T15:32:58.845667Z qemu-system-x86_64: Failed to load virtio_pci/modern_queue_state:used + 2021-10-22T15:32:58.845687Z qemu-system-x86_64: Failed to load virtio_pci/modern_state:vqs + 2021-10-22T15:32:58.845690Z qemu-system-x86_64: Failed to load virtio/extra_state:extra_state + 2021-10-22T15:32:58.845692Z qemu-system-x86_64: Failed to load virtio-rng:virtio + 2021-10-22T15:32:58.845695Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:06.0/virtio-rng' + 2021-10-22T15:32:58.847860Z qemu-system-x86_64: load of migration failed: Input/output error +Oct 22 15:32:59 ybk140931 libvirtd[3237]: operation failed: domain 'instance-00000ba2' is not running +``` diff --git a/results/classifier/zero-shot/108/all/692570 b/results/classifier/zero-shot/108/all/692570 new file mode 100644 index 000000000..a8898dce6 --- /dev/null +++ b/results/classifier/zero-shot/108/all/692570 @@ -0,0 +1,126 @@ +debug: 0.994 +performance: 0.993 +boot: 0.993 +semantic: 0.992 +socket: 0.992 +permissions: 0.989 +device: 0.989 +other: 0.988 +PID: 0.986 +graphic: 0.986 +vnc: 0.984 +files: 0.978 +network: 0.968 +KVM: 0.961 + +APIC Latency causing BSOD. + +I have a Proxmox Server with the following specs: + +Version: + +pve-manager: 1.7-10 (pve-manager/1.7/5323) +running kernel: 2.6.32-4-pve +proxmox-ve-2.6.32: 1.7-28 +pve-kernel-2.6.32-4-pve: 2.6.32-28 +qemu-server: 1.1-25 +pve-firmware: 1.0-9 +libpve-storage-perl: 1.0-16 +vncterm: 0.9-2 +vzctl: 3.0.24-1pve4 +vzdump: 1.2-9 +vzprocps: 2.0.11-1dso2 +vzquota: 3.0.11-1 +pve-qemu-kvm: 0.13.0-2 +ksm-control-daemon: 1.0-4 + +VM Configuration: + +name: TS64 +ide2: none,media=cdrom +bootdisk: ide0 +ostype: w2k3 +ide0: data:vm-104-disk-1 +memory: 10240 +sockets: 1 +vlan0: virtio=C6:4C:B3:BB:AD:67 +onboot: 1 +cores: 4 +boot: cad +freeze: 0 +cpuunits: 1000 +acpi: 1 +kvm: 1 + +CPU 2x Xeon Quad Core E5620 2.4GHZ Processors: + +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 44 +model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz +stepping : 2 +cpu MHz : 2400.323 +cache size : 12288 KB +physical id : 0 +siblings : 8 +core id : 9 +cpu cores : 4 +apicid : 19 +initial apicid : 19 +fpu : yes +fpu_exception : yes +cpuid level : 11 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid +bogomips : 4800.19 +clflush size : 64 +cache_alignment : 64 +address sizes : 40 bits physical, 48 bits virtual +power management: + +Performance: + +CPU BOGOMIPS: 76803.21 +REGEX/SECOND: 850066 +HD SIZE: 33.96 GB (/dev/mapper/pve-root) +BUFFERED READS: 333.03 MB/sec +AVERAGE SEEK TIME: 6.10 ms +FSYNCS/SECOND: 2948.85 +DNS EXT: 131.42 ms +DNS INT: 1.28 ms + +I've been successfully running 2 Windows 2003 32-Bit Standard Edition Servers on this server for over a month now. Both were migrations from actual physical servers. However, I've continued to receive random crashes on a Windows 2003 64-bit standard edition running terminal services, which was a fresh install. The server runs fine for hours under a decent load (20 users) and then will crash with a 3B bug check code (System_Service_Exception). I opened a ticket with Microsoft and submitted multiple memory dumps and their engineers suggested the following: + +Dump Analyses Result: +=================== + +What happened is that the OS initiated an APIC /software interrupt. This is handled by the APIC in real hardware. In your Virtual Environment case where you are using Linux based VM – Proxmox, the VM implementation somehow has to make it happen on a virtual machine with the same latency in the virtual APIC. The problem is that there is a latency between when it was initiated and when it happened. + + +Below are the details for understanding the process or concept of APIC interrupts: + +What the Local APIC Is +The Local APIC (LAPIC) is a circuit that is part of the CPU chip. It contains these basic elements: +A mechanism for generating +1. interrupts +2. A mechanism for accepting interrupts +3. A timer + +If you have a multiprocessor system, the APIC's are wired together so they can communicate. So the LAPIC on CPU 0 can communicate with the LAPIC on CPU 1, etc. + + +What the IO APIC Is + +This is a separate chip that is wired to the Local APIC's so it can forward interrupts on to the CPU chips. It is programmed similar to the 8259's but has more flexibility. +It is wired to the same bus as the Local APIC's so it can communicate with them. + +Note:- In our scenario, it’s all Virtualized interrupts or calls because of hypervisor in picture and thus we need to contact the VM application vendor to get a check of this latency issue in APIC interrupt. +------------------------------------------------End of Message---------------------------------- + + + +Their engineers are saying that there is a latency issue with APIC. I'm not exactly sure how this can be corrected. Is this a known issue and is their a solution to this problem. I love Proxmox, but my main reason for using it was to upgrade my terminal server to better hardware, while leveraging it for other virtual machines as well. The forum administrator for Proxmox, suggested I bring this issue to your attention. + +Since there hasn't been an answer to this within the last years, it looks like nobody here knows about Proxmox problems. So let's close this ticket... + diff --git a/results/classifier/zero-shot/108/all/697510 b/results/classifier/zero-shot/108/all/697510 new file mode 100644 index 000000000..ccb5e4185 --- /dev/null +++ b/results/classifier/zero-shot/108/all/697510 @@ -0,0 +1,167 @@ +permissions: 0.986 +vnc: 0.977 +files: 0.975 +debug: 0.974 +semantic: 0.973 +performance: 0.970 +device: 0.966 +socket: 0.963 +other: 0.960 +boot: 0.955 +PID: 0.953 +graphic: 0.952 +KVM: 0.939 +network: 0.924 + +Machine shut off after tons of lsi_scsi: error: MSG IN data too long + +The problem mostly happens during our backup, syslog does not have any problematic messages. + +Host is Ubuntu 10.10 x86 64 bits +Guest is Windows 2003 Server 32 bits +Using Virtio and Red Hat driver I get a STOP screen 0x100000d1 and machine either reboot, stay frozen or shut off. +Using SCSI the machine shuts off and I get tons of message on stdout; + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 3500 -smp 4,sockets=4,cores=1,threads=1 -name BMSRV0101 -uuid 6ccbb5fa-5880-a1ab-3b7a-fb7ccc7c8ccf -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/BMSRV0101.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=localtime -boot c -device lsi,id=scsi0,bus=pci.0,addr=0x4 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/dev/vgUbuntu/vmBMSRV0101,if=none,id=drive-scsi0-0-0,boot=on,format=raw -device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:5d:7b:07,bus=pci.0,addr=0x3 -net tap,fd=63,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device usb-host,hostbus=002,hostaddr=005,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 +char device redirected to /dev/pts/0 +pci_add_option_rom: failed to find romfile "pxe-virtio.bin" +husb: open device 2.5 +husb: config #1 need -1 +husb: 1 interfaces claimed for configuration 1 +husb: grabbed usb device 2.5 +husb: config #1 need 1 +husb: 1 interfaces claimed for configuration 1 + +lsi_scsi: error: Unimplemented message 0x00 +(x8) + +lsi_scsi: error: MSG IN data too long +lsi_scsi: error: Unimplemented message 0x00 +(x760) + +lsi_scsi: error: MSG IN data too long +lsi_scsi: error: MSG IN data too long +kvm: /build/buildd/qemu-kvm-0.12.5+noroms/hw/lsi53c895a.c:512: lsi_do_dma: Assertion `s->current' failed. + + +I can include minidump file if needed. +I am currently using IDE and it seems OK. + +On Wed, Jan 5, 2011 at 5:05 AM, TiCPU <email address hidden> wrote: +> Using Virtio and Red Hat driver I get a STOP screen 0x100000d1 and machine either reboot, stay frozen or shut off. + +Here the minidump would be useful and we should get in touch with the +person that maintains the virtio-blk Windows driver. + +> Using SCSI the machine shuts off and I get tons of message on stdout; +[...] +> lsi_scsi: error: Unimplemented message 0x00 +> (x8) +> +> lsi_scsi: error: MSG IN data too long +> lsi_scsi: error: Unimplemented message 0x00 +> (x760) +> +> lsi_scsi: error: MSG IN data too long +> lsi_scsi: error: MSG IN data too long +> kvm: /build/buildd/qemu-kvm-0.12.5+noroms/hw/lsi53c895a.c:512: lsi_do_dma: Assertion `s->current' failed. + +Looks like the LSI SCSI device emulation is getting out of sync with +the guest's device driver. + +Can you give more details or a test case that reproduces these +problems? Which backup software are you using and is it known to do +special purpose SCSI commands? + +Stefan + +On Thu, Jan 6, 2011 at 9:43 AM, Stefan Hajnoczi <email address hidden> wrote: +> On Wed, Jan 5, 2011 at 5:05 AM, TiCPU <email address hidden> wrote: +>> Using Virtio and Red Hat driver I get a STOP screen 0x100000d1 and machine either reboot, stay frozen or shut off. +> +> Here the minidump would be useful and we should get in touch with the +> person that maintains the virtio-blk Windows driver. + +Vadim, do you maintain the virtio-blk Windows driver? Perhaps you +have some ideas on how to debug this? + +Stefan + +"Red Hat driver" means driver from rhel virtio-win.prm? + +Some new informations, the IDE bus works for a while then the PC slows down and finally backup fails and freeze most of the I/Os. + +The underlying device is a Iomega REV 120 USB appearing as a CD-ROM, /dev/sr0 and using FAT32 with 32k clusters. +The backup program is Symantec Backup Exec 11d + +I worked around the problem by formatting the REV 120 back to UDF and sharing it via Samba, BackupExec now backups to the REV via network. + +I tried iSCSI and had problems too. + +I attached all the minidumps, they all look the same. + +Can you try viostor with sptd (scsi pass through direct) disabled? + +Triaging old bug tickets ... do you still have this problem with the latest version of QEMU, or could we close this bug nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + +We found a reproducer during fuzzing: + +``` +qemu-system-x86_64: hw/scsi/lsi53c895a.c:624: lsi_do_dma: Assertion `s->current' failed. +``` + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash.iso -nographic -m 100 -enable-kvm -net none -device ich9-usb-ehci1 -device usb-tablet -device lsi53c810,id=scsi0 -drive file=hda.img,if=none,format=raw,discard=unmap,cache=none,id=someid -device scsi-hd,drive=someid,bus=scsi0.0 +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` + +To create disk image run: +``` +dd if=/dev/zero of=hda.img bs=1024 count=1024 +``` + +Here is a qtest reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 -nographic -M q35,accel=qtest -qtest stdio -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw -device lsi53c895a,id=scsi0 -device scsi-hd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -monitor none -serial none +outl 0xcf8 0x80001814 +outl 0xcfc 0xe1068000 +outl 0xcf8 0x80001818 +outl 0xcf8 0x80001804 +outw 0xcfc 0x7 +outl 0xcf8 0x80002010 +write 0xe106802e 0x1 0xff +write 0xe106802f 0x1 0xff +EOF + +With -trace lsi\*: +... +[R +0.037396] write 0xe106802e 0x1 0xff +15257@1594419708.889733:lsi_reg_write Write reg DSP2 0x2e = 0xff +OK +[S +0.037420] OK +[R +0.037434] write 0xe106802f 0x1 0xff +15257@1594419708.889814:lsi_reg_write Write reg DSP3 0x2f = 0xff +15257@1594419708.889862:lsi_execute_script SCRIPTS dsp=0xffff0000 opcode 0x105e8b06 arg 0x89084e8b +qemu-system-i386: /home/alxndr/Development/qemu/hw/scsi/lsi53c895a.c:624: void lsi_do_dma(LSIState *, int): Assertion `s->current' failed. + + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/84 + + diff --git a/results/classifier/zero-shot/108/all/698 b/results/classifier/zero-shot/108/all/698 new file mode 100644 index 000000000..03645d136 --- /dev/null +++ b/results/classifier/zero-shot/108/all/698 @@ -0,0 +1,373 @@ +other: 0.959 +debug: 0.950 +device: 0.949 +performance: 0.947 +files: 0.944 +permissions: 0.944 +KVM: 0.943 +semantic: 0.940 +boot: 0.937 +vnc: 0.937 +network: 0.933 +socket: 0.932 +PID: 0.930 +graphic: 0.927 + +linux-user: emulated process reading /proc/self/mem doesn't see guest view of memory map +Description of problem: +QEMU user-mode emulation of a 32-bit guest on a 64-bit host doesn't seem to emulate `/proc/self/mem` (or `/proc/$pid/mem`) correctly. Based on the contents of `/proc/self/maps`, there seems to be some sort of address translation happening that `/proc/self/mem` doesn't honor. + +The following source file: + +```c +#include <fcntl.h> +#include <inttypes.h> +#include <stdbool.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <sys/wait.h> + +static const char string[] = "Hello, world!\n"; + +static bool copy_to_stdout(const char *path) +{ + bool success = false; + + int fd = open(path, O_RDONLY); + if (fd < 0) { + perror("open"); + return false; + } + + char buf[16 * 1024]; + while (true) { + ssize_t bytes_read = read(fd, buf, sizeof(buf)); + if (bytes_read == 0) { + success = true; + goto out; + } else if (bytes_read < 0) { + perror("read"); + goto out; + } + ssize_t bytes_written = 0; + while (bytes_written < bytes_read) { + ssize_t ret = write(STDOUT_FILENO, buf + bytes_written, + bytes_read - bytes_written); + if (ret < 0) { + perror("write"); + goto out; + } + bytes_written += ret; + } + } + +out: + close(fd); + return success; +} + +static bool dump_maps(void) +{ + printf("Maps read by self:\n"); + fflush(stdout); + if (!copy_to_stdout("/proc/self/maps")) + return false; + + printf("\nMaps read by child process:\n"); + fflush(stdout); + pid_t pid = fork(); + if (pid < 0) { + perror("fork"); + return false; + } + if (pid == 0) { + char parent_maps[32]; + sprintf(parent_maps, "/proc/%u/maps", (unsigned int)getppid()); + if (copy_to_stdout(parent_maps)) + _exit(EXIT_SUCCESS); + else + _exit(EXIT_FAILURE); + } + int wstatus; + if (waitpid(pid, &wstatus, 0) < 0 || + !WIFEXITED(wstatus) || WEXITSTATUS(wstatus) != EXIT_SUCCESS) + return false; + + printf("\n"); + return true; +} + +int main(void) +{ + if (!dump_maps()) + return EXIT_FAILURE; + + int fd = open("/proc/self/mem", O_RDONLY); + if (fd < 0) { + perror("open: /proc/self/mem"); + return EXIT_FAILURE; + } + + char buf[sizeof(string)]; + printf("Reading %zu bytes from %p (%" PRIuPTR ") to %p of PID %u\n", + sizeof(buf), string, (uintptr_t)string, buf, + (unsigned int)getpid()); + fflush(stdout); + + if (pread(fd, buf, sizeof(buf), (uintptr_t)string) < 0) { + perror("pread: /proc/self/mem"); + return EXIT_FAILURE; + } + + if (memcmp(buf, string, sizeof(buf)) != 0) { + fprintf(stderr, "buffer doesn't match\n"); + return EXIT_FAILURE; + } + + return EXIT_SUCCESS; +} +``` + +when compiled for 32-bit ARM produces the following output: + +``` +Maps read by self: +10000-7c000 r-xp 00000000 00:19 8275924 /home/osandov/repro +7c000-8b000 ---p 00000000 00:00 0 +8b000-8c000 r--p 0006b000 00:19 8275924 /home/osandov/repro +8c000-8d000 rw-p 0006c000 00:19 8275924 /home/osandov/repro +8d000-b0000 rw-p 00000000 00:00 0 +3ffff000-40000000 r-xp 00000000 00:00 0 +40000000-40001000 ---p 00000000 00:00 0 +40001000-40801000 rw-p 00000000 00:00 0 [stack] + +Maps read by child process: +00010000-00020000 ---p 00000000 00:00 0 +00020000-0008c000 r--p 00000000 00:19 8275924 /home/osandov/repro +0008c000-0009b000 ---p 00000000 00:00 0 +0009b000-0009c000 r--p 0006b000 00:19 8275924 /home/osandov/repro +0009c000-0009d000 rw-p 0006c000 00:19 8275924 /home/osandov/repro +0009d000-000c0000 rw-p 00000000 00:00 0 +000c0000-4000f000 ---p 00000000 00:00 0 +4000f000-40010000 r--p 00000000 00:00 0 +40010000-40011000 ---p 00000000 00:00 0 +40011000-40811000 rw-p 00000000 00:00 0 +40811000-100000000 ---p 00000000 00:00 0 +100000000-100001000 r--p 00000000 00:00 0 +5636dd7a2000-5636dd8a4000 r--p 00000000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636dd8a4000-5636ddb13000 r-xp 00102000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636ddb13000-5636ddf69000 r--p 00371000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636ddf6a000-5636ddfe7000 r--p 007c7000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636ddfe7000-5636ddff3000 rw-p 00844000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636ddff3000-5636de010000 rw-p 00000000 00:00 0 +5636df67b000-5636df80c000 rw-p 00000000 00:00 0 [heap] +7f3008000000-7f300ffff000 rwxp 00000000 00:00 0 +7f300ffff000-7f3010000000 ---p 00000000 00:00 0 +7f3010000000-7f3010021000 rw-p 00000000 00:00 0 +7f3010021000-7f3014000000 ---p 00000000 00:00 0 +7f3017119000-7f301719a000 rw-p 00000000 00:00 0 +7f301719a000-7f301719b000 ---p 00000000 00:00 0 +7f301719b000-7f30179a1000 rw-p 00000000 00:00 0 +7f30179a1000-7f30179a3000 r--p 00000000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179a3000-7f30179a9000 r-xp 00002000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179a9000-7f30179ab000 r--p 00008000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179ab000-7f30179ac000 r--p 00009000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179ac000-7f30179ad000 rw-p 0000a000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179ad000-7f30179be000 r--p 00000000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f30179be000-7f3017a32000 r-xp 00011000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a32000-7f3017a49000 r--p 00085000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a49000-7f3017a4a000 ---p 0009c000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a4a000-7f3017a4c000 r--p 0009c000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a4c000-7f3017a4d000 rw-p 0009e000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a4d000-7f3017a56000 r--p 00000000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a56000-7f3017a69000 r-xp 00009000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a69000-7f3017a93000 r--p 0001c000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a93000-7f3017a95000 r--p 00045000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a95000-7f3017a96000 rw-p 00047000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a96000-7f3017a98000 rw-p 00000000 00:00 0 +7f3017a98000-7f3017aa4000 r--p 00000000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017aa4000-7f3017ac5000 r-xp 0000c000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017ac5000-7f3017adb000 r--p 0002d000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017adb000-7f3017adc000 ---p 00043000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017adc000-7f3017ade000 r--p 00043000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017ade000-7f3017adf000 rw-p 00045000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017adf000-7f3017ae2000 r--p 00000000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017ae2000-7f3017aee000 r-xp 00003000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017aee000-7f3017af2000 r--p 0000f000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017af2000-7f3017af3000 ---p 00013000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017af3000-7f3017af4000 r--p 00013000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017af4000-7f3017af5000 rw-p 00014000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017af5000-7f3017b06000 r--p 00000000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017b06000-7f3017b3b000 r-xp 00011000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017b3b000-7f3017c72000 r--p 00046000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017c72000-7f3017c76000 r--p 0017c000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017c76000-7f3017c77000 rw-p 00180000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017c77000-7f3017c79000 r--p 00000000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c79000-7f3017c7d000 r-xp 00002000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c7d000-7f3017c97000 r--p 00006000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c97000-7f3017c98000 r--p 0001f000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c98000-7f3017c99000 rw-p 00020000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c99000-7f3017cc2000 r--p 00000000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017cc2000-7f3017d60000 r-xp 00029000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017d60000-7f3017dba000 r--p 000c7000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017dba000-7f3017dc4000 r--p 00120000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017dc4000-7f3017dce000 rw-p 0012a000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017dce000-7f3017dd0000 r--p 00000000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd0000-7f3017dd2000 r-xp 00002000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd2000-7f3017dd3000 r--p 00004000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd3000-7f3017dd4000 r--p 00004000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd4000-7f3017dd5000 rw-p 00005000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd5000-7f3017dd7000 rw-p 00000000 00:00 0 +7f3017dd7000-7f3017dd9000 r--p 00000000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017dd9000-7f3017e2f000 r-xp 00002000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017e2f000-7f3017e4c000 r--p 00058000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017e4c000-7f3017e4d000 r--p 00074000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017e4d000-7f3017e4e000 rw-p 00075000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017e4e000-7f3017e74000 r--p 00000000 00:19 2549806 /usr/lib/libc-2.33.so +7f3017e74000-7f3017fbf000 r-xp 00026000 00:19 2549806 /usr/lib/libc-2.33.so +7f3017fbf000-7f301800b000 r--p 00171000 00:19 2549806 /usr/lib/libc-2.33.so +7f301800b000-7f301800e000 r--p 001bc000 00:19 2549806 /usr/lib/libc-2.33.so +7f301800e000-7f3018011000 rw-p 001bf000 00:19 2549806 /usr/lib/libc-2.33.so +7f3018011000-7f301801a000 rw-p 00000000 00:00 0 +7f301801a000-7f3018021000 r--p 00000000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018021000-7f3018030000 r-xp 00007000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018030000-7f3018034000 r--p 00016000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018034000-7f3018035000 ---p 0001a000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018035000-7f3018036000 r--p 0001a000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018036000-7f3018037000 rw-p 0001b000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018037000-7f301803b000 rw-p 00000000 00:00 0 +7f301803b000-7f301803e000 r--p 00000000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f301803e000-7f3018050000 r-xp 00003000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018050000-7f3018053000 r--p 00015000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018053000-7f3018054000 ---p 00018000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018054000-7f3018055000 r--p 00018000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018055000-7f3018056000 rw-p 00019000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018056000-7f3018065000 r--p 00000000 00:19 2549819 /usr/lib/libm-2.33.so +7f3018065000-7f30180ff000 r-xp 0000f000 00:19 2549819 /usr/lib/libm-2.33.so +7f30180ff000-7f3018197000 r--p 000a9000 00:19 2549819 /usr/lib/libm-2.33.so +7f3018197000-7f3018198000 ---p 00141000 00:19 2549819 /usr/lib/libm-2.33.so +7f3018198000-7f3018199000 r--p 00141000 00:19 2549819 /usr/lib/libm-2.33.so +7f3018199000-7f301819a000 rw-p 00142000 00:19 2549819 /usr/lib/libm-2.33.so +7f301819a000-7f3018233000 r--p 00000000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f3018233000-7f3018333000 r-xp 00099000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f3018333000-7f301839f000 r--p 00199000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f301839f000-7f30183ac000 r--p 00204000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f30183ac000-7f30183ad000 rw-p 00211000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f30183ad000-7f30183b2000 rw-p 00000000 00:00 0 +7f30183b2000-7f30183e6000 r--p 00000000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f30183e6000-7f3018508000 r-xp 00034000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f3018508000-7f301859d000 r--p 00156000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f301859d000-7f301859e000 ---p 001eb000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f301859e000-7f30185af000 r--p 001eb000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f30185af000-7f30185b1000 rw-p 001fc000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f30185b1000-7f30185b3000 rw-p 00000000 00:00 0 +7f30185b3000-7f30185b5000 r--p 00000000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185b5000-7f30185b7000 r-xp 00002000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185b7000-7f30185b8000 r--p 00004000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185b8000-7f30185b9000 r--p 00004000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185b9000-7f30185ba000 rw-p 00005000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185ba000-7f30185d7000 r--p 00000000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30185d7000-7f3018664000 r-xp 0001d000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f3018664000-7f30186ec000 r--p 000aa000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30186ec000-7f30186ed000 ---p 00132000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30186ed000-7f30186ee000 r--p 00132000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30186ee000-7f30186ef000 rw-p 00133000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30186ef000-7f30186f0000 rw-p 00000000 00:00 0 +7f30186f0000-7f30186f2000 r--p 00000000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f2000-7f30186f4000 r-xp 00002000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f4000-7f30186f5000 r--p 00004000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f5000-7f30186f6000 r--p 00004000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f6000-7f30186f7000 rw-p 00005000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f7000-7f30186fa000 r--p 00000000 00:19 2549855 /usr/lib/librt-2.33.so +7f30186fa000-7f30186fe000 r-xp 00003000 00:19 2549855 /usr/lib/librt-2.33.so +7f30186fe000-7f3018700000 r--p 00007000 00:19 2549855 /usr/lib/librt-2.33.so +7f3018700000-7f3018701000 r--p 00008000 00:19 2549855 /usr/lib/librt-2.33.so +7f3018701000-7f3018702000 rw-p 00009000 00:19 2549855 /usr/lib/librt-2.33.so +7f3018702000-7f3018705000 r--p 00000000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f3018705000-7f3018713000 r-xp 00003000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f3018713000-7f3018719000 r--p 00011000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f3018719000-7f301871a000 ---p 00017000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f301871a000-7f301871b000 r--p 00017000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f301871b000-7f301871c000 rw-p 00018000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f301871c000-7f301871e000 rw-p 00000000 00:00 0 +7f301871e000-7f301871f000 r--p 00000000 00:19 2549795 /usr/lib/ld-2.33.so +7f301871f000-7f3018743000 r-xp 00001000 00:19 2549795 /usr/lib/ld-2.33.so +7f3018743000-7f301874c000 r--p 00025000 00:19 2549795 /usr/lib/ld-2.33.so +7f301874c000-7f301874e000 r--p 0002d000 00:19 2549795 /usr/lib/ld-2.33.so +7f301874e000-7f3018750000 rw-p 0002f000 00:19 2549795 /usr/lib/ld-2.33.so +7ffc5c8f6000-7ffc5c917000 rw-p 00000000 00:00 0 [stack] +7ffc5c935000-7ffc5c939000 r--p 00000000 00:00 0 [vvar] +7ffc5c939000-7ffc5c93b000 r-xp 00000000 00:00 0 [vdso] +ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] + +Reading 15 bytes from 0x6377c (407420) to 0x40800638 of PID 278331 +buffer doesn't match +``` + +The program is trying to read from 0x6377c, which according to the emulated maps is in this mapping: + +``` +10000-7c000 r-xp 00000000 00:19 8275924 /home/osandov/repro +``` + +but on the host, it's mapped differently: + +``` +00020000-0008c000 r--p 00000000 00:19 8275924 /home/osandov/repro +``` + +When using `qemu-arm-static` (version `6.1.0 (Debian 1:6.1+dfsg-6)`) via `binfmt_misc`, I also saw a case where the address isn't mapped in the host at all: + +``` +Maps read by self: +10000-7c000 r-xp 00000000 00:19 8275924 /home/osandov/repro +7c000-8b000 ---p 00000000 00:00 0 +8b000-8c000 r--p 0006b000 00:19 8275924 /home/osandov/repro +8c000-8d000 rw-p 0006c000 00:19 8275924 /home/osandov/repro +8d000-b0000 rw-p 00000000 00:00 0 +40000000-40001000 ---p 00000000 00:00 0 +40001000-40801000 rw-p 00000000 00:00 0 [stack] + +Maps read by child process: +00400000-00401000 r--p 00000000 00:19 297 /usr/bin/qemu-arm-static +00401000-00769000 r-xp 00001000 00:19 297 /usr/bin/qemu-arm-static +00769000-00abe000 r--p 00369000 00:19 297 /usr/bin/qemu-arm-static +00abe000-00c58000 r--p 006bd000 00:19 297 /usr/bin/qemu-arm-static +00c58000-00cd3000 rw-p 00857000 00:19 297 /usr/bin/qemu-arm-static +00cd3000-00cf7000 rw-p 00000000 00:00 0 +0253c000-0268e000 rw-p 00000000 00:00 0 [heap] +42645000-42655000 ---p 00000000 00:00 0 +42655000-426c1000 r--p 00000000 00:19 8275924 /home/osandov/repro +426c1000-426d0000 ---p 00000000 00:00 0 +426d0000-426d1000 r--p 0006b000 00:19 8275924 /home/osandov/repro +426d1000-426d2000 rw-p 0006c000 00:19 8275924 /home/osandov/repro +426d2000-426f5000 rw-p 00000000 00:00 0 +426f5000-82645000 ---p 00000000 00:00 0 +82645000-82646000 ---p 00000000 00:00 0 +82646000-82e46000 rw-p 00000000 00:00 0 +82e46000-142635000 ---p 00000000 00:00 0 +142635000-142636000 r--p 00000000 00:00 0 +7f5584000000-7f558bfff000 rwxp 00000000 00:00 0 +7f558bfff000-7f558c000000 ---p 00000000 00:00 0 +7f558c000000-7f558c021000 rw-p 00000000 00:00 0 +7f558c021000-7f5590000000 ---p 00000000 00:00 0 +7f55929b5000-7f5592a36000 rw-p 00000000 00:00 0 +7f5592a36000-7f5592a37000 ---p 00000000 00:00 0 +7f5592a37000-7f5593237000 rw-p 00000000 00:00 0 +7ffc4971a000-7ffc4973b000 rw-p 00000000 00:00 0 [stack] +7ffc497fa000-7ffc497fe000 r--p 00000000 00:00 0 [vvar] +7ffc497fe000-7ffc49800000 r-xp 00000000 00:00 0 [vdso] +ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] + +Reading 15 bytes from 0x6377c (407420) to 0x40800648 of PID 278443 +pread: /proc/self/mem: Input/output error +``` +Steps to reproduce: +1. Download statically-linked ARM [reproducer](/uploads/5563ad67d01f0ec4a10f27d1967216c4/repro). +2. Run `qemu-arm ./repro`. +Additional information: +I encountered this when trying out a CI system that uses QEMU user-mode emulation for 32-bit ARM builds. My project is a debugger that uses `/proc/self/mem`, and a test case tripped over this. See https://github.com/osandov/drgn/pull/126. + +This also seems to happen with a i386 guest, but not with an aarch64 guest, so I'm assuming that it's a 32-bit guest issue. diff --git a/results/classifier/zero-shot/108/all/804517 b/results/classifier/zero-shot/108/all/804517 new file mode 100644 index 000000000..af233fb85 --- /dev/null +++ b/results/classifier/zero-shot/108/all/804517 @@ -0,0 +1,112 @@ +other: 0.967 +boot: 0.965 +debug: 0.961 +permissions: 0.961 +semantic: 0.960 +performance: 0.958 +device: 0.955 +socket: 0.952 +PID: 0.952 +network: 0.951 +files: 0.948 +vnc: 0.948 +graphic: 0.943 +KVM: 0.915 + +qemu crashes on Darwin in qemu_iohandler_poll + +I have an issue when I try to run qemu-system-arm on Mac OS X. +Sometime between 1 and 15 secs after qemu is started it crashes +as shown bellow. + +Same thing on linux host works fine. + +Is anybody else experiencing this? +Any Hints? + +Thanks, + +Damjan + + + +(gdb) run +Starting program: /opt/arm-qemu/bin/qemu-system-arm -M verdex -pflash flash.img -nographic -monitor null -m 289 +Reading symbols for shared libraries .++++++++++++++........................................................................................ done +pxa2xx_clkpwr_write: CPU frequency change attempt + + +U-Boot 1.2.0 (May 10 2008 - 21:17:19) - PXA270@400 MHz - 1604 + +*** Welcome to Gumstix *** + +DRAM: 256 MB +Flash: 32 MB +Using default environment + +Hit any key to stop autoboot: 1 +Program received signal EXC_BAD_ACCESS, Could not access memory. +Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5fbfed30 +0x00007fff5fbfed30 in ?? () +(gdb) +(gdb) bt +#0 0x00007fff5fbfed30 in ?? () +#1 0x00000001000c26f4 in qemu_iohandler_poll () +#2 0x00000001001975ae in main_loop_wait () +#3 0x00000001001976e2 in main_loop () +#4 0x000000010019bfbc in qemu_main () +#5 0x00000001000d63a5 in main () +(gdb) + +fter bisection seems that this starts happening after following patch: + +commit 09716e45a05cc0c93bcf55bd0c0888dd678e490f +Author: Alexander Graf <email address hidden> +Date: Thu Jun 9 00:55:37 2011 +0200 + + sigfd: use pthread_sigmask + + +diff --git a/compatfd.c b/compatfd.c +index bd377c4..41586ce 100644 +--- a/compatfd.c ++++ b/compatfd.c +@@ -29,7 +29,7 @@ static void *sigwait_compat(void *opaque) + sigset_t all; + + sigfillset(&all); +- sigprocmask(SIG_BLOCK, &all, NULL); ++ pthread_sigmask(SIG_BLOCK, &all, NULL); + + while (1) { + + +However before this patch qemu doesn't respond to keyboard (i.e. commit 31b7c261). + +Last full working commit is 630ecca. + + +I am seeing the same think when I try to run a sample built under gcc from the TI tools + +117 void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, fd_set *xfds, int ret) +118 { +119 if (ret > 0) { +120 IOHandlerRecord *pioh, *ioh; +121 +122 QLIST_FOREACH_SAFE(ioh, &io_handlers, next, pioh) { +(gdb) l +123 if (!ioh->deleted && ioh->fd_read && FD_ISSET(ioh->fd, readfds)) { +124 ioh->fd_read(ioh->opaque); +125 } + +(gdb) print ioh +$2 = (IOHandlerRecord *) 0x5 + +However Peter Maydell sent me a kernel image that runs fine on OS X. However when I try to run it under gdb I get the same problem that you see. + +Oliver + +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/zero-shot/108/all/80570214 b/results/classifier/zero-shot/108/all/80570214 new file mode 100644 index 000000000..b531fb673 --- /dev/null +++ b/results/classifier/zero-shot/108/all/80570214 @@ -0,0 +1,410 @@ +vnc: 0.983 +permissions: 0.983 +debug: 0.979 +semantic: 0.978 +other: 0.978 +graphic: 0.978 +performance: 0.976 +PID: 0.976 +network: 0.975 +socket: 0.975 +device: 0.974 +KVM: 0.971 +boot: 0.969 +files: 0.961 + +[Qemu-devel] [vhost-user BUG ?] QEMU process segfault when shutdown or reboot with vhost-user + +Hi, + +We catch a segfault in our project. + +Qemu version is 2.3.0 + +The Stack backtrace is: +(gdb) bt +#0 0x0000000000000000 in ?? () +#1 0x00007f7ad9280b2f in qemu_deliver_packet (sender=<optimized out>, flags=<optimized +out>, data=<optimized out>, size=100, opaque= + 0x7f7ad9d6db10) at net/net.c:510 +#2 0x00007f7ad92831fa in qemu_net_queue_deliver (size=<optimized out>, data=<optimized +out>, flags=<optimized out>, + sender=<optimized out>, queue=<optimized out>) at net/queue.c:157 +#3 qemu_net_queue_flush (queue=0x7f7ad9d39630) at net/queue.c:254 +#4 0x00007f7ad9280dac in qemu_flush_or_purge_queued_packets +(nc=0x7f7ad9d6db10, purge=true) at net/net.c:539 +#5 0x00007f7ad9280e76 in net_vm_change_state_handler (opaque=<optimized out>, +running=<optimized out>, state=100) at net/net.c:1214 +#6 0x00007f7ad915612f in vm_state_notify (running=0, state=RUN_STATE_SHUTDOWN) +at vl.c:1820 +#7 0x00007f7ad906db1a in do_vm_stop (state=<optimized out>) at +/usr/src/packages/BUILD/qemu-kvm-2.3.0/cpus.c:631 +#8 vm_stop (state=RUN_STATE_SHUTDOWN) at +/usr/src/packages/BUILD/qemu-kvm-2.3.0/cpus.c:1325 +#9 0x00007f7ad915e4a2 in main_loop_should_exit () at vl.c:2080 +#10 main_loop () at vl.c:2131 +#11 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at +vl.c:4721 +(gdb) p *(NetClientState *)0x7f7ad9d6db10 +$1 = {info = 0x7f7ad9824520, link_down = 0, next = {tqe_next = 0x7f7ad0f06d10, +tqe_prev = 0x7f7ad98b1cf0}, peer = 0x7f7ad0f06d10, + incoming_queue = 0x7f7ad9d39630, model = 0x7f7ad9d39590 "vhost_user", name = +0x7f7ad9d39570 "hostnet0", info_str = + "vhost-user to charnet0", '\000' <repeats 233 times>, receive_disabled = 0, +destructor = + 0x7f7ad92821f0 <qemu_net_client_destructor>, queue_index = 0, +rxfilter_notify_enabled = 0} +(gdb) p *(NetClientInfo *)0x7f7ad9824520 +$2 = {type = NET_CLIENT_OPTIONS_KIND_VHOST_USER, size = 360, receive = 0, +receive_raw = 0, receive_iov = 0, can_receive = 0, cleanup = + 0x7f7ad9288850 <vhost_user_cleanup>, link_status_changed = 0, +query_rx_filter = 0, poll = 0, has_ufo = + 0x7f7ad92886d0 <vhost_user_has_ufo>, has_vnet_hdr = 0x7f7ad9288670 +<vhost_user_has_vnet_hdr>, has_vnet_hdr_len = 0, + using_vnet_hdr = 0, set_offload = 0, set_vnet_hdr_len = 0} +(gdb) + +The corresponding codes where gdb reports error are: (We have added some codes +in net.c) +ssize_t qemu_deliver_packet(NetClientState *sender, + unsigned flags, + const uint8_t *data, + size_t size, + void *opaque) +{ + NetClientState *nc = opaque; + ssize_t ret; + + if (nc->link_down) { + return size; + } + + if (nc->receive_disabled) { + return 0; + } + + if (flags & QEMU_NET_PACKET_FLAG_RAW && nc->info->receive_raw) { + ret = nc->info->receive_raw(nc, data, size); + } else { + ret = nc->info->receive(nc, data, size); ----> Here is 510 line + } + +I'm not quite familiar with vhost-user, but for vhost-user, these two callback +functions seem to be always NULL, +Why we can come here ? +Is it an error to add VM state change handler for vhost-user ? + +Thanks, +zhanghailiang + +Hi + +On Tue, Nov 3, 2015 at 2:01 PM, zhanghailiang +<address@hidden> wrote: +> +The corresponding codes where gdb reports error are: (We have added some +> +codes in net.c) +Can you reproduce with unmodified qemu? Could you give instructions to do so? + +> +ssize_t qemu_deliver_packet(NetClientState *sender, +> +unsigned flags, +> +const uint8_t *data, +> +size_t size, +> +void *opaque) +> +{ +> +NetClientState *nc = opaque; +> +ssize_t ret; +> +> +if (nc->link_down) { +> +return size; +> +} +> +> +if (nc->receive_disabled) { +> +return 0; +> +} +> +> +if (flags & QEMU_NET_PACKET_FLAG_RAW && nc->info->receive_raw) { +> +ret = nc->info->receive_raw(nc, data, size); +> +} else { +> +ret = nc->info->receive(nc, data, size); ----> Here is 510 line +> +} +> +> +I'm not quite familiar with vhost-user, but for vhost-user, these two +> +callback functions seem to be always NULL, +> +Why we can come here ? +You should not come here, vhost-user has nc->receive_disabled (it +changes in 2.5) + +-- +Marc-André Lureau + +On 2015/11/3 22:54, Marc-André Lureau wrote: +Hi + +On Tue, Nov 3, 2015 at 2:01 PM, zhanghailiang +<address@hidden> wrote: +The corresponding codes where gdb reports error are: (We have added some +codes in net.c) +Can you reproduce with unmodified qemu? Could you give instructions to do so? +OK, i will try to do it. There is nothing special, we run iperf tool in VM, +and then shutdown or reboot it. There is change you can catch segfault. +ssize_t qemu_deliver_packet(NetClientState *sender, + unsigned flags, + const uint8_t *data, + size_t size, + void *opaque) +{ + NetClientState *nc = opaque; + ssize_t ret; + + if (nc->link_down) { + return size; + } + + if (nc->receive_disabled) { + return 0; + } + + if (flags & QEMU_NET_PACKET_FLAG_RAW && nc->info->receive_raw) { + ret = nc->info->receive_raw(nc, data, size); + } else { + ret = nc->info->receive(nc, data, size); ----> Here is 510 line + } + +I'm not quite familiar with vhost-user, but for vhost-user, these two +callback functions seem to be always NULL, +Why we can come here ? +You should not come here, vhost-user has nc->receive_disabled (it +changes in 2.5) +I have looked at the newest codes, i think we can still have chance to +come here, since we will change nc->receive_disable to false temporarily in +qemu_flush_or_purge_queued_packets(), there is no difference between 2.3 and 2.5 +for this. +Besides, is it possible for !QTAILQ_EMPTY(&queue->packets) to be true +in qemu_net_queue_flush() for vhost-user ? + +i will try to reproduce it by using newest qemu. + +Thanks, +zhanghailiang + +On 11/04/2015 10:24 AM, zhanghailiang wrote: +> +On 2015/11/3 22:54, Marc-André Lureau wrote: +> +> Hi +> +> +> +> On Tue, Nov 3, 2015 at 2:01 PM, zhanghailiang +> +> <address@hidden> wrote: +> +>> The corresponding codes where gdb reports error are: (We have added +> +>> some +> +>> codes in net.c) +> +> +> +> Can you reproduce with unmodified qemu? Could you give instructions +> +> to do so? +> +> +> +> +OK, i will try to do it. There is nothing special, we run iperf tool +> +in VM, +> +and then shutdown or reboot it. There is change you can catch segfault. +> +> +>> ssize_t qemu_deliver_packet(NetClientState *sender, +> +>> unsigned flags, +> +>> const uint8_t *data, +> +>> size_t size, +> +>> void *opaque) +> +>> { +> +>> NetClientState *nc = opaque; +> +>> ssize_t ret; +> +>> +> +>> if (nc->link_down) { +> +>> return size; +> +>> } +> +>> +> +>> if (nc->receive_disabled) { +> +>> return 0; +> +>> } +> +>> +> +>> if (flags & QEMU_NET_PACKET_FLAG_RAW && nc->info->receive_raw) { +> +>> ret = nc->info->receive_raw(nc, data, size); +> +>> } else { +> +>> ret = nc->info->receive(nc, data, size); ----> Here is +> +>> 510 line +> +>> } +> +>> +> +>> I'm not quite familiar with vhost-user, but for vhost-user, these two +> +>> callback functions seem to be always NULL, +> +>> Why we can come here ? +> +> +> +> You should not come here, vhost-user has nc->receive_disabled (it +> +> changes in 2.5) +> +> +> +> +I have looked at the newest codes, i think we can still have chance to +> +come here, since we will change nc->receive_disable to false +> +temporarily in +> +qemu_flush_or_purge_queued_packets(), there is no difference between +> +2.3 and 2.5 +> +for this. +> +Besides, is it possible for !QTAILQ_EMPTY(&queue->packets) to be true +> +in qemu_net_queue_flush() for vhost-user ? +The only thing I can image is self announcing. Are you trying to do +migration? 2.5 only support sending rarp through this. + +And it's better to have a breakpoint to see why a packet was queued for +vhost-user. The stack trace may also help in this case. + +> +> +i will try to reproduce it by using newest qemu. +> +> +Thanks, +> +zhanghailiang +> + +On 2015/11/4 11:19, Jason Wang wrote: +On 11/04/2015 10:24 AM, zhanghailiang wrote: +On 2015/11/3 22:54, Marc-André Lureau wrote: +Hi + +On Tue, Nov 3, 2015 at 2:01 PM, zhanghailiang +<address@hidden> wrote: +The corresponding codes where gdb reports error are: (We have added +some +codes in net.c) +Can you reproduce with unmodified qemu? Could you give instructions +to do so? +OK, i will try to do it. There is nothing special, we run iperf tool +in VM, +and then shutdown or reboot it. There is change you can catch segfault. +ssize_t qemu_deliver_packet(NetClientState *sender, + unsigned flags, + const uint8_t *data, + size_t size, + void *opaque) +{ + NetClientState *nc = opaque; + ssize_t ret; + + if (nc->link_down) { + return size; + } + + if (nc->receive_disabled) { + return 0; + } + + if (flags & QEMU_NET_PACKET_FLAG_RAW && nc->info->receive_raw) { + ret = nc->info->receive_raw(nc, data, size); + } else { + ret = nc->info->receive(nc, data, size); ----> Here is +510 line + } + +I'm not quite familiar with vhost-user, but for vhost-user, these two +callback functions seem to be always NULL, +Why we can come here ? +You should not come here, vhost-user has nc->receive_disabled (it +changes in 2.5) +I have looked at the newest codes, i think we can still have chance to +come here, since we will change nc->receive_disable to false +temporarily in +qemu_flush_or_purge_queued_packets(), there is no difference between +2.3 and 2.5 +for this. +Besides, is it possible for !QTAILQ_EMPTY(&queue->packets) to be true +in qemu_net_queue_flush() for vhost-user ? +The only thing I can image is self announcing. Are you trying to do +migration? 2.5 only support sending rarp through this. +Hmm, it's not triggered by migration, For qemu-2.5, IMHO, it doesn't have such +problem, +since the callback function 'receive' is not NULL. It is vhost_user_receive(). +And it's better to have a breakpoint to see why a packet was queued for +vhost-user. The stack trace may also help in this case. +OK, i'm trying to reproduce it. + +Thanks, +zhanghailiang +i will try to reproduce it by using newest qemu. + +Thanks, +zhanghailiang +. + diff --git a/results/classifier/zero-shot/108/all/807893 b/results/classifier/zero-shot/108/all/807893 new file mode 100644 index 000000000..0826a978a --- /dev/null +++ b/results/classifier/zero-shot/108/all/807893 @@ -0,0 +1,499 @@ +performance: 0.985 +graphic: 0.985 +debug: 0.985 +other: 0.984 +permissions: 0.984 +semantic: 0.983 +files: 0.980 +device: 0.978 +PID: 0.977 +socket: 0.974 +vnc: 0.967 +boot: 0.964 +network: 0.959 +KVM: 0.956 + +qemu privilege escalation + +If qemu is started as root, with -runas, the extra groups is not dropped correctly + +/proc/`pidof qemu`/status +.. +Uid: 100 100 100 100 +Gid: 100 100 100 100 +FDSize: 32 +Groups: 0 1 2 3 4 6 10 11 26 27 +... + +The fix is to add initgroups() or setgroups(1, [gid]) where appropriate to os-posix.c. + +The extra gid's allow read or write access to other files (such as /dev etc). + +Emulating the qemu code: + +# python +... +>>> import os +>>> os.setgid(100) +>>> os.setuid(100) +>>> os.execve("/bin/sh", [ "/bin/sh" ], os.environ) +sh-4.1$ xxd /dev/sda | head -n2 +0000000: eb48 9000 0000 0000 0000 0000 0000 0000 .H.............. +0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ +sh-4.1$ ls -l /dev/sda +brw-rw---- 1 root disk 8, 0 Jul 8 11:54 /dev/sda +sh-4.1$ id +uid=100(qemu00) gid=100(users) groups=100(users),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),26(tape),27(video) + +Andrew Griffiths reports that -runas does not set supplementary group +IDs. This means that gid 0 (root) is not dropped when switching to an +unprivileged user. + +Add an initgroups(3) call to use the -runas user's /etc/groups +membership to update the supplementary group IDs. + +Signed-off-by: Stefan Hajnoczi <email address hidden> +--- +Note this needs compile testing on various POSIX host platforms. Tested on +Linux. Should work on BSD and Solaris. initgroups(3) is SVr4/BSD but not in +POSIX. + + os-posix.c | 6 ++++++ + 1 files changed, 6 insertions(+), 0 deletions(-) + +diff --git a/os-posix.c b/os-posix.c +index 7dfb278..6f8d488 100644 +--- a/os-posix.c ++++ b/os-posix.c +@@ -31,6 +31,7 @@ + /*needed for MAP_POPULATE before including qemu-options.h */ + #include <sys/mman.h> + #include <pwd.h> ++#include <grp.h> + #include <libgen.h> + + /* Needed early for CONFIG_BSD etc. */ +@@ -199,6 +200,11 @@ static void change_process_uid(void) + fprintf(stderr, "Failed to setgid(%d)\n", user_pwd->pw_gid); + exit(1); + } ++ if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) { ++ fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n", ++ user_pwd->pw_name, user_pwd->pw_gid); ++ exit(1); ++ } + if (setuid(user_pwd->pw_uid) < 0) { + fprintf(stderr, "Failed to setuid(%d)\n", user_pwd->pw_uid); + exit(1); +-- +1.7.5.4 + + + +Yep, that fix looks fine. RedHat should have a CVE number for this issue. + +or any other linux vendor that has an interest in qemu :) + +On Sat, Jul 9, 2011 at 10:22 AM, Stefan Hajnoczi +<email address hidden> wrote: +> Andrew Griffiths reports that -runas does not set supplementary group +> IDs. This means that gid 0 (root) is not dropped when switching to an +> unprivileged user. +> +> Add an initgroups(3) call to use the -runas user's /etc/groups +> membership to update the supplementary group IDs. +> +> Signed-off-by: Stefan Hajnoczi <email address hidden> +> --- +> Note this needs compile testing on various POSIX host platforms. Tested on +> Linux. Should work on BSD and Solaris. initgroups(3) is SVr4/BSD but not in +> POSIX. +> +> os-posix.c | 6 ++++++ +> 1 files changed, 6 insertions(+), 0 deletions(-) + +Are you happy with this patch? Bumping because security-related. + +Regarding portability, Linux, BSD, Solaris, and Mac OS X all provide +initgroups(3). I think we're good. + +Stefan + + +Requesting CVE. Tools like libvirt deprivilege themselves before launching qemu as an unprivileged user (no use of -runas), so aren't vulnerable. + +This bug is being tracked as CVE-2011-2527 + +* Stefan Hajnoczi (<email address hidden>) wrote: +> @@ -199,6 +200,11 @@ static void change_process_uid(void) +> fprintf(stderr, "Failed to setgid(%d)\n", user_pwd->pw_gid); +> exit(1); +> } +> + if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) { +> + fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n", +> + user_pwd->pw_name, user_pwd->pw_gid); +> + exit(1); +> + } + +Does initgroups need access to /etc/group? How does this combine w/ +-chroot? + +Added bonus...this will fail when the initial user is not privileged +_and_ is the same user as -runas user (probably not what a user intended, +but would've worked before). Something like: + +[doh@laptop qemu]$ qemu -runas doh + + +* Chris Wright (<email address hidden>) wrote: +> * Stefan Hajnoczi (<email address hidden>) wrote: +> > @@ -199,6 +200,11 @@ static void change_process_uid(void) +> > fprintf(stderr, "Failed to setgid(%d)\n", user_pwd->pw_gid); +> > exit(1); +> > } +> > + if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) { +> > + fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n", +> > + user_pwd->pw_name, user_pwd->pw_gid); +> > + exit(1); +> > + } +> +> Does initgroups need access to /etc/group? How does this combine w/ +> -chroot? + +Tested this on Linux, and w/out /etc/group it simply fails to add any +supplementary groups (doesn't fail completely, just fails safely). +Appears similar from solaris manpages. + +Given that... + +Acked-by: Chris Wright <email address hidden> + + +Thanks, applied. + +On Sat, Jul 9, 2011 at 12:22 PM, Stefan Hajnoczi +<email address hidden> wrote: +> Andrew Griffiths reports that -runas does not set supplementary group +> IDs. This means that gid 0 (root) is not dropped when switching to an +> unprivileged user. +> +> Add an initgroups(3) call to use the -runas user's /etc/groups +> membership to update the supplementary group IDs. +> +> Signed-off-by: Stefan Hajnoczi <email address hidden> +> --- +> Note this needs compile testing on various POSIX host platforms. Tested on +> Linux. Should work on BSD and Solaris. initgroups(3) is SVr4/BSD but not in +> POSIX. +> +> os-posix.c | 6 ++++++ +> 1 files changed, 6 insertions(+), 0 deletions(-) +> +> diff --git a/os-posix.c b/os-posix.c +> index 7dfb278..6f8d488 100644 +> --- a/os-posix.c +> +++ b/os-posix.c +> @@ -31,6 +31,7 @@ +> /*needed for MAP_POPULATE before including qemu-options.h */ +> #include <sys/mman.h> +> #include <pwd.h> +> +#include <grp.h> +> #include <libgen.h> +> +> /* Needed early for CONFIG_BSD etc. */ +> @@ -199,6 +200,11 @@ static void change_process_uid(void) +> fprintf(stderr, "Failed to setgid(%d)\n", user_pwd->pw_gid); +> exit(1); +> } +> + if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) { +> + fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n", +> + user_pwd->pw_name, user_pwd->pw_gid); +> + exit(1); +> + } +> if (setuid(user_pwd->pw_uid) < 0) { +> fprintf(stderr, "Failed to setuid(%d)\n", user_pwd->pw_uid); +> exit(1); +> -- +> 1.7.5.4 +> +> +> + + +# ps axwu +... +qemu00 29957 0.5 9.8 480568 405228 ? Sl Jul12 7:41 /usr/bin/qemu-system-x86_64 -runas ... +... + +# ps axwu -L +... +qemu00 29957 29957 0.2 3 9.8 480568 405228 ? Sl Jul12 2:49 /usr/bin/qemu-system-x86_64 -runas ... +root 29957 29959 0.3 3 9.8 480568 405228 ? Sl Jul12 4:47 /usr/bin/qemu-system-x86_64 -runas ... +root 29957 29960 0.0 3 9.8 480568 405228 ? Sl Jul12 0:00 /usr/bin/qemu-system-x86_64 -runas ... +... + + +# cat /proc/29957/task/29959/status +Name: qemu-system-x86 +State: S (sleeping) +Tgid: 29957 +Pid: 29959 +PPid: 1 +TracerPid: 0 +Uid: 0 0 0 0 +Gid: 0 0 0 0 +FDSize: 32 +Groups: 999 + +... + +Threads can have their own uid/gid set. + + + +Once you have code execution in the process, you can modify the others threads execution (if required) to execute your own code. With full capabilities, it would be trivial to escape from a chroot on a normal Linux kernel (grsecurity with appropriate kernel chroot restrictions enabled would reduce the avenues available for escaping.). + +I seem to recall other distro's handle thread privileges differently. + + + +correction: s/other distro's/other operating systems/g + + +On Wed, Jul 13, 2011 at 11:12 AM, Andrew Griffiths +<email address hidden> wrote: +> Once you have code execution in the process, you can modify the others +> threads execution (if required) to execute your own code. With full +> capabilities, it would be trivial to escape from a chroot on a normal +> Linux kernel (grsecurity with appropriate kernel chroot restrictions +> enabled would reduce the avenues available for escaping.). +> +> I seem to recall other distro's handle thread privileges differently. + +Hi Andrew, +I think what Chris meant is that libvirt does not use -runas at all. +It drops privileges (including initgroups(3)) itself *before* invoking +QEMU. So I think his statement is simply that libvirt (commonly used +in KVM deployments) is not affected. + +Stefan + + +Hello Stefan, + +I was explaining the threads / uids per thread issue, in case it wasn't obvious of what the impact was, or how to exploit that issue (in case someone was wondering about that). It was not directed at Chris in any shape or form, nor was it about libvirt. + + + + + + +On Wed, Jul 13, 2011 at 11:50 AM, Andrew Griffiths +<email address hidden> wrote: +> I was explaining the threads / uids per thread issue, in case it wasn't +> obvious of what the impact was, or how to exploit that issue (in case +> someone was wondering about that). It was not directed at Chris in any +> shape or form, nor was it about libvirt. + +I see. Thanks for the clarification. + +Stefan + + +Regarding the threads having different privilege level, I have isolated that to being related to my grsecurity configuration (more specifically, chroot_findtask will block it). + +While it's still an issue on older glibc where the setuid/setgid code does not enforce it across all threads, it may not be high priority since fixing it would be a lot more effort. + + +On Thu, Jul 14, 2011 at 11:37 AM, Andrew Griffiths +<email address hidden> wrote: +> Regarding the threads having different privilege level, I have isolated +> that to being related to my grsecurity configuration (more specifically, +> chroot_findtask will block it). +> +> While it's still an issue on older glibc where the setuid/setgid code +> does not enforce it across all threads, it may not be high priority +> since fixing it would be a lot more effort. + +Wow, just learnt something new that glibc does behind our backs :). I +see it uses SIGRTMIN+1 to signal threads and get them to do the set*id +system calls. + +I'm glad it does this because although most QEMU threads should be +started after command-line parsing, I can think of instances where we +might start a thread before -runas is completed. + +Stefan + + +Actually, from a quick google perhaps ensuring all threads run after chroot / dropping privileges might be a good idea. + +- http://wiki.freebsd.org/Per-Thread%20Credentials +- http://www.cocoabuilder.com/archive/cocoa/33107-cthread-fork.html + +though it looks like you might need to put in effort into getting per-thread uid's for freebsd/macosx when they make that available, and you're assuming they're running a recent glibc. Depending on complexity, it can't hurt to ensure you're not going to hit into per-thread uid/gid's. I'm of two minds about glibc doing this. This was a particular favourite bug class of mine :) + +It seems that there is a linux distro which uses uclibc, which does not emulate the glibc behaviour: + +http://dl-4.alpinelinux.org/alpine/v2.2/main/x86/ <-- has qemu packages. + +we can use http://paste.pocoo.org/raw/438497/ to emulate qemu's behaviour + +# ./test +[main] my [ug]id is 100/100 +[thread] my [ug]id is 0/0 + +^-- the qemu thread would be running as root + +running the same code under glibc (without grsecurity chroot_findtask), and it will drop privileges as you'd expect on recent glibc. + + + + +On Thu, Jul 14, 2011 at 12:46 PM, Andrew Griffiths +<email address hidden> wrote: +> Actually, from a quick google perhaps ensuring all threads run after +> chroot / dropping privileges might be a good idea. +> +> - http://wiki.freebsd.org/Per-Thread%20Credentials +> - http://www.cocoabuilder.com/archive/cocoa/33107-cthread-fork.html +> +> though it looks like you might need to put in effort into getting per- +> thread uid's for freebsd/macosx when they make that available, and +> you're assuming they're running a recent glibc. Depending on complexity, +> it can't hurt to ensure you're not going to hit into per-thread +> uid/gid's. I'm of two minds about glibc doing this. This was a +> particular favourite bug class of mine :) +> +> It seems that there is a linux distro which uses uclibc, which does not +> emulate the glibc behaviour: +> +> http://dl-4.alpinelinux.org/alpine/v2.2/main/x86/ <-- has qemu +> packages. + +Good point about other OSes and distros. QEMU does not create any +threads before -runas processing AFAICT. + +It's a nasty problem in general though because shared libraries could... + +Stefan + + +It does create threads before chroot/setgid/setuid, see https://bugs.launchpad.net/qemu/+bug/807893/comments/10. + +That process was created with following options: + +-enable-kvm +-runas +-chroot +-m +-kernel +-append +-drive +-net nic,model=virtio, -net tap,ifname=xxx +-serial none +-serial unix:.. +-serial file: ... +-monitor unix:... +-daemonize + + +with some grepping of parent callers, looks like the cpu is probably my issue + +static void qemu_kvm_start_vcpu(CPUState *env) +{ + env->thread = qemu_mallocz(sizeof(QemuThread)); + env->halt_cond = qemu_mallocz(sizeof(QemuCond)); + qemu_cond_init(env->halt_cond); + qemu_thread_create(env->thread, qemu_kvm_cpu_thread_fn, env); + + /* init the dynamic translator */ + cpu_exec_init_all(tb_size * 1024 * 1024); + + +.. etc +6613 clone(child_stack=0xa75df454, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xa75dfbd8, {entry_number:6, base_addr:0xa75dfb70, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xa75dfbd8) = 16615 +.. etc +16615 ioctl(4, KVM_CREATE_VCPU, 0) = 7 +16615 ioctl(3, KVM_GET_VCPU_MMAP_SIZE, 0) = 12288 +16615 mmap2(NULL, 12288, PROT_READ|PROT_WRITE, MAP_SHARED, 7, 0) = 0xa6ddc000 +16615 ioctl(7, KVM_SET_VAPIC_ADDR, 0xa75de1a4) = 0 + +later on it does chroot/setgid/setuid + + +On Thu, Jul 14, 2011 at 2:00 PM, Andrew Griffiths +<email address hidden> wrote: +> with some grepping of parent callers, looks like the cpu is probably my +> issue + +The -runas processing doesn't happen until os_setup_post() right +before entering the main loop. It is too late at that point because +threads may have been spawned. + +My mistake was to think -runas processing happens in os_parse_cmd_args(). + +Stefan + + +I think I verified this issue on lastest qemu + +steps: +1./configure && make +2.start qemu-kvm process with -runas nobody +./qemu-system-x86_64 -m 2G -smp 4 -cpu qemu64,+x2apic -usbdevice tablet -drive file=/home/win2003-32-new.raw,if=none,id=drive-ide0-0-0,werror=stop,rerror=stop,cache=none,format=raw -device ide-drive,bus=ide.0,unit=0,bootindex=1,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup,downscript=no -device rtl8139,netdev=hostnet0,mac=76:0E:40:3F:2F:3F -boot dc -uuid cc5aee77-d631-41d4-92a0-4e59c3b5cb6c -rtc-td-hack -monitor stdio -name win2k3-32-serial -vnc :10 -device virtio-balloon-pci,id=balloon0 -runas nobody + +3# cat /proc/25996/status +Name: qemu-system-x86 +State: R (running) +Tgid: 25996 +Pid: 25996 +PPid: 28206 +TracerPid: 0 +Uid: 99 99 99 99 +Gid: 99 99 99 99 +Utrace: 0 +FDSize: 256 +Groups: 99 + +4# cat /proc/25996/task/25996/status +Name: qemu-system-x86 +State: R (running) +Tgid: 25996 +Pid: 25996 +PPid: 28206 +TracerPid: 0 +Uid: 99 99 99 99 +Gid: 99 99 99 99 +Utrace: 0 +FDSize: 256 +Groups: 99 + +Based on above ,I think this bug has been fixed ald. + +Best Regards, +Mike + +Mike, the issue is solved for Linux hosts with a modern glibc. Andrew +explained that uclibc or non-Linux hosts may still be affected if they do +not apply set*id() to all threads in the process. + +The safe way to solve this universally is to perform -runas before creating +threads. + + +Here's some reproduction code you can use to see the difference between glibc and raw system calls: + +https://gist.github.com/1084042 + +If you're wondering about Linux and non-glibc distributions using qemu, Alpine is one particular answer to that question (so the affected Linux distributions is non-zero). + + + + + + +According to Stefan, this problem has been fixed by this commit: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=cc4662f9642995c78 +... so let's close this bug ticket now. + diff --git a/results/classifier/zero-shot/108/all/808588 b/results/classifier/zero-shot/108/all/808588 new file mode 100644 index 000000000..ed44c3ba3 --- /dev/null +++ b/results/classifier/zero-shot/108/all/808588 @@ -0,0 +1,111 @@ +graphic: 0.990 +device: 0.989 +debug: 0.988 +boot: 0.983 +semantic: 0.983 +KVM: 0.981 +permissions: 0.979 +performance: 0.977 +network: 0.976 +PID: 0.968 +vnc: 0.965 +socket: 0.964 +other: 0.959 +files: 0.951 + +Netperf tests cause i82551 network down + +1. boot up a guest with 82551 nic +# qemu-kvm -net nic,model=i82551 ... +2. launch netperf server in the guest +3.on the host +for b in 32 64 128 256 512 1024 1460 2048 4096 8192 9000 16384 32768 65495 65507 +do ./netperf -t TCP_STREAM -f m -H <guest ip> -P 0 -l 10 -- -m $b +done + +for b in 32 64 128 256 512 1024 1460 2048 4096 8192 9000 16384 32768 65495 65507 +do ./netperf -t UDP_STREAM -f m -H <guest ip> -P 0 -l 10 -- -m $b +done + + +Result: +Guest network becomes down + + +netperf client output: +./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 32 + 87380 16384 32 10.97 19.61 +./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 64 + 87380 16384 64 11.55 79.68 +./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 128 + 87380 16384 128 10.16 14.20 +./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 256 + 87380 16384 256 11.17 12.85 +./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 512 + 87380 16384 512 10.01 16.38 +./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 1024 +Interrupted system call +netperf: remote error 4./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 1460 +establish control: are you sure there is a netserver listening on 10.66.9.39 at port 12865? +establish_control could not establish the control connection from 0.0.0.0 port 0 address family AF_UNSPEC to 10.66.9.39 port 12865 address family AF_UNSPEC +./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 2048 + + +qemu debug message: +.... +EE100 nic_receive command 0x0000, link 0x3d3e6822, addr 0xffffffff, size 1518 +EE100 nic_can_receive 0x29a0180 +EE100 nic_receive 0x29a0180 received broadcast, len=60 +EE100 nic_receive Receive buffer (0 bytes) too small for data (60 bytes); data truncated +EE100 nic_receive command 0x8000, link 0x37b32022, addr 0xffffffff, size 0 + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +EE100 nic_receive receive: Running out of frames + ^^^^^^^^^^^^^^^^^^^^^^^^ +EE100 eepro100_write1 addr=Command/Status+1 val=0x20 + + + +kvm version: +qemu-kvm: commit 525e3df73e40290e95743d4c8f8b64d8d9cbe021 +Date: Mon Jul 4 13:36:06 2011 +0300 + +related fix in driver: +http://marc.info/?l=linux-netdev&m=118859393206222&w=3 + + +1. When bug reproduces, we can only capture arp request in the tap device. + +# tcpdump -i tap0 +tcpdump: WARNING: tap0: no IPv4 address assigned +tcpdump: verbose output suppressed, use -v or -vv for full protocol decode +listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes +16:14:11.741203 ARP, Request who-has 10.66.8.167 tell 10.66.8.252, length 28 +16:14:12.741186 ARP, Request who-has 10.66.8.167 tell 10.66.8.252, length 28 +16:14:13.741183 ARP, Request who-has 10.66.8.167 tell 10.66.8.252, length 28 + +2. Execute 'system_reset' in qemu monitor, guest could not get ip address. + +# tcpdump -i tap0 +tcpdump: WARNING: tap0: no IPv4 address assigned +tcpdump: verbose output suppressed, use -v or -vv for full protocol decode +listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes +16:16:21.508588 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 +16:16:21.682585 IP6 :: > ff02::1:ff12:3456: ICMP6, neighbor solicitation, who has fe80::5054:ff:fe12:3456, length 24 +16:16:22.682616 IP6 fe80::5054:ff:fe12:3456 > ff02::2: ICMP6, router solicitation, length 16 +16:16:23.105303 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:12:34:56 (oui Unknown), length 300 +16:16:25.837597 IP6 fe80::5054:ff:fe12:3456 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 +16:16:26.682594 IP6 fe80::5054:ff:fe12:3456 > ff02::2: ICMP6, router solicitation, length 16 +16:16:30.111097 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:12:34:56 (oui Unknown), length 300 +16:16:30.682598 IP6 fe80::5054:ff:fe12:3456 > ff02::2: ICMP6, router solicitation, length 16 +16:16:39.112289 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:12:34:56 (oui Unknown), length 300 +16:16:43.107232 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:12:34:56 (oui Unknown), length 300 + + +The patch mentioned in comment #3 had been included in the kernel here: +http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7734f6e6bcd7ba78b00e93e74a4ddafd9886cdea +So I guess we can close this bug nowadays? Or can you still reproduce this issue with the current kernel and current version of QEMU? + +There hasn't been a reply to my question in the last comment within +months, so I assume nobody cares about this anymore. So I'm closing this +ticket now... + diff --git a/results/classifier/zero-shot/108/all/816 b/results/classifier/zero-shot/108/all/816 new file mode 100644 index 000000000..92dc14f71 --- /dev/null +++ b/results/classifier/zero-shot/108/all/816 @@ -0,0 +1,62 @@ +other: 0.995 +permissions: 0.994 +vnc: 0.993 +device: 0.992 +debug: 0.992 +KVM: 0.991 +semantic: 0.991 +socket: 0.991 +graphic: 0.991 +performance: 0.990 +PID: 0.990 +files: 0.989 +network: 0.986 +boot: 0.982 + +Some errors were encountered while compiling QEMU source code +Description of problem: +When I try to download the source code from gitlab and compile it, the output is as follows: + +``` +FAILED: subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o +clang -m64 -mcx16 -Isubprojects/libvhost-user/libvhost-user.a.p -Isubprojects/libvhost-user -I../subprojects/libvhost-user -fcolor-diagnostics -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -fsanitize=fuzzer-no-link -fsanitize=undefined -fsanitize=address -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-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -fstack-protector-strong -fprofile-instr-generate -fcoverage-mapping -fPIE -pthread -D_GNU_SOURCE -MD -MQ subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o -MF subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o.d -o subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o -c ../subprojects/libvhost-user/libvhost-user.c +In file included from ../subprojects/libvhost-user/libvhost-user.c:43: +../subprojects/libvhost-user/include/atomic.h:1:1: error: expected identifier or '(' +../../../include/qemu/atomic.h +^ +In file included from ../subprojects/libvhost-user/libvhost-user.c:45: +../subprojects/libvhost-user/libvhost-user.h:23:10: fatal error: 'standard-headers/linux/virtio_ring.h' file not found +#include "standard-headers/linux/virtio_ring.h" + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +2 errors generated. +[69/1511] Compiling C object subprojects/libvhost-user/libvhost-user-glib.a.p/libvhost-user-glib.c.o +FAILED: subprojects/libvhost-user/libvhost-user-glib.a.p/libvhost-user-glib.c.o +clang -m64 -mcx16 -Isubprojects/libvhost-user/libvhost-user-glib.a.p -Isubprojects/libvhost-user -I../subprojects/libvhost-user -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fcolor-diagnostics -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -fsanitize=fuzzer-no-link -fsanitize=undefined -fsanitize=address -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-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -fstack-protector-strong -fprofile-instr-generate -fcoverage-mapping -fPIE -pthread -Wno-unused-function -MD -MQ subprojects/libvhost-user/libvhost-user-glib.a.p/libvhost-user-glib.c.o -MF subprojects/libvhost-user/libvhost-user-glib.a.p/libvhost-user-glib.c.o.d -o subprojects/libvhost-user/libvhost-user-glib.a.p/libvhost-user-glib.c.o -c ../subprojects/libvhost-user/libvhost-user-glib.c +In file included from ../subprojects/libvhost-user/libvhost-user-glib.c:15: +In file included from ../subprojects/libvhost-user/libvhost-user-glib.h:19: +../subprojects/libvhost-user/libvhost-user.h:23:10: fatal error: 'standard-headers/linux/virtio_ring.h' file not found +#include "standard-headers/linux/virtio_ring.h" + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +1 error generated. +[70/1511] Generating trace-hw_alpha.h with a custom command +[71/1511] Generating hmp-commands-info.h with a custom command (wrapped by meson to capture output) +[72/1511] Generating qemu-img-cmds.h with a custom command (wrapped by meson to capture output) +[73/1511] Generating hmp-commands.h with a custom command (wrapped by meson to capture output) +[74/1511] Generating qemu-options.def with a custom command (wrapped by meson to capture output) +[75/1511] Compiling C object libslirp.a.p/slirp_src_tcp_input.c.o +[76/1511] Compiling C object libcapstone.a.p/capstone_arch_SystemZ_SystemZDisassembler.c.o +[77/1511] Generating qemu-version.h with a custom command (wrapped by meson to capture output) +[78/1511] Compiling C object libcapstone.a.p/capstone_arch_AArch64_AArch64Disassembler.c.o +[79/1511] Compiling C object libcapstone.a.p/capstone_arch_ARM_ARMInstPrinter.c.o +[80/1511] Compiling C object libcapstone.a.p/capstone_arch_ARM_ARMDisassembler.c.o +[81/1511] Compiling C object libcapstone.a.p/capstone_arch_AArch64_AArch64InstPrinter.c.o +ninja: build stopped: subcommand failed. +Makefile:163: recipe for target 'run-ninja' failed +make: *** [run-ninja] Error 1 +``` + +I looked for the missing file standard-headers/linux/virtio_ring.h and found that the file existed. +Steps to reproduce: +1. ``git clone https://gitlab.com/qemu-project/qemu`` +2. ``CC=clang CXX=clang++ ../configure --enable-fuzzing --enable-sanitizers`` +3. ``make qemu-fuzz-i386`` diff --git a/results/classifier/zero-shot/108/all/844 b/results/classifier/zero-shot/108/all/844 new file mode 100644 index 000000000..6565c1740 --- /dev/null +++ b/results/classifier/zero-shot/108/all/844 @@ -0,0 +1,59 @@ +other: 0.956 +graphic: 0.953 +permissions: 0.953 +semantic: 0.953 +debug: 0.951 +KVM: 0.943 +performance: 0.938 +PID: 0.937 +device: 0.932 +network: 0.926 +files: 0.923 +vnc: 0.921 +socket: 0.915 +boot: 0.913 + +Close gap for x86_64-v3 ABI in TCG - CPU support for fma, f16c, avx, avx2 features required +Description of problem: +There are 3 additional ABIs defined by a collaboration of vendors for the `x86_64` architecture, over the original baseline: + +* https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-sys-info.tex + +This is no problem for KVM assuming suitable host hardware, but TCG is currently unable to support more than the original baseline and the `x86_64-v2` step. + +For `x86_64-v3` there are some gaps in its emulation coverage. This can be seen by taking `Nehalem` which is a good fit for `x86_64-v2`, and requesting the extra v3 features: + +``` +$ qemu-system-x86_64 -accel tcg -cpu Nehalem,+avx,+avx2,+bmi1,+bmi2,+f16c,+fma,+abm,+movbe +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +``` + +IOW, the strict bare minimum TCG needs in order to satisfy `x86_64-v3` is `fma`, `f16c`, `avx` and `avx2` support + +If we want to fully support a named CPU model satisfying v3, then `Haswell` is the closest and that has a few additional gaps + +``` +$ qemu-system-x86_64 -accel tcg -cpu Haswell-noTSX +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] + +``` + +Those additional gaps wouldn't impact ability to execute binaries build for the `x86_64-v3` ABI though, so not as important. + +The reason `x86_64-v3` compatibility in TCG matters is because sooner or later some Linux OS are going to set this as the baseline for their compiler toolchain. There is a proposal to set this in `Fedora ELN`, which is what feeds in to a possible future `RHEL-10`. + +I imagine adding these extra features would be non-negligible work in TCG / take some time to complete. + +Thus I file this bug for the purpose of suggesting these 4 specific missing features be considered a priority to address, compared to other missing CPU features in TCG that might be considered more of a 'nice to have'. + +eg looking further the `x86_64-v4` baseline brings in a requirement for `avx512f`, `avx512bw`, `avx512cd`, `avx512dq`, `avx512vl` which TCG also lacks, but I don't think they really need to be considered important at this point in time. diff --git a/results/classifier/zero-shot/108/all/855800 b/results/classifier/zero-shot/108/all/855800 new file mode 100644 index 000000000..2985f43bd --- /dev/null +++ b/results/classifier/zero-shot/108/all/855800 @@ -0,0 +1,97 @@ +debug: 0.991 +other: 0.986 +permissions: 0.983 +semantic: 0.983 +device: 0.981 +boot: 0.976 +PID: 0.969 +socket: 0.968 +graphic: 0.967 +performance: 0.963 +files: 0.957 +network: 0.948 +KVM: 0.937 +vnc: 0.908 + +KVM crashes when attempting to restart migration + +Operations performed: +Sequence to trigger crash: + + * Start two kvm systems, one on gerph (primary), one on nbuild2 (listening for incoming migration) - do not use -daemonize + * On gerph, connect to monitor. + * "migrate -d -b tcp:nbuild2:4444" + * "info migrate" + * "migrate_cancel" + * "info migrate" + * "migrate -d -b tcp:nbuild2:4444" + * crashed with assertion: +kvm: block-migration.c:355: flush_blks: Assertion `block_mig_state.read_done >= 0' failed. + Connection closed by foreign host. +[1]+ Aborted (core dumped) kvm -drive file=./copy-disk2.img,boot=on -m 4096 -serial mon:telnet::23023,server,nowait -balloon virtio -vnc :99 -usbdevice tablet -net nic,macaddr=f6:a6:31:53:89:9a,model=rtl8139,vlan=0 -net tap,vlan=0 + + +Repeating the operations above often dies in different places; just repeat the cancel and restart the operation. Because the KVM system dies, the underlying VM is obviously terminated. + +Distribution: + +jfletcher@gerph:~$ lsb_release -rd +Description: Ubuntu 10.04.3 LTS +Release: 10.04 + +Package: + +jfletcher@gerph:~$ apt-cache policy kvm +kvm: + Installed: 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.15 + Candidate: 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.15 + Version table: + *** 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.15 0 + 500 http://gb.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages + 500 http://security.ubuntu.com/ubuntu/ lucid-security/main Packages + 100 /var/lib/dpkg/status + 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9 0 + 500 http://gb.archive.ubuntu.com/ubuntu/ lucid/main Packages + +Thanks for taking the time to submit this bug and helping to make Ubuntu better. + +Just to be sure I understand right, if you simply let the migration continue rather than canceling it, you don't get an error, right? I'll mark this low priority under that assumption. If I'm wrong, then priority should be raised. + +(Leaving status New until I manage to reproduce) + +That's correct for the testing I have performed. + +I have been able to perform repeated migrate/migrate_cancel operations much more quickly than I have been able to perform actual migrations, therefore the test set of migrate operations after a cancel is at least an order of magnitude larger than the test set of completing migrations. + +Background in case it's relevant: +I was doing this to test the behaviour if (for example) the target system failed during the migration and it was necessary to cancel and restart, as such resilience is important for the services I maintain. + +If there's any more information required, I'm happy to provide help :-) + +If you *need* to use the live migration (rather than offline migration by copying the disk images) you have already made a decision that the service is sufficiently important that you cannot have downtime on it. If the live migration could fail, and resuming it could crash (as reported), this is going to be a serious concern and most likely not a risk you would wish to take with a service that you have already decided is so vital as to not need downtime. + +The migration feature that if used might crash, is not a feature I would like to trust my valuable services to. + +Therefore I would suggest that this crash have the same priority as the migration feature. If migration is a low priority feature then it would be find as 'low' priority', but if the live migration is an important feature to have then it needs to be solid. + +As an administrator of services, I play have a game of Russian-roulette with them, and migration is that game at present. + +Oops, I meant "I cannot play a game of ..." + +Definately confirmed on lucid. + +In quantal migration always fails, but still after one failed attempt, if I do 'migrate_cancel' and re-try the migration, I get the same error. + +This causes you to lose your VM state. + +upstream git head qemu still behaves the same as quantal qemu-kvm (1.1.0), marking a affecting upstream. + +Can you still reproduce this issue with the latest version of QEMU (currently v2.8)? + +I haven't attempted to reproduce the issue recently, I'm afraid. I've changed jobs twice in the intervening time, so the immediate issue for me has gone away. If I find an opportunity, I shall try to reproduce with the most recent versions. + + +[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.] + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/88225572 b/results/classifier/zero-shot/108/all/88225572 new file mode 100644 index 000000000..292ea66b8 --- /dev/null +++ b/results/classifier/zero-shot/108/all/88225572 @@ -0,0 +1,2910 @@ +permissions: 0.992 +other: 0.987 +debug: 0.986 +PID: 0.984 +semantic: 0.976 +graphic: 0.974 +device: 0.970 +boot: 0.969 +performance: 0.965 +vnc: 0.958 +files: 0.957 +socket: 0.955 +network: 0.950 +KVM: 0.924 + +[BUG qemu 4.0] segfault when unplugging virtio-blk-pci device + +Hi, + +I'm using qemu 4.0 and hit segfault when tearing down kata sandbox, I +think it's because io completion hits use-after-free when device is +already gone. Is this a known bug that has been fixed? (I went through +the git log but didn't find anything obvious). + +gdb backtrace is: + +Core was generated by `/usr/local/libexec/qemu-kvm -name +sandbox-5b8df8c6c6901c3c0a9b02879be10fe8d69d6'. +Program terminated with signal 11, Segmentation fault. +#0 object_get_class (obj=obj@entry=0x0) at +/usr/src/debug/qemu-4.0/qom/object.c:903 +903 return obj->class; +(gdb) bt +#0 object_get_class (obj=obj@entry=0x0) at +/usr/src/debug/qemu-4.0/qom/object.c:903 +#1  0x0000558a2c009e9b in virtio_notify_vector (vdev=0x558a2e7751d0, +  vector=<optimized out>) at /usr/src/debug/qemu-4.0/hw/virtio/virtio.c:1118 +#2  0x0000558a2bfdcb1e in virtio_blk_discard_write_zeroes_complete ( +  opaque=0x558a2f2fd420, ret=0) +  at /usr/src/debug/qemu-4.0/hw/block/virtio-blk.c:186 +#3  0x0000558a2c261c7e in blk_aio_complete (acb=0x558a2eed7420) +  at /usr/src/debug/qemu-4.0/block/block-backend.c:1305 +#4  0x0000558a2c3031db in coroutine_trampoline (i0=<optimized out>, +  i1=<optimized out>) at /usr/src/debug/qemu-4.0/util/coroutine-ucontext.c:116 +#5  0x00007f45b2f8b080 in ?? () from /lib64/libc.so.6 +#6  0x00007fff9ed75780 in ?? () +#7  0x0000000000000000 in ?? () + +It seems like qemu was completing a discard/write_zero request, but +parent BusState was already freed & set to NULL. + +Do we need to drain all pending request before unrealizing virtio-blk +device? Like the following patch proposed? +https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg02945.html +If more info is needed, please let me know. + +Thanks, +Eryu + +On Tue, 31 Dec 2019 18:34:34 +0800 +Eryu Guan <address@hidden> wrote: + +> +Hi, +> +> +I'm using qemu 4.0 and hit segfault when tearing down kata sandbox, I +> +think it's because io completion hits use-after-free when device is +> +already gone. Is this a known bug that has been fixed? (I went through +> +the git log but didn't find anything obvious). +> +> +gdb backtrace is: +> +> +Core was generated by `/usr/local/libexec/qemu-kvm -name +> +sandbox-5b8df8c6c6901c3c0a9b02879be10fe8d69d6'. +> +Program terminated with signal 11, Segmentation fault. +> +#0 object_get_class (obj=obj@entry=0x0) at +> +/usr/src/debug/qemu-4.0/qom/object.c:903 +> +903 return obj->class; +> +(gdb) bt +> +#0 object_get_class (obj=obj@entry=0x0) at +> +/usr/src/debug/qemu-4.0/qom/object.c:903 +> +#1  0x0000558a2c009e9b in virtio_notify_vector (vdev=0x558a2e7751d0, +> +  vector=<optimized out>) at /usr/src/debug/qemu-4.0/hw/virtio/virtio.c:1118 +> +#2  0x0000558a2bfdcb1e in virtio_blk_discard_write_zeroes_complete ( +> +  opaque=0x558a2f2fd420, ret=0) +> +  at /usr/src/debug/qemu-4.0/hw/block/virtio-blk.c:186 +> +#3  0x0000558a2c261c7e in blk_aio_complete (acb=0x558a2eed7420) +> +  at /usr/src/debug/qemu-4.0/block/block-backend.c:1305 +> +#4  0x0000558a2c3031db in coroutine_trampoline (i0=<optimized out>, +> +  i1=<optimized out>) at +> +/usr/src/debug/qemu-4.0/util/coroutine-ucontext.c:116 +> +#5  0x00007f45b2f8b080 in ?? () from /lib64/libc.so.6 +> +#6  0x00007fff9ed75780 in ?? () +> +#7  0x0000000000000000 in ?? () +> +> +It seems like qemu was completing a discard/write_zero request, but +> +parent BusState was already freed & set to NULL. +> +> +Do we need to drain all pending request before unrealizing virtio-blk +> +device? Like the following patch proposed? +> +> +https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg02945.html +> +> +If more info is needed, please let me know. +may be this will help: +https://patchwork.kernel.org/patch/11213047/ +> +> +Thanks, +> +Eryu +> + +On Tue, Dec 31, 2019 at 11:51:35AM +0100, Igor Mammedov wrote: +> +On Tue, 31 Dec 2019 18:34:34 +0800 +> +Eryu Guan <address@hidden> wrote: +> +> +> Hi, +> +> +> +> I'm using qemu 4.0 and hit segfault when tearing down kata sandbox, I +> +> think it's because io completion hits use-after-free when device is +> +> already gone. Is this a known bug that has been fixed? (I went through +> +> the git log but didn't find anything obvious). +> +> +> +> gdb backtrace is: +> +> +> +> Core was generated by `/usr/local/libexec/qemu-kvm -name +> +> sandbox-5b8df8c6c6901c3c0a9b02879be10fe8d69d6'. +> +> Program terminated with signal 11, Segmentation fault. +> +> #0 object_get_class (obj=obj@entry=0x0) at +> +> /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> 903 return obj->class; +> +> (gdb) bt +> +> #0 object_get_class (obj=obj@entry=0x0) at +> +> /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> #1  0x0000558a2c009e9b in virtio_notify_vector (vdev=0x558a2e7751d0, +> +>   vector=<optimized out>) at +> +> /usr/src/debug/qemu-4.0/hw/virtio/virtio.c:1118 +> +> #2  0x0000558a2bfdcb1e in virtio_blk_discard_write_zeroes_complete ( +> +>   opaque=0x558a2f2fd420, ret=0) +> +>   at /usr/src/debug/qemu-4.0/hw/block/virtio-blk.c:186 +> +> #3  0x0000558a2c261c7e in blk_aio_complete (acb=0x558a2eed7420) +> +>   at /usr/src/debug/qemu-4.0/block/block-backend.c:1305 +> +> #4  0x0000558a2c3031db in coroutine_trampoline (i0=<optimized out>, +> +>   i1=<optimized out>) at +> +> /usr/src/debug/qemu-4.0/util/coroutine-ucontext.c:116 +> +> #5  0x00007f45b2f8b080 in ?? () from /lib64/libc.so.6 +> +> #6  0x00007fff9ed75780 in ?? () +> +> #7  0x0000000000000000 in ?? () +> +> +> +> It seems like qemu was completing a discard/write_zero request, but +> +> parent BusState was already freed & set to NULL. +> +> +> +> Do we need to drain all pending request before unrealizing virtio-blk +> +> device? Like the following patch proposed? +> +> +> +> +https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg02945.html +> +> +> +> If more info is needed, please let me know. +> +> +may be this will help: +https://patchwork.kernel.org/patch/11213047/ +Yeah, this looks promising! I'll try it out (though it's a one-time +crash for me). Thanks! + +Eryu + +On Thu, Jan 02, 2020 at 10:08:50AM +0800, Eryu Guan wrote: +> +On Tue, Dec 31, 2019 at 11:51:35AM +0100, Igor Mammedov wrote: +> +> On Tue, 31 Dec 2019 18:34:34 +0800 +> +> Eryu Guan <address@hidden> wrote: +> +> +> +> > Hi, +> +> > +> +> > I'm using qemu 4.0 and hit segfault when tearing down kata sandbox, I +> +> > think it's because io completion hits use-after-free when device is +> +> > already gone. Is this a known bug that has been fixed? (I went through +> +> > the git log but didn't find anything obvious). +> +> > +> +> > gdb backtrace is: +> +> > +> +> > Core was generated by `/usr/local/libexec/qemu-kvm -name +> +> > sandbox-5b8df8c6c6901c3c0a9b02879be10fe8d69d6'. +> +> > Program terminated with signal 11, Segmentation fault. +> +> > #0 object_get_class (obj=obj@entry=0x0) at +> +> > /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> > 903 return obj->class; +> +> > (gdb) bt +> +> > #0 object_get_class (obj=obj@entry=0x0) at +> +> > /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> > #1  0x0000558a2c009e9b in virtio_notify_vector (vdev=0x558a2e7751d0, +> +> >   vector=<optimized out>) at +> +> > /usr/src/debug/qemu-4.0/hw/virtio/virtio.c:1118 +> +> > #2  0x0000558a2bfdcb1e in virtio_blk_discard_write_zeroes_complete ( +> +> >   opaque=0x558a2f2fd420, ret=0) +> +> >   at /usr/src/debug/qemu-4.0/hw/block/virtio-blk.c:186 +> +> > #3  0x0000558a2c261c7e in blk_aio_complete (acb=0x558a2eed7420) +> +> >   at /usr/src/debug/qemu-4.0/block/block-backend.c:1305 +> +> > #4  0x0000558a2c3031db in coroutine_trampoline (i0=<optimized out>, +> +> >   i1=<optimized out>) at +> +> > /usr/src/debug/qemu-4.0/util/coroutine-ucontext.c:116 +> +> > #5  0x00007f45b2f8b080 in ?? () from /lib64/libc.so.6 +> +> > #6  0x00007fff9ed75780 in ?? () +> +> > #7  0x0000000000000000 in ?? () +> +> > +> +> > It seems like qemu was completing a discard/write_zero request, but +> +> > parent BusState was already freed & set to NULL. +> +> > +> +> > Do we need to drain all pending request before unrealizing virtio-blk +> +> > device? Like the following patch proposed? +> +> > +> +> > +https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg02945.html +> +> > +> +> > If more info is needed, please let me know. +> +> +> +> may be this will help: +https://patchwork.kernel.org/patch/11213047/ +> +> +Yeah, this looks promising! I'll try it out (though it's a one-time +> +crash for me). Thanks! +After applying this patch, I don't see the original segfaut and +backtrace, but I see this crash + +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +Core was generated by `/usr/local/libexec/qemu-kvm -name +sandbox-a2f34a11a7e1449496503bbc4050ae040c0d3'. +Program terminated with signal 11, Segmentation fault. +#0 0x0000561216a57609 in virtio_pci_notify_write (opaque=0x5612184747e0, +addr=0, val=<optimized out>, size=<optimized out>) at +/usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324 +1324 VirtIOPCIProxy *proxy = +VIRTIO_PCI(DEVICE(vdev)->parent_bus->parent); +Missing separate debuginfos, use: debuginfo-install +glib2-2.42.2-5.1.alios7.x86_64 glibc-2.17-260.alios7.x86_64 +libgcc-4.8.5-28.alios7.1.x86_64 libseccomp-2.3.1-3.alios7.x86_64 +libstdc++-4.8.5-28.alios7.1.x86_64 numactl-libs-2.0.9-5.1.alios7.x86_64 +pixman-0.32.6-3.1.alios7.x86_64 zlib-1.2.7-16.2.alios7.x86_64 +(gdb) bt +#0 0x0000561216a57609 in virtio_pci_notify_write (opaque=0x5612184747e0, +addr=0, val=<optimized out>, size=<optimized out>) at +/usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324 +#1 0x0000561216835b22 in memory_region_write_accessor (mr=<optimized out>, +addr=<optimized out>, value=<optimized out>, size=<optimized out>, +shift=<optimized out>, mask=<optimized out>, attrs=...) at +/usr/src/debug/qemu-4.0/memory.c:502 +#2 0x0000561216833c5d in access_with_adjusted_size (addr=addr@entry=0, +value=value@entry=0x7fcdeab1b8a8, size=size@entry=2, access_size_min=<optimized +out>, access_size_max=<optimized out>, access_fn=0x561216835ac0 +<memory_region_write_accessor>, mr=0x56121846d340, attrs=...) + at /usr/src/debug/qemu-4.0/memory.c:568 +#3 0x0000561216837c66 in memory_region_dispatch_write +(mr=mr@entry=0x56121846d340, addr=0, data=<optimized out>, size=2, +attrs=attrs@entry=...) at /usr/src/debug/qemu-4.0/memory.c:1503 +#4 0x00005612167e036f in flatview_write_continue (fv=fv@entry=0x56121852edd0, +addr=addr@entry=841813602304, attrs=..., buf=buf@entry=0x7fce7dd97028 <Address +0x7fce7dd97028 out of bounds>, len=len@entry=2, addr1=<optimized out>, +l=<optimized out>, mr=0x56121846d340) + at /usr/src/debug/qemu-4.0/exec.c:3279 +#5 0x00005612167e0506 in flatview_write (fv=0x56121852edd0, addr=841813602304, +attrs=..., buf=0x7fce7dd97028 <Address 0x7fce7dd97028 out of bounds>, len=2) at +/usr/src/debug/qemu-4.0/exec.c:3318 +#6 0x00005612167e4a1b in address_space_write (as=<optimized out>, +addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at +/usr/src/debug/qemu-4.0/exec.c:3408 +#7 0x00005612167e4aa5 in address_space_rw (as=<optimized out>, addr=<optimized +out>, attrs=..., attrs@entry=..., buf=buf@entry=0x7fce7dd97028 <Address +0x7fce7dd97028 out of bounds>, len=<optimized out>, is_write=<optimized out>) +at /usr/src/debug/qemu-4.0/exec.c:3419 +#8 0x0000561216849da1 in kvm_cpu_exec (cpu=cpu@entry=0x56121849aa00) at +/usr/src/debug/qemu-4.0/accel/kvm/kvm-all.c:2034 +#9 0x000056121682255e in qemu_kvm_cpu_thread_fn (arg=arg@entry=0x56121849aa00) +at /usr/src/debug/qemu-4.0/cpus.c:1281 +#10 0x0000561216b794d6 in qemu_thread_start (args=<optimized out>) at +/usr/src/debug/qemu-4.0/util/qemu-thread-posix.c:502 +#11 0x00007fce7bef6e25 in start_thread () from /lib64/libpthread.so.0 +#12 0x00007fce7bc1ef1d in clone () from /lib64/libc.so.6 + +And I searched and found +https://bugzilla.redhat.com/show_bug.cgi?id=1706759 +, which has the same +backtrace as above, and it seems commit 7bfde688fb1b ("virtio-blk: Add +blk_drain() to virtio_blk_device_unrealize()") is to fix this particular +bug. + +But I can still hit the bug even after applying the commit. Do I miss +anything? + +Thanks, +Eryu +> +Eryu + +On Tue, Jan 7, 2020 at 2:06 PM Eryu Guan <address@hidden> wrote: +> +> +On Thu, Jan 02, 2020 at 10:08:50AM +0800, Eryu Guan wrote: +> +> On Tue, Dec 31, 2019 at 11:51:35AM +0100, Igor Mammedov wrote: +> +> > On Tue, 31 Dec 2019 18:34:34 +0800 +> +> > Eryu Guan <address@hidden> wrote: +> +> > +> +> > > Hi, +> +> > > +> +> > > I'm using qemu 4.0 and hit segfault when tearing down kata sandbox, I +> +> > > think it's because io completion hits use-after-free when device is +> +> > > already gone. Is this a known bug that has been fixed? (I went through +> +> > > the git log but didn't find anything obvious). +> +> > > +> +> > > gdb backtrace is: +> +> > > +> +> > > Core was generated by `/usr/local/libexec/qemu-kvm -name +> +> > > sandbox-5b8df8c6c6901c3c0a9b02879be10fe8d69d6'. +> +> > > Program terminated with signal 11, Segmentation fault. +> +> > > #0 object_get_class (obj=obj@entry=0x0) at +> +> > > /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> > > 903 return obj->class; +> +> > > (gdb) bt +> +> > > #0 object_get_class (obj=obj@entry=0x0) at +> +> > > /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> > > #1 0x0000558a2c009e9b in virtio_notify_vector (vdev=0x558a2e7751d0, +> +> > > vector=<optimized out>) at +> +> > > /usr/src/debug/qemu-4.0/hw/virtio/virtio.c:1118 +> +> > > #2 0x0000558a2bfdcb1e in virtio_blk_discard_write_zeroes_complete ( +> +> > > opaque=0x558a2f2fd420, ret=0) +> +> > > at /usr/src/debug/qemu-4.0/hw/block/virtio-blk.c:186 +> +> > > #3 0x0000558a2c261c7e in blk_aio_complete (acb=0x558a2eed7420) +> +> > > at /usr/src/debug/qemu-4.0/block/block-backend.c:1305 +> +> > > #4 0x0000558a2c3031db in coroutine_trampoline (i0=<optimized out>, +> +> > > i1=<optimized out>) at +> +> > > /usr/src/debug/qemu-4.0/util/coroutine-ucontext.c:116 +> +> > > #5 0x00007f45b2f8b080 in ?? () from /lib64/libc.so.6 +> +> > > #6 0x00007fff9ed75780 in ?? () +> +> > > #7 0x0000000000000000 in ?? () +> +> > > +> +> > > It seems like qemu was completing a discard/write_zero request, but +> +> > > parent BusState was already freed & set to NULL. +> +> > > +> +> > > Do we need to drain all pending request before unrealizing virtio-blk +> +> > > device? Like the following patch proposed? +> +> > > +> +> > > +https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg02945.html +> +> > > +> +> > > If more info is needed, please let me know. +> +> > +> +> > may be this will help: +https://patchwork.kernel.org/patch/11213047/ +> +> +> +> Yeah, this looks promising! I'll try it out (though it's a one-time +> +> crash for me). Thanks! +> +> +After applying this patch, I don't see the original segfaut and +> +backtrace, but I see this crash +> +> +[Thread debugging using libthread_db enabled] +> +Using host libthread_db library "/lib64/libthread_db.so.1". +> +Core was generated by `/usr/local/libexec/qemu-kvm -name +> +sandbox-a2f34a11a7e1449496503bbc4050ae040c0d3'. +> +Program terminated with signal 11, Segmentation fault. +> +#0 0x0000561216a57609 in virtio_pci_notify_write (opaque=0x5612184747e0, +> +addr=0, val=<optimized out>, size=<optimized out>) at +> +/usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324 +> +1324 VirtIOPCIProxy *proxy = +> +VIRTIO_PCI(DEVICE(vdev)->parent_bus->parent); +> +Missing separate debuginfos, use: debuginfo-install +> +glib2-2.42.2-5.1.alios7.x86_64 glibc-2.17-260.alios7.x86_64 +> +libgcc-4.8.5-28.alios7.1.x86_64 libseccomp-2.3.1-3.alios7.x86_64 +> +libstdc++-4.8.5-28.alios7.1.x86_64 numactl-libs-2.0.9-5.1.alios7.x86_64 +> +pixman-0.32.6-3.1.alios7.x86_64 zlib-1.2.7-16.2.alios7.x86_64 +> +(gdb) bt +> +#0 0x0000561216a57609 in virtio_pci_notify_write (opaque=0x5612184747e0, +> +addr=0, val=<optimized out>, size=<optimized out>) at +> +/usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324 +> +#1 0x0000561216835b22 in memory_region_write_accessor (mr=<optimized out>, +> +addr=<optimized out>, value=<optimized out>, size=<optimized out>, +> +shift=<optimized out>, mask=<optimized out>, attrs=...) at +> +/usr/src/debug/qemu-4.0/memory.c:502 +> +#2 0x0000561216833c5d in access_with_adjusted_size (addr=addr@entry=0, +> +value=value@entry=0x7fcdeab1b8a8, size=size@entry=2, +> +access_size_min=<optimized out>, access_size_max=<optimized out>, +> +access_fn=0x561216835ac0 <memory_region_write_accessor>, mr=0x56121846d340, +> +attrs=...) +> +at /usr/src/debug/qemu-4.0/memory.c:568 +> +#3 0x0000561216837c66 in memory_region_dispatch_write +> +(mr=mr@entry=0x56121846d340, addr=0, data=<optimized out>, size=2, +> +attrs=attrs@entry=...) at /usr/src/debug/qemu-4.0/memory.c:1503 +> +#4 0x00005612167e036f in flatview_write_continue +> +(fv=fv@entry=0x56121852edd0, addr=addr@entry=841813602304, attrs=..., +> +buf=buf@entry=0x7fce7dd97028 <Address 0x7fce7dd97028 out of bounds>, +> +len=len@entry=2, addr1=<optimized out>, l=<optimized out>, mr=0x56121846d340) +> +at /usr/src/debug/qemu-4.0/exec.c:3279 +> +#5 0x00005612167e0506 in flatview_write (fv=0x56121852edd0, +> +addr=841813602304, attrs=..., buf=0x7fce7dd97028 <Address 0x7fce7dd97028 out +> +of bounds>, len=2) at /usr/src/debug/qemu-4.0/exec.c:3318 +> +#6 0x00005612167e4a1b in address_space_write (as=<optimized out>, +> +addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at +> +/usr/src/debug/qemu-4.0/exec.c:3408 +> +#7 0x00005612167e4aa5 in address_space_rw (as=<optimized out>, +> +addr=<optimized out>, attrs=..., attrs@entry=..., +> +buf=buf@entry=0x7fce7dd97028 <Address 0x7fce7dd97028 out of bounds>, +> +len=<optimized out>, is_write=<optimized out>) at +> +/usr/src/debug/qemu-4.0/exec.c:3419 +> +#8 0x0000561216849da1 in kvm_cpu_exec (cpu=cpu@entry=0x56121849aa00) at +> +/usr/src/debug/qemu-4.0/accel/kvm/kvm-all.c:2034 +> +#9 0x000056121682255e in qemu_kvm_cpu_thread_fn +> +(arg=arg@entry=0x56121849aa00) at /usr/src/debug/qemu-4.0/cpus.c:1281 +> +#10 0x0000561216b794d6 in qemu_thread_start (args=<optimized out>) at +> +/usr/src/debug/qemu-4.0/util/qemu-thread-posix.c:502 +> +#11 0x00007fce7bef6e25 in start_thread () from /lib64/libpthread.so.0 +> +#12 0x00007fce7bc1ef1d in clone () from /lib64/libc.so.6 +> +> +And I searched and found +> +https://bugzilla.redhat.com/show_bug.cgi?id=1706759 +, which has the same +> +backtrace as above, and it seems commit 7bfde688fb1b ("virtio-blk: Add +> +blk_drain() to virtio_blk_device_unrealize()") is to fix this particular +> +bug. +> +> +But I can still hit the bug even after applying the commit. Do I miss +> +anything? +Hi Eryu, +This backtrace seems to be caused by this bug (there were two bugs in +1706759): +https://bugzilla.redhat.com/show_bug.cgi?id=1708480 +Although the solution hasn't been tested on virtio-blk yet, you may +want to apply this patch: +https://lists.nongnu.org/archive/html/qemu-devel/2019-12/msg05197.html +Let me know if this works. + +Best regards, Julia Suvorova. + +On Tue, Jan 07, 2020 at 03:01:01PM +0100, Julia Suvorova wrote: +> +On Tue, Jan 7, 2020 at 2:06 PM Eryu Guan <address@hidden> wrote: +> +> +> +> On Thu, Jan 02, 2020 at 10:08:50AM +0800, Eryu Guan wrote: +> +> > On Tue, Dec 31, 2019 at 11:51:35AM +0100, Igor Mammedov wrote: +> +> > > On Tue, 31 Dec 2019 18:34:34 +0800 +> +> > > Eryu Guan <address@hidden> wrote: +> +> > > +> +> > > > Hi, +> +> > > > +> +> > > > I'm using qemu 4.0 and hit segfault when tearing down kata sandbox, I +> +> > > > think it's because io completion hits use-after-free when device is +> +> > > > already gone. Is this a known bug that has been fixed? (I went through +> +> > > > the git log but didn't find anything obvious). +> +> > > > +> +> > > > gdb backtrace is: +> +> > > > +> +> > > > Core was generated by `/usr/local/libexec/qemu-kvm -name +> +> > > > sandbox-5b8df8c6c6901c3c0a9b02879be10fe8d69d6'. +> +> > > > Program terminated with signal 11, Segmentation fault. +> +> > > > #0 object_get_class (obj=obj@entry=0x0) at +> +> > > > /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> > > > 903 return obj->class; +> +> > > > (gdb) bt +> +> > > > #0 object_get_class (obj=obj@entry=0x0) at +> +> > > > /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> > > > #1 0x0000558a2c009e9b in virtio_notify_vector (vdev=0x558a2e7751d0, +> +> > > > vector=<optimized out>) at +> +> > > > /usr/src/debug/qemu-4.0/hw/virtio/virtio.c:1118 +> +> > > > #2 0x0000558a2bfdcb1e in virtio_blk_discard_write_zeroes_complete ( +> +> > > > opaque=0x558a2f2fd420, ret=0) +> +> > > > at /usr/src/debug/qemu-4.0/hw/block/virtio-blk.c:186 +> +> > > > #3 0x0000558a2c261c7e in blk_aio_complete (acb=0x558a2eed7420) +> +> > > > at /usr/src/debug/qemu-4.0/block/block-backend.c:1305 +> +> > > > #4 0x0000558a2c3031db in coroutine_trampoline (i0=<optimized out>, +> +> > > > i1=<optimized out>) at +> +> > > > /usr/src/debug/qemu-4.0/util/coroutine-ucontext.c:116 +> +> > > > #5 0x00007f45b2f8b080 in ?? () from /lib64/libc.so.6 +> +> > > > #6 0x00007fff9ed75780 in ?? () +> +> > > > #7 0x0000000000000000 in ?? () +> +> > > > +> +> > > > It seems like qemu was completing a discard/write_zero request, but +> +> > > > parent BusState was already freed & set to NULL. +> +> > > > +> +> > > > Do we need to drain all pending request before unrealizing virtio-blk +> +> > > > device? Like the following patch proposed? +> +> > > > +> +> > > > +https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg02945.html +> +> > > > +> +> > > > If more info is needed, please let me know. +> +> > > +> +> > > may be this will help: +https://patchwork.kernel.org/patch/11213047/ +> +> > +> +> > Yeah, this looks promising! I'll try it out (though it's a one-time +> +> > crash for me). Thanks! +> +> +> +> After applying this patch, I don't see the original segfaut and +> +> backtrace, but I see this crash +> +> +> +> [Thread debugging using libthread_db enabled] +> +> Using host libthread_db library "/lib64/libthread_db.so.1". +> +> Core was generated by `/usr/local/libexec/qemu-kvm -name +> +> sandbox-a2f34a11a7e1449496503bbc4050ae040c0d3'. +> +> Program terminated with signal 11, Segmentation fault. +> +> #0 0x0000561216a57609 in virtio_pci_notify_write (opaque=0x5612184747e0, +> +> addr=0, val=<optimized out>, size=<optimized out>) at +> +> /usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324 +> +> 1324 VirtIOPCIProxy *proxy = +> +> VIRTIO_PCI(DEVICE(vdev)->parent_bus->parent); +> +> Missing separate debuginfos, use: debuginfo-install +> +> glib2-2.42.2-5.1.alios7.x86_64 glibc-2.17-260.alios7.x86_64 +> +> libgcc-4.8.5-28.alios7.1.x86_64 libseccomp-2.3.1-3.alios7.x86_64 +> +> libstdc++-4.8.5-28.alios7.1.x86_64 numactl-libs-2.0.9-5.1.alios7.x86_64 +> +> pixman-0.32.6-3.1.alios7.x86_64 zlib-1.2.7-16.2.alios7.x86_64 +> +> (gdb) bt +> +> #0 0x0000561216a57609 in virtio_pci_notify_write (opaque=0x5612184747e0, +> +> addr=0, val=<optimized out>, size=<optimized out>) at +> +> /usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324 +> +> #1 0x0000561216835b22 in memory_region_write_accessor (mr=<optimized out>, +> +> addr=<optimized out>, value=<optimized out>, size=<optimized out>, +> +> shift=<optimized out>, mask=<optimized out>, attrs=...) at +> +> /usr/src/debug/qemu-4.0/memory.c:502 +> +> #2 0x0000561216833c5d in access_with_adjusted_size (addr=addr@entry=0, +> +> value=value@entry=0x7fcdeab1b8a8, size=size@entry=2, +> +> access_size_min=<optimized out>, access_size_max=<optimized out>, +> +> access_fn=0x561216835ac0 <memory_region_write_accessor>, mr=0x56121846d340, +> +> attrs=...) +> +> at /usr/src/debug/qemu-4.0/memory.c:568 +> +> #3 0x0000561216837c66 in memory_region_dispatch_write +> +> (mr=mr@entry=0x56121846d340, addr=0, data=<optimized out>, size=2, +> +> attrs=attrs@entry=...) at /usr/src/debug/qemu-4.0/memory.c:1503 +> +> #4 0x00005612167e036f in flatview_write_continue +> +> (fv=fv@entry=0x56121852edd0, addr=addr@entry=841813602304, attrs=..., +> +> buf=buf@entry=0x7fce7dd97028 <Address 0x7fce7dd97028 out of bounds>, +> +> len=len@entry=2, addr1=<optimized out>, l=<optimized out>, +> +> mr=0x56121846d340) +> +> at /usr/src/debug/qemu-4.0/exec.c:3279 +> +> #5 0x00005612167e0506 in flatview_write (fv=0x56121852edd0, +> +> addr=841813602304, attrs=..., buf=0x7fce7dd97028 <Address 0x7fce7dd97028 +> +> out of bounds>, len=2) at /usr/src/debug/qemu-4.0/exec.c:3318 +> +> #6 0x00005612167e4a1b in address_space_write (as=<optimized out>, +> +> addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) +> +> at /usr/src/debug/qemu-4.0/exec.c:3408 +> +> #7 0x00005612167e4aa5 in address_space_rw (as=<optimized out>, +> +> addr=<optimized out>, attrs=..., attrs@entry=..., +> +> buf=buf@entry=0x7fce7dd97028 <Address 0x7fce7dd97028 out of bounds>, +> +> len=<optimized out>, is_write=<optimized out>) at +> +> /usr/src/debug/qemu-4.0/exec.c:3419 +> +> #8 0x0000561216849da1 in kvm_cpu_exec (cpu=cpu@entry=0x56121849aa00) at +> +> /usr/src/debug/qemu-4.0/accel/kvm/kvm-all.c:2034 +> +> #9 0x000056121682255e in qemu_kvm_cpu_thread_fn +> +> (arg=arg@entry=0x56121849aa00) at /usr/src/debug/qemu-4.0/cpus.c:1281 +> +> #10 0x0000561216b794d6 in qemu_thread_start (args=<optimized out>) at +> +> /usr/src/debug/qemu-4.0/util/qemu-thread-posix.c:502 +> +> #11 0x00007fce7bef6e25 in start_thread () from /lib64/libpthread.so.0 +> +> #12 0x00007fce7bc1ef1d in clone () from /lib64/libc.so.6 +> +> +> +> And I searched and found +> +> +https://bugzilla.redhat.com/show_bug.cgi?id=1706759 +, which has the same +> +> backtrace as above, and it seems commit 7bfde688fb1b ("virtio-blk: Add +> +> blk_drain() to virtio_blk_device_unrealize()") is to fix this particular +> +> bug. +> +> +> +> But I can still hit the bug even after applying the commit. Do I miss +> +> anything? +> +> +Hi Eryu, +> +This backtrace seems to be caused by this bug (there were two bugs in +> +1706759): +https://bugzilla.redhat.com/show_bug.cgi?id=1708480 +> +Although the solution hasn't been tested on virtio-blk yet, you may +> +want to apply this patch: +> +https://lists.nongnu.org/archive/html/qemu-devel/2019-12/msg05197.html +> +Let me know if this works. +Will try it out, thanks a lot! + +Eryu + +On Tue, Jan 07, 2020 at 03:01:01PM +0100, Julia Suvorova wrote: +> +On Tue, Jan 7, 2020 at 2:06 PM Eryu Guan <address@hidden> wrote: +> +> +> +> On Thu, Jan 02, 2020 at 10:08:50AM +0800, Eryu Guan wrote: +> +> > On Tue, Dec 31, 2019 at 11:51:35AM +0100, Igor Mammedov wrote: +> +> > > On Tue, 31 Dec 2019 18:34:34 +0800 +> +> > > Eryu Guan <address@hidden> wrote: +> +> > > +> +> > > > Hi, +> +> > > > +> +> > > > I'm using qemu 4.0 and hit segfault when tearing down kata sandbox, I +> +> > > > think it's because io completion hits use-after-free when device is +> +> > > > already gone. Is this a known bug that has been fixed? (I went through +> +> > > > the git log but didn't find anything obvious). +> +> > > > +> +> > > > gdb backtrace is: +> +> > > > +> +> > > > Core was generated by `/usr/local/libexec/qemu-kvm -name +> +> > > > sandbox-5b8df8c6c6901c3c0a9b02879be10fe8d69d6'. +> +> > > > Program terminated with signal 11, Segmentation fault. +> +> > > > #0 object_get_class (obj=obj@entry=0x0) at +> +> > > > /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> > > > 903 return obj->class; +> +> > > > (gdb) bt +> +> > > > #0 object_get_class (obj=obj@entry=0x0) at +> +> > > > /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> > > > #1 0x0000558a2c009e9b in virtio_notify_vector (vdev=0x558a2e7751d0, +> +> > > > vector=<optimized out>) at +> +> > > > /usr/src/debug/qemu-4.0/hw/virtio/virtio.c:1118 +> +> > > > #2 0x0000558a2bfdcb1e in virtio_blk_discard_write_zeroes_complete ( +> +> > > > opaque=0x558a2f2fd420, ret=0) +> +> > > > at /usr/src/debug/qemu-4.0/hw/block/virtio-blk.c:186 +> +> > > > #3 0x0000558a2c261c7e in blk_aio_complete (acb=0x558a2eed7420) +> +> > > > at /usr/src/debug/qemu-4.0/block/block-backend.c:1305 +> +> > > > #4 0x0000558a2c3031db in coroutine_trampoline (i0=<optimized out>, +> +> > > > i1=<optimized out>) at +> +> > > > /usr/src/debug/qemu-4.0/util/coroutine-ucontext.c:116 +> +> > > > #5 0x00007f45b2f8b080 in ?? () from /lib64/libc.so.6 +> +> > > > #6 0x00007fff9ed75780 in ?? () +> +> > > > #7 0x0000000000000000 in ?? () +> +> > > > +> +> > > > It seems like qemu was completing a discard/write_zero request, but +> +> > > > parent BusState was already freed & set to NULL. +> +> > > > +> +> > > > Do we need to drain all pending request before unrealizing virtio-blk +> +> > > > device? Like the following patch proposed? +> +> > > > +> +> > > > +https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg02945.html +> +> > > > +> +> > > > If more info is needed, please let me know. +> +> > > +> +> > > may be this will help: +https://patchwork.kernel.org/patch/11213047/ +> +> > +> +> > Yeah, this looks promising! I'll try it out (though it's a one-time +> +> > crash for me). Thanks! +> +> +> +> After applying this patch, I don't see the original segfaut and +> +> backtrace, but I see this crash +> +> +> +> [Thread debugging using libthread_db enabled] +> +> Using host libthread_db library "/lib64/libthread_db.so.1". +> +> Core was generated by `/usr/local/libexec/qemu-kvm -name +> +> sandbox-a2f34a11a7e1449496503bbc4050ae040c0d3'. +> +> Program terminated with signal 11, Segmentation fault. +> +> #0 0x0000561216a57609 in virtio_pci_notify_write (opaque=0x5612184747e0, +> +> addr=0, val=<optimized out>, size=<optimized out>) at +> +> /usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324 +> +> 1324 VirtIOPCIProxy *proxy = +> +> VIRTIO_PCI(DEVICE(vdev)->parent_bus->parent); +> +> Missing separate debuginfos, use: debuginfo-install +> +> glib2-2.42.2-5.1.alios7.x86_64 glibc-2.17-260.alios7.x86_64 +> +> libgcc-4.8.5-28.alios7.1.x86_64 libseccomp-2.3.1-3.alios7.x86_64 +> +> libstdc++-4.8.5-28.alios7.1.x86_64 numactl-libs-2.0.9-5.1.alios7.x86_64 +> +> pixman-0.32.6-3.1.alios7.x86_64 zlib-1.2.7-16.2.alios7.x86_64 +> +> (gdb) bt +> +> #0 0x0000561216a57609 in virtio_pci_notify_write (opaque=0x5612184747e0, +> +> addr=0, val=<optimized out>, size=<optimized out>) at +> +> /usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324 +> +> #1 0x0000561216835b22 in memory_region_write_accessor (mr=<optimized out>, +> +> addr=<optimized out>, value=<optimized out>, size=<optimized out>, +> +> shift=<optimized out>, mask=<optimized out>, attrs=...) at +> +> /usr/src/debug/qemu-4.0/memory.c:502 +> +> #2 0x0000561216833c5d in access_with_adjusted_size (addr=addr@entry=0, +> +> value=value@entry=0x7fcdeab1b8a8, size=size@entry=2, +> +> access_size_min=<optimized out>, access_size_max=<optimized out>, +> +> access_fn=0x561216835ac0 <memory_region_write_accessor>, mr=0x56121846d340, +> +> attrs=...) +> +> at /usr/src/debug/qemu-4.0/memory.c:568 +> +> #3 0x0000561216837c66 in memory_region_dispatch_write +> +> (mr=mr@entry=0x56121846d340, addr=0, data=<optimized out>, size=2, +> +> attrs=attrs@entry=...) at /usr/src/debug/qemu-4.0/memory.c:1503 +> +> #4 0x00005612167e036f in flatview_write_continue +> +> (fv=fv@entry=0x56121852edd0, addr=addr@entry=841813602304, attrs=..., +> +> buf=buf@entry=0x7fce7dd97028 <Address 0x7fce7dd97028 out of bounds>, +> +> len=len@entry=2, addr1=<optimized out>, l=<optimized out>, +> +> mr=0x56121846d340) +> +> at /usr/src/debug/qemu-4.0/exec.c:3279 +> +> #5 0x00005612167e0506 in flatview_write (fv=0x56121852edd0, +> +> addr=841813602304, attrs=..., buf=0x7fce7dd97028 <Address 0x7fce7dd97028 +> +> out of bounds>, len=2) at /usr/src/debug/qemu-4.0/exec.c:3318 +> +> #6 0x00005612167e4a1b in address_space_write (as=<optimized out>, +> +> addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) +> +> at /usr/src/debug/qemu-4.0/exec.c:3408 +> +> #7 0x00005612167e4aa5 in address_space_rw (as=<optimized out>, +> +> addr=<optimized out>, attrs=..., attrs@entry=..., +> +> buf=buf@entry=0x7fce7dd97028 <Address 0x7fce7dd97028 out of bounds>, +> +> len=<optimized out>, is_write=<optimized out>) at +> +> /usr/src/debug/qemu-4.0/exec.c:3419 +> +> #8 0x0000561216849da1 in kvm_cpu_exec (cpu=cpu@entry=0x56121849aa00) at +> +> /usr/src/debug/qemu-4.0/accel/kvm/kvm-all.c:2034 +> +> #9 0x000056121682255e in qemu_kvm_cpu_thread_fn +> +> (arg=arg@entry=0x56121849aa00) at /usr/src/debug/qemu-4.0/cpus.c:1281 +> +> #10 0x0000561216b794d6 in qemu_thread_start (args=<optimized out>) at +> +> /usr/src/debug/qemu-4.0/util/qemu-thread-posix.c:502 +> +> #11 0x00007fce7bef6e25 in start_thread () from /lib64/libpthread.so.0 +> +> #12 0x00007fce7bc1ef1d in clone () from /lib64/libc.so.6 +> +> +> +> And I searched and found +> +> +https://bugzilla.redhat.com/show_bug.cgi?id=1706759 +, which has the same +> +> backtrace as above, and it seems commit 7bfde688fb1b ("virtio-blk: Add +> +> blk_drain() to virtio_blk_device_unrealize()") is to fix this particular +> +> bug. +> +> +> +> But I can still hit the bug even after applying the commit. Do I miss +> +> anything? +> +> +Hi Eryu, +> +This backtrace seems to be caused by this bug (there were two bugs in +> +1706759): +https://bugzilla.redhat.com/show_bug.cgi?id=1708480 +> +Although the solution hasn't been tested on virtio-blk yet, you may +> +want to apply this patch: +> +https://lists.nongnu.org/archive/html/qemu-devel/2019-12/msg05197.html +> +Let me know if this works. +Unfortunately, I still see the same segfault & backtrace after applying +commit 421afd2fe8dd ("virtio: reset region cache when on queue +deletion") + +Anything I can help to debug? + +Thanks, +Eryu + +On Thu, Jan 09, 2020 at 12:58:06PM +0800, Eryu Guan wrote: +> +On Tue, Jan 07, 2020 at 03:01:01PM +0100, Julia Suvorova wrote: +> +> On Tue, Jan 7, 2020 at 2:06 PM Eryu Guan <address@hidden> wrote: +> +> > +> +> > On Thu, Jan 02, 2020 at 10:08:50AM +0800, Eryu Guan wrote: +> +> > > On Tue, Dec 31, 2019 at 11:51:35AM +0100, Igor Mammedov wrote: +> +> > > > On Tue, 31 Dec 2019 18:34:34 +0800 +> +> > > > Eryu Guan <address@hidden> wrote: +> +> > > > +> +> > > > > Hi, +> +> > > > > +> +> > > > > I'm using qemu 4.0 and hit segfault when tearing down kata sandbox, +> +> > > > > I +> +> > > > > think it's because io completion hits use-after-free when device is +> +> > > > > already gone. Is this a known bug that has been fixed? (I went +> +> > > > > through +> +> > > > > the git log but didn't find anything obvious). +> +> > > > > +> +> > > > > gdb backtrace is: +> +> > > > > +> +> > > > > Core was generated by `/usr/local/libexec/qemu-kvm -name +> +> > > > > sandbox-5b8df8c6c6901c3c0a9b02879be10fe8d69d6'. +> +> > > > > Program terminated with signal 11, Segmentation fault. +> +> > > > > #0 object_get_class (obj=obj@entry=0x0) at +> +> > > > > /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> > > > > 903 return obj->class; +> +> > > > > (gdb) bt +> +> > > > > #0 object_get_class (obj=obj@entry=0x0) at +> +> > > > > /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> > > > > #1 0x0000558a2c009e9b in virtio_notify_vector (vdev=0x558a2e7751d0, +> +> > > > > vector=<optimized out>) at +> +> > > > > /usr/src/debug/qemu-4.0/hw/virtio/virtio.c:1118 +> +> > > > > #2 0x0000558a2bfdcb1e in virtio_blk_discard_write_zeroes_complete ( +> +> > > > > opaque=0x558a2f2fd420, ret=0) +> +> > > > > at /usr/src/debug/qemu-4.0/hw/block/virtio-blk.c:186 +> +> > > > > #3 0x0000558a2c261c7e in blk_aio_complete (acb=0x558a2eed7420) +> +> > > > > at /usr/src/debug/qemu-4.0/block/block-backend.c:1305 +> +> > > > > #4 0x0000558a2c3031db in coroutine_trampoline (i0=<optimized out>, +> +> > > > > i1=<optimized out>) at +> +> > > > > /usr/src/debug/qemu-4.0/util/coroutine-ucontext.c:116 +> +> > > > > #5 0x00007f45b2f8b080 in ?? () from /lib64/libc.so.6 +> +> > > > > #6 0x00007fff9ed75780 in ?? () +> +> > > > > #7 0x0000000000000000 in ?? () +> +> > > > > +> +> > > > > It seems like qemu was completing a discard/write_zero request, but +> +> > > > > parent BusState was already freed & set to NULL. +> +> > > > > +> +> > > > > Do we need to drain all pending request before unrealizing +> +> > > > > virtio-blk +> +> > > > > device? Like the following patch proposed? +> +> > > > > +> +> > > > > +https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg02945.html +> +> > > > > +> +> > > > > If more info is needed, please let me know. +> +> > > > +> +> > > > may be this will help: +https://patchwork.kernel.org/patch/11213047/ +> +> > > +> +> > > Yeah, this looks promising! I'll try it out (though it's a one-time +> +> > > crash for me). Thanks! +> +> > +> +> > After applying this patch, I don't see the original segfaut and +> +> > backtrace, but I see this crash +> +> > +> +> > [Thread debugging using libthread_db enabled] +> +> > Using host libthread_db library "/lib64/libthread_db.so.1". +> +> > Core was generated by `/usr/local/libexec/qemu-kvm -name +> +> > sandbox-a2f34a11a7e1449496503bbc4050ae040c0d3'. +> +> > Program terminated with signal 11, Segmentation fault. +> +> > #0 0x0000561216a57609 in virtio_pci_notify_write (opaque=0x5612184747e0, +> +> > addr=0, val=<optimized out>, size=<optimized out>) at +> +> > /usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324 +> +> > 1324 VirtIOPCIProxy *proxy = +> +> > VIRTIO_PCI(DEVICE(vdev)->parent_bus->parent); +> +> > Missing separate debuginfos, use: debuginfo-install +> +> > glib2-2.42.2-5.1.alios7.x86_64 glibc-2.17-260.alios7.x86_64 +> +> > libgcc-4.8.5-28.alios7.1.x86_64 libseccomp-2.3.1-3.alios7.x86_64 +> +> > libstdc++-4.8.5-28.alios7.1.x86_64 numactl-libs-2.0.9-5.1.alios7.x86_64 +> +> > pixman-0.32.6-3.1.alios7.x86_64 zlib-1.2.7-16.2.alios7.x86_64 +> +> > (gdb) bt +> +> > #0 0x0000561216a57609 in virtio_pci_notify_write (opaque=0x5612184747e0, +> +> > addr=0, val=<optimized out>, size=<optimized out>) at +> +> > /usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324 +> +> > #1 0x0000561216835b22 in memory_region_write_accessor (mr=<optimized +> +> > out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, +> +> > shift=<optimized out>, mask=<optimized out>, attrs=...) at +> +> > /usr/src/debug/qemu-4.0/memory.c:502 +> +> > #2 0x0000561216833c5d in access_with_adjusted_size (addr=addr@entry=0, +> +> > value=value@entry=0x7fcdeab1b8a8, size=size@entry=2, +> +> > access_size_min=<optimized out>, access_size_max=<optimized out>, +> +> > access_fn=0x561216835ac0 <memory_region_write_accessor>, +> +> > mr=0x56121846d340, attrs=...) +> +> > at /usr/src/debug/qemu-4.0/memory.c:568 +> +> > #3 0x0000561216837c66 in memory_region_dispatch_write +> +> > (mr=mr@entry=0x56121846d340, addr=0, data=<optimized out>, size=2, +> +> > attrs=attrs@entry=...) at /usr/src/debug/qemu-4.0/memory.c:1503 +> +> > #4 0x00005612167e036f in flatview_write_continue +> +> > (fv=fv@entry=0x56121852edd0, addr=addr@entry=841813602304, attrs=..., +> +> > buf=buf@entry=0x7fce7dd97028 <Address 0x7fce7dd97028 out of bounds>, +> +> > len=len@entry=2, addr1=<optimized out>, l=<optimized out>, +> +> > mr=0x56121846d340) +> +> > at /usr/src/debug/qemu-4.0/exec.c:3279 +> +> > #5 0x00005612167e0506 in flatview_write (fv=0x56121852edd0, +> +> > addr=841813602304, attrs=..., buf=0x7fce7dd97028 <Address 0x7fce7dd97028 +> +> > out of bounds>, len=2) at /usr/src/debug/qemu-4.0/exec.c:3318 +> +> > #6 0x00005612167e4a1b in address_space_write (as=<optimized out>, +> +> > addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized +> +> > out>) at /usr/src/debug/qemu-4.0/exec.c:3408 +> +> > #7 0x00005612167e4aa5 in address_space_rw (as=<optimized out>, +> +> > addr=<optimized out>, attrs=..., attrs@entry=..., +> +> > buf=buf@entry=0x7fce7dd97028 <Address 0x7fce7dd97028 out of bounds>, +> +> > len=<optimized out>, is_write=<optimized out>) at +> +> > /usr/src/debug/qemu-4.0/exec.c:3419 +> +> > #8 0x0000561216849da1 in kvm_cpu_exec (cpu=cpu@entry=0x56121849aa00) at +> +> > /usr/src/debug/qemu-4.0/accel/kvm/kvm-all.c:2034 +> +> > #9 0x000056121682255e in qemu_kvm_cpu_thread_fn +> +> > (arg=arg@entry=0x56121849aa00) at /usr/src/debug/qemu-4.0/cpus.c:1281 +> +> > #10 0x0000561216b794d6 in qemu_thread_start (args=<optimized out>) at +> +> > /usr/src/debug/qemu-4.0/util/qemu-thread-posix.c:502 +> +> > #11 0x00007fce7bef6e25 in start_thread () from /lib64/libpthread.so.0 +> +> > #12 0x00007fce7bc1ef1d in clone () from /lib64/libc.so.6 +> +> > +> +> > And I searched and found +> +> > +https://bugzilla.redhat.com/show_bug.cgi?id=1706759 +, which has the same +> +> > backtrace as above, and it seems commit 7bfde688fb1b ("virtio-blk: Add +> +> > blk_drain() to virtio_blk_device_unrealize()") is to fix this particular +> +> > bug. +> +> > +> +> > But I can still hit the bug even after applying the commit. Do I miss +> +> > anything? +> +> +> +> Hi Eryu, +> +> This backtrace seems to be caused by this bug (there were two bugs in +> +> 1706759): +https://bugzilla.redhat.com/show_bug.cgi?id=1708480 +> +> Although the solution hasn't been tested on virtio-blk yet, you may +> +> want to apply this patch: +> +> +https://lists.nongnu.org/archive/html/qemu-devel/2019-12/msg05197.html +> +> Let me know if this works. +> +> +Unfortunately, I still see the same segfault & backtrace after applying +> +commit 421afd2fe8dd ("virtio: reset region cache when on queue +> +deletion") +> +> +Anything I can help to debug? +Please post the QEMU command-line and the QMP commands use to remove the +device. + +The backtrace shows a vcpu thread submitting a request. The device +seems to be partially destroyed. That's surprising because the monitor +and the vcpu thread should use the QEMU global mutex to avoid race +conditions. Maybe seeing the QMP commands will make it clearer... + +Stefan +signature.asc +Description: +PGP signature + +On Mon, Jan 13, 2020 at 04:38:55PM +0000, Stefan Hajnoczi wrote: +> +On Thu, Jan 09, 2020 at 12:58:06PM +0800, Eryu Guan wrote: +> +> On Tue, Jan 07, 2020 at 03:01:01PM +0100, Julia Suvorova wrote: +> +> > On Tue, Jan 7, 2020 at 2:06 PM Eryu Guan <address@hidden> wrote: +> +> > > +> +> > > On Thu, Jan 02, 2020 at 10:08:50AM +0800, Eryu Guan wrote: +> +> > > > On Tue, Dec 31, 2019 at 11:51:35AM +0100, Igor Mammedov wrote: +> +> > > > > On Tue, 31 Dec 2019 18:34:34 +0800 +> +> > > > > Eryu Guan <address@hidden> wrote: +> +> > > > > +> +> > > > > > Hi, +> +> > > > > > +> +> > > > > > I'm using qemu 4.0 and hit segfault when tearing down kata +> +> > > > > > sandbox, I +> +> > > > > > think it's because io completion hits use-after-free when device +> +> > > > > > is +> +> > > > > > already gone. Is this a known bug that has been fixed? (I went +> +> > > > > > through +> +> > > > > > the git log but didn't find anything obvious). +> +> > > > > > +> +> > > > > > gdb backtrace is: +> +> > > > > > +> +> > > > > > Core was generated by `/usr/local/libexec/qemu-kvm -name +> +> > > > > > sandbox-5b8df8c6c6901c3c0a9b02879be10fe8d69d6'. +> +> > > > > > Program terminated with signal 11, Segmentation fault. +> +> > > > > > #0 object_get_class (obj=obj@entry=0x0) at +> +> > > > > > /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> > > > > > 903 return obj->class; +> +> > > > > > (gdb) bt +> +> > > > > > #0 object_get_class (obj=obj@entry=0x0) at +> +> > > > > > /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> > > > > > #1 0x0000558a2c009e9b in virtio_notify_vector +> +> > > > > > (vdev=0x558a2e7751d0, +> +> > > > > > vector=<optimized out>) at +> +> > > > > > /usr/src/debug/qemu-4.0/hw/virtio/virtio.c:1118 +> +> > > > > > #2 0x0000558a2bfdcb1e in +> +> > > > > > virtio_blk_discard_write_zeroes_complete ( +> +> > > > > > opaque=0x558a2f2fd420, ret=0) +> +> > > > > > at /usr/src/debug/qemu-4.0/hw/block/virtio-blk.c:186 +> +> > > > > > #3 0x0000558a2c261c7e in blk_aio_complete (acb=0x558a2eed7420) +> +> > > > > > at /usr/src/debug/qemu-4.0/block/block-backend.c:1305 +> +> > > > > > #4 0x0000558a2c3031db in coroutine_trampoline (i0=<optimized +> +> > > > > > out>, +> +> > > > > > i1=<optimized out>) at +> +> > > > > > /usr/src/debug/qemu-4.0/util/coroutine-ucontext.c:116 +> +> > > > > > #5 0x00007f45b2f8b080 in ?? () from /lib64/libc.so.6 +> +> > > > > > #6 0x00007fff9ed75780 in ?? () +> +> > > > > > #7 0x0000000000000000 in ?? () +> +> > > > > > +> +> > > > > > It seems like qemu was completing a discard/write_zero request, +> +> > > > > > but +> +> > > > > > parent BusState was already freed & set to NULL. +> +> > > > > > +> +> > > > > > Do we need to drain all pending request before unrealizing +> +> > > > > > virtio-blk +> +> > > > > > device? Like the following patch proposed? +> +> > > > > > +> +> > > > > > +https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg02945.html +> +> > > > > > +> +> > > > > > If more info is needed, please let me know. +> +> > > > > +> +> > > > > may be this will help: +https://patchwork.kernel.org/patch/11213047/ +> +> > > > +> +> > > > Yeah, this looks promising! I'll try it out (though it's a one-time +> +> > > > crash for me). Thanks! +> +> > > +> +> > > After applying this patch, I don't see the original segfaut and +> +> > > backtrace, but I see this crash +> +> > > +> +> > > [Thread debugging using libthread_db enabled] +> +> > > Using host libthread_db library "/lib64/libthread_db.so.1". +> +> > > Core was generated by `/usr/local/libexec/qemu-kvm -name +> +> > > sandbox-a2f34a11a7e1449496503bbc4050ae040c0d3'. +> +> > > Program terminated with signal 11, Segmentation fault. +> +> > > #0 0x0000561216a57609 in virtio_pci_notify_write +> +> > > (opaque=0x5612184747e0, addr=0, val=<optimized out>, size=<optimized +> +> > > out>) at /usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324 +> +> > > 1324 VirtIOPCIProxy *proxy = +> +> > > VIRTIO_PCI(DEVICE(vdev)->parent_bus->parent); +> +> > > Missing separate debuginfos, use: debuginfo-install +> +> > > glib2-2.42.2-5.1.alios7.x86_64 glibc-2.17-260.alios7.x86_64 +> +> > > libgcc-4.8.5-28.alios7.1.x86_64 libseccomp-2.3.1-3.alios7.x86_64 +> +> > > libstdc++-4.8.5-28.alios7.1.x86_64 numactl-libs-2.0.9-5.1.alios7.x86_64 +> +> > > pixman-0.32.6-3.1.alios7.x86_64 zlib-1.2.7-16.2.alios7.x86_64 +> +> > > (gdb) bt +> +> > > #0 0x0000561216a57609 in virtio_pci_notify_write +> +> > > (opaque=0x5612184747e0, addr=0, val=<optimized out>, size=<optimized +> +> > > out>) at /usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324 +> +> > > #1 0x0000561216835b22 in memory_region_write_accessor (mr=<optimized +> +> > > out>, addr=<optimized out>, value=<optimized out>, size=<optimized +> +> > > out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at +> +> > > /usr/src/debug/qemu-4.0/memory.c:502 +> +> > > #2 0x0000561216833c5d in access_with_adjusted_size (addr=addr@entry=0, +> +> > > value=value@entry=0x7fcdeab1b8a8, size=size@entry=2, +> +> > > access_size_min=<optimized out>, access_size_max=<optimized out>, +> +> > > access_fn=0x561216835ac0 <memory_region_write_accessor>, +> +> > > mr=0x56121846d340, attrs=...) +> +> > > at /usr/src/debug/qemu-4.0/memory.c:568 +> +> > > #3 0x0000561216837c66 in memory_region_dispatch_write +> +> > > (mr=mr@entry=0x56121846d340, addr=0, data=<optimized out>, size=2, +> +> > > attrs=attrs@entry=...) at /usr/src/debug/qemu-4.0/memory.c:1503 +> +> > > #4 0x00005612167e036f in flatview_write_continue +> +> > > (fv=fv@entry=0x56121852edd0, addr=addr@entry=841813602304, attrs=..., +> +> > > buf=buf@entry=0x7fce7dd97028 <Address 0x7fce7dd97028 out of bounds>, +> +> > > len=len@entry=2, addr1=<optimized out>, l=<optimized out>, +> +> > > mr=0x56121846d340) +> +> > > at /usr/src/debug/qemu-4.0/exec.c:3279 +> +> > > #5 0x00005612167e0506 in flatview_write (fv=0x56121852edd0, +> +> > > addr=841813602304, attrs=..., buf=0x7fce7dd97028 <Address +> +> > > 0x7fce7dd97028 out of bounds>, len=2) at +> +> > > /usr/src/debug/qemu-4.0/exec.c:3318 +> +> > > #6 0x00005612167e4a1b in address_space_write (as=<optimized out>, +> +> > > addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized +> +> > > out>) at /usr/src/debug/qemu-4.0/exec.c:3408 +> +> > > #7 0x00005612167e4aa5 in address_space_rw (as=<optimized out>, +> +> > > addr=<optimized out>, attrs=..., attrs@entry=..., +> +> > > buf=buf@entry=0x7fce7dd97028 <Address 0x7fce7dd97028 out of bounds>, +> +> > > len=<optimized out>, is_write=<optimized out>) at +> +> > > /usr/src/debug/qemu-4.0/exec.c:3419 +> +> > > #8 0x0000561216849da1 in kvm_cpu_exec (cpu=cpu@entry=0x56121849aa00) +> +> > > at /usr/src/debug/qemu-4.0/accel/kvm/kvm-all.c:2034 +> +> > > #9 0x000056121682255e in qemu_kvm_cpu_thread_fn +> +> > > (arg=arg@entry=0x56121849aa00) at /usr/src/debug/qemu-4.0/cpus.c:1281 +> +> > > #10 0x0000561216b794d6 in qemu_thread_start (args=<optimized out>) at +> +> > > /usr/src/debug/qemu-4.0/util/qemu-thread-posix.c:502 +> +> > > #11 0x00007fce7bef6e25 in start_thread () from /lib64/libpthread.so.0 +> +> > > #12 0x00007fce7bc1ef1d in clone () from /lib64/libc.so.6 +> +> > > +> +> > > And I searched and found +> +> > > +https://bugzilla.redhat.com/show_bug.cgi?id=1706759 +, which has the same +> +> > > backtrace as above, and it seems commit 7bfde688fb1b ("virtio-blk: Add +> +> > > blk_drain() to virtio_blk_device_unrealize()") is to fix this particular +> +> > > bug. +> +> > > +> +> > > But I can still hit the bug even after applying the commit. Do I miss +> +> > > anything? +> +> > +> +> > Hi Eryu, +> +> > This backtrace seems to be caused by this bug (there were two bugs in +> +> > 1706759): +https://bugzilla.redhat.com/show_bug.cgi?id=1708480 +> +> > Although the solution hasn't been tested on virtio-blk yet, you may +> +> > want to apply this patch: +> +> > +https://lists.nongnu.org/archive/html/qemu-devel/2019-12/msg05197.html +> +> > Let me know if this works. +> +> +> +> Unfortunately, I still see the same segfault & backtrace after applying +> +> commit 421afd2fe8dd ("virtio: reset region cache when on queue +> +> deletion") +> +> +> +> Anything I can help to debug? +> +> +Please post the QEMU command-line and the QMP commands use to remove the +> +device. +It's a normal kata instance using virtio-fs as rootfs. + +/usr/local/libexec/qemu-kvm -name +sandbox-a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d \ + -uuid e03f6b6b-b80b-40c0-8d5b-0cbfed1305d2 -machine +q35,accel=kvm,kernel_irqchip,nvdimm,nosmm,nosmbus,nosata,nopit \ + -cpu host -qmp +unix:/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/qmp.sock,server,nowait + \ + -qmp +unix:/run/vc/vm/debug-a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/qmp.sock,server,nowait + \ + -m 2048M,slots=10,maxmem=773893M -device +pci-bridge,bus=pcie.0,id=pci-bridge-0,chassis_nr=1,shpc=on,addr=2,romfile= \ + -device virtio-serial-pci,disable-modern=false,id=serial0,romfile= -device +virtconsole,chardev=charconsole0,id=console0 \ + -chardev +socket,id=charconsole0,path=/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/console.sock,server,nowait + \ + -device +virtserialport,chardev=metricagent,id=channel10,name=metric.agent.channel.10 \ + -chardev +socket,id=metricagent,path=/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/metric.agent.channel.sock,server,nowait + \ + -device nvdimm,id=nv0,memdev=mem0 -object +memory-backend-file,id=mem0,mem-path=/usr/local/share/containers-image-1.9.0.img,size=268435456 + \ + -object rng-random,id=rng0,filename=/dev/urandom -device +virtio-rng,rng=rng0,romfile= \ + -device virtserialport,chardev=charch0,id=channel0,name=agent.channel.0 \ + -chardev +socket,id=charch0,path=/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/kata.sock,server,nowait + \ + -chardev +socket,id=char-6fca044b801a78a1,path=/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/vhost-fs.sock + \ + -device +vhost-user-fs-pci,chardev=char-6fca044b801a78a1,tag=kataShared,cache-size=8192M +-netdev tap,id=network-0,vhost=on,vhostfds=3,fds=4 \ + -device +driver=virtio-net-pci,netdev=network-0,mac=76:57:f1:ab:51:5c,disable-modern=false,mq=on,vectors=4,romfile= + \ + -global kvm-pit.lost_tick_policy=discard -vga none -no-user-config -nodefaults +-nographic -daemonize \ + -object memory-backend-file,id=dimm1,size=2048M,mem-path=/dev/shm,share=on +-numa node,memdev=dimm1 -kernel /usr/local/share/kernel \ + -append tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 +i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 +console=hvc1 iommu=off cryptomgr.notests net.ifnames=0 pci=lastbus=0 +root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro ro +rootfstype=ext4 quiet systemd.show_status=false panic=1 nr_cpus=96 +agent.use_vsock=false init=/usr/lib/systemd/systemd +systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service +systemd.mask=systemd-networkd.socket \ + -pidfile +/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/pid +\ + -smp 1,cores=1,threads=1,sockets=96,maxcpus=96 + +QMP command to delete device (the device id is just an example, not the +one caused the crash): + +"{\"arguments\":{\"id\":\"virtio-drive-5967abfb917c8da6\"},\"execute\":\"device_del\"}" + +which has been hot plugged by: +"{\"arguments\":{\"cache\":{\"direct\":true,\"no-flush\":false},\"driver\":\"raw\",\"file\":{\"driver\":\"file\",\"filename\":\"/dev/dm-18\"},\"node-name\":\"drive-5967abfb917c8da6\"},\"execute\":\"blockdev-add\"}" +"{\"return\": {}}" +"{\"arguments\":{\"addr\":\"01\",\"bus\":\"pci-bridge-0\",\"drive\":\"drive-5967abfb917c8da6\",\"driver\":\"virtio-blk-pci\",\"id\":\"virtio-drive-5967abfb917c8da6\",\"romfile\":\"\",\"share-rw\":\"on\"},\"execute\":\"device_add\"}" +"{\"return\": {}}" + +> +> +The backtrace shows a vcpu thread submitting a request. The device +> +seems to be partially destroyed. That's surprising because the monitor +> +and the vcpu thread should use the QEMU global mutex to avoid race +> +conditions. Maybe seeing the QMP commands will make it clearer... +> +> +Stefan +Thanks! + +Eryu + +On Tue, Jan 14, 2020 at 10:50:58AM +0800, Eryu Guan wrote: +> +On Mon, Jan 13, 2020 at 04:38:55PM +0000, Stefan Hajnoczi wrote: +> +> On Thu, Jan 09, 2020 at 12:58:06PM +0800, Eryu Guan wrote: +> +> > On Tue, Jan 07, 2020 at 03:01:01PM +0100, Julia Suvorova wrote: +> +> > > On Tue, Jan 7, 2020 at 2:06 PM Eryu Guan <address@hidden> wrote: +> +> > > > +> +> > > > On Thu, Jan 02, 2020 at 10:08:50AM +0800, Eryu Guan wrote: +> +> > > > > On Tue, Dec 31, 2019 at 11:51:35AM +0100, Igor Mammedov wrote: +> +> > > > > > On Tue, 31 Dec 2019 18:34:34 +0800 +> +> > > > > > Eryu Guan <address@hidden> wrote: +> +> > > > > > +> +> > > > > > > Hi, +> +> > > > > > > +> +> > > > > > > I'm using qemu 4.0 and hit segfault when tearing down kata +> +> > > > > > > sandbox, I +> +> > > > > > > think it's because io completion hits use-after-free when +> +> > > > > > > device is +> +> > > > > > > already gone. Is this a known bug that has been fixed? (I went +> +> > > > > > > through +> +> > > > > > > the git log but didn't find anything obvious). +> +> > > > > > > +> +> > > > > > > gdb backtrace is: +> +> > > > > > > +> +> > > > > > > Core was generated by `/usr/local/libexec/qemu-kvm -name +> +> > > > > > > sandbox-5b8df8c6c6901c3c0a9b02879be10fe8d69d6'. +> +> > > > > > > Program terminated with signal 11, Segmentation fault. +> +> > > > > > > #0 object_get_class (obj=obj@entry=0x0) at +> +> > > > > > > /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> > > > > > > 903 return obj->class; +> +> > > > > > > (gdb) bt +> +> > > > > > > #0 object_get_class (obj=obj@entry=0x0) at +> +> > > > > > > /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> > > > > > > #1 0x0000558a2c009e9b in virtio_notify_vector +> +> > > > > > > (vdev=0x558a2e7751d0, +> +> > > > > > > vector=<optimized out>) at +> +> > > > > > > /usr/src/debug/qemu-4.0/hw/virtio/virtio.c:1118 +> +> > > > > > > #2 0x0000558a2bfdcb1e in +> +> > > > > > > virtio_blk_discard_write_zeroes_complete ( +> +> > > > > > > opaque=0x558a2f2fd420, ret=0) +> +> > > > > > > at /usr/src/debug/qemu-4.0/hw/block/virtio-blk.c:186 +> +> > > > > > > #3 0x0000558a2c261c7e in blk_aio_complete (acb=0x558a2eed7420) +> +> > > > > > > at /usr/src/debug/qemu-4.0/block/block-backend.c:1305 +> +> > > > > > > #4 0x0000558a2c3031db in coroutine_trampoline (i0=<optimized +> +> > > > > > > out>, +> +> > > > > > > i1=<optimized out>) at +> +> > > > > > > /usr/src/debug/qemu-4.0/util/coroutine-ucontext.c:116 +> +> > > > > > > #5 0x00007f45b2f8b080 in ?? () from /lib64/libc.so.6 +> +> > > > > > > #6 0x00007fff9ed75780 in ?? () +> +> > > > > > > #7 0x0000000000000000 in ?? () +> +> > > > > > > +> +> > > > > > > It seems like qemu was completing a discard/write_zero request, +> +> > > > > > > but +> +> > > > > > > parent BusState was already freed & set to NULL. +> +> > > > > > > +> +> > > > > > > Do we need to drain all pending request before unrealizing +> +> > > > > > > virtio-blk +> +> > > > > > > device? Like the following patch proposed? +> +> > > > > > > +> +> > > > > > > +https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg02945.html +> +> > > > > > > +> +> > > > > > > If more info is needed, please let me know. +> +> > > > > > +> +> > > > > > may be this will help: +> +> > > > > > +https://patchwork.kernel.org/patch/11213047/ +> +> > > > > +> +> > > > > Yeah, this looks promising! I'll try it out (though it's a one-time +> +> > > > > crash for me). Thanks! +> +> > > > +> +> > > > After applying this patch, I don't see the original segfaut and +> +> > > > backtrace, but I see this crash +> +> > > > +> +> > > > [Thread debugging using libthread_db enabled] +> +> > > > Using host libthread_db library "/lib64/libthread_db.so.1". +> +> > > > Core was generated by `/usr/local/libexec/qemu-kvm -name +> +> > > > sandbox-a2f34a11a7e1449496503bbc4050ae040c0d3'. +> +> > > > Program terminated with signal 11, Segmentation fault. +> +> > > > #0 0x0000561216a57609 in virtio_pci_notify_write +> +> > > > (opaque=0x5612184747e0, addr=0, val=<optimized out>, size=<optimized +> +> > > > out>) at /usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324 +> +> > > > 1324 VirtIOPCIProxy *proxy = +> +> > > > VIRTIO_PCI(DEVICE(vdev)->parent_bus->parent); +> +> > > > Missing separate debuginfos, use: debuginfo-install +> +> > > > glib2-2.42.2-5.1.alios7.x86_64 glibc-2.17-260.alios7.x86_64 +> +> > > > libgcc-4.8.5-28.alios7.1.x86_64 libseccomp-2.3.1-3.alios7.x86_64 +> +> > > > libstdc++-4.8.5-28.alios7.1.x86_64 +> +> > > > numactl-libs-2.0.9-5.1.alios7.x86_64 pixman-0.32.6-3.1.alios7.x86_64 +> +> > > > zlib-1.2.7-16.2.alios7.x86_64 +> +> > > > (gdb) bt +> +> > > > #0 0x0000561216a57609 in virtio_pci_notify_write +> +> > > > (opaque=0x5612184747e0, addr=0, val=<optimized out>, size=<optimized +> +> > > > out>) at /usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324 +> +> > > > #1 0x0000561216835b22 in memory_region_write_accessor (mr=<optimized +> +> > > > out>, addr=<optimized out>, value=<optimized out>, size=<optimized +> +> > > > out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at +> +> > > > /usr/src/debug/qemu-4.0/memory.c:502 +> +> > > > #2 0x0000561216833c5d in access_with_adjusted_size +> +> > > > (addr=addr@entry=0, value=value@entry=0x7fcdeab1b8a8, +> +> > > > size=size@entry=2, access_size_min=<optimized out>, +> +> > > > access_size_max=<optimized out>, access_fn=0x561216835ac0 +> +> > > > <memory_region_write_accessor>, mr=0x56121846d340, attrs=...) +> +> > > > at /usr/src/debug/qemu-4.0/memory.c:568 +> +> > > > #3 0x0000561216837c66 in memory_region_dispatch_write +> +> > > > (mr=mr@entry=0x56121846d340, addr=0, data=<optimized out>, size=2, +> +> > > > attrs=attrs@entry=...) at /usr/src/debug/qemu-4.0/memory.c:1503 +> +> > > > #4 0x00005612167e036f in flatview_write_continue +> +> > > > (fv=fv@entry=0x56121852edd0, addr=addr@entry=841813602304, attrs=..., +> +> > > > buf=buf@entry=0x7fce7dd97028 <Address 0x7fce7dd97028 out of bounds>, +> +> > > > len=len@entry=2, addr1=<optimized out>, l=<optimized out>, +> +> > > > mr=0x56121846d340) +> +> > > > at /usr/src/debug/qemu-4.0/exec.c:3279 +> +> > > > #5 0x00005612167e0506 in flatview_write (fv=0x56121852edd0, +> +> > > > addr=841813602304, attrs=..., buf=0x7fce7dd97028 <Address +> +> > > > 0x7fce7dd97028 out of bounds>, len=2) at +> +> > > > /usr/src/debug/qemu-4.0/exec.c:3318 +> +> > > > #6 0x00005612167e4a1b in address_space_write (as=<optimized out>, +> +> > > > addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized +> +> > > > out>) at /usr/src/debug/qemu-4.0/exec.c:3408 +> +> > > > #7 0x00005612167e4aa5 in address_space_rw (as=<optimized out>, +> +> > > > addr=<optimized out>, attrs=..., attrs@entry=..., +> +> > > > buf=buf@entry=0x7fce7dd97028 <Address 0x7fce7dd97028 out of bounds>, +> +> > > > len=<optimized out>, is_write=<optimized out>) at +> +> > > > /usr/src/debug/qemu-4.0/exec.c:3419 +> +> > > > #8 0x0000561216849da1 in kvm_cpu_exec (cpu=cpu@entry=0x56121849aa00) +> +> > > > at /usr/src/debug/qemu-4.0/accel/kvm/kvm-all.c:2034 +> +> > > > #9 0x000056121682255e in qemu_kvm_cpu_thread_fn +> +> > > > (arg=arg@entry=0x56121849aa00) at /usr/src/debug/qemu-4.0/cpus.c:1281 +> +> > > > #10 0x0000561216b794d6 in qemu_thread_start (args=<optimized out>) at +> +> > > > /usr/src/debug/qemu-4.0/util/qemu-thread-posix.c:502 +> +> > > > #11 0x00007fce7bef6e25 in start_thread () from /lib64/libpthread.so.0 +> +> > > > #12 0x00007fce7bc1ef1d in clone () from /lib64/libc.so.6 +> +> > > > +> +> > > > And I searched and found +> +> > > > +https://bugzilla.redhat.com/show_bug.cgi?id=1706759 +, which has the +> +> > > > same +> +> > > > backtrace as above, and it seems commit 7bfde688fb1b ("virtio-blk: Add +> +> > > > blk_drain() to virtio_blk_device_unrealize()") is to fix this +> +> > > > particular +> +> > > > bug. +> +> > > > +> +> > > > But I can still hit the bug even after applying the commit. Do I miss +> +> > > > anything? +> +> > > +> +> > > Hi Eryu, +> +> > > This backtrace seems to be caused by this bug (there were two bugs in +> +> > > 1706759): +https://bugzilla.redhat.com/show_bug.cgi?id=1708480 +> +> > > Although the solution hasn't been tested on virtio-blk yet, you may +> +> > > want to apply this patch: +> +> > > +> +> > > +https://lists.nongnu.org/archive/html/qemu-devel/2019-12/msg05197.html +> +> > > Let me know if this works. +> +> > +> +> > Unfortunately, I still see the same segfault & backtrace after applying +> +> > commit 421afd2fe8dd ("virtio: reset region cache when on queue +> +> > deletion") +> +> > +> +> > Anything I can help to debug? +> +> +> +> Please post the QEMU command-line and the QMP commands use to remove the +> +> device. +> +> +It's a normal kata instance using virtio-fs as rootfs. +> +> +/usr/local/libexec/qemu-kvm -name +> +sandbox-a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d \ +> +-uuid e03f6b6b-b80b-40c0-8d5b-0cbfed1305d2 -machine +> +q35,accel=kvm,kernel_irqchip,nvdimm,nosmm,nosmbus,nosata,nopit \ +> +-cpu host -qmp +> +unix:/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/qmp.sock,server,nowait +> +\ +> +-qmp +> +unix:/run/vc/vm/debug-a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/qmp.sock,server,nowait +> +\ +> +-m 2048M,slots=10,maxmem=773893M -device +> +pci-bridge,bus=pcie.0,id=pci-bridge-0,chassis_nr=1,shpc=on,addr=2,romfile= \ +> +-device virtio-serial-pci,disable-modern=false,id=serial0,romfile= -device +> +virtconsole,chardev=charconsole0,id=console0 \ +> +-chardev +> +socket,id=charconsole0,path=/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/console.sock,server,nowait +> +\ +> +-device +> +virtserialport,chardev=metricagent,id=channel10,name=metric.agent.channel.10 \ +> +-chardev +> +socket,id=metricagent,path=/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/metric.agent.channel.sock,server,nowait +> +\ +> +-device nvdimm,id=nv0,memdev=mem0 -object +> +memory-backend-file,id=mem0,mem-path=/usr/local/share/containers-image-1.9.0.img,size=268435456 +> +\ +> +-object rng-random,id=rng0,filename=/dev/urandom -device +> +virtio-rng,rng=rng0,romfile= \ +> +-device virtserialport,chardev=charch0,id=channel0,name=agent.channel.0 \ +> +-chardev +> +socket,id=charch0,path=/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/kata.sock,server,nowait +> +\ +> +-chardev +> +socket,id=char-6fca044b801a78a1,path=/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/vhost-fs.sock +> +\ +> +-device +> +vhost-user-fs-pci,chardev=char-6fca044b801a78a1,tag=kataShared,cache-size=8192M +> +-netdev tap,id=network-0,vhost=on,vhostfds=3,fds=4 \ +> +-device +> +driver=virtio-net-pci,netdev=network-0,mac=76:57:f1:ab:51:5c,disable-modern=false,mq=on,vectors=4,romfile= +> +\ +> +-global kvm-pit.lost_tick_policy=discard -vga none -no-user-config +> +-nodefaults -nographic -daemonize \ +> +-object memory-backend-file,id=dimm1,size=2048M,mem-path=/dev/shm,share=on +> +-numa node,memdev=dimm1 -kernel /usr/local/share/kernel \ +> +-append tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 +> +i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k +> +console=hvc0 console=hvc1 iommu=off cryptomgr.notests net.ifnames=0 +> +pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro +> +ro rootfstype=ext4 quiet systemd.show_status=false panic=1 nr_cpus=96 +> +agent.use_vsock=false init=/usr/lib/systemd/systemd +> +systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service +> +systemd.mask=systemd-networkd.socket \ +> +-pidfile +> +/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/pid +> +\ +> +-smp 1,cores=1,threads=1,sockets=96,maxcpus=96 +> +> +QMP command to delete device (the device id is just an example, not the +> +one caused the crash): +> +> +"{\"arguments\":{\"id\":\"virtio-drive-5967abfb917c8da6\"},\"execute\":\"device_del\"}" +> +> +which has been hot plugged by: +> +"{\"arguments\":{\"cache\":{\"direct\":true,\"no-flush\":false},\"driver\":\"raw\",\"file\":{\"driver\":\"file\",\"filename\":\"/dev/dm-18\"},\"node-name\":\"drive-5967abfb917c8da6\"},\"execute\":\"blockdev-add\"}" +> +"{\"return\": {}}" +> +"{\"arguments\":{\"addr\":\"01\",\"bus\":\"pci-bridge-0\",\"drive\":\"drive-5967abfb917c8da6\",\"driver\":\"virtio-blk-pci\",\"id\":\"virtio-drive-5967abfb917c8da6\",\"romfile\":\"\",\"share-rw\":\"on\"},\"execute\":\"device_add\"}" +> +"{\"return\": {}}" +Thanks. I wasn't able to reproduce this crash with qemu.git/master. + +One thing that is strange about the latest backtrace you posted: QEMU is +dispatching the memory access instead of using the ioeventfd code that +that virtio-blk-pci normally takes when a virtqueue is notified. I +guess this means ioeventfd has already been disabled due to the hot +unplug. + +Could you try with machine type "i440fx" instead of "q35"? I wonder if +pci-bridge/shpc is part of the problem. + +Stefan +signature.asc +Description: +PGP signature + +On Tue, Jan 14, 2020 at 04:16:24PM +0000, Stefan Hajnoczi wrote: +> +On Tue, Jan 14, 2020 at 10:50:58AM +0800, Eryu Guan wrote: +> +> On Mon, Jan 13, 2020 at 04:38:55PM +0000, Stefan Hajnoczi wrote: +> +> > On Thu, Jan 09, 2020 at 12:58:06PM +0800, Eryu Guan wrote: +> +> > > On Tue, Jan 07, 2020 at 03:01:01PM +0100, Julia Suvorova wrote: +> +> > > > On Tue, Jan 7, 2020 at 2:06 PM Eryu Guan <address@hidden> wrote: +> +> > > > > +> +> > > > > On Thu, Jan 02, 2020 at 10:08:50AM +0800, Eryu Guan wrote: +> +> > > > > > On Tue, Dec 31, 2019 at 11:51:35AM +0100, Igor Mammedov wrote: +> +> > > > > > > On Tue, 31 Dec 2019 18:34:34 +0800 +> +> > > > > > > Eryu Guan <address@hidden> wrote: +> +> > > > > > > +> +> > > > > > > > Hi, +> +> > > > > > > > +> +> > > > > > > > I'm using qemu 4.0 and hit segfault when tearing down kata +> +> > > > > > > > sandbox, I +> +> > > > > > > > think it's because io completion hits use-after-free when +> +> > > > > > > > device is +> +> > > > > > > > already gone. Is this a known bug that has been fixed? (I +> +> > > > > > > > went through +> +> > > > > > > > the git log but didn't find anything obvious). +> +> > > > > > > > +> +> > > > > > > > gdb backtrace is: +> +> > > > > > > > +> +> > > > > > > > Core was generated by `/usr/local/libexec/qemu-kvm -name +> +> > > > > > > > sandbox-5b8df8c6c6901c3c0a9b02879be10fe8d69d6'. +> +> > > > > > > > Program terminated with signal 11, Segmentation fault. +> +> > > > > > > > #0 object_get_class (obj=obj@entry=0x0) at +> +> > > > > > > > /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> > > > > > > > 903 return obj->class; +> +> > > > > > > > (gdb) bt +> +> > > > > > > > #0 object_get_class (obj=obj@entry=0x0) at +> +> > > > > > > > /usr/src/debug/qemu-4.0/qom/object.c:903 +> +> > > > > > > > #1 0x0000558a2c009e9b in virtio_notify_vector +> +> > > > > > > > (vdev=0x558a2e7751d0, +> +> > > > > > > > vector=<optimized out>) at +> +> > > > > > > > /usr/src/debug/qemu-4.0/hw/virtio/virtio.c:1118 +> +> > > > > > > > #2 0x0000558a2bfdcb1e in +> +> > > > > > > > virtio_blk_discard_write_zeroes_complete ( +> +> > > > > > > > opaque=0x558a2f2fd420, ret=0) +> +> > > > > > > > at /usr/src/debug/qemu-4.0/hw/block/virtio-blk.c:186 +> +> > > > > > > > #3 0x0000558a2c261c7e in blk_aio_complete +> +> > > > > > > > (acb=0x558a2eed7420) +> +> > > > > > > > at /usr/src/debug/qemu-4.0/block/block-backend.c:1305 +> +> > > > > > > > #4 0x0000558a2c3031db in coroutine_trampoline (i0=<optimized +> +> > > > > > > > out>, +> +> > > > > > > > i1=<optimized out>) at +> +> > > > > > > > /usr/src/debug/qemu-4.0/util/coroutine-ucontext.c:116 +> +> > > > > > > > #5 0x00007f45b2f8b080 in ?? () from /lib64/libc.so.6 +> +> > > > > > > > #6 0x00007fff9ed75780 in ?? () +> +> > > > > > > > #7 0x0000000000000000 in ?? () +> +> > > > > > > > +> +> > > > > > > > It seems like qemu was completing a discard/write_zero +> +> > > > > > > > request, but +> +> > > > > > > > parent BusState was already freed & set to NULL. +> +> > > > > > > > +> +> > > > > > > > Do we need to drain all pending request before unrealizing +> +> > > > > > > > virtio-blk +> +> > > > > > > > device? Like the following patch proposed? +> +> > > > > > > > +> +> > > > > > > > +https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg02945.html +> +> > > > > > > > +> +> > > > > > > > If more info is needed, please let me know. +> +> > > > > > > +> +> > > > > > > may be this will help: +> +> > > > > > > +https://patchwork.kernel.org/patch/11213047/ +> +> > > > > > +> +> > > > > > Yeah, this looks promising! I'll try it out (though it's a +> +> > > > > > one-time +> +> > > > > > crash for me). Thanks! +> +> > > > > +> +> > > > > After applying this patch, I don't see the original segfaut and +> +> > > > > backtrace, but I see this crash +> +> > > > > +> +> > > > > [Thread debugging using libthread_db enabled] +> +> > > > > Using host libthread_db library "/lib64/libthread_db.so.1". +> +> > > > > Core was generated by `/usr/local/libexec/qemu-kvm -name +> +> > > > > sandbox-a2f34a11a7e1449496503bbc4050ae040c0d3'. +> +> > > > > Program terminated with signal 11, Segmentation fault. +> +> > > > > #0 0x0000561216a57609 in virtio_pci_notify_write +> +> > > > > (opaque=0x5612184747e0, addr=0, val=<optimized out>, +> +> > > > > size=<optimized out>) at +> +> > > > > /usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324 +> +> > > > > 1324 VirtIOPCIProxy *proxy = +> +> > > > > VIRTIO_PCI(DEVICE(vdev)->parent_bus->parent); +> +> > > > > Missing separate debuginfos, use: debuginfo-install +> +> > > > > glib2-2.42.2-5.1.alios7.x86_64 glibc-2.17-260.alios7.x86_64 +> +> > > > > libgcc-4.8.5-28.alios7.1.x86_64 libseccomp-2.3.1-3.alios7.x86_64 +> +> > > > > libstdc++-4.8.5-28.alios7.1.x86_64 +> +> > > > > numactl-libs-2.0.9-5.1.alios7.x86_64 +> +> > > > > pixman-0.32.6-3.1.alios7.x86_64 zlib-1.2.7-16.2.alios7.x86_64 +> +> > > > > (gdb) bt +> +> > > > > #0 0x0000561216a57609 in virtio_pci_notify_write +> +> > > > > (opaque=0x5612184747e0, addr=0, val=<optimized out>, +> +> > > > > size=<optimized out>) at +> +> > > > > /usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324 +> +> > > > > #1 0x0000561216835b22 in memory_region_write_accessor +> +> > > > > (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, +> +> > > > > size=<optimized out>, shift=<optimized out>, mask=<optimized out>, +> +> > > > > attrs=...) at /usr/src/debug/qemu-4.0/memory.c:502 +> +> > > > > #2 0x0000561216833c5d in access_with_adjusted_size +> +> > > > > (addr=addr@entry=0, value=value@entry=0x7fcdeab1b8a8, +> +> > > > > size=size@entry=2, access_size_min=<optimized out>, +> +> > > > > access_size_max=<optimized out>, access_fn=0x561216835ac0 +> +> > > > > <memory_region_write_accessor>, mr=0x56121846d340, attrs=...) +> +> > > > > at /usr/src/debug/qemu-4.0/memory.c:568 +> +> > > > > #3 0x0000561216837c66 in memory_region_dispatch_write +> +> > > > > (mr=mr@entry=0x56121846d340, addr=0, data=<optimized out>, size=2, +> +> > > > > attrs=attrs@entry=...) at /usr/src/debug/qemu-4.0/memory.c:1503 +> +> > > > > #4 0x00005612167e036f in flatview_write_continue +> +> > > > > (fv=fv@entry=0x56121852edd0, addr=addr@entry=841813602304, +> +> > > > > attrs=..., buf=buf@entry=0x7fce7dd97028 <Address 0x7fce7dd97028 out +> +> > > > > of bounds>, len=len@entry=2, addr1=<optimized out>, l=<optimized +> +> > > > > out>, mr=0x56121846d340) +> +> > > > > at /usr/src/debug/qemu-4.0/exec.c:3279 +> +> > > > > #5 0x00005612167e0506 in flatview_write (fv=0x56121852edd0, +> +> > > > > addr=841813602304, attrs=..., buf=0x7fce7dd97028 <Address +> +> > > > > 0x7fce7dd97028 out of bounds>, len=2) at +> +> > > > > /usr/src/debug/qemu-4.0/exec.c:3318 +> +> > > > > #6 0x00005612167e4a1b in address_space_write (as=<optimized out>, +> +> > > > > addr=<optimized out>, attrs=..., buf=<optimized out>, +> +> > > > > len=<optimized out>) at /usr/src/debug/qemu-4.0/exec.c:3408 +> +> > > > > #7 0x00005612167e4aa5 in address_space_rw (as=<optimized out>, +> +> > > > > addr=<optimized out>, attrs=..., attrs@entry=..., +> +> > > > > buf=buf@entry=0x7fce7dd97028 <Address 0x7fce7dd97028 out of +> +> > > > > bounds>, len=<optimized out>, is_write=<optimized out>) at +> +> > > > > /usr/src/debug/qemu-4.0/exec.c:3419 +> +> > > > > #8 0x0000561216849da1 in kvm_cpu_exec +> +> > > > > (cpu=cpu@entry=0x56121849aa00) at +> +> > > > > /usr/src/debug/qemu-4.0/accel/kvm/kvm-all.c:2034 +> +> > > > > #9 0x000056121682255e in qemu_kvm_cpu_thread_fn +> +> > > > > (arg=arg@entry=0x56121849aa00) at +> +> > > > > /usr/src/debug/qemu-4.0/cpus.c:1281 +> +> > > > > #10 0x0000561216b794d6 in qemu_thread_start (args=<optimized out>) +> +> > > > > at /usr/src/debug/qemu-4.0/util/qemu-thread-posix.c:502 +> +> > > > > #11 0x00007fce7bef6e25 in start_thread () from +> +> > > > > /lib64/libpthread.so.0 +> +> > > > > #12 0x00007fce7bc1ef1d in clone () from /lib64/libc.so.6 +> +> > > > > +> +> > > > > And I searched and found +> +> > > > > +https://bugzilla.redhat.com/show_bug.cgi?id=1706759 +, which has the +> +> > > > > same +> +> > > > > backtrace as above, and it seems commit 7bfde688fb1b ("virtio-blk: +> +> > > > > Add +> +> > > > > blk_drain() to virtio_blk_device_unrealize()") is to fix this +> +> > > > > particular +> +> > > > > bug. +> +> > > > > +> +> > > > > But I can still hit the bug even after applying the commit. Do I +> +> > > > > miss +> +> > > > > anything? +> +> > > > +> +> > > > Hi Eryu, +> +> > > > This backtrace seems to be caused by this bug (there were two bugs in +> +> > > > 1706759): +https://bugzilla.redhat.com/show_bug.cgi?id=1708480 +> +> > > > Although the solution hasn't been tested on virtio-blk yet, you may +> +> > > > want to apply this patch: +> +> > > > +> +> > > > +https://lists.nongnu.org/archive/html/qemu-devel/2019-12/msg05197.html +> +> > > > Let me know if this works. +> +> > > +> +> > > Unfortunately, I still see the same segfault & backtrace after applying +> +> > > commit 421afd2fe8dd ("virtio: reset region cache when on queue +> +> > > deletion") +> +> > > +> +> > > Anything I can help to debug? +> +> > +> +> > Please post the QEMU command-line and the QMP commands use to remove the +> +> > device. +> +> +> +> It's a normal kata instance using virtio-fs as rootfs. +> +> +> +> /usr/local/libexec/qemu-kvm -name +> +> sandbox-a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d \ +> +> -uuid e03f6b6b-b80b-40c0-8d5b-0cbfed1305d2 -machine +> +> q35,accel=kvm,kernel_irqchip,nvdimm,nosmm,nosmbus,nosata,nopit \ +> +> -cpu host -qmp +> +> unix:/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/qmp.sock,server,nowait +> +> \ +> +> -qmp +> +> unix:/run/vc/vm/debug-a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/qmp.sock,server,nowait +> +> \ +> +> -m 2048M,slots=10,maxmem=773893M -device +> +> pci-bridge,bus=pcie.0,id=pci-bridge-0,chassis_nr=1,shpc=on,addr=2,romfile= \ +> +> -device virtio-serial-pci,disable-modern=false,id=serial0,romfile= -device +> +> virtconsole,chardev=charconsole0,id=console0 \ +> +> -chardev +> +> socket,id=charconsole0,path=/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/console.sock,server,nowait +> +> \ +> +> -device +> +> virtserialport,chardev=metricagent,id=channel10,name=metric.agent.channel.10 +> +> \ +> +> -chardev +> +> socket,id=metricagent,path=/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/metric.agent.channel.sock,server,nowait +> +> \ +> +> -device nvdimm,id=nv0,memdev=mem0 -object +> +> memory-backend-file,id=mem0,mem-path=/usr/local/share/containers-image-1.9.0.img,size=268435456 +> +> \ +> +> -object rng-random,id=rng0,filename=/dev/urandom -device +> +> virtio-rng,rng=rng0,romfile= \ +> +> -device virtserialport,chardev=charch0,id=channel0,name=agent.channel.0 \ +> +> -chardev +> +> socket,id=charch0,path=/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/kata.sock,server,nowait +> +> \ +> +> -chardev +> +> socket,id=char-6fca044b801a78a1,path=/run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/vhost-fs.sock +> +> \ +> +> -device +> +> vhost-user-fs-pci,chardev=char-6fca044b801a78a1,tag=kataShared,cache-size=8192M +> +> -netdev tap,id=network-0,vhost=on,vhostfds=3,fds=4 \ +> +> -device +> +> driver=virtio-net-pci,netdev=network-0,mac=76:57:f1:ab:51:5c,disable-modern=false,mq=on,vectors=4,romfile= +> +> \ +> +> -global kvm-pit.lost_tick_policy=discard -vga none -no-user-config +> +> -nodefaults -nographic -daemonize \ +> +> -object memory-backend-file,id=dimm1,size=2048M,mem-path=/dev/shm,share=on +> +> -numa node,memdev=dimm1 -kernel /usr/local/share/kernel \ +> +> -append tsc=reliable no_timer_check rcupdate.rcu_expedited=1 +> +> i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp +> +> reboot=k console=hvc0 console=hvc1 iommu=off cryptomgr.notests +> +> net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 +> +> rootflags=dax,data=ordered,errors=remount-ro ro rootfstype=ext4 quiet +> +> systemd.show_status=false panic=1 nr_cpus=96 agent.use_vsock=false +> +> init=/usr/lib/systemd/systemd systemd.unit=kata-containers.target +> +> systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket \ +> +> -pidfile +> +> /run/vc/vm/a670786fcb1758d2348eb120939d90ffacf9f049f10b337284ad49bbcd60936d/pid +> +> \ +> +> -smp 1,cores=1,threads=1,sockets=96,maxcpus=96 +> +> +> +> QMP command to delete device (the device id is just an example, not the +> +> one caused the crash): +> +> +> +> "{\"arguments\":{\"id\":\"virtio-drive-5967abfb917c8da6\"},\"execute\":\"device_del\"}" +> +> +> +> which has been hot plugged by: +> +> "{\"arguments\":{\"cache\":{\"direct\":true,\"no-flush\":false},\"driver\":\"raw\",\"file\":{\"driver\":\"file\",\"filename\":\"/dev/dm-18\"},\"node-name\":\"drive-5967abfb917c8da6\"},\"execute\":\"blockdev-add\"}" +> +> "{\"return\": {}}" +> +> "{\"arguments\":{\"addr\":\"01\",\"bus\":\"pci-bridge-0\",\"drive\":\"drive-5967abfb917c8da6\",\"driver\":\"virtio-blk-pci\",\"id\":\"virtio-drive-5967abfb917c8da6\",\"romfile\":\"\",\"share-rw\":\"on\"},\"execute\":\"device_add\"}" +> +> "{\"return\": {}}" +> +> +Thanks. I wasn't able to reproduce this crash with qemu.git/master. +> +> +One thing that is strange about the latest backtrace you posted: QEMU is +> +dispatching the memory access instead of using the ioeventfd code that +> +that virtio-blk-pci normally takes when a virtqueue is notified. I +> +guess this means ioeventfd has already been disabled due to the hot +> +unplug. +> +> +Could you try with machine type "i440fx" instead of "q35"? I wonder if +> +pci-bridge/shpc is part of the problem. +Sure, will try it. But it may take some time, as the test bed is busy +with other testing tasks. I'll report back once I got the results. + +Thanks, +Eryu + diff --git a/results/classifier/zero-shot/108/all/891525 b/results/classifier/zero-shot/108/all/891525 new file mode 100644 index 000000000..09820102e --- /dev/null +++ b/results/classifier/zero-shot/108/all/891525 @@ -0,0 +1,74 @@ +debug: 0.980 +permissions: 0.978 +other: 0.975 +graphic: 0.966 +device: 0.966 +files: 0.965 +network: 0.963 +boot: 0.960 +KVM: 0.960 +socket: 0.958 +PID: 0.956 +semantic: 0.952 +performance: 0.950 +vnc: 0.914 + +Guest kernel crashes when booting a NUMA guest without explicitly specifying cpus= in -numa option + +Target: x86_64-softmmu + +Qemu Command line: [root@hs22 qemu-1.0-rc2]# ./x86_64-softmmu/qemu-system-x86_64 -smp sockets=2,cores=4,threads=2 -numa node,nodeid=0,mem=4g -numa node,nodeid=1,mem=1g -cpu core2duo -m 5g /home/bharata/f15-lvm -nographic --enable-kvm -net nic,macaddr=54:52:00:46:26:84,model=e1000 -net tap,script=/etc/qemu-if,ifname=vnet0 + +Qemu version: 1.0-rc2 + +When guest is started with -numa option without explicitly specifying the cpus=, guest kernel crashes as below: + +[ 0.252159] divide error: 0000 [#1] SMP +[ 0.252970] last sysfs file: +[ 0.252970] CPU 1 +[ 0.252970] Modules linked in: +[ 0.252970] +[ 0.252970] Pid: 2, comm: kthreadd Not tainted 2.6.38.6-26.rc1.fc15.x86_64 #1 Bochs Bochs +[ 0.252970] RIP: 0010:[<ffffffff8104f4d4>] [<ffffffff8104f4d4>] select_task_rq_fair+0x44a/0x571 +[ 0.252970] RSP: 0000:ffff88011767fc60 EFLAGS: 00010046 +[ 0.252970] RAX: 0000000000000000 RBX: ffff88015d6ad300 RCX: 0000000000000000 +[ 0.252970] RDX: 0000000000000000 RSI: 0000000000000100 RDI: 0000000000000000 +[ 0.252970] RBP: ffff88011767fd10 R08: 0000000000000100 R09: ffff88015d6ad338 +[ 0.252970] R10: 0000000000013840 R11: 0000000000800711 R12: 0000000000000000 +[ 0.252970] R13: ffff88015fc0f810 R14: 0000000000000001 R15: 0000000000000000 +[ 0.252970] FS: 0000000000000000(0000) GS:ffff88015fc00000(0000) knlGS:0000000000000000 +[ 0.252970] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b +[ 0.252970] CR2: 00000000ffffffff CR3: 0000000001a03000 CR4: 00000000000006e0 +[ 0.252970] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 0.252970] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +[ 0.252970] Process kthreadd (pid: 2, threadinfo ffff88011767e000, task ffff88015d671720) +[ 0.252970] Stack: +[ 0.252970] ffffffff81475873 ffffffff81a02140 ffff88011767fce0 ffffffff8106c5a3 +[ 0.252970] ffff88015d6ad318 000000010000000e 0000000000013840 0000000000013840 +[ 0.252970] ffff88015d6ad318 0000007d00000001 ffff880100000000 ffff88015d6d81e8 +[ 0.252970] Call Trace: +[ 0.252970] [<ffffffff81475873>] ? _raw_spin_lock_irq+0x1c/0x1e +[ 0.252970] [<ffffffff8106c5a3>] ? alloc_pid+0x2e6/0x335 +[ 0.252970] [<ffffffff81048960>] select_task_rq+0x16/0x46 +[ 0.252970] [<ffffffff8104e29a>] wake_up_new_task+0x3a/0xde +[ 0.252970] [<ffffffff810546ce>] do_fork+0x1f1/0x2bf +[ 0.252970] [<ffffffff8100804e>] ? load_TLS+0x10/0x14 +[ 0.252970] [<ffffffff81008714>] ? __switch_to+0xc6/0x220 +[ 0.252970] [<ffffffff81010c1a>] kernel_thread+0x75/0x77 +[ 0.252970] [<ffffffff8106eacf>] ? kthread+0x0/0x8c +[ 0.252970] [<ffffffff8100a9e0>] ? kernel_thread_helper+0x0/0x10 +[ 0.252970] [<ffffffff8106ee93>] kthreadd+0xe7/0x124 +[ 0.252970] [<ffffffff8100a9e4>] kernel_thread_helper+0x4/0x10 +[ 0.252970] [<ffffffff8106edac>] ? kthreadd+0x0/0x124 +[ 0.252970] [<ffffffff8100a9e0>] ? kernel_thread_helper+0x0/0x10 +[ 0.252970] Code: 01 45 c0 8b 8d 78 ff ff ff 48 8b 75 90 89 cf e8 4a 28 ff ff 3b 05 bd 89 ae 00 89 c1 7c c5 48 8b 45 c0 8b 4b 08 31 d2 48 c1 e0 0a +[ 0.252970] f7 f1 45 85 e4 75 08 48 3b 45 b0 72 08 eb 0d 48 89 45 b8 eb +[ 0.252970] RIP [<ffffffff8104f4d4>] select_task_rq_fair+0x44a/0x571 +[ 0.252970] RSP <ffff88011767fc60> + +When cpus= is specified for each node explicitly, guest boots fine. + +Is this still an issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/893208 b/results/classifier/zero-shot/108/all/893208 new file mode 100644 index 000000000..d6db6d69f --- /dev/null +++ b/results/classifier/zero-shot/108/all/893208 @@ -0,0 +1,556 @@ +other: 0.975 +debug: 0.961 +semantic: 0.961 +PID: 0.956 +performance: 0.953 +vnc: 0.950 +permissions: 0.949 +device: 0.948 +boot: 0.946 +graphic: 0.940 +KVM: 0.929 +socket: 0.922 +network: 0.913 +files: 0.912 + +qemu on ARM hosts can't boot i386 image + +If you apply some workarounds for bug 870990, bug 883133 and bug 883136 QEMU still cannot boot the i386 debian_squeeze_i386_standard.qcow2 image from http://people.debian.org/~aurel32/qemu/i386/ -- grub starts to boot but something causes the system to reset just before display of the blue-background grub menu, so we go round in a loop forever. This image boots OK on i386 hosted qemu so this indicates some kind of ARM-host specific bug. + +I think this is a timer related issue; once I've fixed 883133 it falls with a triple fault from a divide instruction not long after a load of rdtsc stuff. If I use -m 486 I can boot an old Debian 5 netinstall cd into rescue mode (with a bogomips of 69!). + +Dave + + +On the basis of this analysis by David and since we don't seem to have problems with ARM guests on ARM hosts, I think we can deprioritise this bug as not being a requirement for KVM work. + + +I was about to file a bug with the exact symptoms. + +I can't boot a (possibly the very one) debian wheezy standard qcow2 image on my Odroid C1 (works fine on x86-32 with the same command line) using qemu-system-i386 that I built yesterday from git source. + +Is there a workaround or has nobody needed this for the last 4 years? Please advise on how to provide more relevant details. + +Thanks + +Just for laughs I 've tested my qemu build with this guy's x86 kernel and it's working as expected: + +https://github.com/mopp/Axel + +the difference being it was using -cdrom switch to boot from an .iso image + +Hello boyos, + +I got myself an Rpi2 recently and have been reading up on qemu. + +Does this mean there's a problem booting x86 images on Arm or just the ones from that particular source? + + + +On 09/19/15 12:54, Marina Kovalevna wrote: +> Hello boyos, +> +> I got myself an Rpi2 recently and have been reading up on qemu. +> +> Does this mean there's a problem booting x86 images on Arm or just the +> ones from that particular source? +> + +The outlandishness of this use case (-> buy an underpowered toy, run x86 +programs on it via *emulation*) is so exceptional that it tickled my +fancy and I looked into it. + +I'm CCing Peter and Dave; I can see in the LP comments from 2011 that +they looked at this in 2011-2012. We're going to have a good chuckle +here I promise. + +So, Dave was correct in comment #1 +<https://bugs.launchpad.net/qemu-linaro/+bug/893208/comments/1> where he +wrote, + +"it falls with a triple fault from a divide instruction not long after a +load of rdtsc stuff". + +I booted the same Debian i386 Squeeze (and Wheezy) "standard" images +from Aurelien's website as everyone else, in TCG mode, both on an x86_64 +host, and -- "brace for impact" -- on an aarch64 host (APM Mustang). The +command line was simple, + +$ qemu-system-i386 -hda debian_squeeze_i386_standard.qcow2 + +The symptoms reproduced on the aarch64 host, and didn't on the x86_64 host. + +Then I added + + -d in_asm,op,int,exec,cpu,mmu,cpu_reset,ioport,unimp,guest_errors + +to capture the TCG logs, up to the point where grub rebooted (vs. didn't +reboot, on the x86_64 host), and then diffed the logs between each +other. (This wasn't so fast, on the aarch64 host, approx. 530 MB of log +was written before the reboot.) + +Looking at the logs, I can confirm Dave's analysis from 2011 -- there's +a CPUID, then an RDTSC, then a division by zero. + +So if you look at GRUB's code, you find the calibrate_tsc() function in +"grub-core/kern/i386/tsc.c". (We're old friends with that function.) It +calls grub_get_tsc() -- same file --, which explains both CPUID and +RDTSC. (CPUID is only used for serialization, ie. for preventing the CPU +from executing RDTSC out-of-order. RDTSCP would be an alternative, which +combines both, but that's not as widely available.) + +Where does the division by zero come from then? Well grub fetches and +stashes the TSC, then programs the PIT to sleep for some time, then +re-fetches the TSC, and uses the TSC difference as denominator when +calculating the "TSC rate". (It has a solid idea of the real time +passed, due to the PIT frequency being a given.) + +Let's see where the TSC values come from in QEMU / TCG: + +helper_rdtsc() [target-i386/misc_helper.c] + cpu_get_tsc() [hw/i386/pc.c] + cpu_get_ticks() [cpus.c] + cpu_get_real_ticks() [include/qemu/timer.h] + +Now, the cpu_get_real_ticks() implementation is *host* specific. You can +find it implemented for a bunch of host architectures in +"include/qemu/timer.h". + +Neither ARM nor AARCH64 qualify though; for those, the following +pearlescent fallback gets built: + +> /* The host CPU doesn't have an easily accessible cycle counter. +> Just return a monotonically increasing value. This will be +> totally wrong, but hopefully better than nothing. */ +> static inline int64_t cpu_get_real_ticks (void) +> { +> static int64_t ticks = 0; +> return ticks++; +> } + +Note that this code dates back to the following commit (year 2006): + +commit 46152182100e68f7f8aa4954af1bf91160bb3d15 +Author: pbrook <pbrook@c046a42c-6fe2-441c-8c8c-71466251a162> +Date: Sun Jul 30 19:16:29 2006 +0000 + + Rewrite Arm host support. + +So... the frequency of the PIT is 1193182 per second (see PIT_FREQ in +QEMU, and GRUB_SPEAKER_PIT_FREQUENCY in GRUB). Grub sleeps for 65535 +such cycles in calibrate_tsc(), between the two TSC reads. That's +approximately 55 milliseconds. And for that long period, grub finds that +the TSC has incremented by ... one. + +(Side remark: you'll find that recent grub versions don't choke on this. +See <http://git.savannah.gnu.org/cgit/grub.git/commit/?id=2e62352b>, +from January 2015.) + +I applied the following extremely sophisticated patch (with the motto +"it cannot get more wronger"): + +> diff --git a/include/qemu/timer.h b/include/qemu/timer.h +> index 9939246..def22de 100644 +> --- a/include/qemu/timer.h +> +++ b/include/qemu/timer.h +> @@ -1003,8 +1003,7 @@ static inline int64_t cpu_get_real_ticks(void) +> totally wrong, but hopefully better than nothing. */ +> static inline int64_t cpu_get_real_ticks (void) +> { +> - static int64_t ticks = 0; +> - return ticks++; +> + return get_clock(); +> } +> #endif +> + +get_clock() is CLOCK_MONOTONIC based, has (theoretical) nanosecond +resolution, and a nice flat int64_t encoding that should suffice for +approx. 329 years. This should provide grub with a larger denominator. + +This "fix" allowed me to boot the i386 Debian image on the AARCH64 host. + +For a real fix... I think on AARCH64 hosts at least, a "real" cycle +counter should be available, and someone who knows AARCH64 could write a +function that fetches it. + +For 32-bit ARM, I presume the Raspberry Pi 2 and the Odroid C1 are +advanced enough for a similar cycle counter reading function. + +I wonder though if ARM platforms remain in existence for which the 2006 +patch captures the right hardware capability. For those (and perhaps as +a general fallback) I think my "patch" above would be an improvement. + +Peter? + +Thanks +Laszlo + + +On 21 September 2015 at 08:12, Laszlo Ersek <email address hidden> wrote: +> Where does the division by zero come from then? Well grub fetches and +> stashes the TSC, then programs the PIT to sleep for some time, then +> re-fetches the TSC, and uses the TSC difference as denominator when +> calculating the "TSC rate". (It has a solid idea of the real time +> passed, due to the PIT frequency being a given.) + +I was wondering rereading the bug report whether this was down +to our lousy RDTSC implementation...thanks for digging in and +confirming what's going on. + +> Now, the cpu_get_real_ticks() implementation is *host* specific. You can +> find it implemented for a bunch of host architectures in +> "include/qemu/timer.h". + +> I applied the following extremely sophisticated patch (with the motto +> "it cannot get more wronger"): +> +>> diff --git a/include/qemu/timer.h b/include/qemu/timer.h +>> index 9939246..def22de 100644 +>> --- a/include/qemu/timer.h +>> +++ b/include/qemu/timer.h +>> @@ -1003,8 +1003,7 @@ static inline int64_t cpu_get_real_ticks(void) +>> totally wrong, but hopefully better than nothing. */ +>> static inline int64_t cpu_get_real_ticks (void) +>> { +>> - static int64_t ticks = 0; +>> - return ticks++; +>> + return get_clock(); +>> } +>> #endif +>> +> +> get_clock() is CLOCK_MONOTONIC based, has (theoretical) nanosecond +> resolution, and a nice flat int64_t encoding that should suffice for +> approx. 329 years. This should provide grub with a larger denominator. +> +> This "fix" allowed me to boot the i386 Debian image on the AARCH64 host. +> +> For a real fix... I think on AARCH64 hosts at least, a "real" cycle +> counter should be available, and someone who knows AARCH64 could write a +> function that fetches it. +> +> For 32-bit ARM, I presume the Raspberry Pi 2 and the Odroid C1 are +> advanced enough for a similar cycle counter reading function. + +There isn't a user-space readable cycle counter on ARM. +(There is a counter which might be accessible to userspace +depending on kernel config, but the kernel doesn't guarantee +its availability as an ABI thing.) + +Probably we should figure out a sane way to emulate guest +cycle counters that isn't dependent on the host CPU architecture. +I think having QEMU's behaviour as seen by the guest vary like +this is a recipe for confusion. + +thanks +-- PMM + + +* Peter Maydell (<email address hidden>) wrote: +> On 21 September 2015 at 08:12, Laszlo Ersek <email address hidden> wrote: +> > Where does the division by zero come from then? Well grub fetches and +> > stashes the TSC, then programs the PIT to sleep for some time, then +> > re-fetches the TSC, and uses the TSC difference as denominator when +> > calculating the "TSC rate". (It has a solid idea of the real time +> > passed, due to the PIT frequency being a given.) +> +> I was wondering rereading the bug report whether this was down +> to our lousy RDTSC implementation...thanks for digging in and +> confirming what's going on. +> +> > Now, the cpu_get_real_ticks() implementation is *host* specific. You can +> > find it implemented for a bunch of host architectures in +> > "include/qemu/timer.h". +> +> > I applied the following extremely sophisticated patch (with the motto +> > "it cannot get more wronger"): +> > +> >> diff --git a/include/qemu/timer.h b/include/qemu/timer.h +> >> index 9939246..def22de 100644 +> >> --- a/include/qemu/timer.h +> >> +++ b/include/qemu/timer.h +> >> @@ -1003,8 +1003,7 @@ static inline int64_t cpu_get_real_ticks(void) +> >> totally wrong, but hopefully better than nothing. */ +> >> static inline int64_t cpu_get_real_ticks (void) +> >> { +> >> - static int64_t ticks = 0; +> >> - return ticks++; +> >> + return get_clock(); +> >> } +> >> #endif +> >> +> > +> > get_clock() is CLOCK_MONOTONIC based, has (theoretical) nanosecond +> > resolution, and a nice flat int64_t encoding that should suffice for +> > approx. 329 years. This should provide grub with a larger denominator. +> > +> > This "fix" allowed me to boot the i386 Debian image on the AARCH64 host. +> > +> > For a real fix... I think on AARCH64 hosts at least, a "real" cycle +> > counter should be available, and someone who knows AARCH64 could write a +> > function that fetches it. +> > +> > For 32-bit ARM, I presume the Raspberry Pi 2 and the Odroid C1 are +> > advanced enough for a similar cycle counter reading function. +> +> There isn't a user-space readable cycle counter on ARM. +> (There is a counter which might be accessible to userspace +> depending on kernel config, but the kernel doesn't guarantee +> its availability as an ABI thing.) +> +> Probably we should figure out a sane way to emulate guest +> cycle counters that isn't dependent on the host CPU architecture. +> I think having QEMU's behaviour as seen by the guest vary like +> this is a recipe for confusion. + +Time is always hard though; what are the requirements for that +particular view of time: + + 1) It must be monotonic - which get_clock() is iff the host + supports it (which I guess most do?) + 2) It's got to be within a few orders of magnitude of sane + with respect to wall clock, so that if someone measures + it over a second or a 1/100th of a second or whatever then + it's still seen to go up. + +get_clock() isn't that bad if it's monotonic; if not I'd suggest +for TCG a multiple of the number of TBs executed (if that's +already stored somewhere), or something similar. + +Dave + +> thanks +> -- PMM +-- +Dr. David Alan Gilbert / <email address hidden> / Manchester, UK + + +On 09/21/15 17:50, Dr. David Alan Gilbert wrote: +> * Peter Maydell (<email address hidden>) wrote: +>> On 21 September 2015 at 08:12, Laszlo Ersek <email address hidden> wrote: +>>> Where does the division by zero come from then? Well grub fetches and +>>> stashes the TSC, then programs the PIT to sleep for some time, then +>>> re-fetches the TSC, and uses the TSC difference as denominator when +>>> calculating the "TSC rate". (It has a solid idea of the real time +>>> passed, due to the PIT frequency being a given.) +>> +>> I was wondering rereading the bug report whether this was down +>> to our lousy RDTSC implementation...thanks for digging in and +>> confirming what's going on. +>> +>>> Now, the cpu_get_real_ticks() implementation is *host* specific. You can +>>> find it implemented for a bunch of host architectures in +>>> "include/qemu/timer.h". +>> +>>> I applied the following extremely sophisticated patch (with the motto +>>> "it cannot get more wronger"): +>>> +>>>> diff --git a/include/qemu/timer.h b/include/qemu/timer.h +>>>> index 9939246..def22de 100644 +>>>> --- a/include/qemu/timer.h +>>>> +++ b/include/qemu/timer.h +>>>> @@ -1003,8 +1003,7 @@ static inline int64_t cpu_get_real_ticks(void) +>>>> totally wrong, but hopefully better than nothing. */ +>>>> static inline int64_t cpu_get_real_ticks (void) +>>>> { +>>>> - static int64_t ticks = 0; +>>>> - return ticks++; +>>>> + return get_clock(); +>>>> } +>>>> #endif +>>>> +>>> +>>> get_clock() is CLOCK_MONOTONIC based, has (theoretical) nanosecond +>>> resolution, and a nice flat int64_t encoding that should suffice for +>>> approx. 329 years. This should provide grub with a larger denominator. +>>> +>>> This "fix" allowed me to boot the i386 Debian image on the AARCH64 host. +>>> +>>> For a real fix... I think on AARCH64 hosts at least, a "real" cycle +>>> counter should be available, and someone who knows AARCH64 could write a +>>> function that fetches it. +>>> +>>> For 32-bit ARM, I presume the Raspberry Pi 2 and the Odroid C1 are +>>> advanced enough for a similar cycle counter reading function. +>> +>> There isn't a user-space readable cycle counter on ARM. +>> (There is a counter which might be accessible to userspace +>> depending on kernel config, but the kernel doesn't guarantee +>> its availability as an ABI thing.) +>> +>> Probably we should figure out a sane way to emulate guest +>> cycle counters that isn't dependent on the host CPU architecture. +>> I think having QEMU's behaviour as seen by the guest vary like +>> this is a recipe for confusion. +> +> Time is always hard though; what are the requirements for that +> particular view of time: +> +> 1) It must be monotonic - which get_clock() is iff the host +> supports it (which I guess most do?) +> 2) It's got to be within a few orders of magnitude of sane +> with respect to wall clock, so that if someone measures +> it over a second or a 1/100th of a second or whatever then +> it's still seen to go up. +> +> get_clock() isn't that bad if it's monotonic; if not I'd suggest +> for TCG a multiple of the number of TBs executed (if that's +> already stored somewhere), or something similar. + +I think that's quite what -icount does; I had even tested -icount before +posting my email, and it works too. (See -icount in qemu-options.hx.) I +hadn't known about -icount, but I saw the connection in the +cpu_get_ticks() function (mentioned earlier in the call tree): + +/* return the host CPU cycle counter and handle stop/restart */ +/* Caller must hold the BQL */ +int64_t cpu_get_ticks(void) +{ + int64_t ticks; + + if (use_icount) { + return cpu_get_icount(); + } + +... + +I didn't recommend it because the documentation in "qemu-options.hx" +confused me, and I thought the emulation should work without obscure +switches. + +Thanks +Laszlo + + +> +> Dave +> +>> thanks +>> -- PMM +> -- +> Dr. David Alan Gilbert / <email address hidden> / Manchester, UK +> + + + +What a funny coincidence, just before getting all of that bug email (telepathy?), I decided to also try a debian hurd image, but it immediately aborts: + + +qemu-system-i386: qemu-coroutine-lock.c:91: qemu_co_queue_restart_all: Assertion `qemu_in_coroutine()' failed. +Aborted + +Is this known and/or deserving a separate issue? + +PeteVine: That sounds like a separate bug ; probably best to get a separate report for it with a backtrace. + +Thanks for looking into it, Laszlo. I've already tried dosbox and had +no idea qemu was impractical. + + +get_clock() sounds like a good idea. Anybody post the patch? :) + +BTW, it seems the more expensive (but vastly less popular) odroids like the xu4 are built around kvm enabled processors which is why this bug doesn't affect them. + +The most popular C1/C1+'s processor doesn't support kvm though so any update would be appreciated. + +I tried installing openbsd yesterday from an official image to another raw image disk - no problem and the installed system works flawlessly. Hurd also boots fine (via grub) along with a few toy x86 kernels. + +It almost begins to look as if the raw images are ok whereas the qcow2 format is the problem somehow. Had I tried those other images first I'd be convinced running x86 on arm hosts poses no problem at all - how is it even possible? + + +Thanks for all the tips guys, I finally got it to work on my Rpi2. + +Still present in 2.5. + +It doesn't work on my XU4 either. The supported virtualization would probably work for ARM images but it's not something many people need. + +What's the holdup, dear devs? + +The "holdup" is simply that nobody who is interested in this issue has written a patch like that Paolo proposed in comment #13. (Mostly people either want to run ARM or other guest images in emulation on x86, or they're running ARM images with hardware virtualization on ARM hardware. Trying to run x86 images in emulation on ARM hosts is much less common.) + +Would the presence of RTC make any difference? + +No, this doesn't have anything to do with the RTC. It's just about our fallback implementation of cpu_get_host_ticks() being very poor. + + +Another OS that works: + +https://static.redox-os.org/redox-installer.iso + +The previous increment-on-read fallback didn't increment fast +enough for some versions of grub. + +https://bugs.launchpad.net/qemu-linaro/+bug/893208 + +Signed-off-by: Christopher Covington <email address hidden> +--- +I unfortunately don't have the opportunity to fully test this right +now, but I'm sending it out nevertheless on the off chance that +someone else might. +--- + include/qemu/timer.h | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +diff --git a/include/qemu/timer.h b/include/qemu/timer.h +index d0946cb..60c6dd6 100644 +--- a/include/qemu/timer.h ++++ b/include/qemu/timer.h +@@ -998,13 +998,12 @@ static inline int64_t cpu_get_host_ticks(void) + } + + #else +-/* The host CPU doesn't have an easily accessible cycle counter. +- Just return a monotonically increasing value. This will be +- totally wrong, but hopefully better than nothing. */ ++/* The host CPU doesn't have an easily accessible cycle counter, so just return ++ the instruction count. This may make the CPU look like it has an IPC of ++ exactly 1, but that shouldn't cause any functional problems. */ + static inline int64_t cpu_get_host_ticks (void) + { +- static int64_t ticks = 0; +- return ticks++; ++ return cpu_get_icount(); + } + #endif + +-- +Qualcomm Innovation Center, Inc. +Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, +a Linux Foundation Collaborative Project + + + +Unfortunately that doesn't seem to work. Qemu immediately goes into infinite loop and has to be killed -9. + +Building anything besides qemu-system-i386 leads to link errors: + + LINK x86_64-linux-user/qemu-x86_64 +/usr/bin/ld.gold.real: error: ../libqemustub.a(cpu-get-icount.o): multiple definition of 'use_icount' +/usr/bin/ld.gold.real: exec.o: previous definition here + + +FWIW: + +Program received signal SIGINT, Interrupt. +0xb644f73c in seqlock_read_retry (sl=0xb6b2acc8 <timers_state+16>, start=0) + at /tmp/qemu/include/qemu/seqlock.h:69 +69 return unlikely(atomic_read(&sl->sequence) != start); +(gdb) bt +#0 0xb644f73c in seqlock_read_retry (sl=0xb6b2acc8 <timers_state+16>, start=0) + at /tmp/qemu/include/qemu/seqlock.h:69 +#1 0xb644fa3c in cpu_get_icount () at /tmp/qemu/cpus.c:182 +#2 0xb644f518 in cpu_get_host_ticks () at /tmp/qemu/include/qemu/timer.h:1006 +#3 0xb644fcc4 in cpu_enable_ticks () at /tmp/qemu/cpus.c:252 +#4 0xb658a9ec in vm_start () at vl.c:764 +#5 0xb6597200 in main (argc=5, argv=0xbecfa6b4, envp=0xbecfa6cc) at vl.c:4651 + +Looks like a patch for this issue has now been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=d1bb099f6308d594061 + +Indeed, I had no problem booting the images this time around: + +https://asciinema.org/a/d2m42g5c0n3z2pnbskhirdv5j + +The qemu-linaro project seems to have been discontinued; the wiki and git repo links at <https://launchpad.net/qemu-linaro> don't work, and the latest release seems to be "qemu-linaro-1.7.0-2014.01.tar.gz". Marking this ticket as "invalid" for the qemu-linaro project. + diff --git a/results/classifier/zero-shot/108/all/893956 b/results/classifier/zero-shot/108/all/893956 new file mode 100644 index 000000000..a92ac1c3e --- /dev/null +++ b/results/classifier/zero-shot/108/all/893956 @@ -0,0 +1,352 @@ +debug: 0.997 +semantic: 0.996 +graphic: 0.995 +device: 0.994 +PID: 0.994 +permissions: 0.991 +socket: 0.990 +boot: 0.988 +other: 0.987 +performance: 0.987 +files: 0.986 +network: 0.976 +vnc: 0.976 +KVM: 0.952 + +qemu-img bug with dynamic vhd + +Hye, i found a problem with qemu-img when trying to get info of a dynamic vhd. I made imgae of my 60GB computer hard drive with disk2vhd. The dynamic vhd is 21gb size. + +With 1.0-rc3 version : +running command: qemu-img info 60_GB.VHD +qemu-img: Could not open '60_GB.VHD' : File too large + +0.14.1 version give me wrong information : +image: 60_GB.VHD +file format: vpc +virtual size: 127G (136899993600 bytes) +disk size: 21G + +Thanks for reply. + +On Wed, Nov 23, 2011 at 11:33 AM, z22lad <email address hidden> wrote: +> Hye, i found a problem with qemu-img when trying to get info of a +> dynamic vhd. I made imgae of my 60GB computer hard drive with disk2vhd. +> The dynamic vhd is 21gb size. +> +> With 1.0-rc3 version : +> running command: qemu-img info 60_GB.VHD +> qemu-img: Could not open '60_GB.VHD' : File too large +> +> 0.14.1 version give me wrong information : +> image: 60_GB.VHD +> file format: vpc +> virtual size: 127G (136899993600 bytes) +> disk size: 21G + +Which host OS are you running qemu-img on? Is it 32- or 64-bit? + +I wonder if you get the same behavior when using qemu-img convert +instead of "disk2vhd" to create a vhd file. + +Stefan + + +Hi, + +I'm having the same problem. I'm using qemu-img 1.0, running from a Ubuntu Server 12.04 x64 on a SW RAID, ext4. + +The .VHD has 29GB and was made using disk2vhd. + +Here is the command and the results: +sudo kvm-img convert -f vpc -O raw image.VHD image.img +[sudo] password for sysop: +kvm-img: Could not open 'image.VHD': File too large +kvm-img: Could not open 'image.VHD' + +Same error doing a simple qemu-img info image.vhd + +Thanks for your help + +On Mon, Sep 3, 2012 at 10:41 AM, franxico <email address hidden> wrote: +> Hi, +> +> I'm having the same problem. I'm using qemu-img 1.0, running from a +> Ubuntu Server 12.04 x64 on a SW RAID, ext4. +> +> The .VHD has 29GB and was made using disk2vhd. +> +> Here is the command and the results: +> sudo kvm-img convert -f vpc -O raw image.VHD image.img +> [sudo] password for sysop: +> kvm-img: Could not open 'image.VHD': File too large +> kvm-img: Could not open 'image.VHD' +> +> Same error doing a simple qemu-img info image.vhd + +Serge Hallyn introduced the size check when VHD files are opened, you +can read about the background here: +http://patchwork.ozlabs.org/patch/106736/ + +I'm not sure if QEMU has a bug or lacks support for the file format +version used by disk2vhd. + +> +> Thanks for your help +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/893956 +> +> Title: +> qemu-img bug with dynamic vhd +> +> Status in QEMU: +> New +> +> Bug description: +> Hye, i found a problem with qemu-img when trying to get info of a +> dynamic vhd. I made imgae of my 60GB computer hard drive with +> disk2vhd. The dynamic vhd is 21gb size. +> +> With 1.0-rc3 version : +> running command: qemu-img info 60_GB.VHD +> qemu-img: Could not open '60_GB.VHD' : File too large +> +> 0.14.1 version give me wrong information : +> image: 60_GB.VHD +> file format: vpc +> virtual size: 127G (136899993600 bytes) +> disk size: 21G +> +> Thanks for reply. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/893956/+subscriptions +> + + +Though that commit and the comments were about 127G images. HIs is only 27G. + +Also, 'qemu-img info' is also showing the error, which shows that this is not being done on vpc_create(). + +So I think this is a case of qemu-img actually failing to properly parse the FHD file. + +On Tue, Sep 4, 2012 at 4:00 PM, Serge Hallyn <email address hidden> wrote: +> Though that commit and the comments were about 127G images. HIs is only +> 27G. + +The 127 GB limit applies to the virtual disk size, not to the size of +the image file itself. + +> Also, 'qemu-img info' is also showing the error, which shows that this +> is not being done on vpc_create(). + +I'm not sure what you mean. Your commit (efc8243d00) added an -EFBIG +return to vcp_open(), not vpc_create(). This will affect qemu-img +info. + +We need the header/footer contents to be sure what's going on here. + +Stefan + + +On Mon, Sep 3, 2012 at 10:41 AM, franxico <email address hidden> wrote: +> Hi, +> +> I'm having the same problem. I'm using qemu-img 1.0, running from a +> Ubuntu Server 12.04 x64 on a SW RAID, ext4. +> +> The .VHD has 29GB and was made using disk2vhd. +> +> Here is the command and the results: +> sudo kvm-img convert -f vpc -O raw image.VHD image.img +> [sudo] password for sysop: +> kvm-img: Could not open 'image.VHD': File too large +> kvm-img: Could not open 'image.VHD' +> +> Same error doing a simple qemu-img info image.vhd + +Please post the output of the following commands: + +$ hexdump -C -n 512 image.VHD +$ hexdump -C -n 512 -s $(($(ls -l image.VHD | awk '{ print $5 }') - +512)) image.VHD + +This will show the file header/footer, which contains fields that are +validated when opening the file. + +Thanks, +Stefan + + +Quoting Stefan Hajnoczi (<email address hidden>): +> On Tue, Sep 4, 2012 at 4:00 PM, Serge Hallyn <email address hidden> wrote: +> > Though that commit and the comments were about 127G images. HIs is only +> > 27G. +> +> The 127 GB limit applies to the virtual disk size, not to the size of +> the image file itself. + +I thought he had converted a roughly 26GB physical disk, assumed (perhaps +wrongly) that was the virtual disk size. + +> > Also, 'qemu-img info' is also showing the error, which shows that this +> > is not being done on vpc_create(). +> +> I'm not sure what you mean. Your commit (efc8243d00) added an -EFBIG +> return to vcp_open(), not vpc_create(). This will affect qemu-img +> info. + +Oops, good point. Thanks. + +> We need the header/footer contents to be sure what's going on here. + + + + +qemu-img fails to read a disk2vhd (VHD) image created from a Windows Server 2003. +qemu-img will read and convert a VDI image created from that VHD + +VHD header/footer details: + + +[root@T3400 ]# qemu-img info vhd/p.vhd +qemu-img: Could not open 'vhd/p.vhd': File too large + +[root@T3400 ]# ./vhddump -vv -s vhd/p.vhd +Positioning descriptor to VHD footer... +Reading VHD footer... +------------------------ + VHD Footer (512 bytes) +------------------------ + Cookie = conectix + Features = 0x00000002 + File Format Version = 0x00010000 + Data Offset = 0x0000000000000200 + Time Stamp = 0x1893342A + Creator Application = 0x64327600 + Creator Version = 0x00010000 + Creator Host OS = 0x5769326B + Original Size = 0x000000222E6F4000 + = 140006 MB + 976 KiB + Current Size = 0x000000222E6F4000 + = 140006 MB + 976 KiB + Disk Geometry = 0xFFFF10FF + Cylinders = 65535 + Heads = 16 + Sectors/Track = 255 + Disk Type = 0x00000003 + = Dynamic hard disk + Checksum = 0xFFFFEDD8 + Unique ID = 765e24b9-1e33-594a-864e-f39aea210f24 + Saved State = 0x00 + Reserved = <...427 bytes...> +=============================================== +Detecting disk type... +Dynamic hard disk detected. +Positioning descriptor to read VHD footer copy... +Reading VHD footer copy... +------------------------ + VHD Footer (512 bytes) +------------------------ + Cookie = conectix + Features = 0x00000002 + File Format Version = 0x00010000 + Data Offset = 0x0000000000000200 + Time Stamp = 0x1893342A + Creator Application = 0x64327600 + Creator Version = 0x00010000 + Creator Host OS = 0x5769326B + Original Size = 0x000000222E6F4000 + = 140006 MB + 976 KiB + Current Size = 0x000000222E6F4000 + = 140006 MB + 976 KiB + Disk Geometry = 0xFFFF10FF + Cylinders = 65535 + Heads = 16 + Sectors/Track = 255 + Disk Type = 0x00000003 + = Dynamic hard disk + Checksum = 0xFFFFEDD8 + Unique ID = 765e24b9-1e33-594a-864e-f39aea210f24 + Saved State = 0x00 + Reserved = <...427 bytes...> +=============================================== +Reading VHD dynamic disk header... +-------------------------------------- + VHD Dynamic Disk Header (1024 bytes) +-------------------------------------- + Cookie = cxsparse + Data Offset = 0xFFFFFFFFFFFFFFFF + Table Offset = 0x0000000000000600 + Header Version = 0x00010000 + Max Table Entries = 0x00011174 + Block Size = 0x00200000 + Checksum = 0xFFFFF3F1 + Parent UUID = 00000000-0000-0000-0000-000000000000 + Parent TS = 0x00000000 + 0 (10) + Reserved = <...4 bytes...> + Parent Unicode Name = <...512 bytes...> + Parent Loc Entry 1 = <...24 bytes...> + Parent Loc Entry 2 = <...24 bytes...> + Parent Loc Entry 3 = <...24 bytes...> + Parent Loc Entry 4 = <...24 bytes...> + Parent Loc Entry 5 = <...24 bytes...> + Parent Loc Entry 6 = <...24 bytes...> + Parent Loc Entry 7 = <...24 bytes...> + Parent Loc Entry 8 = <...24 bytes...> + + +Can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)? + +No, sorry. The environment was retired in 2014 and we took a different direction. + + +-Bobby + +-----Original Message----- +From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Thomas Huth +Sent: Wednesday, June 07, 2017 4:44 AM +To: <email address hidden> +Subject: [Bug 893956] Re: qemu-img bug with dynamic vhd + +Can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)? + +** Changed in: qemu + Status: New => Incomplete + +-- +You received this bug notification because you are subscribed to the bug report. +https://bugs.launchpad.net/bugs/893956 + +Title: + qemu-img bug with dynamic vhd + +Status in QEMU: + Incomplete + +Bug description: + Hye, i found a problem with qemu-img when trying to get info of a + dynamic vhd. I made imgae of my 60GB computer hard drive with + disk2vhd. The dynamic vhd is 21gb size. + + With 1.0-rc3 version : + running command: qemu-img info 60_GB.VHD + qemu-img: Could not open '60_GB.VHD' : File too large + + 0.14.1 version give me wrong information : + image: 60_GB.VHD + file format: vpc + virtual size: 127G (136899993600 bytes) + disk size: 21G + + Thanks for reply. + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/893956/+subscriptions + + + diff --git a/results/classifier/zero-shot/108/all/904617 b/results/classifier/zero-shot/108/all/904617 new file mode 100644 index 000000000..174bf0bf7 --- /dev/null +++ b/results/classifier/zero-shot/108/all/904617 @@ -0,0 +1,181 @@ +permissions: 0.981 +debug: 0.979 +semantic: 0.978 +performance: 0.977 +device: 0.976 +socket: 0.975 +other: 0.974 +graphic: 0.973 +files: 0.966 +PID: 0.964 +KVM: 0.964 +network: 0.960 +vnc: 0.947 +boot: 0.931 + +device_add usb-hub causes segfault in qemu-1.0 + +When calling the command + +(qemu) device_add usb-hub,bus=usb.0,port=4 + +qemu replies + +Error: usb port 4 (bus usb.0) not found (in use?) + +Then qemu crashes with a segfault: + +[ 1546.177627] qemu-system-x86[1710]: segfault at 0 ip b75d3f8b sp bfddb0b0 error 6 in qemu-system-x86_64[b7488000+2e2000] + +Maybe it might be related to the docs/usb2.txt where UHCI has only 2 ports. But a mistake in the port number should not cause qemu to crash + +Commit f462141f18ffdd75847f6459ef83d90b831d12c0 introduced clean up code +when usb_qdev_init() fails. Unfortunately it calls .handle_destroy() +when .init() was never invoked or failed. This can lead to crashes when +.handle_destroy() tries to clean up things that were never initialized. + +This patch is careful to undo only those steps that completed along the +usb_qdev_init() code path. It's not as pretty as the unified error +handling in f462141f18ffdd75847f6459ef83d90b831d12c0 but it's necessary. + +Signed-off-by: Stefan Hajnoczi <email address hidden> +--- + hw/usb-bus.c | 12 +++++------- + 1 files changed, 5 insertions(+), 7 deletions(-) + +diff --git a/hw/usb-bus.c b/hw/usb-bus.c +index 8cafb76..8203390 100644 +--- a/hw/usb-bus.c ++++ b/hw/usb-bus.c +@@ -77,23 +77,21 @@ static int usb_qdev_init(DeviceState *qdev, DeviceInfo *base) + QLIST_INIT(&dev->strings); + rc = usb_claim_port(dev); + if (rc != 0) { +- goto err; ++ return rc; + } + rc = dev->info->init(dev); + if (rc != 0) { +- goto err; ++ usb_release_port(dev); ++ return rc; + } + if (dev->auto_attach) { + rc = usb_device_attach(dev); + if (rc != 0) { +- goto err; ++ usb_qdev_exit(qdev); ++ return rc; + } + } + return 0; +- +-err: +- usb_qdev_exit(qdev); +- return rc; + } + + static int usb_qdev_exit(DeviceState *qdev) +-- +1.7.7.3 + + + +On Thu, Dec 15, 2011 at 08:18:31AM -0000, Erik Rull wrote: +> Public bug reported: +> +> When calling the command +> +> (qemu) device_add usb-hub,bus=usb.0,port=4 +> +> qemu replies +> +> Error: usb port 4 (bus usb.0) not found (in use?) +> +> Then qemu crashes with a segfault: +> +> [ 1546.177627] qemu-system-x86[1710]: segfault at 0 ip b75d3f8b sp +> bfddb0b0 error 6 in qemu-system-x86_64[b7488000+2e2000] +> +> Maybe it might be related to the docs/usb2.txt where UHCI has only 2 +> ports. But a mistake in the port number should not cause qemu to crash + +Thanks for the bug report. I confirmed this bug is present in +qemu.git/master and have submitted a patch to fix it. + +Please consider sending backtraces when you encounter segfaults in the +future, they make it possible to identify the bug immediately in many +cases. Here's how I reproduced this and got the backtrace: + +$ gdb --args x86_64-softmmu/qemu-system-x86_64 -usb +(gdb) r +(qemu) device_add usb-hub,bus=usb.0,port=4 +Program received signal SIGSEGV, Segmentation fault. +0x00005555556d786a in usb_unregister_port (bus=0x5555567f2ac0, port=0x555556956b40) + at /home/stefanha/qemu/hw/usb-bus.c:231 +231 QTAILQ_REMOVE(&bus->free, port, next); +(gdb) bt + + +On 12/15/2011 04:05 AM, Stefan Hajnoczi wrote: +> Commit f462141f18ffdd75847f6459ef83d90b831d12c0 introduced clean up code +> when usb_qdev_init() fails. Unfortunately it calls .handle_destroy() +> when .init() was never invoked or failed. This can lead to crashes when +> .handle_destroy() tries to clean up things that were never initialized. +> +> This patch is careful to undo only those steps that completed along the +> usb_qdev_init() code path. It's not as pretty as the unified error +> handling in f462141f18ffdd75847f6459ef83d90b831d12c0 but it's necessary. +> +> Signed-off-by: Stefan Hajnoczi<email address hidden> + +Applied. Thanks. + +Regards, + +Anthony Liguori + +> --- +> hw/usb-bus.c | 12 +++++------- +> 1 files changed, 5 insertions(+), 7 deletions(-) +> +> diff --git a/hw/usb-bus.c b/hw/usb-bus.c +> index 8cafb76..8203390 100644 +> --- a/hw/usb-bus.c +> +++ b/hw/usb-bus.c +> @@ -77,23 +77,21 @@ static int usb_qdev_init(DeviceState *qdev, DeviceInfo *base) +> QLIST_INIT(&dev->strings); +> rc = usb_claim_port(dev); +> if (rc != 0) { +> - goto err; +> + return rc; +> } +> rc = dev->info->init(dev); +> if (rc != 0) { +> - goto err; +> + usb_release_port(dev); +> + return rc; +> } +> if (dev->auto_attach) { +> rc = usb_device_attach(dev); +> if (rc != 0) { +> - goto err; +> + usb_qdev_exit(qdev); +> + return rc; +> } +> } +> return 0; +> - +> -err: +> - usb_qdev_exit(qdev); +> - return rc; +> } +> +> static int usb_qdev_exit(DeviceState *qdev) + + + +Stefan's patch had been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=db3a5ed7e4422491dac +==> Fix released + diff --git a/results/classifier/zero-shot/108/all/925405 b/results/classifier/zero-shot/108/all/925405 new file mode 100644 index 000000000..8bc4df373 --- /dev/null +++ b/results/classifier/zero-shot/108/all/925405 @@ -0,0 +1,111 @@ +permissions: 0.990 +other: 0.984 +performance: 0.981 +graphic: 0.978 +semantic: 0.976 +PID: 0.974 +socket: 0.973 +vnc: 0.973 +debug: 0.969 +boot: 0.966 +device: 0.966 +files: 0.961 +KVM: 0.938 +network: 0.937 + +VNC server does not work with Mac Screen Sharing + +When connecting to a QEMU instance from a Mac using any VNC settings on the QEMU CLI and any target arch (ARM, Intel, etc.), the connection is attempted but the negotiation never finishes. + +I've verified this when building QEMU from source (1.0 and HEAD) on Ubuntu, Fedora and Debian or when using Ubuntu (Oneiric) and Debian (Lenny) packages. + +It does not matter whether I specify authentication (or anything else) on QEMU's side, the behavior is always the same - I see the connection being established using netstat and tcpdump, but QEMU does not seem to send back any pixmap data after the connection setup. + +Best guess as to why this happens is that the VNC negotiation on QEMU does not like the protocol version and VNC encoding sent by the Mac's built-in VNC client, or that its negotiation logic is subtly broken. I appreciate that it's not meant to be a full VNC server, but it prevents me from using it remotely until a stable Mac build is feasible. + +Background info: + +Mac OS X includes a VNC client called Screen Sharing that you can invoke in two different ways: + +* At a terminal, by typing "open vnc://hostname:tcp_port" +* From any URI-enabled field (such as the Safari URI field), where you can just type the URI as vnc://hostname:tcp_port + +Please do not confuse the enhanced VNC protocol Apple Remote Desktop uses with Screen Sharing - they are not mutually exclusive, but they are not incompatible either, since what Apple does is to negotiate extra pixmap encoding and authentication options - I use Screen Sharing to access many VNC servers such as vnc4server, tightvncserver, vino, etc. without any issues whatsoever, so the issue I'm reporting is not an issue with Apple's implementation. + +affects me as well. +versions: +qemu-system-common 2.0.0+dfsg-2ubuntu1.2 (current as of 14.04) +Mac OS X: 10.9.4, xnu-2422.110.17, Screen Sharing 1.4 (481.1) + + + +FWIW, this affects me too. + +Ubuntu 14.04 +QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.30), Copyright (c) 2003-2008 Fabrice Bellard +OS X 10.9.5. + +The observed behavior is that when I hit "Connect" a spinning circle appears nearby but nothing else ever happens. + +There are reports online: https://www.reddit.com/r/homelab/comments/4jr893/qemu_with_vnc_to_osx_screen_sharing/ + +QEMU 2.0 is not maintained by the QEMU project anymore. Can you please try again with the latest release of QEMU (v2.8)? ... otherwise you should report this to the bug tracker of your distro instead. + +Hey there. Will git tip from September do? At that time I built QEMU on Ubuntu 16.04.1, pointed my Mac (10.10) at it again and had the same experience (had to use a third-party client) + +Considering I opened this four years ago, I'm kind of surprised it's still a talking topic. Was kind of expecting more people to report it, but then again Launchpad is a bit off the beaten path these days and most people just sigh and fetch a third party client. + +It's just that it seems like a trivial thing to fix overall, so I thought it worthwhile to chime in - Happy New Year! + +On 01/01/2017 17:55, Rui Carmo wrote: +> Hey there. Will git tip from September do? At that time I built QEMU on +> Ubuntu 16.04.1, pointed my Mac (10.10) at it again and had the same +> experience (had to use a third-party client) +> +> Considering I opened this four years ago, I'm kind of surprised it's +> still a talking topic. Was kind of expecting more people to report it, +> but then again Launchpad is a bit off the beaten path these days and +> most people just sigh and fetch a third party client. +> +> It's just that it seems like a trivial thing to fix overall, so I +> thought it worthwhile to chime in - Happy New Year! +> + + +For what it's worth, it's a bug in Apple's client which despite them +claiming to "use the industry standard VNC" (whatever that means) +clearly violates the VNC specs by replying with a boggus protocol +version number. + +I told them 5 years ago but it's not like they care about respecting +standards... + +François. + + +Well, I understand that since they do their own encoding (hence the need for a different protocol number for their stuff to talk to each other), but I don't think that's the whole thing, since I don't get any updates from the server, and the VNC spec (IIRC) allowed for negotiating a common version and encodings. + +Regardless, would it be feasible to fix this from a user perspective? + +(and Happy New Year!) + + +There is no need to change the protocol version itself to use new +encoding, there are provisions for that in the existing one. + +IIRC the problem was also that each party was waiting for the other one +to send data after the protocol version exchange, but that was 5y ago. + +Yes it should be possible to work around this, but I don't have a Mac now. + +François. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/88 + + diff --git a/results/classifier/zero-shot/108/all/928 b/results/classifier/zero-shot/108/all/928 new file mode 100644 index 000000000..9e5d755b0 --- /dev/null +++ b/results/classifier/zero-shot/108/all/928 @@ -0,0 +1,99 @@ +other: 0.980 +graphic: 0.977 +debug: 0.973 +semantic: 0.973 +performance: 0.970 +permissions: 0.968 +PID: 0.965 +boot: 0.962 +device: 0.959 +vnc: 0.958 +socket: 0.955 +files: 0.949 +KVM: 0.934 +network: 0.929 + +QEMU/TCG generates #GP instead #SS for RBP/RSP based faults +Description of problem: +Setting RSP/RBP to a non-canonical address and trying to access a memory location based on RSP/RBP generates a #GP under QEMU/TCG while it should generate an #SS exception instead. This difference in behavior triggers a [Xen selftest](https://github.com/xen-project/xen/blob/1145d94c738e/xen/arch/x86/extable.c#L142-L144) violation as can be seen below. + +- A successful run should look like this, e.g. when run under KVM: + +``` +(XEN) Running stub recovery selftests... +(XEN) Fixup #UD[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7 +(XEN) Fixup #GP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7 +(XEN) Fixup #SS[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7 +(XEN) Fixup #BP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7 +``` + +- Under QEMU/TCG it triggers this scary warning: + +``` +(XEN) Running stub recovery selftests... +(XEN) Fixup #UD[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7 +(XEN) Fixup #GP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7 +(XEN) Fixup #GP[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7 +(XEN) Selftest 2 failed: Opc 02 04 04 c3 expected 12[0000], got 13[0000] +(XEN) Fixup #BP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7 +[...] +(XEN) *************************************************** +(XEN) SELFTEST FAILURE: CORRECT BEHAVIOR CANNOT BE GUARANTEED +(XEN) *************************************************** +(XEN) 3... 2... 1... +``` +Steps to reproduce: +The attached program ([noncanon.c](/uploads/34599a2fe23c6bbf1e9efd8cb8704537/noncanon.c)) generates the following output when run on native hardware or under KVM: + +```shell-session +minipli@bell:~$ for i in "" -sp -bp; do ./noncanon $i; done +Non-canonical acces via RAX: SIGSEGV, signo 11, error 0, code 128, addr (nil) +Non-canonical acces via RSP: SIGBUS, signo 7, error 0, code 128, addr (nil) +Non-canonical acces via RBP: SIGBUS, signo 7, error 0, code 128, addr (nil) +``` + +However, when run under QEMU using TCG, I get the following output: + +```shell-session +root@box:~# for i in "" -sp -bp; do ./noncanon $i; done +Non-canonical acces via RAX: SIGSEGV, signo 11, error 0, code 128, addr (nil) +Non-canonical acces via RSP: SIGSEGV, signo 11, error 0, code 128, addr (nil) +Non-canonical acces via RBP: SIGSEGV, signo 11, error 0, code 128, addr (nil) +``` + +Please note how RSP/RBP based access generates SIGSEGV instead of the expected SIGBUS. +Additional information: +The problem seems to be that QEMU always generates a #GP for non-canonical addresses, while it should differentiate, based on the register that led to the non-canonical address: #SS if RSP/RBP is involved, #GP otherwise. However, short of an instruction decoder, I don't see how this can easily be told apart. + +```diff +diff --git a/target/i386/tcg/sysemu/excp_helper.c b/target/i386/tcg/sysemu/excp_helper.c +index e1b6d8868338..ac4a6351a49d 100644 +--- a/target/i386/tcg/sysemu/excp_helper.c ++++ b/target/i386/tcg/sysemu/excp_helper.c +@@ -386,6 +386,7 @@ static int handle_mmu_fault(CPUState *cs, vaddr addr, int size, + sext = (int64_t)addr >> (pg_mode & PG_MODE_LA57 ? 56 : 47); + if (sext != 0 && sext != -1) { + env->error_code = 0; ++ // XXX: or EXCP0C_STACK for SP/BP bassed error + cs->exception_index = EXCP0D_GPF; + return 1; + } +``` + +Relevant excerpt from the Intel SDM: + +> **6.15 EXCEPTION AND INTERRUPT REFERENCE** +> [...] +> **Interrupt 12—Stack Fault Exception (#SS)** +> [...] +> - A canonical violation is detected in 64-bit mode during an operation that reference memory using the stack pointer register containing a non-canonical memory address. + +Please note the lack of mentioning the base pointer register, but tests on real hardware show it's subject to this as well. + +The AMD manual is more precise about that: +> **8.2.13 #SS—Stack Exception (Vector 12)** +> An #SS exception can occur in the following situations: +> - Implied stack references in which the stack address is not in canonical form. Implied stack references include all push and pop instructions, and any instruction using RSP or RBP as a base register +> [...] + +It explicitly mentions "any instruction using RSP or RBP as a base register". diff --git a/results/classifier/zero-shot/108/all/92957605 b/results/classifier/zero-shot/108/all/92957605 new file mode 100644 index 000000000..4f840de67 --- /dev/null +++ b/results/classifier/zero-shot/108/all/92957605 @@ -0,0 +1,428 @@ +other: 0.997 +permissions: 0.996 +semantic: 0.995 +debug: 0.994 +performance: 0.994 +PID: 0.993 +device: 0.993 +socket: 0.993 +boot: 0.992 +network: 0.989 +graphic: 0.986 +files: 0.986 +KVM: 0.982 +vnc: 0.981 + +[Qemu-devel] Fwd: [BUG] Failed to compile using gcc7.1 + +Hi all, +I encountered the same problem on gcc 7.1.1 and found Qu's mail in +this list from google search. + +Temporarily fix it by specifying the string length in snprintf +directive. Hope this is helpful to other people encountered the same +problem. + +@@ -1,9 +1,7 @@ +--- +--- a/block/blkdebug.c +- "blkdebug:%s:%s", s->config_file ?: "", +--- a/block/blkverify.c +- "blkverify:%s:%s", +--- a/hw/usb/bus.c +- snprintf(downstream->path, sizeof(downstream->path), "%s.%d", +- snprintf(downstream->path, sizeof(downstream->path), "%d", portnr); +-- ++++ b/block/blkdebug.c ++ "blkdebug:%.2037s:%.2037s", s->config_file ?: "", ++++ b/block/blkverify.c ++ "blkverify:%.2038s:%.2038s", ++++ b/hw/usb/bus.c ++ snprintf(downstream->path, sizeof(downstream->path), "%.12s.%d", ++ snprintf(downstream->path, sizeof(downstream->path), "%.12d", portnr); + +Tsung-en Hsiao + +> +Qu Wenruo Wrote: +> +> +Hi all, +> +> +After upgrading gcc from 6.3.1 to 7.1.1, qemu can't be compiled with gcc. +> +> +The error is: +> +> +------ +> +CC block/blkdebug.o +> +block/blkdebug.c: In function 'blkdebug_refresh_filename': +> +> +block/blkdebug.c:693:31: error: '%s' directive output may be truncated +> +writing up to 4095 bytes into a region of size 4086 +> +[-Werror=format-truncation=] +> +> +"blkdebug:%s:%s", s->config_file ?: "", +> +^~ +> +In file included from /usr/include/stdio.h:939:0, +> +from /home/adam/qemu/include/qemu/osdep.h:68, +> +from block/blkdebug.c:25: +> +> +/usr/include/bits/stdio2.h:64:10: note: '__builtin___snprintf_chk' output 11 +> +or more bytes (assuming 4106) into a destination of size 4096 +> +> +return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, +> +^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> +__bos (__s), __fmt, __va_arg_pack ()); +> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> +cc1: all warnings being treated as errors +> +make: *** [/home/adam/qemu/rules.mak:69: block/blkdebug.o] Error 1 +> +------ +> +> +It seems that gcc 7 is introducing more restrict check for printf. +> +> +If using clang, although there are some extra warning, it can at least pass +> +the compile. +> +> +Thanks, +> +Qu + +Hi Tsung-en, + +On 06/11/2017 04:08 PM, Tsung-en Hsiao wrote: +Hi all, +I encountered the same problem on gcc 7.1.1 and found Qu's mail in +this list from google search. + +Temporarily fix it by specifying the string length in snprintf +directive. Hope this is helpful to other people encountered the same +problem. +Thank your for sharing this. +@@ -1,9 +1,7 @@ +--- +--- a/block/blkdebug.c +- "blkdebug:%s:%s", s->config_file ?: "", +--- a/block/blkverify.c +- "blkverify:%s:%s", +--- a/hw/usb/bus.c +- snprintf(downstream->path, sizeof(downstream->path), "%s.%d", +- snprintf(downstream->path, sizeof(downstream->path), "%d", portnr); +-- ++++ b/block/blkdebug.c ++ "blkdebug:%.2037s:%.2037s", s->config_file ?: "", +It is a rather funny way to silent this warning :) Truncating the +filename until it fits. +However I don't think it is the correct way since there is indeed an +overflow of bs->exact_filename. +Apparently exact_filename from "block/block_int.h" is defined to hold a +pathname: +char exact_filename[PATH_MAX]; +but is used for more than that (for example in blkdebug.c it might use +until 10+2*PATH_MAX chars). +I suppose it started as a buffer to hold a pathname then more block +drivers were added and this buffer ended used differently. +If it is a multi-purpose buffer one safer option might be to declare it +as a GString* and use g_string_printf(). +I CC'ed the block folks to have their feedback. + +Regards, + +Phil. ++++ b/block/blkverify.c ++ "blkverify:%.2038s:%.2038s", ++++ b/hw/usb/bus.c ++ snprintf(downstream->path, sizeof(downstream->path), "%.12s.%d", ++ snprintf(downstream->path, sizeof(downstream->path), "%.12d", portnr); + +Tsung-en Hsiao +Qu Wenruo Wrote: + +Hi all, + +After upgrading gcc from 6.3.1 to 7.1.1, qemu can't be compiled with gcc. + +The error is: + +------ + CC block/blkdebug.o +block/blkdebug.c: In function 'blkdebug_refresh_filename': + +block/blkdebug.c:693:31: error: '%s' directive output may be truncated writing +up to 4095 bytes into a region of size 4086 [-Werror=format-truncation=] + + "blkdebug:%s:%s", s->config_file ?: "", + ^~ +In file included from /usr/include/stdio.h:939:0, + from /home/adam/qemu/include/qemu/osdep.h:68, + from block/blkdebug.c:25: + +/usr/include/bits/stdio2.h:64:10: note: '__builtin___snprintf_chk' output 11 or +more bytes (assuming 4106) into a destination of size 4096 + + return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + __bos (__s), __fmt, __va_arg_pack ()); + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +cc1: all warnings being treated as errors +make: *** [/home/adam/qemu/rules.mak:69: block/blkdebug.o] Error 1 +------ + +It seems that gcc 7 is introducing more restrict check for printf. + +If using clang, although there are some extra warning, it can at least pass the +compile. + +Thanks, +Qu + +On 2017-06-12 05:19, Philippe Mathieu-Daudé wrote: +> +Hi Tsung-en, +> +> +On 06/11/2017 04:08 PM, Tsung-en Hsiao wrote: +> +> Hi all, +> +> I encountered the same problem on gcc 7.1.1 and found Qu's mail in +> +> this list from google search. +> +> +> +> Temporarily fix it by specifying the string length in snprintf +> +> directive. Hope this is helpful to other people encountered the same +> +> problem. +> +> +Thank your for sharing this. +> +> +> +> +> @@ -1,9 +1,7 @@ +> +> --- +> +> --- a/block/blkdebug.c +> +> - "blkdebug:%s:%s", s->config_file ?: "", +> +> --- a/block/blkverify.c +> +> - "blkverify:%s:%s", +> +> --- a/hw/usb/bus.c +> +> - snprintf(downstream->path, sizeof(downstream->path), "%s.%d", +> +> - snprintf(downstream->path, sizeof(downstream->path), "%d", +> +> portnr); +> +> -- +> +> +++ b/block/blkdebug.c +> +> + "blkdebug:%.2037s:%.2037s", s->config_file ?: "", +> +> +It is a rather funny way to silent this warning :) Truncating the +> +filename until it fits. +> +> +However I don't think it is the correct way since there is indeed an +> +overflow of bs->exact_filename. +> +> +Apparently exact_filename from "block/block_int.h" is defined to hold a +> +pathname: +> +char exact_filename[PATH_MAX]; +> +> +but is used for more than that (for example in blkdebug.c it might use +> +until 10+2*PATH_MAX chars). +In any case, truncating the filenames will do just as much as truncating +the result: You'll get an unusable filename. + +> +I suppose it started as a buffer to hold a pathname then more block +> +drivers were added and this buffer ended used differently. +> +> +If it is a multi-purpose buffer one safer option might be to declare it +> +as a GString* and use g_string_printf(). +What it is supposed to be now is just an information string we can print +to the user, because strings are nicer than JSON objects. There are some +commands that take a filename for identifying a block node, but I dream +we can get rid of them in 3.0... + +The right solution is to remove it altogether and have a +"char *bdrv_filename(BlockDriverState *bs)" function (which generates +the filename every time it's called). I've been working on this for some +years now, actually, but it was never pressing enough to get it finished +(so I never had enough time). + +What we can do in the meantime is to not generate a plain filename if it +won't fit into bs->exact_filename. + +(The easiest way to do this probably would be to truncate +bs->exact_filename back to an empty string if snprintf() returns a value +greater than or equal to the length of bs->exact_filename.) + +What to do about hw/usb/bus.c I don't know (I guess the best solution +would be to ignore the warning, but I don't suppose that is going to work). + +Max + +> +> +I CC'ed the block folks to have their feedback. +> +> +Regards, +> +> +Phil. +> +> +> +++ b/block/blkverify.c +> +> + "blkverify:%.2038s:%.2038s", +> +> +++ b/hw/usb/bus.c +> +> + snprintf(downstream->path, sizeof(downstream->path), "%.12s.%d", +> +> + snprintf(downstream->path, sizeof(downstream->path), "%.12d", +> +> portnr); +> +> +> +> Tsung-en Hsiao +> +> +> +>> Qu Wenruo Wrote: +> +>> +> +>> Hi all, +> +>> +> +>> After upgrading gcc from 6.3.1 to 7.1.1, qemu can't be compiled with +> +>> gcc. +> +>> +> +>> The error is: +> +>> +> +>> ------ +> +>> CC block/blkdebug.o +> +>> block/blkdebug.c: In function 'blkdebug_refresh_filename': +> +>> +> +>> block/blkdebug.c:693:31: error: '%s' directive output may be +> +>> truncated writing up to 4095 bytes into a region of size 4086 +> +>> [-Werror=format-truncation=] +> +>> +> +>> "blkdebug:%s:%s", s->config_file ?: "", +> +>> ^~ +> +>> In file included from /usr/include/stdio.h:939:0, +> +>> from /home/adam/qemu/include/qemu/osdep.h:68, +> +>> from block/blkdebug.c:25: +> +>> +> +>> /usr/include/bits/stdio2.h:64:10: note: '__builtin___snprintf_chk' +> +>> output 11 or more bytes (assuming 4106) into a destination of size 4096 +> +>> +> +>> return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, +> +>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> +>> __bos (__s), __fmt, __va_arg_pack ()); +> +>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> +>> cc1: all warnings being treated as errors +> +>> make: *** [/home/adam/qemu/rules.mak:69: block/blkdebug.o] Error 1 +> +>> ------ +> +>> +> +>> It seems that gcc 7 is introducing more restrict check for printf. +> +>> +> +>> If using clang, although there are some extra warning, it can at +> +>> least pass the compile. +> +>> +> +>> Thanks, +> +>> Qu +> +> +signature.asc +Description: +OpenPGP digital signature + diff --git a/results/classifier/zero-shot/108/all/939995 b/results/classifier/zero-shot/108/all/939995 new file mode 100644 index 000000000..38ffc1d2e --- /dev/null +++ b/results/classifier/zero-shot/108/all/939995 @@ -0,0 +1,116 @@ +permissions: 0.981 +socket: 0.977 +debug: 0.971 +semantic: 0.969 +other: 0.968 +vnc: 0.964 +PID: 0.962 +performance: 0.962 +graphic: 0.952 +boot: 0.952 +files: 0.942 +device: 0.935 +network: 0.933 +KVM: 0.932 + +v1.0-1172-g235fe3b crashes (opts=0x0) + +C:\msys\home\User\qemu\i386-softmmu>gdb --args qemu-system-i386.exe -L ..\pc-bios +GNU gdb (GDB) 7.3 +Copyright (C) 2011 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "mingw32". +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>... +Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe... +done. +(gdb) r +Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L ..\\pc-bios +[New Thread 4724.0x1224] + +Program received signal SIGSEGV, Segmentation fault. +0x004eeda6 in qemu_opt_get (opts=0x0, name=0x68a7c3 "kernel") + at qemu-option.c:545 +545 QemuOpt *opt = qemu_opt_find(opts, name); +(gdb) bt +#0 0x004eeda6 in qemu_opt_get (opts=0x0, name=0x68a7c3 "kernel") + at qemu-option.c:545 +#1 0x004c7166 in qemu_main (argc=3, argv=0x3e5200, envp=0x0) + at C:/msys/home/User/qemu/vl.c:3250 +#2 0x004c906a in SDL_main (argc=3, argv=0x3e5200) + at C:/msys/home/User/qemu/vl.c:102 +#3 0x0061dcf4 in console_main () +#4 0x0061ddb4 in WinMain@16 () +#5 0x006329fb in main () +(gdb) + +qemu_opt_find() doesn't check if opts is NULL or not before use. +The patch fixes that issue. + +This is fixed by http://patchwork.ozlabs.org/patch/142548/ (which hasn't been applied yet but hopefully will be soon). + + + +2012/2/24 Peter Maydell <email address hidden>: +> This is fixed by http://patchwork.ozlabs.org/patch/142548/ (which hasn't +> been applied yet but hopefully will be soon). +> + +It looks like a workaround to me as if you feed NULL to +qemu_opt_find() it will still crashing. + +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/939995 +> +> Title: +> v1.0-1172-g235fe3b crashes (opts=0x0) +> +> Status in QEMU: +> New +> +> Bug description: +> C:\msys\home\User\qemu\i386-softmmu>gdb --args qemu-system-i386.exe -L ..\pc-bios +> GNU gdb (GDB) 7.3 +> Copyright (C) 2011 Free Software Foundation, Inc. +> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +> This is free software: you are free to change and redistribute it. +> There is NO WARRANTY, to the extent permitted by law. Type "show copying" +> and "show warranty" for details. +> This GDB was configured as "mingw32". +> For bug reporting instructions, please see: +> <http://www.gnu.org/software/gdb/bugs/>... +> Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe... +> done. +> (gdb) r +> Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L ..\\pc-bios +> [New Thread 4724.0x1224] +> +> Program received signal SIGSEGV, Segmentation fault. +> 0x004eeda6 in qemu_opt_get (opts=0x0, name=0x68a7c3 "kernel") +> at qemu-option.c:545 +> 545 QemuOpt *opt = qemu_opt_find(opts, name); +> (gdb) bt +> #0 0x004eeda6 in qemu_opt_get (opts=0x0, name=0x68a7c3 "kernel") +> at qemu-option.c:545 +> #1 0x004c7166 in qemu_main (argc=3, argv=0x3e5200, envp=0x0) +> at C:/msys/home/User/qemu/vl.c:3250 +> #2 0x004c906a in SDL_main (argc=3, argv=0x3e5200) +> at C:/msys/home/User/qemu/vl.c:102 +> #3 0x0061dcf4 in console_main () +> #4 0x0061ddb4 in WinMain@16 () +> #5 0x006329fb in main () +> (gdb) +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/939995/+subscriptions + + +Peter's fix had been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=967c0da73a7b0da186baba6 +... so I think we can close this bug ticket now. + diff --git a/results/classifier/zero-shot/108/all/95154278 b/results/classifier/zero-shot/108/all/95154278 new file mode 100644 index 000000000..2dc0c2ffc --- /dev/null +++ b/results/classifier/zero-shot/108/all/95154278 @@ -0,0 +1,165 @@ +permissions: 0.989 +other: 0.953 +debug: 0.951 +device: 0.951 +graphic: 0.950 +PID: 0.949 +vnc: 0.948 +semantic: 0.937 +performance: 0.936 +files: 0.918 +KVM: 0.916 +socket: 0.913 +network: 0.913 +boot: 0.902 + +[Qemu-devel] [BUG] checkpatch.pl hangs on target/mips/msa_helper.c + +If checkpatch.pl is applied (using switch "-f") on file +target/mips/msa_helper.c, it will hang. + +There is a workaround for this particular file: + +These lines in msa_helper.c: + + uint## BITS ##_t S = _S, T = _T; \ + uint## BITS ##_t as, at, xs, xt, xd; \ + +should be replaced with: + + uint## BITS ## _t S = _S, T = _T; \ + uint## BITS ## _t as, at, xs, xt, xd; \ + +(a space is added after the second "##" in each line) + +The workaround is found by partial deleting and undeleting of the code in +msa_helper.c in binary search fashion. + +This workaround will soon be submitted by me as a patch within a series on misc +MIPS issues. + +I took a look at checkpatch.pl code, and it looks it is fairly complicated to +fix the issue, since it happens in the code segment involving intricate logic +conditions. + +Regards, +Aleksandar + +On Wed, Jul 04, 2018 at 03:35:18PM +0000, Aleksandar Markovic wrote: +> +If checkpatch.pl is applied (using switch "-f") on file +> +target/mips/msa_helper.c, it will hang. +> +> +There is a workaround for this particular file: +> +> +These lines in msa_helper.c: +> +> +uint## BITS ##_t S = _S, T = _T; \ +> +uint## BITS ##_t as, at, xs, xt, xd; \ +> +> +should be replaced with: +> +> +uint## BITS ## _t S = _S, T = _T; \ +> +uint## BITS ## _t as, at, xs, xt, xd; \ +> +> +(a space is added after the second "##" in each line) +> +> +The workaround is found by partial deleting and undeleting of the code in +> +msa_helper.c in binary search fashion. +> +> +This workaround will soon be submitted by me as a patch within a series on +> +misc MIPS issues. +> +> +I took a look at checkpatch.pl code, and it looks it is fairly complicated to +> +fix the issue, since it happens in the code segment involving intricate logic +> +conditions. +Thanks for figuring this out, Aleksandar. Not sure if anyone else has +the apetite to fix checkpatch.pl. + +Stefan +signature.asc +Description: +PGP signature + +On 07/11/2018 09:36 AM, Stefan Hajnoczi wrote: +> +On Wed, Jul 04, 2018 at 03:35:18PM +0000, Aleksandar Markovic wrote: +> +> If checkpatch.pl is applied (using switch "-f") on file +> +> target/mips/msa_helper.c, it will hang. +> +> +> +> There is a workaround for this particular file: +> +> +> +> These lines in msa_helper.c: +> +> +> +> uint## BITS ##_t S = _S, T = _T; \ +> +> uint## BITS ##_t as, at, xs, xt, xd; \ +> +> +> +> should be replaced with: +> +> +> +> uint## BITS ## _t S = _S, T = _T; \ +> +> uint## BITS ## _t as, at, xs, xt, xd; \ +> +> +> +> (a space is added after the second "##" in each line) +> +> +> +> The workaround is found by partial deleting and undeleting of the code in +> +> msa_helper.c in binary search fashion. +> +> +> +> This workaround will soon be submitted by me as a patch within a series on +> +> misc MIPS issues. +> +> +> +> I took a look at checkpatch.pl code, and it looks it is fairly complicated +> +> to fix the issue, since it happens in the code segment involving intricate +> +> logic conditions. +> +> +Thanks for figuring this out, Aleksandar. Not sure if anyone else has +> +the apetite to fix checkpatch.pl. +Anyone else but Paolo ;P +http://lists.nongnu.org/archive/html/qemu-devel/2018-07/msg01250.html +signature.asc +Description: +OpenPGP digital signature + diff --git a/results/classifier/zero-shot/108/all/965133 b/results/classifier/zero-shot/108/all/965133 new file mode 100644 index 000000000..ab78b5c81 --- /dev/null +++ b/results/classifier/zero-shot/108/all/965133 @@ -0,0 +1,160 @@ +other: 0.995 +permissions: 0.994 +semantic: 0.993 +debug: 0.993 +graphic: 0.993 +socket: 0.991 +boot: 0.991 +files: 0.991 +performance: 0.990 +PID: 0.990 +device: 0.989 +network: 0.986 +vnc: 0.986 +KVM: 0.976 + +Sparc64 crash on start + +qemu version 1.0.1 compiled on a Ubuntu live on a HP laptop win a x64 architecture. + +With more than 4G of memory sparc64 machine crash on start. + +command line: qemu-system-sparc64 -m 4G + +output: +VNC server running on `127.0.0.1:5900' +qemu: fatal: Trap 0x0064 while trap level (5) >= MAXTL (5), Error state +pc: 00000000ffd04c80 npc: 00000000ffd04c84 +General Registers: +%g0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 + +Current Register Window: +%o0-3: 00000000ffd00000 0000000000080000 0000000000080000 0000000000000000 +%o4-7: 0000000000000000 0000000000000000 00000000fff754e1 00000000ffd144d4 +%l0-3: 0000000100000000 00000000fff75c4d 0000000000000000 0000000000000000 +%l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%i0-3: 0000000000000000 0000000000000000 0000000100000000 0000000000000036 +%i4-7: 00000000ffe87418 00000000ffe87648 00000000fff75591 00000000ffd0bf54 + +Floating Point Registers: +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +pstate: 00000414 ccr: 99 (icc: N--C xcc: N--C) asi: 00 tl: 5 pil: 0 +cansave: 5 canrestore: 1 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 3 +fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 +Aborted (core dumped) + +On Mon, Mar 26, 2012 at 10:27, Tiziano Vecchi <email address hidden> wrote: +> Public bug reported: +> +> qemu version 1.0.1 compiled on a Ubuntu live on a HP laptop win a x64 +> architecture. +> +> With more than 4G of memory sparc64 machine crash on start. +> +> command line: qemu-system-sparc64 -m 4G +> +> output: +> VNC server running on `127.0.0.1:5900' +> qemu: fatal: Trap 0x0064 while trap level (5) >= MAXTL (5), Error state +> pc: 00000000ffd04c80 npc: 00000000ffd04c84 +> General Registers: +> %g0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> +> Current Register Window: +> %o0-3: 00000000ffd00000 0000000000080000 0000000000080000 0000000000000000 +> %o4-7: 0000000000000000 0000000000000000 00000000fff754e1 00000000ffd144d4 +> %l0-3: 0000000100000000 00000000fff75c4d 0000000000000000 0000000000000000 +> %l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %i0-3: 0000000000000000 0000000000000000 0000000100000000 0000000000000036 +> %i4-7: 00000000ffe87418 00000000ffe87648 00000000fff75591 00000000ffd0bf54 +> +> Floating Point Registers: +> %f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> pstate: 00000414 ccr: 99 (icc: N--C xcc: N--C) asi: 00 tl: 5 pil: 0 +> cansave: 5 canrestore: 1 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 3 +> fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 +> Aborted (core dumped) + +This is actually a bug in OpenBIOS. It is mapped at 0xffd00000 (below +4G) for compatibility with 32 bit code, but the code does not handle +this case where top of RAM overlaps OpenBIOS. + +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/965133 +> +> Title: +> Sparc64 crash on start +> +> Status in QEMU: +> New +> +> Bug description: +> qemu version 1.0.1 compiled on a Ubuntu live on a HP laptop win a x64 +> architecture. +> +> With more than 4G of memory sparc64 machine crash on start. +> +> command line: qemu-system-sparc64 -m 4G +> +> output: +> VNC server running on `127.0.0.1:5900' +> qemu: fatal: Trap 0x0064 while trap level (5) >= MAXTL (5), Error state +> pc: 00000000ffd04c80 npc: 00000000ffd04c84 +> General Registers: +> %g0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> +> Current Register Window: +> %o0-3: 00000000ffd00000 0000000000080000 0000000000080000 0000000000000000 +> %o4-7: 0000000000000000 0000000000000000 00000000fff754e1 00000000ffd144d4 +> %l0-3: 0000000100000000 00000000fff75c4d 0000000000000000 0000000000000000 +> %l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %i0-3: 0000000000000000 0000000000000000 0000000100000000 0000000000000036 +> %i4-7: 00000000ffe87418 00000000ffe87648 00000000fff75591 00000000ffd0bf54 +> +> Floating Point Registers: +> %f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> %f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +> pstate: 00000414 ccr: 99 (icc: N--C xcc: N--C) asi: 00 tl: 5 pil: 0 +> cansave: 5 canrestore: 1 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 3 +> fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 +> Aborted (core dumped) +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/965133/+subscriptions +> + + +Can you still reproduce this problem with the latest version of QEMU / OpenBIOS? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/96782458 b/results/classifier/zero-shot/108/all/96782458 new file mode 100644 index 000000000..6fa03cc39 --- /dev/null +++ b/results/classifier/zero-shot/108/all/96782458 @@ -0,0 +1,1009 @@ +debug: 0.989 +permissions: 0.986 +performance: 0.985 +semantic: 0.984 +other: 0.982 +boot: 0.980 +PID: 0.980 +files: 0.978 +socket: 0.976 +vnc: 0.976 +device: 0.974 +graphic: 0.973 +network: 0.967 +KVM: 0.963 + +[Qemu-devel] [BUG] Migrate failes between boards with different PMC counts + +Hi all, + +Recently, I found migration failed when enable vPMU. + +migrate vPMU state was introduced in linux-3.10 + qemu-1.7. + +As long as enable vPMU, qemu will save / load the +vmstate_msr_architectural_pmu(msr_global_ctrl) register during the migration. +But global_ctrl generated based on cpuid(0xA), the number of general-purpose +performance +monitoring counters(PMC) can vary according to Intel SDN. The number of PMC +presented +to vm, does not support configuration currently, it depend on host cpuid, and +enable all pmc +defaultly at KVM. It cause migration to fail between boards with different PMC +counts. + +The return value of cpuid (0xA) is different dur to cpu, according to Intel +SDNï¼18-10 Vol. 3B: + +Note: The number of general-purpose performance monitoring counters (i.e. N in +Figure 18-9) +can vary across processor generations within a processor family, across +processor families, or +could be different depending on the configuration chosen at boot time in the +BIOS regarding +Intel Hyper Threading Technology, (e.g. N=2 for 45 nm Intel Atom processors; N +=4 for processors +based on the Nehalem microarchitecture; for processors based on the Sandy Bridge +microarchitecture, N = 4 if Intel Hyper Threading Technology is active and N=8 +if not active). + +Also I found, N=8 if HT is not active based on the broadwellï¼, +such as CPU E7-8890 v4 @ 2.20GHz + +# ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -smp 4 -m 4096 -hda +/data/zyy/test_qemu.img.sles12sp1 -vnc :99 -cpu kvm64,pmu=true -incoming +tcp::8888 +Completed 100 % +qemu-system-x86_64: error: failed to set MSR 0x38f to 0x7000000ff +qemu-system-x86_64: /data/zyy/git/test/qemu/target/i386/kvm.c:1833: +kvm_put_msrs: +Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +Aborted + +So make number of pmc configurable to vm ? Any better idea ? + + +Regards, +-Zhuang Yanying + +* Zhuangyanying (address@hidden) wrote: +> +Hi all, +> +> +Recently, I found migration failed when enable vPMU. +> +> +migrate vPMU state was introduced in linux-3.10 + qemu-1.7. +> +> +As long as enable vPMU, qemu will save / load the +> +vmstate_msr_architectural_pmu(msr_global_ctrl) register during the migration. +> +But global_ctrl generated based on cpuid(0xA), the number of general-purpose +> +performance +> +monitoring counters(PMC) can vary according to Intel SDN. The number of PMC +> +presented +> +to vm, does not support configuration currently, it depend on host cpuid, and +> +enable all pmc +> +defaultly at KVM. It cause migration to fail between boards with different +> +PMC counts. +> +> +The return value of cpuid (0xA) is different dur to cpu, according to Intel +> +SDNï¼18-10 Vol. 3B: +> +> +Note: The number of general-purpose performance monitoring counters (i.e. N +> +in Figure 18-9) +> +can vary across processor generations within a processor family, across +> +processor families, or +> +could be different depending on the configuration chosen at boot time in the +> +BIOS regarding +> +Intel Hyper Threading Technology, (e.g. N=2 for 45 nm Intel Atom processors; +> +N =4 for processors +> +based on the Nehalem microarchitecture; for processors based on the Sandy +> +Bridge +> +microarchitecture, N = 4 if Intel Hyper Threading Technology is active and +> +N=8 if not active). +> +> +Also I found, N=8 if HT is not active based on the broadwellï¼, +> +such as CPU E7-8890 v4 @ 2.20GHz +> +> +# ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -smp 4 -m 4096 -hda +> +/data/zyy/test_qemu.img.sles12sp1 -vnc :99 -cpu kvm64,pmu=true -incoming +> +tcp::8888 +> +Completed 100 % +> +qemu-system-x86_64: error: failed to set MSR 0x38f to 0x7000000ff +> +qemu-system-x86_64: /data/zyy/git/test/qemu/target/i386/kvm.c:1833: +> +kvm_put_msrs: +> +Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +Aborted +> +> +So make number of pmc configurable to vm ? Any better idea ? +Coincidentally we hit a similar problem a few days ago with -cpu host - it +took me +quite a while to spot the difference between the machines was the source +had hyperthreading disabled. + +An option to set the number of counters makes sense to me; but I wonder +how many other options we need as well. Also, I'm not sure there's any +easy way for libvirt etc to figure out how many counters a host supports - it's +not in /proc/cpuinfo. + +Dave + +> +> +Regards, +> +-Zhuang Yanying +-- +Dr. David Alan Gilbert / address@hidden / Manchester, UK + +On Mon, Apr 24, 2017 at 10:23:21AM +0100, Dr. David Alan Gilbert wrote: +> +* Zhuangyanying (address@hidden) wrote: +> +> Hi all, +> +> +> +> Recently, I found migration failed when enable vPMU. +> +> +> +> migrate vPMU state was introduced in linux-3.10 + qemu-1.7. +> +> +> +> As long as enable vPMU, qemu will save / load the +> +> vmstate_msr_architectural_pmu(msr_global_ctrl) register during the +> +> migration. +> +> But global_ctrl generated based on cpuid(0xA), the number of +> +> general-purpose performance +> +> monitoring counters(PMC) can vary according to Intel SDN. The number of PMC +> +> presented +> +> to vm, does not support configuration currently, it depend on host cpuid, +> +> and enable all pmc +> +> defaultly at KVM. It cause migration to fail between boards with different +> +> PMC counts. +> +> +> +> The return value of cpuid (0xA) is different dur to cpu, according to Intel +> +> SDNï¼18-10 Vol. 3B: +> +> +> +> Note: The number of general-purpose performance monitoring counters (i.e. N +> +> in Figure 18-9) +> +> can vary across processor generations within a processor family, across +> +> processor families, or +> +> could be different depending on the configuration chosen at boot time in +> +> the BIOS regarding +> +> Intel Hyper Threading Technology, (e.g. N=2 for 45 nm Intel Atom +> +> processors; N =4 for processors +> +> based on the Nehalem microarchitecture; for processors based on the Sandy +> +> Bridge +> +> microarchitecture, N = 4 if Intel Hyper Threading Technology is active and +> +> N=8 if not active). +> +> +> +> Also I found, N=8 if HT is not active based on the broadwellï¼, +> +> such as CPU E7-8890 v4 @ 2.20GHz +> +> +> +> # ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -smp 4 -m 4096 -hda +> +> /data/zyy/test_qemu.img.sles12sp1 -vnc :99 -cpu kvm64,pmu=true -incoming +> +> tcp::8888 +> +> Completed 100 % +> +> qemu-system-x86_64: error: failed to set MSR 0x38f to 0x7000000ff +> +> qemu-system-x86_64: /data/zyy/git/test/qemu/target/i386/kvm.c:1833: +> +> kvm_put_msrs: +> +> Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +> Aborted +> +> +> +> So make number of pmc configurable to vm ? Any better idea ? +> +> +Coincidentally we hit a similar problem a few days ago with -cpu host - it +> +took me +> +quite a while to spot the difference between the machines was the source +> +had hyperthreading disabled. +> +> +An option to set the number of counters makes sense to me; but I wonder +> +how many other options we need as well. Also, I'm not sure there's any +> +easy way for libvirt etc to figure out how many counters a host supports - +> +it's not in /proc/cpuinfo. +We actually try to avoid /proc/cpuinfo whereever possible. We do direct +CPUID asm instructions to identify features, and prefer to use +/sys/devices/system/cpu if that has suitable data + +Where do the PMC counts come from originally ? CPUID or something else ? + +Regards, +Daniel +-- +|: +https://berrange.com +-o- +https://www.flickr.com/photos/dberrange +:| +|: +https://libvirt.org +-o- +https://fstop138.berrange.com +:| +|: +https://entangle-photo.org +-o- +https://www.instagram.com/dberrange +:| + +* Daniel P. Berrange (address@hidden) wrote: +> +On Mon, Apr 24, 2017 at 10:23:21AM +0100, Dr. David Alan Gilbert wrote: +> +> * Zhuangyanying (address@hidden) wrote: +> +> > Hi all, +> +> > +> +> > Recently, I found migration failed when enable vPMU. +> +> > +> +> > migrate vPMU state was introduced in linux-3.10 + qemu-1.7. +> +> > +> +> > As long as enable vPMU, qemu will save / load the +> +> > vmstate_msr_architectural_pmu(msr_global_ctrl) register during the +> +> > migration. +> +> > But global_ctrl generated based on cpuid(0xA), the number of +> +> > general-purpose performance +> +> > monitoring counters(PMC) can vary according to Intel SDN. The number of +> +> > PMC presented +> +> > to vm, does not support configuration currently, it depend on host cpuid, +> +> > and enable all pmc +> +> > defaultly at KVM. It cause migration to fail between boards with +> +> > different PMC counts. +> +> > +> +> > The return value of cpuid (0xA) is different dur to cpu, according to +> +> > Intel SDNï¼18-10 Vol. 3B: +> +> > +> +> > Note: The number of general-purpose performance monitoring counters (i.e. +> +> > N in Figure 18-9) +> +> > can vary across processor generations within a processor family, across +> +> > processor families, or +> +> > could be different depending on the configuration chosen at boot time in +> +> > the BIOS regarding +> +> > Intel Hyper Threading Technology, (e.g. N=2 for 45 nm Intel Atom +> +> > processors; N =4 for processors +> +> > based on the Nehalem microarchitecture; for processors based on the Sandy +> +> > Bridge +> +> > microarchitecture, N = 4 if Intel Hyper Threading Technology is active +> +> > and N=8 if not active). +> +> > +> +> > Also I found, N=8 if HT is not active based on the broadwellï¼, +> +> > such as CPU E7-8890 v4 @ 2.20GHz +> +> > +> +> > # ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -smp 4 -m 4096 -hda +> +> > /data/zyy/test_qemu.img.sles12sp1 -vnc :99 -cpu kvm64,pmu=true -incoming +> +> > tcp::8888 +> +> > Completed 100 % +> +> > qemu-system-x86_64: error: failed to set MSR 0x38f to 0x7000000ff +> +> > qemu-system-x86_64: /data/zyy/git/test/qemu/target/i386/kvm.c:1833: +> +> > kvm_put_msrs: +> +> > Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +> > Aborted +> +> > +> +> > So make number of pmc configurable to vm ? Any better idea ? +> +> +> +> Coincidentally we hit a similar problem a few days ago with -cpu host - it +> +> took me +> +> quite a while to spot the difference between the machines was the source +> +> had hyperthreading disabled. +> +> +> +> An option to set the number of counters makes sense to me; but I wonder +> +> how many other options we need as well. Also, I'm not sure there's any +> +> easy way for libvirt etc to figure out how many counters a host supports - +> +> it's not in /proc/cpuinfo. +> +> +We actually try to avoid /proc/cpuinfo whereever possible. We do direct +> +CPUID asm instructions to identify features, and prefer to use +> +/sys/devices/system/cpu if that has suitable data +> +> +Where do the PMC counts come from originally ? CPUID or something else ? +Yes, they're bits 8..15 of CPUID leaf 0xa + +Dave + +> +Regards, +> +Daniel +> +-- +> +|: +https://berrange.com +-o- +https://www.flickr.com/photos/dberrange +:| +> +|: +https://libvirt.org +-o- +https://fstop138.berrange.com +:| +> +|: +https://entangle-photo.org +-o- +https://www.instagram.com/dberrange +:| +-- +Dr. David Alan Gilbert / address@hidden / Manchester, UK + +On Mon, Apr 24, 2017 at 11:27:16AM +0100, Dr. David Alan Gilbert wrote: +> +* Daniel P. Berrange (address@hidden) wrote: +> +> On Mon, Apr 24, 2017 at 10:23:21AM +0100, Dr. David Alan Gilbert wrote: +> +> > * Zhuangyanying (address@hidden) wrote: +> +> > > Hi all, +> +> > > +> +> > > Recently, I found migration failed when enable vPMU. +> +> > > +> +> > > migrate vPMU state was introduced in linux-3.10 + qemu-1.7. +> +> > > +> +> > > As long as enable vPMU, qemu will save / load the +> +> > > vmstate_msr_architectural_pmu(msr_global_ctrl) register during the +> +> > > migration. +> +> > > But global_ctrl generated based on cpuid(0xA), the number of +> +> > > general-purpose performance +> +> > > monitoring counters(PMC) can vary according to Intel SDN. The number of +> +> > > PMC presented +> +> > > to vm, does not support configuration currently, it depend on host +> +> > > cpuid, and enable all pmc +> +> > > defaultly at KVM. It cause migration to fail between boards with +> +> > > different PMC counts. +> +> > > +> +> > > The return value of cpuid (0xA) is different dur to cpu, according to +> +> > > Intel SDNï¼18-10 Vol. 3B: +> +> > > +> +> > > Note: The number of general-purpose performance monitoring counters +> +> > > (i.e. N in Figure 18-9) +> +> > > can vary across processor generations within a processor family, across +> +> > > processor families, or +> +> > > could be different depending on the configuration chosen at boot time +> +> > > in the BIOS regarding +> +> > > Intel Hyper Threading Technology, (e.g. N=2 for 45 nm Intel Atom +> +> > > processors; N =4 for processors +> +> > > based on the Nehalem microarchitecture; for processors based on the +> +> > > Sandy Bridge +> +> > > microarchitecture, N = 4 if Intel Hyper Threading Technology is active +> +> > > and N=8 if not active). +> +> > > +> +> > > Also I found, N=8 if HT is not active based on the broadwellï¼, +> +> > > such as CPU E7-8890 v4 @ 2.20GHz +> +> > > +> +> > > # ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -smp 4 -m 4096 -hda +> +> > > /data/zyy/test_qemu.img.sles12sp1 -vnc :99 -cpu kvm64,pmu=true +> +> > > -incoming tcp::8888 +> +> > > Completed 100 % +> +> > > qemu-system-x86_64: error: failed to set MSR 0x38f to 0x7000000ff +> +> > > qemu-system-x86_64: /data/zyy/git/test/qemu/target/i386/kvm.c:1833: +> +> > > kvm_put_msrs: +> +> > > Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +> > > Aborted +> +> > > +> +> > > So make number of pmc configurable to vm ? Any better idea ? +> +> > +> +> > Coincidentally we hit a similar problem a few days ago with -cpu host - +> +> > it took me +> +> > quite a while to spot the difference between the machines was the source +> +> > had hyperthreading disabled. +> +> > +> +> > An option to set the number of counters makes sense to me; but I wonder +> +> > how many other options we need as well. Also, I'm not sure there's any +> +> > easy way for libvirt etc to figure out how many counters a host supports - +> +> > it's not in /proc/cpuinfo. +> +> +> +> We actually try to avoid /proc/cpuinfo whereever possible. We do direct +> +> CPUID asm instructions to identify features, and prefer to use +> +> /sys/devices/system/cpu if that has suitable data +> +> +> +> Where do the PMC counts come from originally ? CPUID or something else ? +> +> +Yes, they're bits 8..15 of CPUID leaf 0xa +Ok, that's easy enough for libvirt to detect then. More a question of what +libvirt should then do this with the info.... + +Regards, +Daniel +-- +|: +https://berrange.com +-o- +https://www.flickr.com/photos/dberrange +:| +|: +https://libvirt.org +-o- +https://fstop138.berrange.com +:| +|: +https://entangle-photo.org +-o- +https://www.instagram.com/dberrange +:| + +> +-----Original Message----- +> +From: Daniel P. Berrange [ +mailto:address@hidden +> +Sent: Monday, April 24, 2017 6:34 PM +> +To: Dr. David Alan Gilbert +> +Cc: Zhuangyanying; Zhanghailiang; wangxin (U); address@hidden; +> +Gonglei (Arei); Huangzhichao; address@hidden +> +Subject: Re: [Qemu-devel] [BUG] Migrate failes between boards with different +> +PMC counts +> +> +On Mon, Apr 24, 2017 at 11:27:16AM +0100, Dr. David Alan Gilbert wrote: +> +> * Daniel P. Berrange (address@hidden) wrote: +> +> > On Mon, Apr 24, 2017 at 10:23:21AM +0100, Dr. David Alan Gilbert wrote: +> +> > > * Zhuangyanying (address@hidden) wrote: +> +> > > > Hi all, +> +> > > > +> +> > > > Recently, I found migration failed when enable vPMU. +> +> > > > +> +> > > > migrate vPMU state was introduced in linux-3.10 + qemu-1.7. +> +> > > > +> +> > > > As long as enable vPMU, qemu will save / load the +> +> > > > vmstate_msr_architectural_pmu(msr_global_ctrl) register during the +> +migration. +> +> > > > But global_ctrl generated based on cpuid(0xA), the number of +> +> > > > general-purpose performance monitoring counters(PMC) can vary +> +> > > > according to Intel SDN. The number of PMC presented to vm, does +> +> > > > not support configuration currently, it depend on host cpuid, and +> +> > > > enable +> +all pmc defaultly at KVM. It cause migration to fail between boards with +> +different PMC counts. +> +> > > > +> +> > > > The return value of cpuid (0xA) is different dur to cpu, according to +> +> > > > Intel +> +SDNï¼18-10 Vol. 3B: +> +> > > > +> +> > > > Note: The number of general-purpose performance monitoring +> +> > > > counters (i.e. N in Figure 18-9) can vary across processor +> +> > > > generations within a processor family, across processor +> +> > > > families, or could be different depending on the configuration +> +> > > > chosen at boot time in the BIOS regarding Intel Hyper Threading +> +> > > > Technology, (e.g. N=2 for 45 nm Intel Atom processors; N =4 for +> +processors based on the Nehalem microarchitecture; for processors based on +> +the Sandy Bridge microarchitecture, N = 4 if Intel Hyper Threading Technology +> +is active and N=8 if not active). +> +> > > > +> +> > > > Also I found, N=8 if HT is not active based on the broadwellï¼, +> +> > > > such as CPU E7-8890 v4 @ 2.20GHz +> +> > > > +> +> > > > # ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -smp 4 -m +> +> > > > 4096 -hda +> +> > > > /data/zyy/test_qemu.img.sles12sp1 -vnc :99 -cpu kvm64,pmu=true +> +> > > > -incoming tcp::8888 Completed 100 % +> +> > > > qemu-system-x86_64: error: failed to set MSR 0x38f to +> +> > > > 0x7000000ff +> +> > > > qemu-system-x86_64: /data/zyy/git/test/qemu/target/i386/kvm.c:1833: +> +kvm_put_msrs: +> +> > > > Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +> > > > Aborted +> +> > > > +> +> > > > So make number of pmc configurable to vm ? Any better idea ? +> +> > > +> +> > > Coincidentally we hit a similar problem a few days ago with -cpu +> +> > > host - it took me quite a while to spot the difference between +> +> > > the machines was the source had hyperthreading disabled. +> +> > > +> +> > > An option to set the number of counters makes sense to me; but I +> +> > > wonder how many other options we need as well. Also, I'm not sure +> +> > > there's any easy way for libvirt etc to figure out how many +> +> > > counters a host supports - it's not in /proc/cpuinfo. +> +> > +> +> > We actually try to avoid /proc/cpuinfo whereever possible. We do +> +> > direct CPUID asm instructions to identify features, and prefer to +> +> > use /sys/devices/system/cpu if that has suitable data +> +> > +> +> > Where do the PMC counts come from originally ? CPUID or something +> +else ? +> +> +> +> Yes, they're bits 8..15 of CPUID leaf 0xa +> +> +Ok, that's easy enough for libvirt to detect then. More a question of what +> +libvirt +> +should then do this with the info.... +> +Do you mean to do a validation at the begining of migration? in +qemuMigrationBakeCookie() & qemuMigrationEatCookie(), if the PMC numbers are +not equal, just quit migration? +It maybe a good enough first edition. +But for a further better edition, maybe it's better to support Heterogeneous +migration I think, so we might need to make PMC number configrable, then we +need to modify KVM/qemu as well. + +Regards, +-Zhuang Yanying + +* Zhuangyanying (address@hidden) wrote: +> +> +> +> -----Original Message----- +> +> From: Daniel P. Berrange [ +mailto:address@hidden +> +> Sent: Monday, April 24, 2017 6:34 PM +> +> To: Dr. David Alan Gilbert +> +> Cc: Zhuangyanying; Zhanghailiang; wangxin (U); address@hidden; +> +> Gonglei (Arei); Huangzhichao; address@hidden +> +> Subject: Re: [Qemu-devel] [BUG] Migrate failes between boards with different +> +> PMC counts +> +> +> +> On Mon, Apr 24, 2017 at 11:27:16AM +0100, Dr. David Alan Gilbert wrote: +> +> > * Daniel P. Berrange (address@hidden) wrote: +> +> > > On Mon, Apr 24, 2017 at 10:23:21AM +0100, Dr. David Alan Gilbert wrote: +> +> > > > * Zhuangyanying (address@hidden) wrote: +> +> > > > > Hi all, +> +> > > > > +> +> > > > > Recently, I found migration failed when enable vPMU. +> +> > > > > +> +> > > > > migrate vPMU state was introduced in linux-3.10 + qemu-1.7. +> +> > > > > +> +> > > > > As long as enable vPMU, qemu will save / load the +> +> > > > > vmstate_msr_architectural_pmu(msr_global_ctrl) register during the +> +> migration. +> +> > > > > But global_ctrl generated based on cpuid(0xA), the number of +> +> > > > > general-purpose performance monitoring counters(PMC) can vary +> +> > > > > according to Intel SDN. The number of PMC presented to vm, does +> +> > > > > not support configuration currently, it depend on host cpuid, and +> +> > > > > enable +> +> all pmc defaultly at KVM. It cause migration to fail between boards with +> +> different PMC counts. +> +> > > > > +> +> > > > > The return value of cpuid (0xA) is different dur to cpu, according +> +> > > > > to Intel +> +> SDNï¼18-10 Vol. 3B: +> +> > > > > +> +> > > > > Note: The number of general-purpose performance monitoring +> +> > > > > counters (i.e. N in Figure 18-9) can vary across processor +> +> > > > > generations within a processor family, across processor +> +> > > > > families, or could be different depending on the configuration +> +> > > > > chosen at boot time in the BIOS regarding Intel Hyper Threading +> +> > > > > Technology, (e.g. N=2 for 45 nm Intel Atom processors; N =4 for +> +> processors based on the Nehalem microarchitecture; for processors based on +> +> the Sandy Bridge microarchitecture, N = 4 if Intel Hyper Threading +> +> Technology +> +> is active and N=8 if not active). +> +> > > > > +> +> > > > > Also I found, N=8 if HT is not active based on the broadwellï¼, +> +> > > > > such as CPU E7-8890 v4 @ 2.20GHz +> +> > > > > +> +> > > > > # ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -smp 4 -m +> +> > > > > 4096 -hda +> +> > > > > /data/zyy/test_qemu.img.sles12sp1 -vnc :99 -cpu kvm64,pmu=true +> +> > > > > -incoming tcp::8888 Completed 100 % +> +> > > > > qemu-system-x86_64: error: failed to set MSR 0x38f to +> +> > > > > 0x7000000ff +> +> > > > > qemu-system-x86_64: /data/zyy/git/test/qemu/target/i386/kvm.c:1833: +> +> kvm_put_msrs: +> +> > > > > Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +> +> > > > > Aborted +> +> > > > > +> +> > > > > So make number of pmc configurable to vm ? Any better idea ? +> +> > > > +> +> > > > Coincidentally we hit a similar problem a few days ago with -cpu +> +> > > > host - it took me quite a while to spot the difference between +> +> > > > the machines was the source had hyperthreading disabled. +> +> > > > +> +> > > > An option to set the number of counters makes sense to me; but I +> +> > > > wonder how many other options we need as well. Also, I'm not sure +> +> > > > there's any easy way for libvirt etc to figure out how many +> +> > > > counters a host supports - it's not in /proc/cpuinfo. +> +> > > +> +> > > We actually try to avoid /proc/cpuinfo whereever possible. We do +> +> > > direct CPUID asm instructions to identify features, and prefer to +> +> > > use /sys/devices/system/cpu if that has suitable data +> +> > > +> +> > > Where do the PMC counts come from originally ? CPUID or something +> +> else ? +> +> > +> +> > Yes, they're bits 8..15 of CPUID leaf 0xa +> +> +> +> Ok, that's easy enough for libvirt to detect then. More a question of what +> +> libvirt +> +> should then do this with the info.... +> +> +> +> +Do you mean to do a validation at the begining of migration? in +> +qemuMigrationBakeCookie() & qemuMigrationEatCookie(), if the PMC numbers are +> +not equal, just quit migration? +> +It maybe a good enough first edition. +> +But for a further better edition, maybe it's better to support Heterogeneous +> +migration I think, so we might need to make PMC number configrable, then we +> +need to modify KVM/qemu as well. +Yes agreed; the only thing I wanted to check was that libvirt would have enough +information to be able to use any feature we added to QEMU. + +Dave + +> +Regards, +> +-Zhuang Yanying +-- +Dr. David Alan Gilbert / address@hidden / Manchester, UK + diff --git a/results/classifier/zero-shot/108/all/977391 b/results/classifier/zero-shot/108/all/977391 new file mode 100644 index 000000000..6e7226fea --- /dev/null +++ b/results/classifier/zero-shot/108/all/977391 @@ -0,0 +1,732 @@ +permissions: 0.991 +debug: 0.989 +other: 0.989 +semantic: 0.987 +performance: 0.983 +files: 0.983 +device: 0.983 +graphic: 0.979 +PID: 0.977 +socket: 0.976 +boot: 0.972 +network: 0.971 +vnc: 0.957 +KVM: 0.933 + +BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] in lucid + +Two days back my KVM base machine got hung up all of a sudden. +Not sure what exactly happened. + +cat /proc/version_signature +Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12 + + +-Rahul N. + + + +Thanks for reporting this bug. + +To give us some more information on your system, could you please run 'apport-collect 977391' ? + +Is there any alternate way I can provide you the information? +I am actually not comfortable in executing this command on the system. + +-Rahul N. + +On Mon, Apr 9, 2012 at 11:59 PM, Serge Hallyn <email address hidden>wrote: + +> Thanks for reporting this bug. +> +> To give us some more information on your system, could you please run +> 'apport-collect 977391' ? +> +> ** Package changed: kvm (Ubuntu) => qemu-kvm (Ubuntu) +> +> ** Changed in: qemu-kvm (Ubuntu) +> Status: New => Incomplete +> +> ** Also affects: linux (Ubuntu) +> Importance: Undecided +> Status: New +> +> ** Changed in: linux (Ubuntu) +> Status: New => Incomplete +> +> ** Changed in: qemu-kvm (Ubuntu) +> Importance: Undecided => Medium +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/977391 +> +> Title: +> BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] +> +> Status in “linux” package in Ubuntu: +> Incomplete +> Status in “qemu-kvm” package in Ubuntu: +> Incomplete +> +> Bug description: +> Two days back my KVM base machine got hung up all of a sudden. +> Not sure what exactly happened. +> +> cat /proc/version_signature +> Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12 +> +> +> -Rahul N. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/977391/+subscriptions +> + + + +-- +-Rahul N. +IT Department +In2M Technologies Pvt Ltd. (Finicity) +Website: www.finicity.com/india + + +Quoting Rahul (<email address hidden>): +> Is there any alternate way I can provide you the information? +> I am actually not comfortable in executing this command on the system. + +The most important information given the nature of the bug would be the +configuration (in particular what is sitting under the backing store) of +your VM, and the relevant contents of /var/log/syslog and /var/log/dmesg*. + +Are you able to reprocuce this at will? + + +Serge, + +I attaching the logs along with this mail. + +-Rahul N. + +On Tue, Apr 10, 2012 at 1:39 AM, Serge Hallyn <email address hidden>wrote: + +> Quoting Rahul (<email address hidden>): +> > Is there any alternate way I can provide you the information? +> > I am actually not comfortable in executing this command on the system. +> +> The most important information given the nature of the bug would be the +> configuration (in particular what is sitting under the backing store) of +> your VM, and the relevant contents of /var/log/syslog and /var/log/dmesg*. +> +> Are you able to reprocuce this at will? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/977391 +> +> Title: +> BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] +> +> Status in QEMU: +> New +> Status in “linux” package in Ubuntu: +> Confirmed +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> +> Bug description: +> Two days back my KVM base machine got hung up all of a sudden. +> Not sure what exactly happened. +> +> cat /proc/version_signature +> Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12 +> +> +> -Rahul N. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/977391/+subscriptions +> + + +Thanks - unfortunately they seem to be from after the event. + +If it happens again, please do post the new logs. + +And if you know how to trigger this at will, please let us know. + +rahul, thank you for reporting this and helping make Ubuntu better. Could you please capture the oops following https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Capturing_OOPs ? + +Serge, + +These are the logs at the time when event occurred. +But unfortunately nothing helpful was there in the logs. +I am not sure about how can I provide you the proper logs even if this +happened again. + +-Rahul N. + +On Tue, Apr 10, 2012 at 3:23 AM, Serge Hallyn <email address hidden>wrote: + +> Thanks - unfortunately they seem to be from after the event. +> +> If it happens again, please do post the new logs. +> +> And if you know how to trigger this at will, please let us know. +> +> ** Summary changed: +> +> - BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] +> + BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] in lucid +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/977391 +> +> Title: +> BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] in lucid +> +> Status in QEMU: +> Confirmed +> Status in “linux” package in Ubuntu: +> Confirmed +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> +> Bug description: +> Two days back my KVM base machine got hung up all of a sudden. +> Not sure what exactly happened. +> +> cat /proc/version_signature +> Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12 +> +> +> -Rahul N. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/977391/+subscriptions +> + + + +-- +-Rahul N. +IT Department +In2M Technologies Pvt Ltd. (Finicity) +Website: www.finicity.com/india + + +Please check the attached screenshot that I took during the issue. +I cant find anything useful in the logs. + +-Rahul N. + +On Tue, Apr 10, 2012 at 3:31 AM, Christopher M. Penalver < +<email address hidden>> wrote: + +> rahul, thank you for reporting this and helping make Ubuntu better. +> Could you please capture the oops following +> https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Capturing_OOPs +> ? +> +> ** Tags added: lucid +> +> ** Changed in: linux (Ubuntu) +> Status: Confirmed => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/977391 +> +> Title: +> BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] in lucid +> +> Status in QEMU: +> Confirmed +> Status in “linux” package in Ubuntu: +> Incomplete +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> +> Bug description: +> Two days back my KVM base machine got hung up all of a sudden. +> Not sure what exactly happened. +> +> cat /proc/version_signature +> Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12 +> +> +> -Rahul N. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/977391/+subscriptions +> + + + +-- +-Rahul N. +IT Department +In2M Technologies Pvt Ltd. (Finicity) +Website: www.finicity.com/india + + +Serge, + +May be this screenshot (attached) will help. + +-Rahul N. + +On Tue, Apr 10, 2012 at 4:37 AM, Rahul Nair <email address hidden> wrote: + +> Serge, +> +> These are the logs at the time when event occurred. +> But unfortunately nothing helpful was there in the logs. +> I am not sure about how can I provide you the proper logs even if this +> happened again. +> +> -Rahul N. +> +> On Tue, Apr 10, 2012 at 3:23 AM, Serge Hallyn <email address hidden>wrote: +> +>> Thanks - unfortunately they seem to be from after the event. +>> +>> If it happens again, please do post the new logs. +>> +>> And if you know how to trigger this at will, please let us know. +>> +>> ** Summary changed: +>> +>> - BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] +>> + BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] in lucid +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/977391 +>> +>> Title: +>> BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] in lucid +>> +>> Status in QEMU: +>> Confirmed +>> Status in “linux” package in Ubuntu: +>> Confirmed +>> Status in “qemu-kvm” package in Ubuntu: +>> Confirmed +>> +>> Bug description: +>> Two days back my KVM base machine got hung up all of a sudden. +>> Not sure what exactly happened. +>> +>> cat /proc/version_signature +>> Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12 +>> +>> +>> -Rahul N. +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/977391/+subscriptions +>> +> +> +> +> -- +> -Rahul N. +> IT Department +> In2M Technologies Pvt Ltd. (Finicity) +> Website: www.finicity.com/india +> +> + + +-- +-Rahul N. +IT Department +In2M Technologies Pvt Ltd. (Finicity) +Website: www.finicity.com/india + + +Were you able to find any clues...? + +Rahul N. +On Tuesday, April 10, 2012, Rahul Nair <email address hidden> wrote: +> Please check the attached screenshot that I took during the issue. +> I cant find anything useful in the logs. +> +> -Rahul N. +> +> On Tue, Apr 10, 2012 at 3:31 AM, Christopher M. Penalver < +<email address hidden>> wrote: +>> +>> rahul, thank you for reporting this and helping make Ubuntu better. +>> Could you please capture the oops following +>> https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Capturing_OOPs +>> ? +>> +>> ** Tags added: lucid +>> +>> ** Changed in: linux (Ubuntu) +>> Status: Confirmed => Incomplete +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/977391 +>> +>> Title: +>> BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] in lucid +>> +>> Status in QEMU: +>> Confirmed +>> Status in “linux” package in Ubuntu: +>> Incomplete +>> Status in “qemu-kvm” package in Ubuntu: +>> Confirmed +>> +>> Bug description: +>> Two days back my KVM base machine got hung up all of a sudden. +>> Not sure what exactly happened. +>> +>> cat /proc/version_signature +>> Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12 +>> +>> +>> -Rahul N. +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/977391/+subscriptions +> +> +> +> -- +> -Rahul N. +> IT Department +> In2M Technologies Pvt Ltd. (Finicity) +> Website: www.finicity.com/india +> + +-- +-Rahul N. +IT Department +In2M Technologies Pvt Ltd. (Finicity) +Website: www.finicity.com/india + + +Sorry, the screenshot does show that the deadlock is on a spinlock during flush_tlb_others(), perhaps at + + if (nr_cpu_ids > NUM_INVALIDATE_TLB_VECTORS) + raw_spin_lock(&f->tlbstate_lock); + + +Uh, I meant "sorry, but the reason that happened isn't shown". + +Is there anything in /var/log/kern.log.* ? A fuller oops would be valuable. + +If this vm was spawned with libvirt, could you post the xml description? What OS was the guest running? + +Serge, + +This is a KVM base machine which faced the issue not a guest machine. +In kern.log there was no Call Trace found during the time of issue. +Also nothing was found in /var/crash/* too. +Are you aware of any possible reason due to which its not logged in any of +the log files? + +-Rahul N. + +On Tue, Apr 10, 2012 at 8:35 PM, Serge Hallyn <email address hidden>wrote: + +> Is there anything in /var/log/kern.log.* ? A fuller oops would be +> valuable. +> +> If this vm was spawned with libvirt, could you post the xml description? +> What OS was the guest running? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/977391 +> +> Title: +> BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] in lucid +> +> Status in QEMU: +> Confirmed +> Status in “linux” package in Ubuntu: +> Confirmed +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> +> Bug description: +> Two days back my KVM base machine got hung up all of a sudden. +> Not sure what exactly happened. +> +> cat /proc/version_signature +> Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12 +> +> +> -Rahul N. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/977391/+subscriptions +> + + + +-- +-Rahul N. +IT Department +In2M Technologies Pvt Ltd. (Finicity) +Website: www.finicity.com/india + + +Also FYI: + +OS: Ubuntu 10.04 +kernel: 2.6.32-28 + +-Rahul N. + +On Wed, Apr 11, 2012 at 4:49 PM, Rahul Nair <email address hidden> wrote: + +> Serge, +> +> This is a KVM base machine which faced the issue not a guest machine. +> In kern.log there was no Call Trace found during the time of issue. +> Also nothing was found in /var/crash/* too. +> Are you aware of any possible reason due to which its not logged in any of +> the log files? +> +> -Rahul N. +> +> On Tue, Apr 10, 2012 at 8:35 PM, Serge Hallyn <email address hidden>wrote: +> +>> Is there anything in /var/log/kern.log.* ? A fuller oops would be +>> valuable. +>> +>> If this vm was spawned with libvirt, could you post the xml description? +>> What OS was the guest running? +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/977391 +>> +>> Title: +>> BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] in lucid +>> +>> Status in QEMU: +>> Confirmed +>> Status in “linux” package in Ubuntu: +>> Confirmed +>> Status in “qemu-kvm” package in Ubuntu: +>> Confirmed +>> +>> Bug description: +>> Two days back my KVM base machine got hung up all of a sudden. +>> Not sure what exactly happened. +>> +>> cat /proc/version_signature +>> Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12 +>> +>> +>> -Rahul N. +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/977391/+subscriptions +>> +> +> +> +> -- +> -Rahul N. +> IT Department +> In2M Technologies Pvt Ltd. (Finicity) +> Website: www.finicity.com/india +> +> + + +-- +-Rahul N. +IT Department +In2M Technologies Pvt Ltd. (Finicity) +Website: www.finicity.com/india + + +Quoting Rahul (<email address hidden>): +> Serge, +> +> This is a KVM base machine which faced the issue not a guest machine. + +Yes, but it's possible that using the same guest OS will make reproducing +the bug possible. Since there isn't enough collected debug info, I'll +need to be able to reproduce it. + +> In kern.log there was no Call Trace found during the time of issue. + +Thanks. + +> Also nothing was found in /var/crash/* too. + +Drat. + +> Are you aware of any possible reason due to which its not logged in any of +> the log files? + +No. + + +found that there is patch available for this bug but the patch is for Ubuntu 8.04.4 LTS(2.6.24-26). I am looking if the same patch is available for Ubuntu 10.04.2 LTS. Here is the link describing about the bug and its available patch. please advise. +https://bugs.launchpad.net/ubuntu/hardy/+source/linux/+bug/790557 + + + +Plz co-ordinate with launchpad via bug we have created. +I need you to focus on this and get root cause by next week as per +postmortem. + +-Rahul N. + +On Saturday, April 14, 2012, arun gathiya <email address hidden> wrote: +> found that there is patch available for this bug but the patch is for +Ubuntu 8.04.4 LTS(2.6.24-26). I am looking if the same patch is available +for Ubuntu 10.04.2 LTS. Here is the link describing about the bug and its +available patch. please advise. +> https://bugs.launchpad.net/ubuntu/hardy/+source/linux/+bug/790557 +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/977391 +> +> Title: +> BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] in lucid +> +> Status in QEMU: +> Confirmed +> Status in “linux” package in Ubuntu: +> Confirmed +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> +> Bug description: +> Two days back my KVM base machine got hung up all of a sudden. +> Not sure what exactly happened. +> +> cat /proc/version_signature +> Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12 +> +> +> -Rahul N. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/977391/+subscriptions +> + +-- +-Rahul N. +IT Department +In2M Technologies Pvt Ltd. (Finicity) +Website: www.finicity.com/india + + +Plz co-ordinate with launchpad via bug we have created. +I need you to focus on this and get root cause by next week as per +postmortem. + +-Rahul + +On Saturday, April 14, 2012, arun gathiya <email address hidden> wrote: +> found that there is patch available for this bug but the patch is for +Ubuntu 8.04.4 LTS(2.6.24-26). I am looking if the same patch is available +for Ubuntu 10.04.2 LTS. Here is the link describing about the bug and its +available patch. please advise. +> https://bugs.launchpad.net/ubuntu/hardy/+source/linux/+bug/790557 +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/977391 +> +> Title: +> BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] in lucid +> +> Status in QEMU: +> Confirmed +> Status in “linux” package in Ubuntu: +> Confirmed +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> +> Bug description: +> Two days back my KVM base machine got hung up all of a sudden. +> Not sure what exactly happened. +> +> cat /proc/version_signature +> Ubuntu 2.6.32-28.55-server 2.6.32.27+drm33.12 +> +> +> -Rahul N. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/977391/+subscriptions +> + +-- +-Rahul N. +IT Department +In2M Technologies Pvt Ltd. (Finicity) +Website: www.finicity.com/india + + +Thanks. The bug you linked was fixed upstream as of 2.6.25. + +Can you post some information on your storage backend? + +You mean there is patch available for 10.04.2? OR same below patch is applicable for Ubuntu 10.04.2 LTS ? +which specific information you want on storage backend? sorry I did't get you there. +: +found that there is patch available for this bug but the patch is for Ubuntu 8.04.4 LTS(2.6.24-26). I am looking if the same patch is available for Ubuntu 10.04.2 LTS. Here is the link describing about the bug and its available patch. please advise. +https://bugs.launchpad.net/ubuntu/hardy/+source/linux/+bug/790557 + +Rahul, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest server release of Ubuntu? ISO images are available from http://releases.ubuntu.com/raring/ . + +If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report: + +apport-collect -p linux <replace-with-bug-number> + +Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags: +kernel-fixed-upstream +kernel-fixed-upstream-VERSION-NUMBER + +where VERSION-NUMBER is the version number of the kernel you tested. For example: +kernel-fixed-upstream-v3.11-rc7 + +This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag: +needs-upstream-testing + +If the mainline kernel does not fix this bug, please add the following tags: +kernel-bug-exists-upstream +kernel-bug-exists-upstream-VERSION-NUMBER + +As well, please remove the tag: +needs-upstream-testing + +Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding. + +This sounds like a kernel bug, so it should not be tracked via the QEMU bug tracker. + +Setting Incomplete for qemu-kvm as well, pending the reporter's response on whether this is still an issue. + +[Expired for linux (Ubuntu) because there has been no activity for 60 days.] + +[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/all/986770 b/results/classifier/zero-shot/108/all/986770 new file mode 100644 index 000000000..ba0af4d87 --- /dev/null +++ b/results/classifier/zero-shot/108/all/986770 @@ -0,0 +1,90 @@ +debug: 0.972 +permissions: 0.966 +other: 0.965 +graphic: 0.959 +performance: 0.958 +semantic: 0.956 +vnc: 0.955 +device: 0.943 +socket: 0.937 +PID: 0.936 +files: 0.935 +boot: 0.933 +KVM: 0.928 +network: 0.915 + +Oops: spice configured but not active + +with latest qemu-kvm from git i have following problem: + + /usr/bin/kvm -daemonize -smp 4 -cpu host -vga qxl -enable-kvm -m 4096 -localtime -drive file=/home/sss/vm/win_xp/tmp_sys.img,if=virtio,media=disk,cache=none -drive file=/home/sss/vm/data.img,if=virtio,media=disk,cache=none -net nic,vlan=0,model=virtio,macaddr=6a:94:fc:2d:b9:04 -net tap,vlan=0,ifname=vtap0,script=no -usb -usbdevice tablet -name "Windows XP qt" -spice port=5934,addr=127.0.0.1,ipv4,playback-compression=off,disable-ticketing -monitor telnet::4448,server,nowait -device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -balloon virtio +qemu-system-x86_64: Oops: spice configured but not active + +Seems commit ad1be89948f88e89708b04ccd782456ccec3a6f0 from qemu needs to go in to qemu-kvm. + +Could you try that and report if it fixes the issue for you? + +commit ad1be89948f88e89708b04ccd782456ccec3a6f0 +Author: Alon Levy <email address hidden> +Date: Wed Mar 14 20:33:37 2012 +0200 + + spice: fix broken initialization + + Commit 1b71f7c14fab6f00c2680d4489fbee7baf796e4f moved MODULE_INIT_QOM to + way before MODULE_INIT_MACHINE, thereby breaking assumptions made in + spice-core.c which registered both a type initializer and a machine + intializer. + + This fix removes the type registration, and replaces it with calling + qemu_spice_init in vl.c after command line parsing (second pass) is + done, and after timers are armed, required by spice server. + + Signed-off-by: Alon Levy <email address hidden> + Signed-off-by: Gerd Hoffmann <email address hidden> + +diff --git a/ui/spice-core.c b/ui/spice-core.c +index 80535b6..a468524 100644 +--- a/ui/spice-core.c ++++ b/ui/spice-core.c +@@ -554,7 +554,7 @@ void qemu_spice_init(void) + + qemu_thread_get_self(&me); + +- if (!opts) { ++ if (!opts) { + return; + } + port = qemu_opt_get_number(opts, "port", 0); +@@ -787,10 +787,3 @@ static void spice_register_config(void) + qemu_add_opts(&qemu_spice_opts); + } + machine_init(spice_register_config); +- +-static void spice_register_types(void) +-{ +- qemu_spice_init(); +-} +- +-type_init(spice_register_types) +diff --git a/vl.c b/vl.c +index bd95539..eeb634b 100644 +--- a/vl.c ++++ b/vl.c +@@ -3369,6 +3369,11 @@ int main(int argc, char **argv, char **envp) + exit(1); + } + ++#ifdef CONFIG_SPICE ++ /* spice needs the timers to be initialized by this point */ ++ qemu_spice_init(); ++#endif ++ + if (icount_option && (kvm_enabled() || xen_enabled())) { + fprintf(stderr, "-icount is not allowed with kvm or xen\n"); + exit(1); + + +thx, this solves problem, but patches failed, i have to edit code manually + +Commit ad1be89948f88e8 has been included long ago, so let's set this ticket to "Fix released" now. + diff --git a/results/classifier/zero-shot/108/all/990364 b/results/classifier/zero-shot/108/all/990364 new file mode 100644 index 000000000..b4d88ae67 --- /dev/null +++ b/results/classifier/zero-shot/108/all/990364 @@ -0,0 +1,445 @@ +device: 0.981 +socket: 0.974 +network: 0.973 +other: 0.972 +graphic: 0.971 +PID: 0.968 +permissions: 0.967 +semantic: 0.967 +files: 0.967 +boot: 0.965 +performance: 0.964 +vnc: 0.962 +debug: 0.958 +KVM: 0.921 + +virtio_ioport_write: unexpected address 0x13 value 0x1 + +Hello! I have: + +virtio_ioport_write: unexpected address 0x13 value 0x1 + +on config: + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 +1c1839e4ba -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +,cache=none -drive file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net tap,fd=43,vlan=0,name=tap.0 -serial +none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus +pci_add_option_rom: failed to find romfile "pxe-virtio.bin" + +with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 x86_64 GNU/Linux +qemu drivers are virtio-win-0.1-22.iso +kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 +qemu 0.12.3+noroms-0ubuntu9.18 + + + +I forgot: guest os is Windows XP Pro SP3 + + + +Hi Vadim, +Here is a recent bug report with virtio-win-0.1-22.iso. Wanted to +bring it to your attention, please let me know if you already monitor +these bug emails. + +Stefan + +On Sat, Apr 28, 2012 at 9:49 AM, Vitalis <email address hidden> wrote: +> Public bug reported: +> +> Hello! I have: +> +> virtio_ioport_write: unexpected address 0x13 value 0x1 +> +> on config: +> +> LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 +> 1c1839e4ba -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +> ,cache=none -drive file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net tap,fd=43,vlan=0,name=tap.0 -serial +> none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus +> pci_add_option_rom: failed to find romfile "pxe-virtio.bin" +> +> with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 x86_64 GNU/Linux +> qemu drivers are virtio-win-0.1-22.iso +> kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 +> qemu 0.12.3+noroms-0ubuntu9.18 +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> +> ** Tags: bug kvm virtio +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/990364 +> +> Title: +> virtio_ioport_write: unexpected address 0x13 value 0x1 +> +> Status in QEMU: +> New +> +> Bug description: +> Hello! I have: +> +> virtio_ioport_write: unexpected address 0x13 value 0x1 +> +> on config: +> +> LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 +> 1c1839e4ba -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +> ,cache=none -drive file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net tap,fd=43,vlan=0,name=tap.0 -serial +> none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus +> pci_add_option_rom: failed to find romfile "pxe-virtio.bin" +> +> with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 x86_64 GNU/Linux +> qemu drivers are virtio-win-0.1-22.iso +> kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 +> qemu 0.12.3+noroms-0ubuntu9.18 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/990364/+subscriptions +> + + +On Monday, April 30, 2012 03:31:03 PM Stefan Hajnoczi wrote: +> Hi Vadim, +> Here is a recent bug report with virtio-win-0.1-22.iso. Wanted to +> bring it to your attention, please let me know if you already monitor +> these bug emails. +Hi Stefan, +Yes, it's on my radar. +Cheers, +Vadim. +> +> Stefan +> +> On Sat, Apr 28, 2012 at 9:49 AM, Vitalis <email address hidden> wrote: +> > Public bug reported: +> > +> > Hello! I have: +> > +> > virtio_ioport_write: unexpected address 0x13 value 0x1 +> > +> > on config: +> > +> > LC_ALL=C +> > PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin +> > QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm +> > -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 1c1839e4ba +> > -chardev +> > socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowa +> > it -monitor chardev:monitor -localtime -boot c -drive +> > file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +> > ,cache=none -drive +> > file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,forma +> > t=raw -net +> > nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net +> > tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice +> > tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed +> > to find romfile "pxe-virtio.bin" +> > +> > with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 +> > x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso +> > kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 +> > qemu 0.12.3+noroms-0ubuntu9.18 +> > +> > ** Affects: qemu +> > Importance: Undecided +> > Status: New +> > +> > +> > ** Tags: bug kvm virtio +> > +> > -- +> > You received this bug notification because you are a member of qemu- +> > devel-ml, which is subscribed to QEMU. +> > https://bugs.launchpad.net/bugs/990364 +> > +> > Title: +> > virtio_ioport_write: unexpected address 0x13 value 0x1 +> > +> > Status in QEMU: +> > New +> > +> > Bug description: +> > Hello! I have: +> > +> > virtio_ioport_write: unexpected address 0x13 value 0x1 +> > +> > on config: +> > +> > LC_ALL=C +> > PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin +> > QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm +> > -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 1c1839e4ba +> > -chardev +> > socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowa +> > it -monitor chardev:monitor -localtime -boot c -drive +> > file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +> > ,cache=none -drive +> > file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,forma +> > t=raw -net +> > nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net +> > tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice +> > tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed +> > to find romfile "pxe-virtio.bin" +> > +> > with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 +> > x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso +> > kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 +> > qemu 0.12.3+noroms-0ubuntu9.18 +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/990364/+subscriptions + + +On Monday, April 30, 2012 07:17:09 PM Vadim Rozenfeld wrote: +> On Monday, April 30, 2012 03:31:03 PM Stefan Hajnoczi wrote: +> > Hi Vadim, +> > Here is a recent bug report with virtio-win-0.1-22.iso. Wanted to +> > bring it to your attention, please let me know if you already monitor +> > these bug emails. +> +> Hi Stefan, +> Yes, it's on my radar. +> Cheers, +> Vadim. +> +seems to be ndis related +(https://bugzilla.redhat.com/show_bug.cgi?id=808654#c10) +cc'ing Yan. + +> > Stefan +> > +> > On Sat, Apr 28, 2012 at 9:49 AM, Vitalis <email address hidden> wrote: +> > > Public bug reported: +> > > +> > > Hello! I have: +> > > +> > > virtio_ioport_write: unexpected address 0x13 value 0x1 +> > > +> > > on config: +> > > +> > > LC_ALL=C +> > > PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin +> > > QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm +> > > -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 +> > > 1c1839e4ba -chardev +> > > socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,now +> > > a it -monitor chardev:monitor -localtime -boot c -drive +> > > file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +> > > ,cache=none -drive +> > > file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,form +> > > a t=raw -net +> > > nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net +> > > tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice +> > > tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed +> > > to find romfile "pxe-virtio.bin" +> > > +> > > with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC +> > > 2012 x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso +> > > kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 +> > > qemu 0.12.3+noroms-0ubuntu9.18 +> > > +> > > ** Affects: qemu +> > > +> > > Importance: Undecided +> > > +> > > Status: New +> > > +> > > ** Tags: bug kvm virtio +> > > +> > > -- +> > > You received this bug notification because you are a member of qemu- +> > > devel-ml, which is subscribed to QEMU. +> > > https://bugs.launchpad.net/bugs/990364 +> > > +> > > Title: +> > > virtio_ioport_write: unexpected address 0x13 value 0x1 +> > > +> > > Status in QEMU: +> > > New +> > > +> > > Bug description: +> > > Hello! I have: +> > > +> > > virtio_ioport_write: unexpected address 0x13 value 0x1 +> > > +> > > on config: +> > > +> > > LC_ALL=C +> > > +> > > PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin +> > > QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm +> > > -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 +> > > 1c1839e4ba -chardev +> > > socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,now +> > > a it -monitor chardev:monitor -localtime -boot c -drive +> > > file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +> > > ,cache=none -drive +> > > file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,form +> > > a t=raw -net +> > > nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net +> > > tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice +> > > tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed +> > > to find romfile "pxe-virtio.bin" +> > > +> > > with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC +> > > 2012 +> > > +> > > x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso +> > > +> > > kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18 +> > > qemu 0.12.3+noroms-0ubuntu9.18 +> > > +> > > To manage notifications about this bug go to: +> > > https://bugs.launchpad.net/qemu/+bug/990364/+subscriptions + + +And what? Where can I get new drivers for WinXP? + +On Thursday, May 03, 2012 10:17:15 PM Vitalis wrote: +> And what? Where can I get new drivers for WinXP? + +http://people.redhat.com/vrozenfe/build-27/virtio-win-prewhql-0.1.zip + + +But with new drivers i got "virtio_ioport_write: unexpected address 0x13 value 0x1" again. + +can you upload the corresponding dump file? + +I see in properties of drivers version 51.63.103.2700 (date is 20.04.2012). + +It doesn't look like as a vritio-win driver problem. +you get the following message +"virtio_ioport_write: unexpected address 0x13 value 0x1" +because netkvm driver triggers BSOD event, which happened in +different stack, and then kills the hosting QEMU prccess +by writing to ISR register. + +In your case (minidumps in comments #1 and #11) BSOD +happened inside of Raw Input Thread, which usually caused +by all kind of key and mouse filters/loggers. + +Unfortunately minidump doesn't provide enough information +to troubleshoot such kind of problems. If it's possible - try disabling +antivirus and RDP on your system. +Vadim. + +I change network card in guest to RTL and no have BSOD, on all guest. Why? +How can we detect the cause? + +and how can i use winXP without antivirus and RDP? Its nonsense!!! :-) no sense! + +Hard to say at the moment. +In both cases the crash stack looks absolutely the same: + +nt!KiDeliverApc+0x66 +hal!HalpApcInterrupt+0xc5 +hal!HalRequestSoftwareInterrupt+0x3b +win32k!RawInputThread+0x625 +win32k!xxxCreateSystemThreads+0x60 +win32k!NtUserCallOneParam+0x23 +nt!KiFastCallEntry+0xf8 + +Try reproducing the problem with Kernel +memory dump option turned on instead of +minidump. In this case it will be possible +to extract more useful information. + +Vadim. + +How turn on kernel memory dump in XP? + +http://support.microsoft.com/kb/316450 + +Hello! +ANd again "virtio_ioport_write: unexpected address 0x13 value 0x1". +Drvers: from virtio-win-0.1-30.iso +config: <domain type='kvm'> + <name>buh_xp</name> + <uuid>f0e8ac00-4545-eb5d-e8f2-c885063e5ad0</uuid> + <memory>1097152</memory> + <currentMemory>1097152</currentMemory> + <vcpu>1</vcpu> + <os> + <type arch='i686' machine='pc-0.12'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + </features> + <clock offset='localtime'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='raw' cache='none'/> + <source file='/root/buh_xp.qcow2'/> + <target dev='hda' bus='virtio'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/home/worky/virtio-win-0.1-30.iso'/> + <target dev='hdc' bus='ide'/> + <readonly/> + </disk> + <interface type='bridge'> + <mac address='00:16:36:2f:11:31'/> + <source bridge='br0'/> + <model type='virtio'/> + </interface> + <console type='pty'> + <target port='0'/> + </console> + <console type='pty'> + <target port='0'/> + </console> + <input type='tablet' bus='usb'/> + <input type='mouse' bus='ps2'/> + <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/> + <video> + <model type='cirrus' vram='9216' heads='1'/> + </video> + </devices> +</domain> + +uname: Linux test-2 2.6.32-43-server #97-Ubuntu SMP Wed Sep 5 16:56:41 UTC 2012 x86_64 GNU/Linux +qemu-kvm: 0.12.3+noroms-0ubuntu9.20 +kvm: 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.20 +hardware: SuperMicro x8sil-f + + +I can't add much, except that I started noticing his issue when migrating my VMs to an Ubuntu Precise server hypervisor where under (heavy?) load my Win 2008 Server VM started to crash very frequently with the error showing up in the libvirt log of the VM. + +It might be useful information that I ended up moving the VM back to a Debian Squeeze hypervisor which hosted it originally and things were running smoothly until earlier today when a crash with the same message happened again. What's sure is that under Squeeze the issue is far-far less frequent, on Precise the VM got reset a dozen times during the first 48 h, while on Squeeze it's been running fine even under heavy load for weeks without a hiccup. + +Details of the Precise hypervisor: +kvm: 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.3 +qemu-kvm: 1.0+noroms-0ubuntu14.3 +kernel: 3.2.0-32-generic +(tested with virtio drivers virtio-win-0.1-15.iso and virtio-win-0.1-30.iso) + +Details of the Squeeze hypervisor: +kvm: 1:0.12.5+dfsg-5+squeeze8 +qemu-kvm: 0.12.5+dfsg-5+squeeze8 +kernel: 2.6.32-5-amd64 +(tested with virtio drivers virtio-win-0.1-15.iso) + + +IMHO, Ubuntu Server for KVM virtualization - is BAD idea! Very BAD idea...... + +Status changed to 'Confirmed' because the bug affects multiple users. + +Hi, +this got to my attention after being reassigned from upstream to Ubuntu's qemu. + +I'd assume that this is very much timed out and no more applicable and mark it incomplete by that to give everybody a chance to object and describe what they face today. + diff --git a/results/classifier/zero-shot/108/all/994662 b/results/classifier/zero-shot/108/all/994662 new file mode 100644 index 000000000..6c434e034 --- /dev/null +++ b/results/classifier/zero-shot/108/all/994662 @@ -0,0 +1,179 @@ +other: 0.991 +graphic: 0.980 +debug: 0.977 +permissions: 0.975 +semantic: 0.974 +device: 0.971 +boot: 0.970 +performance: 0.968 +KVM: 0.968 +vnc: 0.967 +socket: 0.964 +network: 0.962 +PID: 0.961 +files: 0.961 + +QEMU crashes on ioport access + +While running a fuzzer inside the guest, QEMU crashed with the following message and dumped the state of all vcpus: + + +qemu: hardware error: register_ioport_read: invalid opaque for address 0x0Al +CPU #0: +RAX=ffff880007a73000 RBX=ffff8800095b6000 RCX=ffff880007a33530 RDX=ffff880007a33530 +RSI=0000000000aa6000 RDI=0000000000aa6000 RBP=ffff880007c13c68 RSP=ffff880007c13c48 +R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000001 +R12=0000000000aa6000 R13=8000000033556045 R14=0000000000aa6000 R15=ffff8800095b6000 +RIP=ffffffff8108ae02 RFL=00000282 [--S----] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 ffffffff 00000000 +CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0000 0000000000000000 ffffffff 00000000 +FS =0000 00007f7de18e8700 ffffffff 00000000 +GS =0000 ffff88000d800000 ffffffff 00000000 +LDT=0000 0000000000000000 ffffffff 00000000 +TR =0040 ffff88000d9d2540 00002087 00008b00 DPL=0 TSS64-busy +GDT= ffff88000d804000 0000007f +IDT= ffffffff8436d000 00000fff +CR0=8005003b CR2=00007f2f25752e9c CR3=0000000007a3d000 CR4=000407f0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +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=0000000000ff0000000000ff00000000 XMM01=25252525252525252525252525252525 +XMM02=00000000000000000000000000000000 XMM03=ffff0000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000 +XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000 +XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000 +XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000 +CPU #1: +RAX=ffff88001b588000 RBX=ffffea00004ab300 RCX=ffffc90000304000 RDX=0000000000000005 +RSI=ffffc90000304000 RDI=0050000000380028 RBP=ffff880012681c38 RSP=ffff880012681c28 +R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000002 +R12=0000000000000004 R13=ffff88001bfd3000 R14=0000000000fef000 R15=ffff88000ed51000 +RIP=ffffffff811daf87 RFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 ffffffff 00000000 +CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0000 0000000000000000 ffffffff 00000000 +FS =0000 00007fe38bb99700 ffffffff 00000000 +GS =0000 ffff88001b800000 ffffffff 00000000 +LDT=0000 0000000000000000 ffffffff 00000000 +TR =0040 ffff88001b9d2540 00002087 00008b00 DPL=0 TSS64-busy +GDT= ffff88001b804000 0000007f +IDT= ffffffff8436d000 00000fff +CR0=8005003b CR2=00007f2f25ac4518 CR3=000000001173e000 CR4=000407e0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +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=0000000000000000ff0000ff000000ff XMM01=25252525252525252525252525252525 +XMM02=00000000000000000000000000000000 XMM03=0000ff000000ff0000000000ff000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000 +XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000 +XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000 +XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000 +CPU #2: +RAX=000000000000001d RBX=0000000000000080 RCX=0000000000000080 RDX=0000000000000cfc +RSI=0000000000000000 RDI=0000000000000086 RBP=ffff8800121f7de8 RSP=ffff8800121f7db8 +R8 =0000000000000004 R9 =000000000000001d R10=0000000000000000 R11=0000000000000002 +R12=ffff88001b7b0000 R13=000000000000001d R14=0000000000000084 R15=ffff88003523ad00 +RIP=ffffffff82870591 RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 ffffffff 00000000 +CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0000 0000000000000000 ffffffff 00000000 +FS =0000 00007f2f25ce7700 ffffffff 00000000 +GS =0000 ffff880029800000 ffffffff 00000000 +LDT=0000 0000000000000000 ffffffff 00000000 +TR =0040 ffff8800299d2540 00002087 00008b00 DPL=0 TSS64-busy +GDT= ffff880029804000 0000007f +IDT= ffffffff8436d000 00000fff +CR0=80050033 CR2=00007f2f25750003 CR3=0000000011b88000 CR4=000407e0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +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=0000000000000000ff0000ff000000ff XMM01=25252525252525252525252525252525 +XMM02=00000000000000000000000000000000 XMM03=0000ff000000ff0000000000ff000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000 +XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000 +XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000 +XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000 +CPU #3: +RAX=0000000000000086 RBX=0000000000000086 RCX=0000000000000001 RDX=ffff88001afb3000 +RSI=0000000000000001 RDI=ffffffff810f1904 RBP=ffff88001afb9c50 RSP=ffff88001afb9c38 +R8 =0000000000000000 R9 =0000000000000001 R10=0000000000000000 R11=0000000000000001 +R12=ffff88001afb38e0 R13=0000000000000001 R14=ffffffff82d967a8 R15=ffffffff82d967a8 +RIP=ffffffff811171ee RFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 ffffffff 00000000 +CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0000 0000000000000000 ffffffff 00000000 +FS =0000 0000000000000000 ffffffff 00000000 +GS =0000 ffff880035a00000 ffffffff 00000000 +LDT=0000 0000000000000000 ffffffff 00000000 +TR =0040 ffff880035bd2540 00002087 00008b00 DPL=0 TSS64-busy +GDT= ffff880035a04000 0000007f +IDT= ffffffff8436d000 00000fff +CR0=8005003b CR2=0000000000af7130 CR3=000000002cffb000 CR4=000407e0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +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=0000000000000000ff0000ff000000ff XMM01=25252525252525252525252525252525 +XMM02=00000000000000000000000000000000 XMM03=0000ff000000ff0000000000ff000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000 +XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000 +XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000 +XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000 + +And this is the trace: + +Thread 5 (Thread 0x7fffee7b8700 (LWP 1754)): +#0 0x00007ffff40d3ad5 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 +#1 0x00007ffff40d4f56 in *__GI_abort () at abort.c:93 +#2 0x000055555572a0fa in hw_error (fmt=<optimized out>) at /home/sasha/work/src/qemu-kvm/cpus.c:357 +#3 0x0000555555750265 in register_ioport_read (start=<optimized out>, length=<optimized out>, size=<optimized out>, + func=<optimized out>, opaque=<optimized out>) at /home/sasha/work/src/qemu-kvm/ioport.c:154 +#4 0x0000555555750364 in ioport_register (ioport=0x5555565401b8) at /home/sasha/work/src/qemu-kvm/ioport.c:240 +#5 0x000055555575e910 in access_with_adjusted_size (addr=0, value=0x7fffee7b7db8, size=4, access_size_min=<optimized out>, + access_size_max=<optimized out>, access=0x55555575e830 <memory_region_write_accessor>, opaque=0x5555564c1eb0) + at /home/sasha/work/src/qemu-kvm/memory.c:359 +#6 0x0000555555760212 in memory_region_iorange_write (iorange=<optimized out>, offset=0, width=4, data=29) + at /home/sasha/work/src/qemu-kvm/memory.c:436 +#7 0x000055555575375d in kvm_handle_io (count=1, size=4, direction=1025, data=<optimized out>, port=3324) + at /home/sasha/work/src/qemu-kvm/kvm-all.c:1132 +#8 kvm_cpu_exec (env=0x55555648b810) at /home/sasha/work/src/qemu-kvm/kvm-all.c:1274 +#9 0x0000555555729781 in qemu_kvm_cpu_thread_fn (arg=0x55555648b810) at /home/sasha/work/src/qemu-kvm/cpus.c:733 +#10 0x00007ffff647ad0c in start_thread (arg=0x7fffee7b8700) at pthread_create.c:301 +#11 0x00007ffff417af1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 + +Has this issue been fixed or can it still be reproduced with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + |