[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-discuss] Trouble starting various qemu-system-*.exe on Windows
|
From: |
Steere, Andy |
|
Subject: |
Re: [Qemu-discuss] Trouble starting various qemu-system-*.exe on Windows 7 |
|
Date: |
Tue, 17 Jun 2014 21:07:40 +0000 |
Your memory is correct. "Qemu-system-mipsel.exe --help" writes the help message
to stdout.txt in the folder where qemu was installed (C:\Program Files
(x86)\qemu). Errors are written to stderr.txt.
On to the real problem - running qemu mipsel with a Debian release on a Windows
7, 64bit machine.
1. Installed the Windows 64 bit Qemu from here: http://qemu.weilnetz.de/w64/
2. Use the vmlinux and qcow from here:
http://people.debian.org/~aurel32/qemu/mipsel/.
3. Run the following:
qemu-system-mipsel.exe -M malta -kernel vmlinux-2.6.32-5-4kc-malta -hda
debian_squeeze_mipsel_standard.qcow2 -append "root=/dev/sda1 console=tty0"
mipsel.exe crashes with the following Windows Application event log data
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event";>
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2014-06-17T20:58:42.000000000Z" />
<EventRecordID>56420</EventRecordID>
<Channel>Application</Channel>
<Computer>address@hidden</Computer>
<Security />
</System>
<EventData>
<Data>qemu-system-mipsel.exe</Data>
<Data>2.0.50.0</Data>
<Data>53a01b95</Data>
<Data>msvcrt.dll</Data>
<Data>7.0.7601.17744</Data>
<Data>4eeb033f</Data>
<Data>c0000005</Data>
<Data>000000000001586f</Data>
<Data>1db4</Data>
<Data>01cf8a6eeb974286</Data>
<Data>c:\Program Files\qemu\qemu-system-mipsel.exe</Data>
<Data>C:\windows\system32\msvcrt.dll</Data>
<Data>29698e7d-f662-11e3-9eeb-cc52af8aa3bb</Data>
</EventData>
</Event>
Just in case, I installed the Windows 32 bit Qemu from here:
http://qemu.weilnetz.de/w32/
In a similar fashion mipsel crashes in msvcrt with the following Windows
Application event data:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event";>
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2014-06-17T20:21:52.000000000Z" />
<EventRecordID>56403</EventRecordID>
<Channel>Application</Channel>
<Computer>address@hidden </Computer>
<Security />
</System>
<EventData>
<Data>qemu-system-mipsel.exe</Data>
<Data>2.0.50.0</Data>
<Data>5386bc69</Data>
<Data>msvcrt.dll</Data>
<Data>7.0.7601.17744</Data>
<Data>4eeaf722</Data>
<Data>c0000005</Data>
<Data>000099e4</Data>
<Data>15a0</Data>
<Data>01cf8a69c548347a</Data>
<Data>c:\Program Files (x86)\qemu\qemu-system-mipsel.exe</Data>
<Data>C:\windows\syswow64\msvcrt.dll</Data>
<Data>0421e50f-f65d-11e3-9eeb-cc52af8aa3bb</Data>
</EventData>
</Event>
Thanks for the help.
Andy
-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of address@hidden
Sent: Tuesday, June 17, 2014 3:48 AM
To: address@hidden
Subject: Qemu-discuss Digest, Vol 33, Issue 18
Send Qemu-discuss mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.nongnu.org/mailman/listinfo/qemu-discuss
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific than "Re:
Contents of Qemu-discuss digest..."
Today's Topics:
1. Re: Hang on reboot in FreeBSD guest on Linux KVM host
(John Nielsen)
2. Re: qemu -kernel u-boot.bin (Peter Maydell)
3. Re: Trouble starting various qemu-system-*.exe on Windows 7
(Peter Maydell)
4. Re: Hang on reboot in FreeBSD guest on Linux KVM host
(Paolo Bonzini)
5. Re: Hang on reboot in FreeBSD guest on Linux KVM host
(John Nielsen)
6. Re: qemu -kernel u-boot.bin (Matwey V. Kornilov)
7. Using multiple network interfaces on a guest (Pavel Troller)
8. Re: Hang on reboot in FreeBSD guest on Linux KVM host
(Paolo Bonzini)
----------------------------------------------------------------------
Message: 1
Date: Mon, 16 Jun 2014 10:09:25 -0600
From: John Nielsen <address@hidden>
To: address@hidden, address@hidden
Subject: Re: [Qemu-discuss] Hang on reboot in FreeBSD guest on Linux
KVM host
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
[Adding -devel to CC.]
I've opened a bug regarding this issue:
https://bugs.launchpad.net/qemu/+bug/1329956
I was unable to duplicate the issue in a different hypervisor, so it seems
likely the problem (or at least its solution) is in Qemu. Any ideas or feedback
still very much appreciated.
JN
On May 9, 2014, at 2:12 PM, John Nielsen <address@hidden> wrote:
> I am trying to solve a problem with x86_64 FreeBSD virtual machines running
> on a Linux+libvirt+KVM hypervisor. To be honest I'm not sure if the problem
> is in FreeBSD or the hypervisor, but I'm trying to approach it from both
> directions.
>
> The _second_ time FreeBSD boots in a virtual machine with more than one core,
> the boot hangs just before the kernel would normally bring up the additional
> processors. The VM will boot fine a first time, but running either "shutdown
> -r now" OR "reboot" will lead to a hung second boot. Stopping and starting
> the host qemu-kvm process is the only way to continue.
>
> Interestingly the problem does not manifest itself after a "virsh reset" on
> the host. I can also avoid it by patching the guest kernel to skip the SMP
> part of the shutdown routine.
>
> Clearly something in the normal FreeBSD shutdown code ls leaving the VM in a
> bad state that hinders the next boot, but I haven't been able to identify
> what exactly. Can someone on the list suggest ways to debug this further?
> Unless it's a FreeBSD bug, I'd like to find a solution or workaround that
> doesn't involve modifying the guest OS.
>
> One more thing: the problem only appears on one of two clusters of host
> machines. The hosts within each cluster are identical, and the two clusters
> are _nearly_ identical to each other. All are running the same software,
> including:
> CentOS 6.5
> kernel 3.12.13 (custom)
> libvirt-1.1.4-2.el6
> qemu-kvm-1.7.0-2.el6
> seabios-1.7.3.1-1.el6
>
> The only substantial difference on the hardware side is the CPU. The hosts
> where the problem occurs use "Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz",
> while the hosts that don't show the problem use the prior revision, "Intel(R)
> Xeon(R) CPU E5-2650 0 @ 2.00GHz".
>
> All ideas appreciated.
------------------------------
Message: 2
Date: Mon, 16 Jun 2014 17:32:52 +0100
From: Peter Maydell <address@hidden>
To: "Matwey V. Kornilov" <address@hidden>
Cc: "Dale R. Worley" <address@hidden>, qemu-discuss
<address@hidden>
Subject: Re: [Qemu-discuss] qemu -kernel u-boot.bin
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=UTF-8
On 13 June 2014 09:50, Matwey V. Kornilov <address@hidden> wrote:
> I am stuck here. I've put u-boot binary on the 0 of flash.bin (which
> is 67108864 bytes long), and run following
>
> qemu-system-arm -M vexpress-a9 -pflash pflash.bin -S -s
>
> I have no warnings, but when I attach with gdb I either don't see my
> code, and nothing happens again, execution just goes successively
> until 0x04000000 reached.
Hmm. Are you running a reasonably recent QEMU? I forget exactly when we put the
pflash device into the vexpress board model.
-- PMM
------------------------------
Message: 3
Date: Mon, 16 Jun 2014 17:33:52 +0100
From: Peter Maydell <address@hidden>
To: "Steere, Andy" <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Qemu-discuss] Trouble starting various qemu-system-*.exe
on Windows 7
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=UTF-8
On 13 June 2014 18:10, Steere, Andy <address@hidden> wrote:
> Thanks for the clarifying. I now understand that not passing arguments would
> get different behavior so I will ask a simpler form of my question.
>
> Running "qemu-system-mipsel --help" on Ubuntu 14.0 gives a help message.
>
> Should Windows "qemu-system-mipsel --help" running as administrator give a
> help message?
I have a feeling it writes it to a file... (stupidity about windows binaries
not being able to be graphics programs and also write to a terminal).
thanks
-- PMM
------------------------------
Message: 4
Date: Mon, 16 Jun 2014 18:39:28 +0200
From: Paolo Bonzini <address@hidden>
To: John Nielsen <address@hidden>, address@hidden,
address@hidden
Subject: Re: [Qemu-discuss] Hang on reboot in FreeBSD guest on Linux
KVM host
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Il 16/06/2014 18:09, John Nielsen ha scritto:
>>> The only substantial difference on the hardware side is the CPU.
>>> The hosts where the problem occurs use "Intel(R) Xeon(R) CPU
>>> E5-2650 v2 @ 2.60GHz", while the hosts that don't show the problem
>>> use the prior revision, "Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz".
Can you do "grep . /sys/module/kvm_intel/parameters/*" on both hosts please?
Paolo
------------------------------
Message: 5
Date: Mon, 16 Jun 2014 10:47:14 -0600
From: John Nielsen <address@hidden>
To: Paolo Bonzini <address@hidden>
Cc: address@hidden, address@hidden
Subject: Re: [Qemu-discuss] Hang on reboot in FreeBSD guest on Linux
KVM host
Message-ID: <address@hidden>
Content-Type: text/plain; charset=iso-8859-1
On Jun 16, 2014, at 10:39 AM, Paolo Bonzini <address@hidden> wrote:
> Il 16/06/2014 18:09, John Nielsen ha scritto:
>>>> The only substantial difference on the hardware side is the CPU.
>>>> The hosts where the problem occurs use "Intel(R) Xeon(R) CPU
>>>> E5-2650 v2 @ 2.60GHz", while the hosts that don't show the problem
>>>> use the prior revision, "Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz".
>
> Can you do "grep . /sys/module/kvm_intel/parameters/*" on both hosts please?
No differences that I can see. Output below.
Working host:
Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz # grep .
/sys/module/kvm_intel/parameters/*
/sys/module/kvm_intel/parameters/emulate_invalid_guest_state:Y
/sys/module/kvm_intel/parameters/enable_apicv:N
/sys/module/kvm_intel/parameters/enable_shadow_vmcs:N
/sys/module/kvm_intel/parameters/ept:Y
/sys/module/kvm_intel/parameters/eptad:N
/sys/module/kvm_intel/parameters/fasteoi:Y
/sys/module/kvm_intel/parameters/flexpriority:Y
/sys/module/kvm_intel/parameters/nested:N
/sys/module/kvm_intel/parameters/ple_gap:128
/sys/module/kvm_intel/parameters/ple_window:4096
/sys/module/kvm_intel/parameters/unrestricted_guest:Y
/sys/module/kvm_intel/parameters/vmm_exclusive:Y
/sys/module/kvm_intel/parameters/vpid:Y
Problem host:
Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz # grep .
/sys/module/kvm_intel/parameters/*
/sys/module/kvm_intel/parameters/emulate_invalid_guest_state:Y
/sys/module/kvm_intel/parameters/enable_apicv:Y
/sys/module/kvm_intel/parameters/enable_shadow_vmcs:N
/sys/module/kvm_intel/parameters/ept:Y
/sys/module/kvm_intel/parameters/eptad:N
/sys/module/kvm_intel/parameters/fasteoi:Y
/sys/module/kvm_intel/parameters/flexpriority:Y
/sys/module/kvm_intel/parameters/nested:N
/sys/module/kvm_intel/parameters/ple_gap:128
/sys/module/kvm_intel/parameters/ple_window:4096
/sys/module/kvm_intel/parameters/unrestricted_guest:Y
/sys/module/kvm_intel/parameters/vmm_exclusive:Y
/sys/module/kvm_intel/parameters/vpid:Y
------------------------------
Message: 6
Date: Mon, 16 Jun 2014 21:03:43 +0400
From: "Matwey V. Kornilov" <address@hidden>
To: Peter Maydell <address@hidden>
Cc: "Dale R. Worley" <address@hidden>, qemu-discuss
<address@hidden>
Subject: Re: [Qemu-discuss] qemu -kernel u-boot.bin
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
2014-06-16 20:32 GMT+04:00 Peter Maydell <address@hidden>:
> On 13 June 2014 09:50, Matwey V. Kornilov <address@hidden> wrote:
>> I am stuck here. I've put u-boot binary on the 0 of flash.bin (which
>> is 67108864 bytes long), and run following
>>
>> qemu-system-arm -M vexpress-a9 -pflash pflash.bin -S -s
>>
>> I have no warnings, but when I attach with gdb I either don't see my
>> code, and nothing happens again, execution just goes successively
>> until 0x04000000 reached.
>
> Hmm. Are you running a reasonably recent QEMU? I forget exactly when
> we put the pflash device into the vexpress board model.
Now I am trying master:
qemu-system-arm -M vexpress-a9 -pflash pflash.bin
The same. When I try to use gdb, and layout asm, it says that [ No Assembly
Available ], when I run it just increments PC forever.
--
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp:address@hidden
------------------------------
Message: 7
Date: Tue, 17 Jun 2014 09:44:01 +0200
From: Pavel Troller <address@hidden>
To: address@hidden
Cc: address@hidden
Subject: [Qemu-discuss] Using multiple network interfaces on a guest
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
Hi!
I have a strange problem. I need to run a guest with two separate network
cards. On the host, their tap ends are connected to two separate bridges.
It's on qemu-2.0.0. Related part of the command line looks like this:
qemu-system-x86_64...
...-net nic,model=virtio,macaddr=xx-xx-xx-xx-xx-xx -net tap,ifname=alpha-tap..
...-net nic,model=virtio,macaddr=yy-yy-yy-yy-yy-yy -net tap,ifname=bravo-tap..
They are incorporated to the bridges on the host:
address@hidden:# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.300bff486546 no eth1
delta-tap
bravo-tap
echo-tap
br1 8000.bc03d650794a no eth0
alpha-tap
The br1 bridge is anonymous one, it doesn't have an IP address and serves just
to bridge the traffic from the guest to a dedicated physical card (eth0).
delta-tap and echo-tap come from another guests. The br1 bridge never contains
more interfaces.
On the guest, there is no bridging between its virtual nics. Every one has its
own IP address and some set of routes, there is just one default route,
leading to the dedicated network card on the host. But NO BRIDGING. There is
no bridge interface activated at all.
And now, to the problem: Immediately after bringing the guest up and adding
its interfaces to the appropriate bridges, it starts to bridge them together!
All the traffic (including arp queries, DHCP transactions etc.) visible on
br0 starts to be visible on br1 and vice versa. It makes a lot of serious
network problems - confused ARP tables, unstable routing, even forwarding
the local DHCP server (coming from delta-tap on br0) to the dedicated card
(eth0) on br1, etc. Bringing either alpha-tap or bravo-tap down stops the
bridging, bringing them up starts it again. Bringing down the virtual nics
on the guest DOESN'T stop the bridging at all.
I can't understand, why this happens. How to prevent the bridging ? Is it
a feature of tap interfaces, that all ones are automatically bridged together?
Or is it a qemu bug ? I'm really confused and a lot of hours spent by
searching the problem on the net didn't bring anything useful, it seems that
nobody ever tried more virtual nics on one guest.
Sorry for such a long post. Any useful reply will be highly appreciated.
With regards,
Pavel
------------------------------
Message: 8
Date: Tue, 17 Jun 2014 06:21:23 +0200
From: Paolo Bonzini <address@hidden>
To: John Nielsen <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Qemu-discuss] Hang on reboot in FreeBSD guest on Linux
KVM host
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Il 16/06/2014 18:47, John Nielsen ha scritto:
> On Jun 16, 2014, at 10:39 AM, Paolo Bonzini <address@hidden> wrote:
>
>> Il 16/06/2014 18:09, John Nielsen ha scritto:
>>>>> The only substantial difference on the hardware side is the CPU.
>>>>> The hosts where the problem occurs use "Intel(R) Xeon(R) CPU
>>>>> E5-2650 v2 @ 2.60GHz", while the hosts that don't show the
>>>>> problem use the prior revision, "Intel(R) Xeon(R) CPU E5-2650 0 @
>>>>> 2.00GHz".
>>
>> Can you do "grep . /sys/module/kvm_intel/parameters/*" on both hosts please?
>
> No differences that I can see. Output below.
Not really:
> Working host:
> Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
> # grep . /sys/module/kvm_intel/parameters/*
> /sys/module/kvm_intel/parameters/enable_apicv:N
>
> Problem host:
> Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
> # grep . /sys/module/kvm_intel/parameters/*
> /sys/module/kvm_intel/parameters/enable_apicv:Y
So we have a clue. Let me study the code more, I'll try to get back
with a suggestion.
In the meanwhile, I'm CCing the KVM list and BCCing QEMU, so that
follow-ups come to the KVM list.
Paolo
------------------------------
_______________________________________________
Qemu-discuss mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/qemu-discuss
End of Qemu-discuss Digest, Vol 33, Issue 18
********************************************