[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |