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, 18 Feb 2011 22:14:13 +0100
Delivery-date: Fri, 18 Feb 2011 13:15:02 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D52658E.9060907@xxxxxxxxxxx>
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> <4D4BE212.1090400@xxxxxxxxxxx> <1296818935.13091.648.camel@xxxxxxxxxxxxxxxxxxxxxx> <4D4BFBE4.6080809@xxxxxxxxxxx> <1296827449.13091.670.camel@xxxxxxxxxxxxxxxxxxxxxx> <4D4C06BB.8010907@xxxxxxxxxxx> <4D52658E.9060907@xxxxxxxxxxx>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101213 Lightning/1.0b2 Icedove/3.1.7
Hello,
Back online after my exams :)

Had some time to perform tests with my Debian Squeeze 32bits domU and
2.6.37 kernel from experimental.
DomU config is:
*****************************************************************
kernel       = '/cluster/kernels/vmlinuz-2.6.37-trunk-686-bigmem'
ramdisk      = '/cluster/kernels/initrd.img-2.6.37-trunk-686-bigmem'
#kernel       = '/cluster/kernels/vmlinuz-2.6.37-trunk-686-bigmem-sky2'
#ramdisk      = '/cluster/kernels/initrd.img-2.6.37-trunk-686-bigmem-sky2'
builder      = 'linux'
memory=268
vcpus        = '1'
cpus         = '2'
localtime    = 0
serial       = 'pty'
boot         = 'cdn'
disk         = [ 'drbd:xps-106,xvda,w' ]
on_poweroff  = 'destroy'
on_reboot    = 'restart'
on_crash     = 'restart'
name         = 'xps-106'
hostname     = 'xps-106.clichy.jbfavre.org'

extra = "root=/dev/mapper/xps--106-root ro iommu=soft swiotlb=force
console=hvc0 xencons=tty"
pci = [ '04:00.0' ]
*****************************************************************

Tests were done first with "legacy" kernel from Debian and with patched
kernel (patches from Ian to get verbose debug).
Each test consist in executing following command:
ping -c5 -s150 10.0.0.1
ping -c5 -s85 10.0.0.1

10.0.0.1 is my gateway

As you can see bellow, all verbose debug display "__netif_receive_skb
dropping skb" with various "proto" value and always "ip summed 2".
I can provide full detailled output if you want.

Here are the results:
Memory  2.6.37  2.6.37-patched
128     Works   Works
130     NoBoot  NoBoot
132     Works   Works
134     NoBoot  NoBoot
136     Works   Works
138     NoBoot  NoBoot
140     Fails   __netif_receive_skb dropping skb
142     NoBoot  NoBoot
144     Fails   __netif_receive_skb dropping skb
146     NoBoot  NoBoot
148     Fails   __netif_receive_skb dropping skb
150     NoBoot  NoBoot
152     Fails   __netif_receive_skb dropping skb
154     NoBoot  NoBoot
156     Fails   __netif_receive_skb dropping skb
158     NoBoot  NoBoot
160     Fails   __netif_receive_skb dropping skb
192     Fails   __netif_receive_skb dropping skb
224     Fails   __netif_receive_skb dropping skb
256     Fails   __netif_receive_skb dropping skb
264     Fails   __netif_receive_skb dropping skb
266     NoBoot  NoBoot
268     Works   Works
272     Works   Works
288     Works   Works
320     Works   Works
352     Works   Works
384     Works   Works
416     Works   Works
448     Works   Works
480     Works   Works
512     Works   Works

Now, I'll try to do the same tests with OpenWRT.
I hope I'll have similar results :)

Regards,
JB



Le 09/02/2011 10:59, Jean Baptiste Favre a écrit :
> Hello,
> Sorry for long silent period.
> 
> I'm taking night classes to get an engineering degree and am in the
> midst of exams this whole week.
> 
> I'll be back available next week to perform required tests and will
> provide you an update as soon as possible.
> 
> Regards,
> JB
> 
> Le 04/02/2011 15:01, Jean Baptiste Favre a écrit :
>> Le 04/02/2011 14:50, Ian Campbell a écrit :
>>> On Fri, 2011-02-04 at 13:15 +0000, Jean Baptiste Favre wrote:
>>>
>>>>
>>>>>> 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)
>>>
>>> Hang on, I thought you previously said copybreak=0 made everything work
>>> ok. If that isn't definitely the case then we may be following a red
>>> herring.
>> That's something I'm investigating.
>> Under Debian, copybreak=0 solve the problem
>> Under OpenWRT, copybreak=0 + patch breaks. Will try without patch.
>>
>>> Are you saying that copybreak=0 + this patch breaks? That would be very
>>> surprising since the patch doesn't cause any flow control differences.
>>>
>>> Perhaps there is some difference between your self-built kernels and the
>>> Debian kernels you started with? Perhaps you should try the self built
>>> kernel with no patches, just to confirm it behaves the same as the
>>> Debian kernels?
>> Under Debian, I use 2.6.37 from experimental
>> Under OpenWRT, use legacy 2.6.37, build env applies patches for OpenWRT
>> and compile.
>>
>> OpenWRT provides complete build env, as I still have problem compiling
>> Debian 32bits kernel from 64bits env. That's why I switched back to
>> openWRT for testing.
>>
>>
>>>>> Thanks.
>>>>>
>>>>> Please gather the tcpdump's too.
>>>> Both tcpdump from GW and domU are Attached.
>>>
>>> Were these collected with or without patches? With or without ethtool -K
>>> options? With or without copybreak?
>>>
>>> Please try and be explicit about everything you post, there are lots of
>>> variables in the air.
>> OK, sorry. Will redo all tests
>>
>> Regards,
>> JB
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>>
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 


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

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