summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/118/virtual/1459622
blob: 890297fb5d3557940823b0f1613017805d722bcc (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
virtual: 0.954
x86: 0.943
architecture: 0.910
performance: 0.894
device: 0.861
kernel: 0.778
graphic: 0.741
PID: 0.727
KVM: 0.723
hypervisor: 0.669
user-level: 0.655
ppc: 0.641
vnc: 0.635
register: 0.594
network: 0.552
permissions: 0.543
boot: 0.524
i386: 0.514
semantic: 0.484
mistranslation: 0.450
socket: 0.342
VMM: 0.327
risc-v: 0.315
arm: 0.311
files: 0.310
peripherals: 0.283
assembly: 0.241
debug: 0.185
TCG: 0.173

firefox hang with virtfs

Firefox hangs once it starts to load pages. I tried to delete .cache/mozilla/ and .mozilla/ but it doesn't help. But if I mount tmpfs on to .mozilla (not necessary for .cache/mozilla/), pages loads fine.

I started the vm as root (sudo) with the following command: qemu-system-x86_64 -enable-kvm -m 4G -virtfs local,mount_tag=qemu,security_model=passthrough,path=/mnt/qemu/ -kernel /mnt/qemu/boot/vmlinuz-linux -initrd /mnt/qemu/boot/initramfs-linux-fallback.img -append 'rw root=qemu fstype=9p' -usbdevice tablet -vga qxl -spice port=12345,disable-ticketing

/mnt/qemu is a btrfs snapshot of the subvolume used as the host root

Arch Linux, qemu 2.3.0, firefox 38.0.1



Same situation here:
Firefox can't handle ~/.mozilla to be a virtio-9p mount.
Here the subvolume is ext4, mounted only at /home.

I also noticed that chromium is working, but it complains about some errors:
getrlimit(RLIMIT_NOFILE) failed
[4809:4839:0804/230514:ERROR:backend_impl.cc(1365)] Unable to map Index file
[4809:4839:0804/230514:ERROR:backend_impl.cc(1365)] Unable to map Index file
[4809:4840:0804/230514:ERROR:cache_creator.cc(133)] Unable to create cache
[4845:4845:0804/230514:ERROR:sandbox_linux.cc(340)] InitializeSandbox() called with multiple threads in process gpu-process


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.]