WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] PCI passthrough issue

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] PCI passthrough issue
From: Jean Baptiste Favre <xen-devel@xxxxxxxxxxx>
Date: Fri, 04 Feb 2011 12:25:06 +0100
Delivery-date: Fri, 04 Feb 2011 03:25:43 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1296817460.13091.646.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D47F9CF.2040107@xxxxxxxxxxx> <1296566401.13091.171.camel@xxxxxxxxxxxxxxxxxxxxxx> <4D4814CE.5050303@xxxxxxxxxxx> <1296569931.13091.194.camel@xxxxxxxxxxxxxxxxxxxxxx> <4D48234F.2020907@xxxxxxxxxxx> <4D4828D9.6090601@xxxxxxxxxxx> <1296577389.13091.288.camel@xxxxxxxxxxxxxxxxxxxxxx> <4D488355.8010706@xxxxxxxxxxx> <1296638873.13091.315.camel@xxxxxxxxxxxxxxxxxxxxxx> <4D4930F3.608@xxxxxxxxxxx> <20110202174250.GA8148@xxxxxxxxxxxx> <4D4BBC15.4080201@xxxxxxxxxxx> <1296809586.13091.546.camel@xxxxxxxxxxxxxxxxxxxxxx> <4D4BBEC6.8070809@xxxxxxxxxxx> <4D4BD121.2080505@xxxxxxxxxxx> <1296817460.13091.646.camel@xxxxxxxxxxxxxxxxxxxxxx>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
Hello,

Le 04/02/2011 12:04, Ian Campbell a écrit :
> On Fri, 2011-02-04 at 10:12 +0000, Jean Baptiste Favre wrote:
>> Hello Ian,
>> Applyed your patches.
> 
> Thanks.
> 
>> 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 patch
>> bellow
> 
> Interesting. the number printed in the warning is type == skb->protocol
> == 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 valid
> Ethernet frame length (min 64) so it's not that sort of confusion
> AFAICT.
> 
> 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.
> 
> 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=0 ttl=64 time=10.455 ms
64 bytes from 10.0.0.1: seq=1 ttl=64 time=0.870 ms
^C
--- 10.0.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 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


> 
> Please can you post the output of "ethtool -k <sky2-device>".
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 disabling
> them ("ethtool -K <sky2-device> [tx|rx] off"). This setting controls the
> 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.
> 
> The following patch enhances the previous one with a few checks for
> protocol 0x20 getting set.
> 
> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>