From owner-freebsd-stable@FreeBSD.ORG  Tue Apr  1 05:29:06 2008
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Delivered-To: freebsd-stable@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id B63EC1065672;
	Tue,  1 Apr 2008 05:29:06 +0000 (UTC) (envelope-from root@mmu.edu.my)
Received: from staff.cyber.mmu.edu.my (staff.cyber.mmu.edu.my [203.106.62.12])
	by mx1.freebsd.org (Postfix) with ESMTP id 483488FC13;
	Tue,  1 Apr 2008 05:29:05 +0000 (UTC) (envelope-from root@mmu.edu.my)
Received: by staff.cyber.mmu.edu.my (Postfix, from userid 0)
	id CA3A74D5AEF; Tue,  1 Apr 2008 13:20:56 +0800 (MYT)
Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53])
	by mmu.edu.my (Postfix) with ESMTP id EDB3555E491
	for <opal@mmu.edu.my>; Fri, 28 Mar 2008 13:48:46 +0800 (MYT)
Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36])
	by mx2.freebsd.org (Postfix) with ESMTP id 80D711610E7;
	Fri, 28 Mar 2008 05:48:04 +0000 (UTC)
	(envelope-from owner-freebsd-current@freebsd.org)
Received: from hub.freebsd.org (localhost [127.0.0.1])
	by hub.freebsd.org (Postfix) with ESMTP id EC14E10656DF;
	Fri, 28 Mar 2008 05:48:01 +0000 (UTC)
	(envelope-from owner-freebsd-current@freebsd.org)
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 5368A106566C
	for <freebsd-current@freebsd.org>; Fri, 28 Mar 2008 05:47:52 +0000 (UTC)
	(envelope-from wearabnet@yahoo.ca)
Received: from web33703.mail.mud.yahoo.com (web33703.mail.mud.yahoo.com
	[68.142.201.200])
	by mx1.freebsd.org (Postfix) with SMTP id 1C99C8FC1A
	for <freebsd-current@freebsd.org>; Fri, 28 Mar 2008 05:47:51 +0000 (UTC)
	(envelope-from wearabnet@yahoo.ca)
Received: (qmail 8833 invoked by uid 60001); 28 Mar 2008 05:47:51 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca;
	h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID;
	b=aH+yxp+O0chwFgRns5Ll6tSkyqW8SaP8jG1kA6bmPbsso+eVsaEaVBvPy4Yon1RqgEyJeZwT5x3BxLQC+dn2rG4AvZOGp4wUQouK8G8u07xKvN1itx2mKXt62GEw8MXVkAWdEksQ9D6KedatSo8BuJ2mGd0bAc8bEM9T391VvQA=;
X-YMail-OSG: RS_D9OwVM1kjFCcO6HeQpou2N07SVxSlk8xTXiTvtVzxfvK6QNeqacW35ZPeOvhiOw--
Received: from [82.148.96.69] by web33703.mail.mud.yahoo.com via HTTP;
	Thu, 27 Mar 2008 22:47:51 PDT
X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185
Date: Thu, 27 Mar 2008 22:47:51 -0700 (PDT)
From: Abdullah Ibn Hamad Al-Marri <wearabnet@yahoo.ca>
To: pyunyh@gmail.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <485760.8465.qm@web33703.mail.mud.yahoo.com>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Sender: owner-freebsd-current@freebsd.org
Errors-To: owner-freebsd-current@freebsd.org
Cc: FreeBSD Current <freebsd-current@freebsd.org>,
	FreeBSD STABLE <freebsd-stable@freebsd.org>
Subject: Re: Packet corruption in re0
X-BeenThere: freebsd-stable@freebsd.org
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>, 
	<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Apr 2008 05:29:06 -0000

