Re: Packet corruption in re0

----- Original Message ----
From: Pyun YongHyeon <pyunyh@xxxxxxxxx>
To: Abdullah Ibn Hamad Al-Marri <wearabnet@xxxxxxxx>
Cc: Ian FREISLICH <ianf@xxxxxxxxxx>; FreeBSD Current <freebsd-current@xxxxxxxxxxx>; FreeBSD STABLE <freebsd-stable@xxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxx:/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-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Packet corruption in re0
    ... Subject: Packet corruption in re0 ... >> From: Pyun YongHyeon ... >> To: Ian FREISLICH ... *** Error code 1 ...
    (freebsd-current)
  • Re: Packet corruption in re0
    ... Subject: Packet corruption in re0 ... >> From: Pyun YongHyeon ... >> To: Ian FREISLICH ... *** Error code 1 ...
    (freebsd-stable)
  • Re: CFT: vr(4)
    ... At 09:23 PM 2/3/2008, Pyun YongHyeon wrote: ... database showed vris not stable enough under high load and ... *** Error code 1 ...
    (freebsd-current)
  • Re: Packet corruption in re0
    ... I guess rein HEAD shall fix all known issues reported. ... Pyun YongHyeon ... *** Error code 1 ...
    (freebsd-current)
  • Re: Packet corruption in re0
    ... I guess rein HEAD shall fix all known issues reported. ... Pyun YongHyeon ... *** Error code 1 ...
    (freebsd-stable)