Hi. Sorry for the slow follow-up.
Stefan Hajnoczi writes:
> Yes, it's odd that QEMU changes make the issue go away but tcpdump
> suggests the packet is not being sent from the bridge to the tap
> device.
Indeed. I really don't understand how to the two could possible interact!
> e1000 and rtl8
On Thu, Apr 12, 2012 at 10:37 AM, Chris Webb wrote:
> Stefan Hajnoczi writes:
>
>> On Tue, Apr 3, 2012 at 5:37 PM, Chris Webb wrote:
>> > Stefan Hajnoczi writes:
>> >
>> >
>> >> >> Are you sure no other guest has the same MAC address or IP address?
>> >> >> This weird behavior sounds similar to
Stefan Hajnoczi writes:
> On Tue, Apr 3, 2012 at 5:37 PM, Chris Webb wrote:
> > Stefan Hajnoczi 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 netw
On Tue, Apr 3, 2012 at 5:37 PM, Chris Webb wrote:
> Stefan Hajnoczi 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
Stefan Hajnoczi 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
On Tue, Apr 3, 2012 at 2:41 PM, Chris Webb wrote:
> Stefan Hajnoczi writes:
>
>> No, that's weird. I would have simply tried "b start_xmit" and as
>> long as the binary has symbols gdb would know what to do.
>
> I'll get another one and give it a go. There wasn't any particular reason I
> gave a
On Tue, Apr 3, 2012 at 1:42 PM, Chris Webb wrote:
> Stefan Hajnoczi writes:
>
>> In a case like this it might be most effective to catch a VM in the
>> bad state and then go in with gdb to see what is broken. The basic
>> approach would be putting breakpoints on the e1000 device model's
>> trans
Stefan Hajnoczi writes:
> No, that's weird. I would have simply tried "b start_xmit" and as
> long as the binary has symbols gdb would know what to do.
I'll get another one and give it a go. There wasn't any particular reason I
gave a line number rather than a function except that I worried the
Stefan Hajnoczi writes:
> In a case like this it might be most effective to catch a VM in the
> bad state and then go in with gdb to see what is broken. The basic
> approach would be putting breakpoints on the e1000 device model's
> transmit/receive paths to see if the guest is giving us packets
On Tue, Apr 3, 2012 at 9:13 AM, Chris Webb wrote:
> Stefan Hajnoczi writes:
>> On Mon, Apr 02, 2012 at 04:37:23PM +0100, Chris Webb wrote:
>> It sounds like this is not the issue, but are you sure the bridge has
>> forwarding delay set to 0 or Spanning Tree Protocol disabled? With STP
>> enabled
Stefan Hajnoczi writes:
> On Mon, Apr 02, 2012 at 04:37:23PM +0100, Chris Webb wrote:
> > We initially saw a problem after an upgrade from 0.15.x to 1.0.
>
> Perhaps git-bisect(1) can help you track down the change that introduced
> this between 0.15 and 1.0.
Hi. I attempted this, but the bug i
On Mon, Apr 02, 2012 at 04:37:23PM +0100, Chris Webb wrote:
> We initially saw a problem after an upgrade from 0.15.x to 1.0.
Perhaps git-bisect(1) can help you track down the change that introduced
this between 0.15 and 1.0.
> Once I've got a guest with broken networking, the network stays down
I have an interesting bug with the e1000 emulation in qemu-kvm 1.0. I've
spent a bit of time trying to track it down, but the behaviour is
sufficiently odd that I'm rather baffled.
The public networking on our VMs consists of a bridge to which the physical
nic is enslaved, a tap interface created
13 matches
Mail list logo
