netdev - Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 Mar 2016 10:35:55 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Sowmini Varadhan <sowmini.varadhan@...cle.com>
Cc:	Alexander Duyck <aduyck@...antis.com>,
	Netdev <netdev@...r.kernel.org>,
	intel-wired-lan <intel-wired-lan@...ts.osuosl.org>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Subject: Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload
 instead of 8 per packet

On Wed, Mar 30, 2016 at 10:20 AM, Sowmini Varadhan
<sowmini.varadhan@...cle.com> wrote:
> On (03/30/16 10:12), Alexander Duyck wrote:
>> Yeah.  The patch was sort of a knee-jerk reaction to being told that
>> the patch referenced caused a regression.  From what I can tell that
>> is not the case as I am also seeing the Tx hangs when I run the test
>> with the frames being linearized.
>
> I'm not sure how important of a subtlety this is, but the actual
> console log after the patch is the following:
>
>  i40e 0000:82:00.0: TX driver issue detected, PF reset issued
>  i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
>  i40e 0000:82:00.0: TX driver issue detected, PF reset issued
>  i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
>  i40e 0000:82:00.0: TX driver issue detected, PF reset issued
>
> Comparing with what I'd pasted in the sourceforge thread earlier,
> I see that it does not say "Hung Tx queue etc."  any more, though
> it still resets.
>
> Not sure if that changed info is significant?

It might be.  Right now I am chasing down the Tx driver issue as that
I what I am reproducing in my environment as well.

>From what I can tell by enabling msglvl tx_err it is reporting MDD
event 0x2.  Unfortunately the documentation doesn't say what that is
so I am checking a few different possibilities.

- Alex