summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/118/none/1793275
blob: 2c95ceef5a56525cfa5bcbecc3cd7897ccd05a0f (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
user-level: 0.287
register: 0.239
hypervisor: 0.184
PID: 0.183
risc-v: 0.180
permissions: 0.173
performance: 0.172
boot: 0.169
virtual: 0.162
network: 0.159
architecture: 0.151
arm: 0.141
KVM: 0.139
kernel: 0.132
vnc: 0.129
peripherals: 0.105
ppc: 0.104
device: 0.100
VMM: 0.100
files: 0.100
graphic: 0.100
assembly: 0.100
socket: 0.095
TCG: 0.090
debug: 0.087
x86: 0.077
mistranslation: 0.074
semantic: 0.066
i386: 0.049

Hosts fail to start after update to QEMU 3.0

Host OS: Archlinux
Host Architecture: AMD64
Guest OS: FreeBSD-11.2 (x2) and Archlinux (x1)
Guest Architecture: AMD64

I have been using QEMU 2.x without issue for a number of years but since updating to QEMU 3.0 my guests do not complete startup.

FreeBSD 11.2 guest failure symptom:
The two FreeBSD-11.2 guests output repeated messages of "unexpected cache type 4". This appears to be an internal error message and I've not found any instances of it through Google search.

Archlinux guest failure symptom:
The single Archlinux guest gets no further than the message "uncompressing initial ramdisk".

The guests are started by a qemu-kvm invokation. No virtual machine managers are used. The command lines used (from ps awx) to launch the VMs are:

[neil@optimus ~]$ ps awx |grep qemu
 1492 ?        Sl     3:19 /usr/bin/qemu-system-x86_64 -daemonize -pidfile /run/qemu_vps1.pid -enable-kvm -cpu host -smp 2 -k en-gb -boot order=c -drive file=/dev/system/vps1,cache=none,format=raw,if=virtio,index=0,media=disk -m 1024 -name FreeBSD_1 -net nic,macaddr=52:54:AD:86:64:00,model=virtio -net vde,sock=/run/vde_switch-tap0.sock -monitor telnet:127.0.0.2:23,server,nowait -vnc 192.168.0.1:0
 1510 ?        Sl     0:54 /usr/bin/qemu-system-x86_64 -daemonize -pidfile /run/qemu_vps2.pid -enable-kvm -cpu host -smp 2 -k en-gb -boot order=c -drive file=/dev/system/vps2,cache=none,format=raw,if=virtio,index=0,media=disk -m 1024 -name Archlinux -net nic,macaddr=52:54:AD:86:64:01,model=virtio -net vde,sock=/run/vde_switch-tap0.sock -monitor telnet:127.0.0.3:23,server,nowait -vnc 192.168.0.1:1
 1529 ?        Sl     3:07 /usr/bin/qemu-system-x86_64 -daemonize -pidfile /run/qemu_vps3.pid -enable-kvm -cpu host -smp 2 -k en-gb -boot order=c -drive file=/dev/system/vps3,cache=none,format=raw,if=virtio,index=0,media=disk -m 1024 -name FreeBSD_2 -net nic,macaddr=52:54:AD:86:64:02,model=virtio -net vde,sock=/run/vde_switch-tap0.sock -monitor telnet:127.0.0.4:23,server,nowait -vnc 192.168.0.1:2

The VMs were installed to LVM volumes on the host machine (hence the /dev/system/vpsN device names). Networking is over a Linux tap interface connected to a VDE2 virtual network switch.

Currently working version of QEMU: qemu-headless 2.12.1-1
Failing version of QEMU: qemu-headless-3.0.0-1

Archlinux have released qemu-headless-3.0.0-3 which includes a backported patch for virtio. I have tested this version and the problem still persists.

This bug is not present in QEMU-3.1.0.

Ok, thanks for the update. Closing this bug since it seems to be fixed in 3.1.