From owner-freebsd-bugs@FreeBSD.ORG Tue Apr 10 01:21:56 2007 Return-Path: X-Original-To: freebsd-bugs@freebsd.org Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5EA3116A407 for ; Tue, 10 Apr 2007 01:21:56 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by mx1.freebsd.org (Postfix) with ESMTP id A2BFD13C48C for ; Tue, 10 Apr 2007 01:21:53 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wr-out-0506.google.com with SMTP id 50so1003765wra for ; Mon, 09 Apr 2007 18:21:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=b7pVtsazp4jo9ciPjTwZE+4nLsQxSxDokMdQdlKsMPGjnEnCfOcLKFIb5Lgp4kz9P0LY7Wucz1Nw018vqFRbGkPUa2sPEEYUP1e6olYWR5Q5DQpo0plvBGdp7QpF5wFSpsgx8AuGT9acJ7TzHc0RZ/B9zT3t+7evkUTZj+o9aV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=FtuKHzCa4QoL/Pkg/OQU60Aa7at2aawNwgKI9GHuiZLlLn7jualYzB5xNPQ7NT5n2Hby1ySRVVakNLkphKYw8D9zKNyPpOkPcMqqZcuXBUV2GoKJIHCPstrSBkjqkPFfu7C+zeKUkMyrBIwEG9khc5RrP6ZchNXqucY7fGiuDFA= Received: by 10.114.153.18 with SMTP id a18mr2588612wae.1176168112226; Mon, 09 Apr 2007 18:21:52 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id q20sm3755331pog.2007.04.09.18.21.49; Mon, 09 Apr 2007 18:21:51 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l3A1NPVP046361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 10:23:25 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l3A1NNgS046360; Tue, 10 Apr 2007 10:23:23 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 10 Apr 2007 10:23:23 +0900 From: Pyun YongHyeon To: Harald Schmalzbauer Message-ID: <20070410012323.GB45776@cdnetworks.co.kr> References: <200704082120.l38LKA3v058525@freefall.freebsd.org> <20070409062618.GA41379@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <20070409062618.GA41379@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.1i Cc: freebsd-bugs@FreeBSD.org Subject: Re: kern/111384: msk hw checksum problem X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 01:21:56 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 09, 2007 at 03:26:18PM +0900, To Harald Schmalzbauer wrote: > On Sun, Apr 08, 2007 at 09:20:10PM +0000, Harald Schmalzbauer wrote: > > The following reply was made to PR kern/111384; it has been noted by GNATS. > > > > From: Harald Schmalzbauer > > To: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org > > Cc: > > Subject: Re: kern/111384: msk hw checksum problem > > Date: Sun, 8 Apr 2007 22:58:12 +0200 > > > > I did a quick check on 6.2-stable and couldn't see the symptom (no connection > > to freeshports). But I haven't captured traffic, so I can't guarantee that > > the "TCP checksum mismatch" doesn't aplly to 6.2-stable as well. > > > > Hmm, it's odd that STABLE works wihtout issues. msk(4) in STABLE > takes the same code path so it shoud have the issue too if msk(4) in > HEAD also has checksum offload issues. > > The reason of sending Winwdos probe message comes from the other > party' zero window advertisement in SYN + ACK packet. As you know > TCP can't send more data except window probing message if it recevied > zero window advirtisement. > Maybe the other party(www.freshports.org) advertise its window update > packet if it received correct window probe message from msk(4). > Since msk(4) failed to generate correct TCP cheksum the other party > didn't receive the probe message and you've lost connection here. > > Anyway I was able to reproduce the issue on HEAD but I have no idea > atm. Just padding with zeros to make it 60 bytes frame didn't work and > I wonder how it could work in STABLE. > Please try attached patch and let me know the result. -- Regards, Pyun YongHyeon --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="if_msk.chksum.patch" Index: if_msk.c =================================================================== RCS file: /home/ncvs/src/sys/dev/msk/if_msk.c,v retrieving revision 1.12 diff -u -r1.12 if_msk.c --- if_msk.c 6 Apr 2007 02:02:07 -0000 1.12 +++ if_msk.c 10 Apr 2007 01:19:23 -0000 @@ -131,6 +131,7 @@ #include #include +#include #include #include @@ -2647,7 +2648,6 @@ * hardware. However, TSO performance of Yukon II is very * good such that it's worth to implement it. */ - struct ether_vlan_header *evh; struct ether_header *eh; struct ip *ip; struct tcphdr *tcp; @@ -2669,17 +2669,37 @@ *m_head = NULL; return (ENOBUFS); } - evh = mtod(m, struct ether_vlan_header *); - ip = (struct ip *)(evh + 1); - } else - ip = (struct ip *)(eh + 1); + } m = m_pullup(m, offset + sizeof(struct ip)); if (m == NULL) { *m_head = NULL; return (ENOBUFS); } + ip = (struct ip *)(mtod(m, char *) + offset); offset += (ip->ip_hl << 2); tcp_offset = offset; + /* + * It seems that Yukon II has Tx checksum offload bug for + * small TCP packets that's less than 60 bytes in size + * (e.g. TCP window probe packet, pure ACK packet). + * Common work around like padding with zeros to make the + * frame minimum ethernet frame size didn't work at all. + * Instead of disabling checksum offload completely we + * resort to S/W checksum routine when we encounter short + * TCP frames. + * Short UDP packets appear to be handled correctly by + * Yukon II. + */ + if (m->m_pkthdr.len < MSK_MIN_FRAMELEN && + (m->m_pkthdr.csum_flags & CSUM_TCP) != 0) { + uint16_t csum; + + csum = in_cksum_skip(m, ntohs(ip->ip_len) + offset - + (ip->ip_hl << 2), offset); + *(uint16_t *)(m->m_data + offset + + m->m_pkthdr.csum_data) = csum; + m->m_pkthdr.csum_flags &= ~CSUM_TCP; + } if ((m->m_pkthdr.csum_flags & CSUM_TSO) != 0) { m = m_pullup(m, offset + sizeof(struct tcphdr)); if (m == NULL) { --9amGYk9869ThD9tj--