Date: Wed, 29 Sep 2004 20:38:14 +0200 From: Max Laier <max@love2party.net> To: freebsd-current@freebsd.org Cc: Robert Watson <rwatson@freebsd.org> Subject: Re: High rate traffic silence an em interface. Message-ID: <200409292038.23349.max@love2party.net> In-Reply-To: <Pine.NEB.3.96L.1040924135726.82478I-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1040924135726.82478I-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1208317.dBTlZHnssG Content-Type: multipart/mixed; boundary="Boundary-01=_YEwWB2PanWTc3dH" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_YEwWB2PanWTc3dH Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline This might be my fault! Just committed a fix from Mike Makonnen, that might= =20 solve the problem you are seeing. It's just a missing "!" so it should be=20 easy to apply to RELENG_5 as well. Please give it a try (and accept my=20 apology for the headache caused). On Friday 24 September 2004 20:01, Robert Watson wrote: > On Sat, 25 Sep 2004, Shunsuke SHINOMIYA wrote: > > traffic over output interface's transmission rate silence an em > > interface with 5.3-BETA5. > > > > I configured a P4 with HTT box with two em interfaces for a router, one > > interface is set to 100BaseTX, the other is set to 10BaseT. > > > > And I sent the IPv4 11Mbps(only 1Mbps exceed 10Mbps) traffic for 10 > > seconds from 100BaseTX side to 10BaseT side by smartbits, most of > > packets dropped and this measurement terminated with failure. > > Then I did ping to a host over 10baseT side at the box, ping outputted > > with "No buffers space avilable". > > I'm seeing this also. For me, the threshold to trigger the problem is > somewhere between 50Kpps and 250Kpps, depending on factors I can't > identify. However, the box I'm running on also has some interesting > interrupt configuration issues, so I'm wondering if what I'm looking at is > a driver race condition. It seems not to be related to Giant over the > network stack -- I see the weding with and without debug.mpsafenet=3D1. > > I saw Sam Leffler also report a similar problem today. Bosko and I have > been seeing this if_em problem on some test hardware we have been using > for several months. Bosko tried updating to the latest version of the > driver from Intel's web site, and it appeared to make the problem go away. > However, the version on Intel's web site doesn't have busdma support or > fine-grained locking, so if it is a race condition, maybe their version of > the driver doesn't trigger it because it's doing these things differently > (i.e., might still exist there). > > You might try using the netrate tool I committed to > src/tools/tools/netrate to try and figure out the threshold transmission > level necessary to trigger the problem. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Principal Research Scientist, McAfee Resear= ch > > > >> ping 10.1.1.3 > > > > > >PING 10.1.1.3 (10.1.1.3): 56 data bytes > > >ping: sendto: No buffer space available > > >^C > > >--- 10.1.1.3 ping statistics --- > > >1 packets transmitted, 0 packets received, 100% packet loss > > > > I found two methods for recovery. One is up & down the interface of > > 10BaseT side, the other (strange?) one is ping6 to the host over 10baseT > > side like "ping6 ff02::1%em1". > > > > "Tx Descriptors not avail1" counter by hw.em1.debug_info increased. > > Another counters kept zero. > > > > > em1: Adapter hardware address =3D 0xc3dc6b34 > > > em1:CTRL =3D 0x40f01849 > > > em1:RCTL =3D 0x8002 PS=3D(0x8402) > > > em1:tx_int_delay =3D 0, tx_abs_int_delay =3D 0 > > > em1:rx_int_delay =3D 0, rx_abs_int_delay =3D 0 > > > em1: fifo workaround =3D 0, fifo_reset =3D 0 > > > em1: hw tdh =3D 132, hw tdt =3D 132 > > > em1: Num Tx descriptors avail =3D 256 > > > em1: Tx Descriptors not avail1 =3D 6430 > > > em1: Tx Descriptors not avail2 =3D 0 > > > em1: Std mbuf failed =3D 0 > > > em1: Std mbuf cluster failed =3D 0 > > > em1: Driver dropped packets =3D 0 > > > > Is this a peculiar problem just with me? > > > > -- > > Shunsuke SHINOMIYA <shino@fornext.org> =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_YEwWB2PanWTc3dH Content-Type: text/x-diff; charset="iso-8859-1"; name="if_em.c.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="if_em.c.diff" Index: sys/dev/em/if_em.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v retrieving revision 1.45 diff -u -r1.45 if_em.c =2D-- sys/dev/em/if_em.c 1 Sep 2004 23:22:41 -0000 1.45 +++ sys/dev/em/if_em.c 28 Sep 2004 21:08:54 -0000 @@ -1019,7 +1019,7 @@ loop_cnt--; } =20 =2D if (ifp->if_flags & IFF_RUNNING && IFQ_DRV_IS_EMPTY(&ifp->if_snd= )) + if (ifp->if_flags & IFF_RUNNING && !IFQ_DRV_IS_EMPTY(&ifp->if_snd)) em_start_locked(ifp); =20 EM_UNLOCK(adapter); --Boundary-01=_YEwWB2PanWTc3dH-- --nextPart1208317.dBTlZHnssG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBWwEfXyyEoT62BG0RArFiAJoDYU0Pu1xG7amFZir9EAnaFhrCHQCfQ+HK X+ZFF3bRpQfRLBfoZ+5jpRw= =YpGn -----END PGP SIGNATURE----- --nextPart1208317.dBTlZHnssG--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409292038.23349.max>