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

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



> > 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.

It should be able to read the MAC from xenstore. This must be a bug.

> > > 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.

Hang on, you mean within the guest you don't see it sending a reply? If
true, that must be a guest issue and its hard to see how doing anything
in dom0 will help.

 
> 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.

That sounds like a symptom of the block devices being wedged. Are you
using a PV block device or emulated IDE?

Ian

> 
> 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. /vm/73c84d4e-220c-5e88-5cf4-
> 2786f4ce5a44/vncpasswd.
> 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
> xs_write(/vm/73c84d4e-220c-5e88-5cf4-2786f4ce5a44/rtc/timeoffset,
> 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 behavior.
> 
> >
> > 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
> ryanh@xxxxxxxxxx

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.