From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean Baptiste Favre Subject: Re: PCI passthrough issue Date: Fri, 04 Feb 2011 12:25:06 +0100 Message-ID: <4D4BE212.1090400@jbfavre.org> References: <4D47F9CF.2040107@jbfavre.org> <1296566401.13091.171.camel@zakaz.uk.xensource.com> <4D4814CE.5050303@jbfavre.org> <1296569931.13091.194.camel@zakaz.uk.xensource.com> <4D48234F.2020907@jbfavre.org> <4D4828D9.6090601@jbfavre.org> <1296577389.13091.288.camel@zakaz.uk.xensource.com> <4D488355.8010706@jbfavre.org> <1296638873.13091.315.camel@zakaz.uk.xensource.com> <4D4930F3.608@jbfavre.org> <20110202174250.GA8148@dumpdata.com> <4D4BBC15.4080201@jbfavre.org> <1296809586.13091.546.camel@zakaz.uk.xensource.com> <4D4BBEC6.8070809@jbfavre.org> <4D4BD121.2080505@jbfavre.org> <1296817460.13091.646.camel@zakaz.uk.xensource.com> Reply-To: xen-devel@lists.xensource.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1296817460.13091.646.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Hello, Le 04/02/2011 12:04, Ian Campbell a =C3=A9crit : > On Fri, 2011-02-04 at 10:12 +0000, Jean Baptiste Favre wrote: >> Hello Ian, >> Applyed your patches. >=20 > Thanks. >=20 >> Now, I've: >> # ping -s86 10.0.0.1 >> PING 10.0.0.1 (10.0.0.1): 86 data bytes >> __netif_receive_skb dropping skb proto 0x20 >> >> >> So problem seems to occur in net/core/dev.c file, according to the pat= ch >> bellow >=20 > Interesting. the number printed in the warning is type =3D=3D skb->prot= ocol > =3D=3D 0x20 which is not a valid protocol that I can find anywhere (nor= is > 0x2000 in case I'm mixing my endianesses up). Neither is 0x20 it a vali= d > Ethernet frame length (min 64) so it's not that sort of confusion > AFAICT. >=20 > skb->protocol is initialised in sky2_status_intr with the return value > of "eth_type_trans(skb, dev)" which as far as I can tell cannot return > 0x20. >=20 > The domU network configuration is using the sky2 device directly, no > bridging, VLAN, tunnels or anything else like that? At boot it uses bridge. For the test, I delete bridge and set IP address directly on eth0 root@OpenWrt:/# ifconfig br-lan down br-lan: port 1(eth0) entering forwarding state root@OpenWrt:/# brctl delbr br-lan device eth0 left promiscuous mode br-lan: port 1(eth0) entering disabled state root@OpenWrt:/# ifconfig eth0 10.0.0.8 netmask 255.255.255.0 root@OpenWrt:/# ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: seq=3D0 ttl=3D64 time=3D10.455 ms 64 bytes from 10.0.0.1: seq=3D1 ttl=3D64 time=3D0.870 ms ^C --- 10.0.0.1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max =3D 0.870/5.662/10.455 ms root@OpenWrt:/# ping -s86 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 86 data bytes ^C --- 10.0.0.1 ping statistics --- 12 packets transmitted, 0 packets received, 100% packet loss >=20 > Please can you post the output of "ethtool -k ". root@OpenWrt:/# ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off ntuple-filters: off receive-hashing: on > If either tx or rx checksumming are enabled please can you try disablin= g > them ("ethtool -K [tx|rx] off"). This setting controls th= e > code path in sky2_skb_rx which can go either to netif_receive_skb or > napi_gro_receive. root@OpenWrt:/# ethtool -K eth0 tx off root@OpenWrt:/# ethtool -K eth0 rx off root@OpenWrt:/# ping -s86 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 86 data bytes ^C --- 10.0.0.1 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss root@OpenWrt:/# ethtool -k eth0 Offload parameters for eth0: rx-checksumming: off tx-checksumming: off scatter-gather: off tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: off large-receive-offload: off ntuple-filters: off receive-hashing: on > The tcpdump captures from both ends would still be interesting to see. >=20 > The following patch enhances the previous one with a few checks for > protocol 0x20 getting set. >=20 > Ian. What is a bit strange here is that I don't any more the KERN_CRIT printk message. Could be a false positive ? I'm currently compiling new kernel with your last patch. will keep you updated Regards, JB