blob: 629f9a351d3f7b59857190e22cbdac1f85f8366f (
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
|
device: 0.618
graphic: 0.587
performance: 0.587
boot: 0.490
semantic: 0.483
architecture: 0.446
register: 0.435
permissions: 0.400
network: 0.378
files: 0.367
mistranslation: 0.331
ppc: 0.320
x86: 0.291
user-level: 0.279
socket: 0.260
hypervisor: 0.246
virtual: 0.233
PID: 0.186
vnc: 0.180
debug: 0.130
peripherals: 0.119
kernel: 0.108
assembly: 0.100
risc-v: 0.075
arm: 0.074
VMM: 0.072
TCG: 0.069
i386: 0.029
KVM: 0.014
Qemu on Windows
I have a problem with the latest snapshot from http://qemu.weilnetz.de/. Where should I raise it? Here? It's not clear to me that I should do it since that's probably an unsupported build, whereas there is no support forum or e-mail address on that website.
THanks.
Please describe the problem, maybe I can help you then. Yes, qemu.weilnetz.de contains experimental software which might contain bugs - see the comments on that site. If I get a qualified problem report, I usually try to fix it.
I have found the following symptoms with any combination of image and guest operating system, including Linux and freebsd, with qemu-system-x86_64 and qemu-system-sparc, so I'm pretty sure it's a systematic problem. The images all boot fine on a Linux host.
What's happening is that the guest operating system bootloader finds the operating system and starts to boot, but it fails as soon as it tries to read /etc/init with messages implying it can't read the root filesystem. This is strange because the booter has read it. I wonder if the difference is that the booter uses polled I/O whereas the operating systems use DMA and interrupts? What ever the reason is I'm baffled on how to proceed.
The host operating system is Windows 8.
[Expired for QEMU because there has been no activity for 60 days.]
|