From mboxrd@z Thu Jan  1 00:00:00 1970
From: Zoltan Kiss <zoltan.kiss@linaro.org>
Subject: Re: PV DomU running linux 3.17.3 causing xen-netback
 fatal error in Dom0
Date: Fri, 05 Dec 2014 12:48:58 +0000
Message-ID: <5481A9BA.1000009@linaro.org>
References: <19758084.30.1417707380178.JavaMail.root@zimbra.overnetdata.com>
	<54808372.8090102@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <54808372.8090102@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: David Vrabel <david.vrabel@citrix.com>, Anthony Wright <anthony@overnetdata.com>
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>
List-Id: xen-devel@lists.xenproject.org

Hi,

Maybe I'm misreading it, but it seems to me that netfront doesn't slice 
up the linear buffer at all, just blindly sends it. In xennet_start_xmit:

unsigned int offset = offset_in_page(data);
unsigned int len = skb_headlen(skb);
...
tx->offset = offset;
tx->size = len;

Although in the slot counting it calculates it correctly:
DIV_ROUND_UP(offset + len, PAGE_SIZE)

Am I missing something?

Zoli

On 04/12/14 15:53, David Vrabel wrote:
> On 04/12/14 15:36, Anthony Wright wrote:
>>> On 01/12/14 14:22, David Vrabel wrote:
>>> This VIF protocol is weird. The first slot contains a txreq with a
>>> size
>>> for the total length of the packet, subsequent slots have sizes for
>>> that
>>> fragment only.
>>>
>>> netback then has to calculate how long the first slot is, by
>>> subtracting
>>> all the size from the following slots.
>>>
>>> So something has gone wrong but it's not obvious what it is. Any
>>> chance
>>> you can dump the ring state when it happens?
>>
>> We think we've worked out how to dump the ring state, please see below.
>
> We need the full contents of the ring which isn't currently available
> via debugfs and I haven't had time to put together a debug patch to make
> it available.
>
> David
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>