qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Intermittent e1000 failure on qemu-kvm 1.0


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] Intermittent e1000 failure on qemu-kvm 1.0
Date: Wed, 11 Apr 2012 12:47:05 +0100

On Tue, Apr 3, 2012 at 5:37 PM, Chris Webb <address@hidden> wrote:
> Stefan Hajnoczi <address@hidden> writes:
>
>
>> >> Are you sure no other guest has the same MAC address or IP address?
>> >> This weird behavior sounds similar to what happens when you have
>> >> multiple devices on a network using the same address - the results are
>> >> very confusing :).
>> >
>> > Yes, I agree! However, in this case there's no other guest with the same 
>> > MAC
>> > or IP address on the network. I've explicitly rechecked this to be sure, 
>> > and
>> > also deliberately varied the MAC address to something I know can't be
>> > generated by our scripts. In any case, I'm using the same MAC and IP 
>> > address
>> > for every reboot of this VM, and usually (19 times out of 20) it works 
>> > fine.
>>
>> The lack of ARP reply is a host networking problem.  Have you checked
>> host dmesg(1) output just in case there was a kernel message related
>> to this?
>
> Nothing there I'm afraid. Just the usual
>
>  device tap1 entered promiscuous mode
>  ADDRCONF(NETDEV_UP): tap1: link is not ready
>  ADDRCONF(NETDEV_CHANGE): tap1: link becomes ready
>  br0: port 2(tap1) entering forwarding state
>  br0: port 2(tap1) entering forwarding state
>  kvm: 20288: cpu0 unhandled rdmsr: 0xc0010112
>  kvm: 20288: cpu0 unhandled rdmsr: 0xc0010048
>  tap1: no IPv6 routers present
>  br0: port 2(tap1) entering forwarding state
>  br0: port 2(tap1) entering forwarding state
>  br0: port 2(tap1) entering forwarding state
>  br0: port 2(tap1) entering forwarding state
>  br0: port 2(tap1) entering disabled state
>
> cycle. It looks just the same for a working guest as for a non-working
> guest.

Is the "disabled state" because QEMU exited?

I'm afraid I don't have any suggestions beyond debugging the
bridge->tap code in the kernel since packets are not being forwarded
for some reason.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]