On Fri, Feb 8, 2019 at 12:26 PM Mahesh Bandewar (महेश बंडेवार)
wrote:
>
> On Wed, Feb 6, 2019 at 8:51 PM Mahesh Bandewar (महेश बंडेवार)
> wrote:
> >
> > On Tue, Feb 5, 2019 at 11:36 AM Michael Chan
> > wrote:
> > > I've looked at this a little more. The blackhole_dev is not IFF_UP |
> > > IFF_
On Wed, Feb 6, 2019 at 8:51 PM Mahesh Bandewar (महेश बंडेवार)
wrote:
>
> On Tue, Feb 5, 2019 at 11:36 AM Michael Chan
> wrote:
> >
> > On Wed, Jan 30, 2019 at 5:00 PM Mahesh Bandewar (महेश बंडेवार)
> > wrote:
> > >
> > > On Wed, Jan 30, 2019 at 1:07 AM Michael Chan
> > > wrote:
> > > >
> > >
On Tue, Feb 5, 2019 at 11:36 AM Michael Chan wrote:
>
> On Wed, Jan 30, 2019 at 5:00 PM Mahesh Bandewar (महेश बंडेवार)
> wrote:
> >
> > On Wed, Jan 30, 2019 at 1:07 AM Michael Chan
> > wrote:
> > >
> > > On Tue, Jan 22, 2019 at 10:29 AM Mahesh Bandewar (महेश बंडेवार)
> > > wrote:
> > >
> > > >
On Wed, Jan 30, 2019 at 5:00 PM Mahesh Bandewar (महेश बंडेवार)
wrote:
>
> On Wed, Jan 30, 2019 at 1:07 AM Michael Chan
> wrote:
> >
> > On Tue, Jan 22, 2019 at 10:29 AM Mahesh Bandewar (महेश बंडेवार)
> > wrote:
> >
> > >
> > > The idea behind the fix is very simple and it is to create a dst-onl
On Wed, Jan 30, 2019 at 1:07 AM Michael Chan wrote:
>
> On Tue, Jan 22, 2019 at 10:29 AM Mahesh Bandewar (महेश बंडेवार)
> wrote:
>
> >
> > The idea behind the fix is very simple and it is to create a dst-only
> > (unregistered) device with a very low MTU and use it instead of 'lo'
> > while inval
On Tue, Jan 22, 2019 at 10:29 AM Mahesh Bandewar (महेश बंडेवार)
wrote:
>
> The idea behind the fix is very simple and it is to create a dst-only
> (unregistered) device with a very low MTU and use it instead of 'lo'
> while invalidating the dst. This would make it *not* forward packets
> to drive
From: Mahesh Bandewar (महेश बंडेवार)
Date: Tue, 22 Jan 2019 10:28:58 -0800
> On Mon, Jan 21, 2019 at 4:59 PM Michael Chan
> wrote:
>>
>> On Mon, Jan 21, 2019 at 4:36 PM Daniel Axtens wrote:
>>
>> > I hit a similar sounding issue on a bnx2x - see commit
>> > 8914a595110a6eca69a5e275b323f5d09e18
On Mon, Jan 21, 2019 at 4:59 PM Michael Chan wrote:
>
> On Mon, Jan 21, 2019 at 4:36 PM Daniel Axtens wrote:
>
> > I hit a similar sounding issue on a bnx2x - see commit
> > 8914a595110a6eca69a5e275b323f5d09e18f4f9
> >
> > In that case, a GSO packet with gso_size too large for the firmware was
>
On Mon, Jan 21, 2019 at 4:36 PM Daniel Axtens wrote:
> I hit a similar sounding issue on a bnx2x - see commit
> 8914a595110a6eca69a5e275b323f5d09e18f4f9
>
> In that case, a GSO packet with gso_size too large for the firmware was
> coming to the bnx2x driver from an ibmveth device via Open vSwitch
On Mon, Jan 21, 2019 at 4:13 PM Mahesh Bandewar (महेश बंडेवार)
wrote:
> I have cooked few patches to address this issue, however, I'm finding it
> really hard to reproduce this issue in my test environment. If you could try
> them and see if those fixes the issue, we can refine them if necessar
Hi Michael,
> I've received a bug report of oversized UDP packets sent to the
> bnxt_en driver for transmission. There is no check for illegal length
> in the driver and it will send a corrupted BD to the NIC if the
> non-TSO length exceeds the maximum MTU supported by the driver. This
> ultimat
I've received a bug report of oversized UDP packets sent to the
bnxt_en driver for transmission. There is no check for illegal length
in the driver and it will send a corrupted BD to the NIC if the
non-TSO length exceeds the maximum MTU supported by the driver. This
ultimately causes the driver t
12 matches
Mail list logo
