This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] PV on HVM network stops

* Ian Pratt <Ian.Pratt@xxxxxxxxxxxx> [2007-05-09 18:00]:
> > > If I pause the domain and then unpause, networking comes back.  Does
> > > this help narrow down where I should be looking for debugging this
> > > issue?
> > 
> > Actually, what works more reliably is to ifdown vifX.0; and then
> > ifconfig vifX.0 0, which brings it back up, we get bridge topology
> > state changes, and then network traffic resumes.
> Presumably taking the guest interface down makes no difference? (Not
> sure you can unload the module, but have you tried?)

I tried.  It doesn't completely work, I'll get the dmesg output again
for future reference.  Reloading the module didn't help as it set the
device mac add to all nulls.

> > Using tcpdump, I can see traffic arrive in the domain, but no traffic
> > leaves the guest.
> So, packets seem to be received by the guest, but if you tcpdump the
> associated vifX.0 you don't see anything (whereas a tcpdump in the guest
> indicates packets are being sent).

tcpdump on vifX.0 shows traffic on the bridge, arps for the guest ip.
tcpdump in the guest showed it getting the arps, but no reply.  ie, no
outgoing traffic.

I've worked around this issue by cycling the vif in the host.  

What I am seeing now is that sometimes the guest just doesn't seem to be
making progress, no cpu time.  xm console the guest hangs any new
processes don't seem to execute.  For example, I can have a console
session connected and watch networking die, cycle the vif, pings start
working again, and running ps in the guest just blocks.  xm list shows
the guest in the block state.  At this point, the guest is pretty much
dead even though it will continue to process ICMP packets.

There isn't much output in the qemu-dm log file, but I'll toss that in
here to see if it rings any bells:

domid: 5
qemu: the number of cpus is 1
Watching /local/domain/5/logdirty/next-active
qemu_map_cache_init nr_buckets = 4000
shared page at pfn 1ffff
buffered io page at pfn 1fffd
Time offset set 0
xs_read(): vncpasswd get error. 
char device redirected to /dev/pts/3
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Triggered log-dirty buffer switch
rtc/timeoffset): write error

More details: 

Host 32-bit pae, guest 32-bit, 1 vcpu, 512M ram

I've tried running with acpi=0 apic=0, and 1,1 respectively, but no change in 

> One way to debug this would be to add a dom0 sysrq key handler to dump
> the producer consumer pointers, or otherwise export them via sysfs. Does
> cat /proc/interrupts show rx interrupts on the vif?

I'll give these a spin.

Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253

Xen-devel mailing list