On 09/12/2014 22:30, Siegmann Joseph wrote:
>
> Would you mind sharing what it would take to correct this issue… is
> there a file I could just replace until a patch is released?
>
We simply applied David Vrabel's patch from 8/12/14 to a stock 3.17.3
kernel we were running in the DomU and it fixed
On 08/12/2014 12:03, David Vrabel wrote:
> Does this patch to netfront fix it?
>
> 8<-
> xen-netfront: use correct linear area after linearizing an skb
>
> Commit 97a6d1bb2b658ac85ed88205ccd1ab809899884d (xen-netfront: Fix
> handling packets on compound p
On 28/11/14 15:19, Anthony Wright wrote:
> We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2 to
> 3.17.3 running on a 64 bit 3.17.3 Dom0 with Xen 4.4.0.
>
> Shortly after the upgrade we started to lose network connectivity to the
> DomU a few times a day that required a reboot to
On 05/12/14 12:48, Zoltan Kiss wrote:
> 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:
This is handled in the beginning of xennet_make_frags() (which I would
agree isn't not the obvious pl
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
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 l
> 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 th
- Original Message -
> On 01/12/14 14:22, David Vrabel wrote:
> > On 28/11/14 15:19, Anthony Wright wrote:
> > The guest's frontend driver isn't putting valid requests onto the
> > ring
> > (it crosses a page boundary) so this is a frontend bug.
>
> This VIF protocol is weird. The first
On 01/12/14 14:22, David Vrabel wrote:
> On 28/11/14 15:19, Anthony Wright wrote:
>> We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2 to
>> 3.17.3 running on a 64 bit 3.17.3 Dom0 with Xen 4.4.0.
>>
>> Shortly after the upgrade we started to lose network connectivity to the
>> Dom
> On 28/11/14 15:19, Anthony Wright wrote:
> > We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2
> > to
> > 3.17.3 running on a 64 bit 3.17.3 Dom0 with Xen 4.4.0.
> >
> > Shortly after the upgrade we started to lose network connectivity to
> > the
> > DomU a few times a day that r
On 28/11/14 15:19, Anthony Wright wrote:
> We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2 to
> 3.17.3 running on a 64 bit 3.17.3 Dom0 with Xen 4.4.0.
>
> Shortly after the upgrade we started to lose network connectivity to the
> DomU a few times a day that required a reboot to
On 28/11/2014 15:23, Ian Campbell wrote:
> On Fri, 2014-11-28 at 15:19 +, Anthony Wright wrote:
>> We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2 to
>> 3.17.3
> Is this a Debian kernel? In which case you might be seeing
It's a stock kernel from kernel.org, we have a custom
On Fri, 2014-11-28 at 15:19 +, Anthony Wright wrote:
> We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2 to
> 3.17.3
Is this a Debian kernel? In which case you might be seeing
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767261 , this will be
fixed in the next upload of
We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2 to
3.17.3 running on a 64 bit 3.17.3 Dom0 with Xen 4.4.0.
Shortly after the upgrade we started to lose network connectivity to the
DomU a few times a day that required a reboot to fix. We see nothing in
the xen logs or xl dmesg, b
14 matches
Mail list logo