----- Original Message ----
> From: Pyun YongHyeon <pyunyh@gmail.com>
> To: Abdullah Ibn Hamad Al-Marri <wearabnet@yahoo.ca>
> Cc: Ian FREISLICH <ianf@clue.co.za>; FreeBSD Current <freebsd-current@freebsd.org>; FreeBSD STABLE <freebsd-stable@freebsd.org>
> Sent: Friday, March 28, 2008 4:39:23 AM
> Subject: Re: Packet corruption in re0
> 
> On Thu, Mar 27, 2008 at 10:41:48AM -0700, Abdullah Ibn Hamad Al-Marri wrote:
>  > ----- Original Message ----
>  > > From: Pyun YongHyeon 
>  > > To: Ian FREISLICH 
>  > > Cc: FreeBSD Current ; Robert Backhaus 
> 
>  > > Sent: Monday, March 17, 2008 8:12:03 AM
>  > > Subject: Re: Packet corruption in re0
>  > > 
>  > > On Fri, Feb 22, 2008 at 10:43:22AM +0200, Ian FREISLICH wrote:
>  > >  > Pyun YongHyeon wrote:
>  > >  > > On Thu, Feb 21, 2008 at 01:18:18PM +0200, Ian FREISLICH wrote:
>  > >  > >  > Pyun YongHyeon wrote:
>  > >  > >  > > On Thu, Feb 21, 2008 at 02:47:43PM +1000, Robert Backhaus wrote:
>  > >  > >  > >  > On Thu, Feb 21, 2008 at 1:50 PM, Pyun YongHyeon  
>  > > wr
>  > >  > ote:
>  > >  > >  > >  > > On Thu, Feb 21, 2008 at 11:03:02AM +1000, Robert Backhaus 
> wrote:
>  > >  > >  > >  > >   > I am experiencing roughly 15% packet corruption on the 
> re 
>  > > inter
>  > >  > face 
>  > >  > >  > on
>  > >  > >  > >  > >   > my freebsd 7/amd64  box.
>  > >  > >  > >  > >   >
>  > >  > >  > >  > >   > FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD 
>  > > 7.0-PRERELEA
>  > >  > SE #8
>  > >  > >  > :
>  > >  > >  > >  > >   > Tue Feb  5 09:49:55 EST 2008
>  > >  > >  > >  > >   > root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW  amd64
>  > >  > >  > >  > >   >
>  > >  > >  > >  > >   > Just to make troubleshooting difficult, this problem 
> only 
>  > > shows
>  > >  >  up
>  > >  > >  > >  > >   > after the system has been up for roughly 36 hours, 
> depending 
>  > > on
>  > >  >  the
>  > >  > >  > >  > >   > amount of traffic.
>  > >  > >  > >  > >   >
>  > >  > >  > >  > >
>  > >  > >  > >  > >  I didn't take a look attached tcpdump files but I guess the
>  > >  > >  > >  > >  instability issue was fixed in HEAD. It's not yet MFCed but
>  > >  > >  > >  > >  I'll handle it in a week.
>  > >  > >  > >  > >
>  > >  > >  > >  > >  Would you try re(4) in HEAD?
>  > >  > >  > >  > >
>  > >  > >  > >  > 
>  > >  > >  > >  > OK, I'll do that. What is the best way to do that? csupping to 
> "." 
>  > > se
>  > >  > ems a
>  > >  > >  > >  > bit drastic, and I don't do much with cvs proper. I take it 
> that I 
>  > > sh
>  > >  > ould 
>  > >  > >  > use
>  > >  > >  > >  > anon-cvs to grab the directory, but I don't quite know how.
>  > >  > >  > >  > 
>  > >  > >  > > 
>  > >  > >  > > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box.
>  > >  > >  > > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to 
> add
>  > >  > >  > > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c 
> on
>  > >  > >  > > HEAD/RELENG_7 to if_re.c). That would make it build on your box.
>  > >  > >  > 
>  > >  > >  > This doesn't solve the problem that I'm seeing on re(4) interfaces.
>  > >  > >  > It basically shows up as quagga establishing OSPF neighours as
>  > >  > >  > "Exchange/DR" when VLAN hardware tagging is enabled.  I'm running
>  > >  > >  > OSPF over 802.1Q vlans.  Neighbours are correctly negotiated once
>  > >  > >  > VLAN hardware tagging is disabled on the interface.
>  > >  > >  > 
>  > >  > >  > I'll do more debugging.
>  > >  > >  > 
>  > >  > > 
>  > >  > > Hmm. That sounds like different issue to me. I guess I din't change
>  > >  > > any semantics in VLAN H/W tagging. Do you still the same VLAN H/W
>  > >  > > tagging related issues on RELENG_7?
>  > >  > > 
>  > >  > > To narrow down the issue it would be even better to know which parts
>  > >  > > of H/W assistance was broken. For example,
>  > >  > >  - Disable checksum offload for VLAN interface first and check
>  > >  > >    whether quagga works.
>  > >  > 
>  > >  > You can only disable offload on the parent interface.
>  > >  > 
>  > >  > >  - Disable checksum offload for parent interface and check again.
>  > >  > > If you can post tcpdump output for broken conntection it may help a
>  > >  > > lot to diagnose the issue.
>  > >  > 
>  > >  > The only flag affecting this behaviour is vlanhwtag.  Various
>  > >  > permutations of the interface flags make no difference to this
>  > >  > behaviour as long as hardware tagging is enabled.
>  > >  > 
>  > >  > It seems like it's corrupting large packets on transmit when vlanhwtag
>  > >  > is enabled.  From the tcpdump output it looks like a padding or
>  > >  > packet length issue.
>  > >  > 
>  > >  > Here's what tcpdump on the re(4) device thinks it's transmitting:
>  > >  > 
>  > >  > 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype 802.1Q (0x8100), length 
> 
>  > > 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.92 > 196.22.138.89: 
> OSPFv2, 
>  > > Database Description, length: 1472
>  > >  > 
>  > >  > Here's what was actually recieved by the em(4) device on the
>  > >  > neighbour.  Note the absense of the 801.1Q header:
>  > >  > 
>  > >  > 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype IPv4 (0x0800), length 
> 1506: 
>  > > 196.22.138.92 > 196.22.138.89: OSPFv2, Database Description, length: 1472
>  > >  > 
>  > >  > When vlanhwtagging is disabled, the re(4) device transmits:
>  > >  > 
>  > >  > 00:90:fb:0c:89:7d > 00:08:a1:3c:32:9c, ethertype 802.1Q (0x8100), length 
> 
>  > > 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.89 > 196.22.138.92: 
> OSPFv2, 
>  > > Database Description, length: 1472
>  > >  > 
>  > >  > and the em(4) device recieves:
>  > >  > 
>  > >  > 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype 802.1Q (0x8100), length 
> 
>  > > 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.92 > 196.22.138.89: 
> OSPFv2, 
>  > > Database Description, length: 1472
>  > >  > 
>  > >  > Let me know if you need more detailed tcpdump output than I've provided.
>  > >  > 
>  > > 
>  > > I guess I've found a VLAN hardware tagging bug in re(4).
>  > > Please try this one and let me know the result.
>  > > http://people.freebsd.org/~yongari/re/if_re.c
>  > > http://people.freebsd.org/~yongari/re/if_rlreg.h
>  > > 
>  > >  > Ian
>  > >  > 
>  > >  > --
>  > >  > Ian Freislich
>  > >  > 
>  > > 
>  > > -- 
>  > > Regards,
>  > > Pyun YongHyeon
>  > 
>  > 
>  > Pyun,
>  > 
>  > I used it, and I got no bufer space available message, I run a server with 
> heavey http requests and named as we..
>  > 
>  > so I had to increase the buffer.
>  > 
> 
> Please try re(4) in HEAD.
> I've just committed one important fix to PCIe variants of RealTek
> chip. I guess re(4) in HEAD shall fix all known issues reported.

 
> I'll MFC re(4) changes in a week.
> 
> -- 
> Regards,
> Pyun YongHyeon
> 

