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