From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Tomt Subject: Re: Fw: [Bug 201423] New: eth0: hw csum failure Date: Sun, 21 Oct 2018 15:34:19 +0200 Message-ID: References: <20181015081519.0bf076bc@xeon-e3> <4693819f-4a76-532f-9b24-d4328183c807@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Stephen Hemminger , netdev , rossi.f@inwind.it, Dimitris Michailidis To: Eric Dumazet , Eric Dumazet Return-path: Received: from mail1.ugh.no ([178.79.162.34]:48386 "EHLO mail1.ugh.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727345AbeJUVso (ORCPT ); Sun, 21 Oct 2018 17:48:44 -0400 In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 20.10.2018 00:25, Eric Dumazet wrote: > On 10/19/2018 02:58 PM, Eric Dumazet wrote: >> On 10/16/2018 06:00 AM, Eric Dumazet wrote: >>> On Mon, Oct 15, 2018 at 11:30 PM Andre Tomt wrote: >>>> I've seen similar on several systems with mlx4 cards when using 4.18.x - >>>> that is hw csum failure followed by some backtrace. >>>> >>>> Only seems to happen on systems dealing with quite a bit of UDP. >>>> >>> >>> Strange, because mlx4 on IPv6+UDP should not use CHECKSUM_COMPLETE, >>> but CHECKSUM_UNNECESSARY >>> >>> I would be nice to track this a bit further, maybe by providing the >>> full packet content. >>> >> >> As a matter of fact Dimitris found the issue in the patch and is working on a fix involving csum_block_sub() >> >> Problems comes from trimming an odd number of bytes. > > More exactly, trimming bytes starting at an odd offset. No hw csum failures here since I deployed Dimitris fix on top of 4.18.16 32 hours ago. Thanks