Le 04/02/2011 12:28, Ian Campbell a écrit :
> On Fri, 2011-02-04 at 11:25 +0000, Jean Baptiste Favre wrote:
>> 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
>
> OK, good.
>
> [...]
>> generic-segmentation-offload: on
> [...]
>> receive-hashing: on
>
> Can you also try turning these two off (independently and together).
No change with ethtool -K gso off
Can not change receive-hashing:
# ethtool -K eth1 rxhash off
Cannot set device flag settings: Invalid argument
>> What is a bit strange here is that I don't any more the KERN_CRIT printk
>> message.
>> Could be a false positive ?
>
> Worth bearing in mind, lets see what the next test run produces.
Seems that I got this messge only with copybreak=0.
With default value (128), no such message
More, with copybreak=0, all packets are dropped (even a ping with
default packet size is dropped. Same with ping -s1)
>> I'm currently compiling new kernel with your last patch. will keep you
>> updated
No new messages, despite your patch :(
> Thanks.
>
> Please gather the tcpdump's too.
Both tcpdump from GW and domU are Attached.
Commands were:
domU# tcpdump -n -w domU.cap -s0 -i eth0 ether host 00:1f:c6:eb:71:43 or
ether broadcast
gw# tcpdump -n -w gw.cap -s0 -i br0 ether host 00:1f:c6:eb:71:43 or
ether broadcast
gw.cap
Description: Binary data
domU.cap
Description: Binary data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home