Hello Pyun,

I did fetch if_rlreg.h and if_re.c from HEAD, but it didn't compile in RELENG_7.

machine -> /usr/src/sys/amd64/include
rm -f .depend
mkdep -f .depend -a   -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/ARABPE /usr/src/sys/modules/mfi/mfi_linux/../../../dev/mfi/mfi_linux.c
===> mii (depend)
@ -> /usr/src/sys
machine -> /usr/src/sys/amd64/include
awk -f @/tools/makeobjops.awk @/dev/mii/miibus_if.m -c
awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h
awk -f @/tools/makeobjops.awk @/kern/device_if.m -h
awk -f @/tools/miidevs2h.awk @/dev/mii/miidevs
awk -f @/tools/makeobjops.awk @/dev/mii/miibus_if.m -h
awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h
rm -f .depend
mkdep -f .depend -a   -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/ARABPE /usr/src/sys/modules/mii/../../dev/mii/acphy.c /usr/src/sys/modules/mii/../../dev/mii/amphy.c /usr/src/sys/modules/mii/../../dev/mii/bmtphy.c /usr/src/sys/modules/mii/../../dev/mii/brgphy.c /usr/src/sys/modules/mii/../../dev/mii/ciphy.c /usr/src/sys/modules/mii/../../dev/mii/e1000phy.c /usr/src/sys/modules/mii/../../dev/mii/exphy.c /usr/src/sys/modules/mii/../../dev/mii/gentbi.c /usr/src/sys/modules/mii/../../dev/mii/icsphy.c /usr/src/sys/modules/mii/../../dev/mii/inphy.c /usr/src/sys/modules/mii/../../dev/mii/ip1000phy.c /usr/src/sys/modules/mii/../../dev/mii/lxtphy.c miibus_if.c /usr/src/sys/modules/mii/../../dev/mii/mii.c /usr/src/sys/modules/mii/../../dev/mii/mii_physubr.c /usr/src/sys/modules/mii/../../dev/mii/mlphy.c /usr/src/sys/modules/mii/../../dev/mii/nsgphy.c /usr/src/sys/modules/mii/../../dev/mii/nsphy.c
 /usr/src/sys/modules/mii/../../dev/mii/nsphyter.c /usr/src/sys/modules/mii/../../dev/mii/pnaphy.c /usr/src/sys/modules/mii/../../dev/mii/qsphy.c /usr/src/sys/modules/mii/../../dev/mii/rgephy.c /usr/src/sys/modules/mii/../../dev/mii/rlphy.c /usr/src/sys/modules/mii/../../dev/mii/ruephy.c /usr/src/sys/modules/mii/../../dev/mii/tdkphy.c /usr/src/sys/modules/mii/../../dev/mii/tlphy.c /usr/src/sys/modules/mii/../../dev/mii/ukphy.c /usr/src/sys/modules/mii/../../dev/mii/ukphy_subr.c /usr/src/sys/modules/mii/../../dev/mii/xmphy.c
In file included from /usr/src/sys/modules/mii/../../dev/mii/rgephy.c:60:
@/pci/if_rlreg.h:654:28: error: token ";" is not valid in preprocessor expressions
@/pci/if_rlreg.h:1062:6: error: unterminated comment
@/pci/if_rlreg.h:654:1: error: unterminated #if
In file included from /usr/src/sys/modules/mii/../../dev/mii/rlphy.c:56:
@/pci/if_rlreg.h:654:28: error: token ";" is not valid in preprocessor expressions
@/pci/if_rlreg.h:1062:6: error: unterminated comment
@/pci/if_rlreg.h:654:1: error: unterminated #if
mkdep: compile failed
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
2 errors
*** Error code 2
1 error
*** Error code 2
1 error



Could you please help with a patch could be applied in RELENG_7? This is urgent issue.



--- 
Regards,

-Abdullah Ibn Hamad Al-Marri
Arab Portal
http://www.WeArab.Net/





      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"