Well you are definitely still seeing large packets... maybe disable tso
too? Also disable rx and tx checksumming.
James
> Hi James
> Thanks for the detailed instructions.
> There are 2 VMs that use this bridge (2000 svr and xp sp2), but it
makes
> no difference to the bsod if 1 or both are running. With
> both running the xp tap is tap1, otherwise it's tap0.
> When I do the tcdump it shows only packets that seem to relate to the
ssh
> session to DOM0 (The ssh port is 22716, DOM0 is
> 192.168.20.7 and machine I am ssh from is 192.168.20.30), then it
bsods.
> Before the bsod there is some double size packets. (Even
> though I have disabled gso on all interfaces, bridges and otherwise),
but
> not directly prior to the bsod. So at this stage I am not
> sure if I'm down the garden path or still on the verandah. :-)
> The physical interface that the packets run on is eth1. I am a little
> confused as to why the ssh packets also show up on the tap1
> interface as there is no ssh connection to the DOMU, only DOM0.
> Thanks. The dump is below:
>
------------------------------------------------------------------------
--
> -
> # tcpdump -i tap0 greater 1500
> tcpdump: WARNING: tap0: no IPv4 address assigned
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
> listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
> 20:44:42.183259 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 2964273857:2964275317(1460) ack 3005185253 win 545
> 20:44:43.626964 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 7296:8756(1460) ack 417 win 545
> 20:44:43.626980 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 8756:10216(1460) ack 417 win 545
> 20:44:44.266984 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 12784:15704(2920) ack 449 win 545
> 20:44:45.225979 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 16912:18372(1460) ack 449 win 545
> 20:44:46.178139 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 20272:21732(1460) ack 449 win 545
> 20:44:46.576267 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 23824:25284(1460) ack 529 win 545
> 20:44:46.577062 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 25888:27348(1460) ack 529 win 545
> 20:44:46.585779 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 27348:28808(1460) ack 529 win 545
> 20:44:47.178179 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 30160:33080(2920) ack 609 win 545
> 20:44:47.885066 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 35712:37172(1460) ack 609 win 545
> 20:44:47.885997 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 37776:39236(1460) ack 609 win 545
> 20:44:47.893317 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 39236:40696(1460) ack 609 win 545
> 20:44:48.182306 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 41520:44440(2920) ack 641 win 545
> 20:44:48.182329 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: P
> 44440:45888(1448) ack 641 win 545
> 20:44:48.191866 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 47248:48708(1460) ack 641 win 545
> 20:44:48.234170 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 50192:51652(1460) ack 721 win 545
> 20:44:48.407627 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 52912:54372(1460) ack 721 win 545
> 20:44:48.408410 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 54960:56420(1460) ack 721 win 545
> 20:44:48.409493 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 56800:58260(1460) ack 721 win 545
> 20:44:48.571215 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 58608:60068(1460) ack 753 win 545
> 20:44:48.600938 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 60496:61956(1460) ack 801 win 545
> 20:44:48.601814 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 62336:63796(1460) ack 801 win 545
> 20:44:48.715526 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 64384:65844(1460) ack 801 win 545
> 20:44:48.716277 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 66416:67876(1460) ack 801 win 545
> 20:44:48.717355 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 68256:69716(1460) ack 801 win 545
> 20:44:49.182112 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 70304:73224(2920) ack 833 win 545
> 20:44:49.182136 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 73224:74684(1460) ack 833 win 545
> 20:44:50.182639 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 76720:78180(1460) ack 833 win 545
> 20:44:50.182659 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 78180:79640(1460) ack 833 win 545
> 20:44:50.188947 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
> 79872:81332(1460) ack 833 win 545
> tcpdump: pcap_loop: recvfrom: Network is down
> 31 packets captured
> 66 packets received by filter
> 0 packets dropped by kernel
> [root@catss3 vm]# Traceback (most recent call last):
> File "/usr/share/virt-manager/virtManager/console.py", line 202, in
> _vnc_disconnected
> self.try_login()
> File "/usr/share/virt-manager/virtManager/console.py", line 217, in
> try_login
> protocol, host, port = self.vm.get_graphics_console()
> File "/usr/share/virt-manager/virtManager/domain.py", line 447, in
> get_graphics_console
> type = self.get_xml_string("/domain/devices/graphics/@type")
> File "/usr/share/virt-manager/virtManager/domain.py", line 417, in
> get_xml_string
> xml = self.get_xml()
> File "/usr/share/virt-manager/virtManager/domain.py", line 51, in
> get_xml
> self.xml = self.vm.XMLDesc(0)
> File "/usr/lib64/python2.4/site-packages/libvirt.py", line 196, in
> XMLDesc
> if ret is None: raise libvirtError ('virDomainGetXMLDesc()
failed',
> dom=self)
> libvirt.libvirtError: virDomainGetXMLDesc() failed
>
------------------------------------------------------------------------
--
> --------
> -----Original Message-----
> From: James Harper [mailto:james.harper@xxxxxxxxxxxxxxxx]
> Sent: Tuesday, 25 March 2008 5:55 PM
> To: xensource.2007@xxxxxxxxxxxxxxxxx; xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-users] Xen Windows Clients - BSOD
> withApplicationFirewallInstalls
>
>
> I think you'll need to figure out what interface is launching these
> packets onto your network, but in the meantime just turn of gso
> on all interfaces attached to the bridge - do a 'brctl show' to get a
list
> of them.
>
> If you are still getting BSoD's after doing that, do a tcpdump on the
tapX
> device belonging to your windows HVM domain, and see if a
> large packet coincides with your BSoD. If it doesn't, then I've
probably
> lead you down the wrong path.
>
> It might be easiest to do that second step first:
> . brctl show
> . create your domain in a paused state
> . brctl show
> . start a tcpdump on your tapX interface (eg the one that wasn't there
in
> the first brctl show but is in the second). If this is
> your only hvm domain then you can skip this and just assume tap0
>
> The syntax you want for your tcpdump is probably something like
'tcpdump -
> i tapX greater 1500', which should be fired whenever a
> packet is >1500 bytes.
>
> James
>
> > -----Original Message-----
> > From: DoNotReply [mailto:DoNotReply@xxxxxxxxxxxxxxxxx] On Behalf Of
> > xensource.2007@xxxxxxxxxxxxxxxxx
> > Sent: Tuesday, 25 March 2008 18:36
> > To: James Harper; xensource.2007@xxxxxxxxxxxxxxxxx; xen-
> > users@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Xen-users] Xen Windows Clients - BSOD
> > withApplicationFirewallInstalls
> >
> > Thanks James
> > But it makes no dif. Am I applying it to the correct interface
> (xenbr1)?
> >
> >
> > -----Original Message-----
> > From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-users-
> > bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of James Harper
> > Sent: Monday, 24 March 2008 6:49 PM
> > To: xensource.2007@xxxxxxxxxxxxxxxxx; Rudi Ahlers; xen-
> > users@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Xen-users] Xen Windows Clients - BSOD
> > withApplicationFirewallInstalls
> >
> >
> > > 6) At firewall startup, BSOD
> > > 7) Subsequent restarts result in BSOD as previously stated.
> >
> > Xen appears to be sending 'large' packets onto the bridge, and the
tap
> > interface isn't 'un-large-ing' them.
> >
> > "
> > 20:40:34.437312 IP (tos 0x0, ttl 128, id 34470, offset 0, flags
[DF],
> > proto: TCP (6), length: 52) 192.168.207.200.5001 >
> > 192.168.207.254.53981: ., cksum 0x05aa (correct), 1:1(0) ack 14505
win
> > 58295 <nop,nop,timestamp 57828874 1445680997> 20:40:34.437324 IP
(tos
> > 0x0, ttl 64, id 51510, offset 0, flags [DF],
> > proto: TCP (6), length: 4396) 192.168.207.254.53981 >
> > 192.168.207.200.5001: . 23193:27537(4344) ack 1 win 46
> <nop,nop,timestamp
> > 1445680998 57828874> 20:40:34.439653 IP (tos 0x0, ttl 128,
> > id 34471, offset 0, flags [DF],
> > proto: TCP (6), length: 64) 192.168.207.200.5001 >
> > 192.168.207.254.53981: ., cksum 0x2a79 (correct), 1:1(0) ack 15953
win
> > 56847 <nop,nop,timestamp 57828874 1445680997,nop,nop,sack 1
> > {17401:18849}> 20:40:34.439670 IP (tos 0x0, ttl 64, id 51513,
offset
> 0,
> > flags [DF],
> > proto: TCP (6), length: 4396) 192.168.207.254.53981 >
> > 192.168.207.200.5001: . 27537:31881(4344) ack 1 win 46
> <nop,nop,timestamp
> > 1445680999 57828874> "
> >
> > Note the lengh of 4396 - the hardware interface is supposed to break
> that
> > up into MSS sized chunks, but there is no hardware
> > interface involved in this case.
> >
> > I'm trying to resolve the problem in the GPL PV drivers.
> >
> > I've had wireshark (npf.sys) BSOD when it receives a packet with a
> size
> > greater than MTU, so I imagine a firewall may well do the same
thing.
> >
> > Try turning off large send offload for all interfaces on the bridge
> (the
> > same bridge as your crashing DomU), eg:
> >
> > "
> > ethtool -K <ifname> gso off
> > "
> >
> > Iperf gives horrible results too when DomU is the 'server' and Dom0
is
> the
> > 'client' because of this.
> >
> > James
> >
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
> >
> > No virus found in this incoming message.
> > Checked by AVG.
> > Version: 7.5.519 / Virus Database: 269.22.0/1341 - Release Date:
> > 24/03/2008 3:03 PM
> >
> > No virus found in this outgoing message.
> > Checked by AVG.
> > Version: 7.5.519 / Virus Database: 269.22.0/1341 - Release Date:
> > 24/03/2008 3:03 PM
> >
> >
>
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.22.0/1341 - Release Date:
> 24/03/2008 3:03 PM
>
> No virus found in this outgoing message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.22.0/1341 - Release Date:
> 24/03/2008 3:03 PM
>
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home