Hi James, I''ve just updated my Opensolaris installation to the latest build available (snv_106), and want to test GPLPV on it again. David Edmondson from Sun also has expressed his interest in helping to get GPLPV working on Opensolaris dom0 http://opensolaris.org/jive/thread.jspa?messageID=335550 So here goes. As it stands right now : - driver installation is succesful - boot with /NOGPLV both disk and network works correctly. - boot WITHOUT /NOGPLV disk driver works correctly. Network icon shows connected, but no traffic is getting through. Here''s what I get from tcpdump on dom0 during a ping test from domU # tcpdump -n -i bnx0 src or dst 192.168.129.1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bnx0, link-type EN10MB (Ethernet), capture size 96 bytes 17:28:43.080609 arp who-has 192.168.129.1 tell 192.168.129.99 17:28:43.081106 arp reply 192.168.129.1 is-at 00:16:3e:df:d5:c0 17:28:48.480171 arp who-has 192.168.129.1 tell 192.168.129.99 17:28:48.480607 arp reply 192.168.129.1 is-at 00:16:3e:df:d5:c0 192.168.129.99 is domU''s ip address, 192.168.129.1 is the router, bnx0 is physical interface on dom0. Both arp request and reply passes through dom0 just fine, but it seems that domU isn''t getting the arp reply. Any ideas on how to get this working? Regards, Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Hi James, > > I''ve just updated my Opensolaris installation to the latest build > available (snv_106), and want to test GPLPV on it again. David > Edmondson from Sun also has expressed his interest in helping to get > GPLPV working on Opensolaris dom0 > > http://opensolaris.org/jive/thread.jspa?messageID=335550 > > So here goes. As it stands right now : > - driver installation is succesful > - boot with /NOGPLV both disk and network works correctly. > - boot WITHOUT /NOGPLV disk driver works correctly. Network icon shows > connected, but no traffic is getting through. > > Here''s what I get from tcpdump on dom0 during a ping test from domU > > # tcpdump -n -i bnx0 src or dst 192.168.129.1 > tcpdump: verbose output suppressed, use -v or -vv for full protocoldecode> listening on bnx0, link-type EN10MB (Ethernet), capture size 96 bytes > 17:28:43.080609 arp who-has 192.168.129.1 tell 192.168.129.99 > 17:28:43.081106 arp reply 192.168.129.1 is-at 00:16:3e:df:d5:c0 > 17:28:48.480171 arp who-has 192.168.129.1 tell 192.168.129.99 > 17:28:48.480607 arp reply 192.168.129.1 is-at 00:16:3e:df:d5:c0 > > 192.168.129.99 is domU''s ip address, 192.168.129.1 is the router, bnx0 > is physical interface on dom0. Both arp request and reply passes > through dom0 just fine, but it seems that domU isn''t getting the arp > reply. > > Any ideas on how to get this working? >That seems to be working a bit better than last time, I think the network never even connected. Can you try disabling all offloads in Windows (checksum and large send)? Also try running wireshark or another traffic capture routine and see what that picks up. It could be getting corrupt packets or no packets at all. There could maybe be something wrong with broadcast packets... try adding an arp entry manually in Dom0 for DomU and then try pinging it. James _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sat, Feb 7, 2009 at 5:09 AM, James Harper <james.harper@bendigoit.com.au> wrote:> Can you try disabling all offloads in Windows (checksum and large send)?No effect. Same thing happens.> > Also try running wireshark or another traffic capture routine and see > what that picks up. It could be getting corrupt packets or no packets at > all. > > There could maybe be something wrong with broadcast packets... try > adding an arp entry manually in Dom0 for DomU and then try pinging it. >After adding static arp, wireshark on domU shows it sends ICMP echo packets but doesn''t receive anything (not even corrupted packets). tcpdump on dom0 shows something interesting though. 05:58:02.333904 IP (tos 0x0, ttl 128, id 41, offset 0, flags [none], proto: ICMP (1), length: 60) 192.168.129.99 > 192.168.129.89: ICMP echo request, id 512, seq 1280, length 40 05:58:02.334044 IP (tos 0x0, ttl 255, id 64313, offset 0, flags [DF], proto: ICMP (1), length: 60) 192.168.129.89 > 192.168.129.99: ICMP echo reply, id 512, seq 1280, length 40 the ICMP reply (which domU never got) has [DF] flag. Is this normal? Is this MTU-related issue? Regards, Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> > > > Also try running wireshark or another traffic capture routine andsee> > what that picks up. It could be getting corrupt packets or nopackets at> > all. > > > > There could maybe be something wrong with broadcast packets... try > > adding an arp entry manually in Dom0 for DomU and then try pingingit.> > > > After adding static arp, wireshark on domU shows it sends ICMP echo > packets but doesn''t receive anything (not even corrupted packets). > tcpdump on dom0 shows something interesting though. > > 05:58:02.333904 IP (tos 0x0, ttl 128, id 41, offset 0, flags [none], > proto: ICMP (1), length: 60) 192.168.129.99 > 192.168.129.89: ICMP > echo request, id 512, seq 1280, length 40 > 05:58:02.334044 IP (tos 0x0, ttl 255, id 64313, offset 0, flags [DF], > proto: ICMP (1), length: 60) 192.168.129.89 > 192.168.129.99: ICMP > echo reply, id 512, seq 1280, length 40 > > the ICMP reply (which domU never got) has [DF] flag. Is this normal? > Is this MTU-related issue? >I thought windows only asserted DF when you used the ''-f'' flag, but with a length of 60 bytes it won''t be an MTU issue. It could be that the interrupts are never getting called... which version of GPLPV are you running? Could you try the very latest version - 0.9.12-pre15-dont-use.exe? That one is definitely not suitable for production use but it does contain a few changes in the network. Also, if it is an interrupt issue, there should be a total of <256 that will be sent before the queue fills up and no more can be sent. Can you send 256 ping packets from Windows to Dom0 and then see if Dom0 receives more after that? James _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sat, Feb 7, 2009 at 6:36 AM, James Harper <james.harper@bendigoit.com.au> wrote:> It could be that the interrupts are never getting called... which > version of GPLPV are you running?0.9.12-pre15> Could you try the very latest version > - 0.9.12-pre15-dont-use.exe? That one is definitely not suitable for > production use but it does contain a few changes in the network. >Tried that. Same result.> Also, if it is an interrupt issue, there should be a total of <256 that > will be sent before the queue fills up and no more can be sent. Can you > send 256 ping packets from Windows to Dom0 and then see if Dom0 receives > more after that?What do you mean by "dom0 receive more" ? I tried ping -n 260 -w 250 192.168.129.89. Where 192.168.129.89 is dom0 IP address If you mean "can dom0 receive (and reply) all 260 ping packets", then yes, it can. None of the replies got to domU though. Same result on domU side (wireshark only showed ICMP echo request packets, and dom0 showed this (last few lines only): 19:48:46.120445 IP (tos 0x0, ttl 128, id 287, offset 0, flags [none], proto: ICMP (1), length: 60) 192.168.129.99 > 192.168.129.89: ICMP echo request, id 512, seq 769, length 40 19:48:46.120506 IP (tos 0x0, ttl 255, id 55202, offset 0, flags [DF], proto: ICMP (1), length: 60) 192.168.129.89 > 192.168.129.99: ICMP echo reply, id 512, seq 769, length 40 19:48:47.622604 IP (tos 0x0, ttl 128, id 288, offset 0, flags [none], proto: ICMP (1), length: 60) 192.168.129.99 > 192.168.129.89: ICMP echo request, id 512, seq 1025, length 40 19:48:47.622664 IP (tos 0x0, ttl 255, id 55203, offset 0, flags [DF], proto: ICMP (1), length: 60) 192.168.129.89 > 192.168.129.99: ICMP echo reply, id 512, seq 1025, length 40 I attached xenstore-ls output of the domU. if I remembered correctly you mentioned a long time ago that it might help find out what the problem is. Regards, Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sat, Feb 7, 2009 at 8:07 PM, Fajar A. Nugraha <fajar@fajar.net> wrote:> On Sat, Feb 7, 2009 at 6:36 AM, James Harper > <james.harper@bendigoit.com.au> wrote: >> It could be that the interrupts are never getting called... which >> version of GPLPV are you running? > > 0.9.12-pre15Sorry, a little typo. Should''ve read 0.9.12-pre13. As you suggested though, I installed 0.9.12-pre15-dont-use with the same result. The rest of my email above is from 0.9.12-pre15-dont-use Regards, Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> On Sat, Feb 7, 2009 at 6:36 AM, James Harper > <james.harper@bendigoit.com.au> wrote: > > It could be that the interrupts are never getting called... which > > version of GPLPV are you running? > > 0.9.12-pre15 > > > Could you try the very latest version > > - 0.9.12-pre15-dont-use.exe? That one is definitely not suitable for > > production use but it does contain a few changes in the network. > > > > Tried that. Same result. > > > Also, if it is an interrupt issue, there should be a total of <256that> > will be sent before the queue fills up and no more can be sent. Canyou> > send 256 ping packets from Windows to Dom0 and then see if Dom0receives> > more after that? > > What do you mean by "dom0 receive more" ? > I tried > > ping -n 260 -w 250 192.168.129.89. > > Where 192.168.129.89 is dom0 IP address > If you mean "can dom0 receive (and reply) all 260 ping packets", then > yes, it can. None of the replies got to domU though. > > Same result on domU side (wireshark only showed ICMP echo request > packets, and dom0 showed this (last few lines only): >Can you also run DebugView from sysinternals and just see if that shows anything up? Are you able to build gplpv from source? If so I''ll get you to put some debug statements into the rx interrupt path. If not, you''ll have to wait until I''ve gotten the wdf conversion done. shouldn''t be too long. James _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sat, Feb 7, 2009 at 8:13 PM, James Harper <james.harper@bendigoit.com.au> wrote:> > Can you also run DebugView from sysinternals and just see if that shows > anything up?Should be possible. Any particular instruction on what and when to capture?> > Are you able to build gplpv from source?Unfortunately no.> If so I''ll get you to put some > debug statements into the rx interrupt path. If not, you''ll have to wait > until I''ve gotten the wdf conversion done. shouldn''t be too long.I''ll wait. Thanks for looking into this. Regards, Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> > Should be possible. Any particular instruction on what and when to > capture? >Download it from sysinternals.com and run it. You probably need to tick ''kernel capture'' in one of the menu''s but that should be it. If anything is really wrong you might get a line or two per packet complaining about things, but I''m guessing it probably won''t tell us anything... James _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sat, Feb 7, 2009 at 8:43 PM, James Harper <james.harper@bendigoit.com.au> wrote:> Download it from sysinternals.com and run it. You probably need to tick > ''kernel capture'' in one of the menu''s but that should be it. If anything > is really wrong you might get a line or two per packet complaining about > things, but I''m guessing it probably won''t tell us anything...Hi James, running ping while debugview is running shows nothing. HOWEVER After I try to disable - enable xennet device, the device shows exclamation mark. Attached are debugview output of when that happens. There''s a lot of "00000076 1.00755072 XenPCI Still waiting for 2 (currently 6)..." Maybe that''s where the problem is. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users