Date: Mon, 23 May 2011 12:16:39 +0200 From: Attila Nagy <bra@fsn.hu> To: pyunyh@gmail.com Cc: freebsd-net@freebsd.org, rmacklem@uoguelph.ca, sthaug@nethelp.no, Ronald Klop <ronald-freebsd8@klop.yi.org> Subject: Re: TSO ethernet frame errors on 8-STABLE, was: bogus 0 len IP packet Message-ID: <4DDA3407.8020200@fsn.hu> In-Reply-To: <20110207002235.GA1244@michelle.cdnetworks.com> References: <op.vpekz9uz8527sy@212-123-145-58.ip.telfort.nl> <708793006.292748.1295186099577.JavaMail.root@erie.cs.uoguelph.ca> <20110117005524.GA1305@michelle.cdnetworks.com> <20110118.093804.74673434.sthaug@nethelp.no> <op.vpokw9c58527sy@pinky> <op.vqh69nx08527sy@212-123-145-58.ip.telfort.nl> <20110207002235.GA1244@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Hi, On 02/07/11 01:22, Pyun YongHyeon wrote: > On Sun, Feb 06, 2011 at 11:54:49PM +0100, Ronald Klop wrote: >> On Sat, 22 Jan 2011 00:01:47 +0100, Ronald Klop >> <ronald-freebsd8@klop.yi.org> wrote: >> >>> On Tue, 18 Jan 2011 09:38:04 +0100,<sthaug@nethelp.no> wrote: >>> >>>>>> So, does anyone have an idea why the IP length field would be set to >>>>> 0 >>>>>> for these TCP/IP packets? >>>>>> >>>>>> Here's some info from Ronald w.r.t. his hardware. (All I can think >>>>> of is >>>>>> that he could try disabling TSO, etc?) >>>>>> >>>>>> Thanks in advance for any help with this, rick >>>>>> >>>>> It seems that issue came from TSO. Driver will set ip_len and >>>>> ip_sum field to 0 before passing the TCP segment to controller. >>>>> The failed length were 4446, 5858, 3034 and 4310 and the total >>>>> number of such frames are more than 35k within 90 seconds. Since >>>>> failed length 4310 is continuously repeated I guess there is edge >>>>> case where em(4) didn't free failed TCP segment for TSO. >>>>> I remember there was commit to HEAD(r217295) which could be related >>>>> with this issue. >>>> I'm seeing the same problem with Broadcom NetXtreme (bce) cards: >>>> >>>> bce0@pci0:3:0:0: class=0x020000 card=0x03421014 chip=0x164c14e4 >>>> rev=0x12 hdr=0x00 >>>> vendor = 'Broadcom Corporation' >>>> device = 'Broadcom NetXtreme II Gigabit Ethernet Adapter >>>> (BCM5708)' >>>> class = network >>>> subclass = ethernet >>>> >>>> This is with 8.2-PRERELEASE. Turning off TSO (ifconfig bce0 -tso) >>>> removes the problem. >>>> >>>> Steinar Haug, Nethelp consulting, sthaug@nethelp.no >>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> I tried -tso and -txcsum in various combinations, but it didn't solve >>> the problem. I wil look for another brand of network card to try. But >>> this has to wait till monday when I'm at the office again. >> I also used another network card (rl0) and it has the same problem with >> NFS. I'm going to change some network cables to see if that helps. I have >> some hints that there might be something wrong with that. >> > Hmm, given that rl(4) also shows the issue it seems the issue could > be in TCP/IP stack, not in driver side. rl(4) is dumb device so > network stack should do segmentation and checksum computation. > I highly doubt the issue came from faulty cable since other users > also reported the same issue. > Unfortunately I have no clue yet and I was not able to reproduce it > on my box. I vaguely guess some code in kernel changed the ip_len > to 0 in the middle of transmission. Rick's captured traffic looks > normal except 0 ip_len given that controller is computing checksum > on the fly. If mbuf chain was corrupted(e.g. m_len == 0) driver > would have failed to send those frames. I can see something similar. Attached are two pcaps, with TSO enabled/disabled (net.inet.tcp.tso). NIC is: bce0: <HP NC373i Multifunction Gigabit Server Adapter (B2)> mem 0xfa000000-0xfbffffff irq 16 at device 0.0 on pci7 miibus0: <MII bus> on bce0 brgphy0: <BCM5708S 1000/2500BaseSX PHY> PHY 2 on miibus0 brgphy0: 1000baseSX-FDX, 2500baseSX-FDX, auto bce0: Ethernet address: 00:1f:29:cc:97:62 bce0: [ITHREAD] In a HP BL460c. The OS is a 8-STABLE/amd64, compiled two days ago. [-- Attachment #2 --] ò 2M J J )̗b pѭ E <g@ @dDD#ϜH H \P8/ 2M J J pѭ )̗b E <?@ @DDH#ϵlo I *\P8/2M B B )̗b pѭ E 4h@ @dDD#ϜH Ilpи \P8/*2MF { { )̗b pѭ E mi@ @dDD#ϜH Ilp@ \P8/*GET / HTTP/1.1 Connection: Close Host: 192.168.68.3 2MӇ pѭ )̗b E ?@ @DDH#ϵlp b *9\P8/HTTP/1.1 404 Not Found Content-Type: text/html; charset=iso-8859-1 Cache-Control: must-revalidate,no-cache,no-store Content-Length: 1365 Connection: close Server: Jetty(6.1.21) <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/> <title>Error 404 NOT_FOUND</title> </head> <body><h2>HTTP ERROR 404</h2> <p>Problem accessing /. Reason: <pre> NOT_FOUND</pre></p><hr /><i><small>Powered by Jetty://</small></i><br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> 2M pѭ )̗b E ?@ @RDDH#ϵl *9\P8/ <br/> </body> </html> 2M B B pѭ )̗b E 4?@ @DDH#ϵl~ *9\P8/2Mk B B )̗b pѭ E 4j@ @dDD#ϜH l! \P82*92M B B )̗b pѭ E 4k@ @dDD#ϜH l~!] \P82*92M% B B )̗b pѭ E 4l@ @dDD#ϜH l![ \P82*92MH B B pѭ )̗b E 4?@ @DDH#ϵl *9\P82 [-- Attachment #3 --] ò I1MgU J J )̗b ,Q&
