From owner-freebsd-net@FreeBSD.ORG Sun Nov 5 01:09:44 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0D5816A417 for ; Sun, 5 Nov 2006 01:09:44 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4465E43D5E for ; Sun, 5 Nov 2006 01:09:42 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20061105010940m9100el2n9e>; Sun, 5 Nov 2006 01:09:40 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id kA519cUJ007537; Sat, 4 Nov 2006 19:09:38 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id kA519aMm007536; Sat, 4 Nov 2006 19:09:36 -0600 (CST) (envelope-from brooks) Date: Sat, 4 Nov 2006 19:09:36 -0600 From: Brooks Davis To: MQ Message-ID: <20061105010936.GA6669@lor.one-eyed-alien.net> References: <20061102142543.GC70915@lor.one-eyed-alien.net> <200611031220.53791.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: Max Laier , freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 01:09:44 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 04, 2006 at 03:01:00AM +0000, MQ wrote: > I use google mail web interface to post messages, I can't connect to the > google mail POP server because someone disabled it on the firewall :( >=20 > I don't know if this post will be better? >=20 > 2006/11/3, Max Laier : > > > >Hello "MQ", > > > >your email client is seriously mis-configured, could you please look into > >this as it is a bit annoying. > > > >On Friday 03 November 2006 10:46, MQ wrote: > >> 2006/11/2, Brooks Davis : > >> > On Thu, Nov 02, 2006 at 08:26:27AM +0000, . wrote: > >> > > Hi, > >> > > > >> > > I am confused by the use of inet_ntoa function in the kernel. > >> > > > >> > > The function inet_ntoa in the /sys/libkern/inet_ntoa.c uses a > >> > > static > >> > > >> > array > >> > > >> > > static char buf[4 * sizeof "123"]; > >> > > to store the result. And it returns the address of the array to the > >> > > >> > caller. > >> > > >> > > I think this inet_ntoa is not reentrant, though there are several > >> > > >> > functions > >> > > >> > > calling it. If two functions call it simultaneously, the result > >> > > will be corrupted. Though I haven't really encountered this > >> > > situation, it may > >> > > >> > occur > >> > > >> > > someday, especially when using multi-processors. > >> > > > >> > > There is another reentrant version of inet_ntoa called inet_ntoa_r > >> > > in > >> > > >> > the > >> > > >> > > same file. It has been there for several years, but just used by > >> > > ipfw2 > >> > > >> > for > >> > > >> > > about four times in 7-CURRENT. In my patch, I replaced all the > >> > > calls to inet_ntoa with calls to inet_ntoa_r. > >> > > > >> > > By the way, some of the original calls is written in this style: > >> > > strcpy(buf, inet_ntoa(ip)) > >> > > The modified code is written in this style > >> > > inet_ntoa_r(ip, buf) > >> > > This change avoids a call to strcpy, and can save a little time. > >> > > > >> > > Here is the patch. > >> > > >> > http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah > >> >-net > >> > > >> > > I've already sent to PR(kern/104738), but got no reply, maybe it > >> > > should > >> > > >> > be > >> > > >> > > discussed here first? > >> > > >> > I've got to agree with other posters that the stack variable > >> > allocations are ugly. What about extending log and printf to > >> > understand ip4v addresses? That's 90% of the uses and the others > >> > appears to have buffers already. > >> > > >> > -- Brooks > >> > > >> > >> Ugly? Why? Don't you use local variables in your sources? > > > >You have to understand, that stack space is a limited resource in the > >kernel. Some of the functions are leaf nodes in quite long call paths, > >which means adding those buffers can hit quite hard. > > > >I guess what Brooks and I are trying to say is, that this needs to be > >considered carefully. A simple search and replace won't do. > > > >BTW, I took the PR for now and will look into it. I don't think it's > >something we need to rush, as I haven't seen any reports or indication of > >real problems yet - fwiw we don't spew a lot of IP addresses to console > >or log in normal operation. > > > >> By the way, implementing a printf/log which understands ipv4 address is > >> tedious, perhaps. > > > >Actually, it's a ~15 line patch, I will see if I can get to it later > >today. If we reuse the number buffer we can even get away without > >increase in stack space usage. Whether or not this is a good idea is on > >another page, but %I and %lI (for IPv6) would be available and we already > >have %D and %b as special cases in the kernel. > > > I know for sure that the kernel stack is much smaller than that in > userland programms, but is the kernel stack too small to contain > another 32 bytes at most? I've no idea, and is there any way to trace > the usage of the kernel stack? KGDB? > > The reason why I don't like the idea that adding the facility into > printf is we already had the converter inet_ntoa, adding the facility > seems duplicated. But if implemented, and use a local buffer, this > should be a really good way to solve the reentrant problem. Given that except for a few cases that should have obviously used inet_ntoa_r, inet_ntoa is only used to feed printf and log, the right answer is clearly to implement it in printf and log and the nuke this fundamental broken API. -- Brooks --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFTTnPXY6L6fI4GtQRAlzYAJ0UtouH4Y57Sx+JcVazUDAWHoRUfACeKvE1 cTJ1Jep4uRf4VCipMS2k3MY= =pjjJ -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 5 01:18:56 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CADDC16A49E for ; Sun, 5 Nov 2006 01:18:56 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4510843D46 for ; Sun, 5 Nov 2006 01:18:56 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20061105011853m9100ekcoee>; Sun, 5 Nov 2006 01:18:53 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id kA51Io3V007728; Sat, 4 Nov 2006 19:18:50 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id kA51Ioml007727; Sat, 4 Nov 2006 19:18:50 -0600 (CST) (envelope-from brooks) Date: Sat, 4 Nov 2006 19:18:49 -0600 From: Brooks Davis To: MQ Message-ID: <20061105011849.GB6669@lor.one-eyed-alien.net> References: <20061102142543.GC70915@lor.one-eyed-alien.net> <20061103141732.GA87515@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f2QGlHpHGjS2mn6Y" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 01:18:57 -0000 --f2QGlHpHGjS2mn6Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 04, 2006 at 02:46:30AM +0000, MQ wrote: > 2006/11/3, Brooks Davis : > > > >On Fri, Nov 03, 2006 at 09:46:47AM +0000, MQ wrote: > >> 2006/11/2, Brooks Davis : > >> > > >> >On Thu, Nov 02, 2006 at 08:26:27AM +0000, . wrote: > >> >> Hi, > >> >> > >> >> I am confused by the use of inet_ntoa function in the kernel. > >> >> > >> >> The function inet_ntoa in the /sys/libkern/inet_ntoa.c uses a static > >> >array > >> >> static char buf[4 * sizeof "123"]; > >> >> to store the result. And it returns the address of the array to the > >> >caller. > >> >> > >> >> I think this inet_ntoa is not reentrant, though there are several > >> >functions > >> >> calling it. If two functions call it simultaneously, the result will > >be > >> >> corrupted. Though I haven't really encountered this situation, it m= ay > >> >occur > >> >> someday, especially when using multi-processors. > >> >> > >> >> There is another reentrant version of inet_ntoa called inet_ntoa_r = in > >> >the > >> >> same file. It has been there for several years, but just used by > >ipfw2 > >> >for > >> >> about four times in 7-CURRENT. In my patch, I replaced all the calls > >to > >> >> inet_ntoa with calls to inet_ntoa_r. > >> >> > >> >> By the way, some of the original calls is written in this style: > >> >> strcpy(buf, inet_ntoa(ip)) > >> >> The modified code is written in this style > >> >> inet_ntoa_r(ip, buf) > >> >> This change avoids a call to strcpy, and can save a little time. > >> >> > >> >> Here is the patch. > >> >> > >> > > >http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah-net > >> >> > >> >> I've already sent to PR(kern/104738), but got no reply, maybe it > >should > >> >be > >> >> discussed here first? > >> > > >> >I've got to agree with other posters that the stack variable > >allocations > >> >are ugly. What about extending log and printf to understand ip4v > >> >addresses? That's 90% of the uses and the others appears to have > >> >buffers already. > >> > > >> >-- Brooks > >> > > >> > > >> >Ugly? Why? Don't you use local variables in your sources? > > > >The particular definition used is excedingly ugly. At a minimum there > >needs to be a define or a constant "16" for the lenght rather than the > >4*sizeof("123") nonsense. > > > >-- Brooks > > > > > > > Oh, I see. This kind of definition is really annoying, and hard to keep a= ll > the > occurrences consistent. Maybe a better way is use a macro to make that > clear? >=20 > #define IPV4_ADDRSZ (4 * sizeof "123") > char buf[IPV4_ADDRSZ]; >=20 > This "ugly" definition comes from inet_ntoa() in /sys/libkern/inet_ntoa.c, > I just copied the style without too much consideration, it's my fault. I'd just use 16. The inet_ntoa function is frankly inane. It attempts to support chars that aren't 8 bits which would break so much stuff it isn't funny. -- Brooks --f2QGlHpHGjS2mn6Y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFTTv5XY6L6fI4GtQRAnIjAJ428EtXz7lIYgbYl+3TiXlrXx23eQCgtofE yKK4poW//ljNzoV46uBC5ik= =+uSP -----END PGP SIGNATURE----- --f2QGlHpHGjS2mn6Y-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 5 02:58:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80ECF16A415 for ; Sun, 5 Nov 2006 02:58:39 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8EC443EAD for ; Sun, 5 Nov 2006 02:58:38 +0000 (GMT) (envelope-from antinvidia@gmail.com) Received: by nf-out-0910.google.com with SMTP id i2so2026641nfe for ; Sat, 04 Nov 2006 18:58:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=G90R7fU8gmzpZAhshQPtUvV2CFwpSECSiNY+P+Cv6+9UwOTq+UsSxuQ1JFPdRTx7iDmfIEBNDkXkeShVgATrpqsL0+VtRzeWWn2hPtqijMNx+tUAwS2Yt2L3/mYZGYuofkjgLf/ajWG9TleRliUr0SmagMtBVl9T80ntP3e4Yg4= Received: by 10.78.97.7 with SMTP id u7mr4956653hub.1162695517059; Sat, 04 Nov 2006 18:58:37 -0800 (PST) Received: by 10.78.167.2 with HTTP; Sat, 4 Nov 2006 18:58:36 -0800 (PST) Message-ID: Date: Sun, 5 Nov 2006 02:58:36 +0000 From: MQ To: "Brooks Davis" In-Reply-To: <20061105011849.GB6669@lor.one-eyed-alien.net> MIME-Version: 1.0 References: <20061102142543.GC70915@lor.one-eyed-alien.net> <20061103141732.GA87515@lor.one-eyed-alien.net> <20061105011849.GB6669@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 02:58:39 -0000 2006/11/5, Brooks Davis : > > On Sat, Nov 04, 2006 at 02:46:30AM +0000, MQ wrote: > > 2006/11/3, Brooks Davis : > > > > > >On Fri, Nov 03, 2006 at 09:46:47AM +0000, MQ wrote: > > >> 2006/11/2, Brooks Davis : > > >> > > > >> >On Thu, Nov 02, 2006 at 08:26:27AM +0000, . wrote: > > >> >> Hi, > > >> >> > > >> >> I am confused by the use of inet_ntoa function in the kernel. > > >> >> > > >> >> The function inet_ntoa in the /sys/libkern/inet_ntoa.c uses a > static > > >> >array > > >> >> static char buf[4 * sizeof "123"]; > > >> >> to store the result. And it returns the address of the array to > the > > >> >caller. > > >> >> > > >> >> I think this inet_ntoa is not reentrant, though there are several > > >> >functions > > >> >> calling it. If two functions call it simultaneously, the result > will > > >be > > >> >> corrupted. Though I haven't really encountered this situation, it > may > > >> >occur > > >> >> someday, especially when using multi-processors. > > >> >> > > >> >> There is another reentrant version of inet_ntoa called inet_ntoa_r > in > > >> >the > > >> >> same file. It has been there for several years, but just used by > > >ipfw2 > > >> >for > > >> >> about four times in 7-CURRENT. In my patch, I replaced all the > calls > > >to > > >> >> inet_ntoa with calls to inet_ntoa_r. > > >> >> > > >> >> By the way, some of the original calls is written in this style: > > >> >> strcpy(buf, inet_ntoa(ip)) > > >> >> The modified code is written in this style > > >> >> inet_ntoa_r(ip, buf) > > >> >> This change avoids a call to strcpy, and can save a little time. > > >> >> > > >> >> Here is the patch. > > >> >> > > >> > > > > > http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah-net > > >> >> > > >> >> I've already sent to PR(kern/104738), but got no reply, maybe it > > >should > > >> >be > > >> >> discussed here first? > > >> > > > >> >I've got to agree with other posters that the stack variable > > >allocations > > >> >are ugly. What about extending log and printf to understand ip4v > > >> >addresses? That's 90% of the uses and the others appears to have > > >> >buffers already. > > >> > > > >> >-- Brooks > > >> > > > >> > > > >> >Ugly? Why? Don't you use local variables in your sources? > > > > > >The particular definition used is excedingly ugly. At a minimum there > > >needs to be a define or a constant "16" for the lenght rather than the > > >4*sizeof("123") nonsense. > > > > > >-- Brooks > > > > > > > > > > > Oh, I see. This kind of definition is really annoying, and hard to keep > all > > the > > occurrences consistent. Maybe a better way is use a macro to make that > > clear? > > > > #define IPV4_ADDRSZ (4 * sizeof "123") > > char buf[IPV4_ADDRSZ]; > > > > This "ugly" definition comes from inet_ntoa() in > /sys/libkern/inet_ntoa.c, > > I just copied the style without too much consideration, it's my fault. > > I'd just use 16. The inet_ntoa function is frankly inane. It attempts > to support chars that aren't 8 bits which would break so much stuff it > isn't funny. > > -- Brooks > > > Yes, you are right. Refer to the ISO/IEC C standard, the characters that may used by an ipv4 address are members of the basic character sets defined by the standard. And the char type should be large enough to contain any member of the basic execution character set. So just defining the array size to 16 is enough. And the original writer considered to much(or the C standard of that time didn't make such clear rules on the character set). From owner-freebsd-net@FreeBSD.ORG Sun Nov 5 03:04:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1452916A788 for ; Sun, 5 Nov 2006 03:04:52 +0000 (UTC) (envelope-from jean-pierre.marierrowp@gmc.ulaval.ca) Received: from pool-71-251-251-157.char.east.verizon.net (pool-71-251-251-157.char.east.verizon.net [71.251.251.157]) by mx1.FreeBSD.org (Postfix) with SMTP id 7D51B443BE for ; Sun, 5 Nov 2006 02:31:27 +0000 (GMT) (envelope-from jean-pierre.marierrowp@gmc.ulaval.ca) Received: from boromir.hydre.ulaval.ca by pool-71-251-251-157.char.east.verizon.net (8.9.3/8.9.3) with ESMTP id cpQgOVaxL6Rp for ; Sun, 5 Nov 2006 16:37:25 -0500 Received: from unknown (236.163.209.22) by boromir.hydre.ulaval.ca via HTTP for ; Sun, 5 Nov 2006 16:37:25 -0500 From: "Wendell" Message-ID: <5697378106.638487955153@gmc.ulaval.ca> Date: Sun, 5 Nov 2006 16:37:25 -0500 To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: large DAATlNG SlTEE. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Wendell Coates List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 03:04:52 -0000 Freee operative datingg sitee. http://rawstern1326zy.com From owner-freebsd-net@FreeBSD.ORG Sun Nov 5 04:24:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0172A16A583 for ; Sun, 5 Nov 2006 04:24:42 +0000 (UTC) (envelope-from rec33mzm@ricochet.com) Received: from ricochet.com (pc-56-220-47-190.cm.vtr.net [190.47.220.56]) by mx1.FreeBSD.org (Postfix) with SMTP id BE88F43D5D for ; Sun, 5 Nov 2006 04:24:37 +0000 (GMT) (envelope-from rec33mzm@ricochet.com) To: From: "Jessi Johana" Date: Sun, 05 Nov 2006 01:24:37 -0400 Message-ID: <723zt980o.81674@ricochet.com> User-Agent: Mozilla Thunderbird 1.5 (Windows/20060111) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/related; boundary="------------Next_Part_14347039" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: d I AM SO GLAD I DISCOVERED VIGRAMAX ITS THE ONLY ED/ANTI-IMPOTENCE PILL DRUG THAT ACTUALLY WORK six window X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 04:24:43 -0000 This is a multi-part message in MIME format. --------------Next_Part_14347039 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable VigraMax - Natural Anti_ImpotencePill BetterThanViagra, fast acting - start working within 30 mins We served over 100,000 satisfied returning customers worldwide (Ship all countries) VigraMax=$0.94/pill Cheaper 20 times than GenuineViagra=$17.50/pill It cures: Loss of Libido, ErectileDysfunction, LackOfSexual desire, Impotence, Mood swings, Sperm count and potency, General weakness & Depression To conclude, VigraMax is the best solution available for all impotence related problems with NO side effects. Only $0.94/pill, Dont waste $ on other pill (click the link to save) http://rgwbh.ohyeahwhatisthis.com supposedto beautiful page, miserable interest length address similar, benefit you teach? --------------Next_Part_14347039 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" turning similar sorry kept given bread, VigraMax - Natural = Anti_ImpotencePill We served = over 100,000 satisfied returning customers worldwide (Ship all = countries) BetterThanViagra, fast acting - start = working within 30 mins VigraMax=3D$0.94/pill Cheaper 20 times than = GenuineViagra=3D$17.50/pill It's fine blend of safe herbs and all essential vitamins to = give you a break from all those erection problems like impotence, ED, = loss of libido, lack of Sexual Derive, etc It cures: Loss of Libido, ErectileDysfunction, LackOfSexual desire, Impotence, Mood = swings, Sperm count and potency, = General weakness & Depression To conclude, VigraMax is the best solution available for = all impotence related problems with NO side effects. [1]k Only $0.94/pill, Dont waste $ on = other pill (click here) = x end remained yours independence, References 1. 3Dhttp://rgwbh.ohyeahwhatisthis.com/ --------------Next_Part_14347039-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 5 08:18:33 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA10916A742 for ; Sun, 5 Nov 2006 08:18:32 +0000 (UTC) (envelope-from kayogk@cargolink.com) Received: from cargolink.com (62-43-83-194.user.ono.com [62.43.83.194]) by mx1.FreeBSD.org (Postfix) with SMTP id 3812343D53 for ; Sun, 5 Nov 2006 08:18:32 +0000 (GMT) (envelope-from kayogk@cargolink.com) Message-ID: <019d01c70013$3bcf42d0$5947d3f0@lwristh> From: "Beatrice Rutledge" To: Date: Sun, 05 Nov 2006 09:18:21 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Watch out for this one ty X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Beatrice Rutledge List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 08:18:33 -0000 OF INTEREST PAY ATTENTION VITAL This advisory is based on exclusive insiders/agents information. (AVLN.OB) Avalon Energy Corporation has an undivided 85% working interest in the Shotgun Draw Prospect in the prolific natural gas producing Uinta Basin , located in the US Rockies, Utah . The lease comprises 13,189 acres with a potential 4 TCF recoverable gas and is overpressured by a 0.55 . 0.85 gradient. ON MONDAY NOV 6th: at 11 cents its a STEAL - Volume: 389,001 - Volume: + 50% - Price: +5.77% The key to any tade is buying low and selling high, WELL the energy market has bottomed out and time to get in is now. We specialise in calling market bottom and when it comes to energy THIS IS THE BOTTOM, SO GET IN FOLKS YOU WANNA WATCH THIS YOU WANNA WATCH THIS "The truth is the Democrats can't answer that question," Bush said. "Harsh criticism is not a plan for victory. Second guessing is not a strategy. Small planes could previously fly below 1,100 feet along the river without filing flight plans or checking in with air traffic control. The FAA said the rule change -- a temporary one -- was made for safety reasons. Bush said Democrats calling for withdrawing U.S. troops from Iraq aren't unpatriotic, just wrong. He said Democrats who voted against legislation to detain and interrogate suspected terrorists, the National Security Agency's eavesdropping program and the Patriot Act don't understand the stakes in the war on terror. "This arrest really does help with some of the closure, the healing that we in the Forest Service community, and in the families, need," said Jeanne Wade Evans, the San Bernardino National Forest supervisor. From owner-freebsd-net@FreeBSD.ORG Sun Nov 5 09:42:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A627C16A4D1 for ; Sun, 5 Nov 2006 09:42:03 +0000 (UTC) (envelope-from apache@server5.web4a.de) Received: from server5.web4a.de (server5.web4a.de [82.149.231.244]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7966E43D7E for ; Sun, 5 Nov 2006 09:41:50 +0000 (GMT) (envelope-from apache@server5.web4a.de) Received: by server5.web4a.de (server5.web4a.de, from userid 48) id 0A043CB898; Sun, 5 Nov 2006 10:01:27 +0100 (CET) To: freebsd-net@freebsd.org From: Wellsfargo Security Center Content-Transfer-Encoding: 8bit Message-Id: <20061105090127.0A043CB898@server5.web4a.de> Date: Sun, 5 Nov 2006 10:01:27 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Urgent Alert : Protect Your Account X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ofsrep.alert_cpw@wellsfargo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 09:42:03 -0000 [1]Wells Fargo [2]Wells Fargo Credit Card Dear valued WellsFargo ® member: Due to concerns, for the safety and integrity of the wellsfargo account we have issued this warning message : We have noticed that your Wells Fargo online account needs to be updated once again, please enter your online account information, because we have to verify all of the online accounts after we have updated our Wells Fargo Online Banking site. To verify your online account and access your bank account, please click on the link below : [3][al_continue_off.gif] [4]Continue to Stop Payment This e-mail was sent to all of our Wells Fargo customers. Recently, we have found that many accounts were hacked. For further information, please contact our Customer Services. Contact Us: If you have questions, please do not respond to this message using the 'Reply' button. Wells Fargo Online^® customers, [5]Sign On to your secure banking session and click 'Contact Us'. If you are not a Wells Fargo Online customer, [6]contact us here. Online Customer Service Code: 0610SVCCD42703 References 1. http://www.robol.net/doup/gebruikers/www.wellsfargo.com/www.wellsfargo.com/www.wellsfargo.com/www.wellsfargo.com/updateyouraccountinformation/index.html 2. http://www.robol.net/doup/gebruikers/www.wellsfargo.com/www.wellsfargo.com/www.wellsfargo.com/www.wellsfargo.com/updateyouraccountinformation/ 3. http://www.robol.net/doup/gebruikers/www.wellsfargo.com/www.wellsfargo.com/www.wellsfargo.com/www.wellsfargo.com/updateyouraccountinformation/index.html 4. http://www.robol.net/doup/gebruikers/www.wellsfargo.com/www.wellsfargo.com/www.wellsfargo.com/www.wellsfargo.com/updateyouraccountinformation/index.html 5. http://www.robol.net/doup/gebruikers/www.wellsfargo.com/www.wellsfargo.com/www.wellsfargo.com/updateyouraccountinformation/index.html 6. http://www.wellsfargo.com/per/per_ask_us.jhtml?cid=12779736424 From owner-freebsd-net@FreeBSD.ORG Sun Nov 5 09:45:33 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 213F316A40F; Sun, 5 Nov 2006 09:45:33 +0000 (UTC) (envelope-from frode@nordahl.net) Received: from smtp1.powertech.no (smtp1.powertech.no [195.159.0.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id B92DD43D46; Sun, 5 Nov 2006 09:45:32 +0000 (GMT) (envelope-from frode@nordahl.net) Received: from [195.159.148.126] (dhcp7.xu.nordahl.net [195.159.148.126]) by smtp1.powertech.no (Postfix) with ESMTP id C338583A1; Sun, 5 Nov 2006 10:45:30 +0100 (CET) In-Reply-To: <2a41acea0611031816n1af99819rdc6b99e9dd2deb7c@mail.gmail.com> References: <2a41acea0611031816n1af99819rdc6b99e9dd2deb7c@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Frode Nordahl Date: Sun, 5 Nov 2006 10:45:37 +0100 To: Jack Vogel X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net , freebsd-stable@freebsd.org Subject: Re: New em patch for 6.2 BETA 3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 09:45:33 -0000 On 4. nov. 2006, at 03.16, Jack Vogel wrote: > I have been hard at work trying to understand and fix the > remaining issues with the em driver. What I have here is > a patch that has gotten rid of any issues that I can reproduce. > > It solves the intermittent watchdogs that have been happening. > It also fixes the problem noted with jumbo frame tx > > I, and re, would very much appreciate any test feedback you can > give on this code. I am happy with the changes, I hope these get > rid of everyone's issues. > > Thanks to Gleb and Scott and John for all the help! This patch solves the watchdog timeout issues I had on one of my test servers on 6.2-BETA3, thanks! -- Frode Nordahl From owner-freebsd-net@FreeBSD.ORG Sun Nov 5 09:59:56 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5333716A415 for ; Sun, 5 Nov 2006 09:59:56 +0000 (UTC) (envelope-from aburke@nullplusone.net) Received: from alpha.nullplusone.net (sub25-168.member.dsl-only.net [63.105.25.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5702543D46 for ; Sun, 5 Nov 2006 09:59:52 +0000 (GMT) (envelope-from aburke@nullplusone.net) Received: from leda (leda.int.nullplusone.net [192.168.10.242]) by alpha.nullplusone.net (8.12.9/8.12.9) with ESMTP id kA59xj8J014182; Sun, 5 Nov 2006 01:59:45 -0800 (PST) (envelope-from aburke@nullplusone.net) From: "Aaron Burke" To: , Date: Sun, 5 Nov 2006 01:59:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200611031202.kA3C20nl078493@lurza.secnetix.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Cc: Subject: RE: VLAN switch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 09:59:56 -0000 > I think you'll need a 550 for layer3 ("routing switch"). > The 510 and 520 are both layer2 (i.e. normal switches). Yep, you are correct. My mistake sorry freebsd-net. Intel 510T Layer 2 managed 10/100 switch: dirt cheap. Intel 520T Layer 2 managed 10/100 switch: dirt cheap. Intel 550T Layer 3 managed 10/100 switch: dirt cheap. According to ebay, the 550 can be had for about $30.00 USD. In my opinion, thats a killer deal for a 24 port managed ethernet switch. If I didnt allready have too many switches, I would buy some. -- Aaron Burke From owner-freebsd-net@FreeBSD.ORG Sun Nov 5 10:40:47 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D921716A512 for ; Sun, 5 Nov 2006 10:40:47 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id E705043DCF for ; Sun, 5 Nov 2006 10:40:30 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 1546D24D1B4; Sun, 5 Nov 2006 21:40:29 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 51C7B8C07; Sun, 5 Nov 2006 21:40:27 +1100 (EST) Date: Sun, 5 Nov 2006 21:40:26 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Brooks Davis In-Reply-To: <20061105010936.GA6669@lor.one-eyed-alien.net> Message-ID: <20061105202925.D44623@delplex.bde.org> References: <20061102142543.GC70915@lor.one-eyed-alien.net> <200611031220.53791.max@love2party.net> <20061105010936.GA6669@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Max Laier , MQ , freebsd-net@FreeBSD.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 10:40:48 -0000 On Sat, 4 Nov 2006, Brooks Davis wrote: > On Sat, Nov 04, 2006 at 03:01:00AM +0000, MQ wrote: >> 2006/11/3, Max Laier : >>> On Friday 03 November 2006 10:46, MQ wrote: >>>> By the way, implementing a printf/log which understands ipv4 address is >>>> tedious, perhaps. It certainly is. >>> Actually, it's a ~15 line patch, I will see if I can get to it later >>> today. More like ~15 files: libkern/inet_ntoa.c: -current: remove RELENG_6: keep for compatibility RELENG_old: no change (but complicates merges) conf/files: remove reference in -current only kern/subr_prof.c: implement in -current and RELENG_6 man9/printf.9: document in -current and RELENG_6 gcc/c-format.c: implement format checking in -current and RELENG_6. Maintain this forever. gcc/gcc.1: in RELENG_6 fix old bug -- the -fformat-extensions options, which is needed to actually use the new %? and the old %[bD], has never been documented. Maintain this in RELENG_6. gcc/doc/gcc.1: in -current, merge with the fixed gcc/gcc.1. While here, also merge FreeBSD extensions which were actully documented. Maintain this forever. gcc/doc/*.texi: document the new %?. While here, document the old -fformat-extensions and %[bD]. Maintain this forever. >>> If we reuse the number buffer we can even get away without >>> increase in stack space usage. Whether or not this is a good idea is on >>> another page, It's OK for a specialized function, but bad for printf. >>> but %I and %lI (for IPv6) would be available and we already >>> have %D and %b as special cases in the kernel. %I should be reserved for integer operands with the size of the operand given as a parameter. >> I know for sure that the kernel stack is much smaller than that in >> userland programms, but is the kernel stack too small to contain >> another 32 bytes at most? I've no idea, and is there any way to trace >> the usage of the kernel stack? KGDB? 32 isn't much, but many multiples of 32 would be ugly at best. The problem is that gcc will allocate 16 bytes for the buffer whether or not the error-handling code that actually uses the buffer is executed, and whether or not the uses of the buffer are nested (in -current, the uses can't be nested since normal interrupt handlers are in separate threads). It is enough to have local declarations of the buffer in nested function calls. Speaking of ugly allocations, the kernel has some stupid code like: { int table[] == { 1, 2, ..., }; use(table); } where the table is const (but not declared const). Such code not only wastes stack, but causes gcc to initialize the table from static storage on every call to the function. (IIRC, gcc is not very smart about optimizing away either the stack use or the copying, even if the table is declared const.) The above wouldn't even have compiled in K&R C. The kernel also has too many uses of the C99 feature variable-sized auto arrays. I looked at a few of these and they were mostly like "int vmstuff[n];" where we have to know that the variable parameter n is less than about 16 to know that the stack won't explode, and we do know that at compile time but then we can write the above more safely and clearly, though less quickly, as "int vmstuff[16];" [CTASSERT(MAX_n <= 16;]". >> The reason why I don't like the idea that adding the facility into >> printf is we already had the converter inet_ntoa, adding the facility >> seems duplicated. But if implemented, and use a local buffer, this >> should be a really good way to solve the reentrant problem. The kernel inet_ntoa() would be removed if a printf format for it was implemented. > Given that except for a few cases that should have obviously used > inet_ntoa_r, inet_ntoa is only used to feed printf and log, the right > answer is clearly to implement it in printf and log and the nuke this > fundamental broken API. I think you misspelled "wrong" [answer]. Specialized formats don't belong in printf(). printf()'s behaviour of not using any storage in the unbuffered case is often convenient, but hardly anyone seems to worry about the huge (;-)) wastage of storage caused by using sprintf() or better yet, strcat(), when the output needs to be adjusted a bit before printing it. Bruce From owner-freebsd-net@FreeBSD.ORG Sun Nov 5 11:08:49 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2996316A403 for ; Sun, 5 Nov 2006 11:08:49 +0000 (UTC) (envelope-from lunchca@france-transactions.fr) Received: from france-transactions.fr (mel77-2-82-244-235-60.fbx.proxad.net [82.244.235.60]) by mx1.FreeBSD.org (Postfix) with SMTP id A1CCB43D7E for ; Sun, 5 Nov 2006 11:08:31 +0000 (GMT) (envelope-from lunchca@france-transactions.fr) Message-ID: <05a501c70004$3caf90c0$5711b2e0@ostraightq> From: "Romeoa Tamika" To: Date: Sun, 05 Nov 2006 12:08:33 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Powerhouse Stock Profiles da X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Romeoa Tamika List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 11:08:49 -0000 OF INTEREST PAY ATTENTION VITAL This advisory is based on exclusive insiders/agents information. (NHVP.PK) NHVP has provided investors with 1000% + gains during the real estate boom, and now with the sector at its bottom, is ready to provide with results yet again.. OCT 13th: Northeast Development Corp. to Receive Funding from European Investment Firm. Preliminary discussions suggest figures of -3 million with a combination of real estate and equity collateralization. GET IN ON MONDAY NOV 6th: at 08 cents its a STEAL - Volume: 8,000 - Volume: + 100% - Price: +100% The key to any tade is buying low and selling high, WELL the REAL ESTATE market has bottomed out and time to get in is now. We specialise in calling market bottom and when it comes to REAL ESTATE THIS IS THE BOTTOM, SO GET IN FOLKS JOIN BEFORE YOU GET BEAT JOIN BEFORE YOU GET BEAT "Nine days ago, one of the worst tragedies in the 100-year history of the Forest Service took the lives of five heroes," U.S. Forest Service Chaplain Steve Seltzner said as the service began. "It has shaken this agency and the men and women of the San Benardino National Forest to its very core and shocked the entire world." Oyler "adamantly denies involvement in this fire and in any of these fires," attorney Mark McDonald said outside court. "He's very distraught and scared ... The finger is pointing at him." Democrats say they are ahead in many races because of the public's growing dissatisfaction with the war in Iraq. And polls show that a clear majority of Americans see the war as a mistake and far fewer support the president's handling of it. The National Transportation Safety Board said the wind, coupled with the pilot's inability to turn sharply, forced the aircraft away from its intended path over the East River and into the building. From owner-freebsd-net@FreeBSD.ORG Sun Nov 5 11:35:17 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B9D616A54A for ; Sun, 5 Nov 2006 11:35:17 +0000 (UTC) (envelope-from peter@alastria.net) Received: from nebula.thdo.uk.alastria.net (nebula.thdo.uk.alastria.net [212.13.198.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id D409243E18 for ; Sun, 5 Nov 2006 11:33:46 +0000 (GMT) (envelope-from peter@alastria.net) Received: from [10.10.4.10] (88-96-139-34.dsl.zen.co.uk [88.96.139.34]) (authenticated bits=0) by nebula.thdo.uk.alastria.net (8.13.3/8.13.3) with ESMTP id kA5BXdSx002491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 5 Nov 2006 11:33:41 GMT (envelope-from peter@alastria.net) Message-ID: <454DCC04.6020106@alastria.net> Date: Sun, 05 Nov 2006 11:33:24 +0000 From: Peter Wood User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <2864.10.10.4.10.1162579931.squirrel@neon.alastria.lan> <454D25C4.2000503@uk.tiscali.com> In-Reply-To: <454D25C4.2000503@uk.tiscali.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Flag: NO X-Virus-Status: No X-Spam-Score: 0.137 () RCVD_IN_SORBS_DUL X-Spam-Ultra-Flag: NO X-Spam-Low-Flag: NO X-Spam-Flag: NO X-Spam-High-Flag: NO X-Scanned-By: MIMEDefang 2.51 on 212.13.198.8 Subject: Re: IPSEC, isakmpd, tunnel/transport encapsulation... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 11:35:17 -0000 Heya Chris, > I tried to setup something exactly like you did. I could do it fine with > freebsd boxes as I would do it via username not ip. Never really got the > roblem sorted for windows though. I ended up using openVPN instead. Thanks for your follow up, I've used OpenVPN before and I agree it is a lot easier, however in this case I don't want the requirement of installing software on the end clients who might only log on once every few months. Also it's NAT traversing capabilities don't really apply as it's IP to IP on the same subnet :). Cheers for the suggestion though, I'll keep kicking it for a bit longer. I should add that the config I previously gave for isakmpd had a mistake (from my trails and errors). #Configuration = ipsec-quick-mode Was actually uncommented. Configuration = ipsec-quick-mode Cheers, Peter. From owner-freebsd-net@FreeBSD.ORG Sun Nov 5 12:35:19 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65D1216A4C2 for ; Sun, 5 Nov 2006 12:35:19 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FE6343D98 for ; Sun, 5 Nov 2006 12:34:33 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 6DE3B5A0EA8; Sun, 5 Nov 2006 23:34:22 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id E43DD8C03; Sun, 5 Nov 2006 23:34:20 +1100 (EST) Date: Sun, 5 Nov 2006 23:34:20 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Brooks Davis In-Reply-To: <20061105011849.GB6669@lor.one-eyed-alien.net> Message-ID: <20061105214041.F44623@delplex.bde.org> References: <20061102142543.GC70915@lor.one-eyed-alien.net> <20061103141732.GA87515@lor.one-eyed-alien.net> <20061105011849.GB6669@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org, MQ Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 12:35:19 -0000 On Sat, 4 Nov 2006, Brooks Davis wrote: > On Sat, Nov 04, 2006 at 02:46:30AM +0000, MQ wrote: >> 2006/11/3, Brooks Davis : >>> The particular definition used is excedingly ugly. At a minimum there >>> needs to be a define or a constant "16" for the lenght rather than the >>> 4*sizeof("123") nonsense. The `4*sizeof "123"' is not nonsense. It is better than the userland version at the time it was committed. The userland version hard-coded the size as 18 (sic). The current userland version still hard-codes 18, but now actually needs it to print an error message of length 17. The uglyness in `4*sizeof "123"' is just that it has 3 formatting style bugs (missing spaces around binary operator, space after sizeof, and missing parentheses for sizeof) and depends on the storage for a '.' being the same as the storage for the the '\0' terminator. I would write it as sizeof("255.255.255.255"). >> Oh, I see. This kind of definition is really annoying, and hard to keep all >> the >> occurrences consistent. Maybe a better way is use a macro to make that >> clear? >> >> #define IPV4_ADDRSZ (4 * sizeof "123") >> char buf[IPV4_ADDRSZ]; This is less clear, since it takes twice as much code to obfuscate the size in a macro for no benefits since the macro is only used once. >> This "ugly" definition comes from inet_ntoa() in /sys/libkern/inet_ntoa.c, >> I just copied the style without too much consideration, it's my fault. > > I'd just use 16. The inet_ntoa function is frankly inane. It attempts > to support chars that aren't 8 bits which would break so much stuff it > isn't funny. No, it assumes 8-bit chars. It's masking with 0xff is apparently copied from an old implementation that used plain chars. The userland implementation at the time it was committed does that, but uses a macro to do the masking and is missing lots of style bugs. The userland version now calls inet_ntop(). This is missing the design bug of using a static buffer. It calls inet_ntop4() for the ipv4 case. This is closer to being non-ugly: % static const char * % inet_ntop4(const u_char *src, char *dst, socklen_t size) % { % static const char fmt[] = "%u.%u.%u.%u"; % char tmp[sizeof "255.255.255.255"]; % int l; % % l = snprintf(tmp, sizeof(tmp), fmt, src[0], src[1], src[2], src[3]); % if (l <= 0 || (socklen_t) l >= size) { % errno = ENOSPC; % return (NULL); % } % strlcpy(dst, tmp, size); % return (dst); % } I would write this as: %%% CTASSERT(CHAR_BIT == 8); /* else src would be misintepreted */ static const char * inet_ntop4(const u_char *src, char *dst, socklen_t size) { int n; n = snprintf(dst, size, "%u.%u.%u.%u", src[0], src[1], src[2], src[3]); assert(n >= 0); /* CHAR_BIT == 8 imples 0 < n <= 16 */ if ((u_int)n >= size) { errno = ENOSPC; return (NULL); } return (dst); } %%% This is closer to the version in RELENG_6 than the current version. It doesn't use tmp[]] to preserve dst on error, and fixes the bounds checking without introducing several style bugs and not actually fixing the bounds checking. The old version was: if ((socklen_t)snprintf(dst, size, fmt, src[0], src[1], src[2], src[3] >= size) { ... } This is good enough since 0 < l <= 16 implies that the preposterou case (l <= 0) and the preposterous broken case ((socklen_t)l != l) can't happen, but it is easier to use correct bounds checking than to understant why bugs in the bounds checking are harmless. Bruce From owner-freebsd-net@FreeBSD.ORG Sun Nov 5 15:26:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1952916A403 for ; Sun, 5 Nov 2006 15:26:25 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id D34D043D5F for ; Sun, 5 Nov 2006 15:26:20 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id CCE01EB0ACD; Sun, 5 Nov 2006 23:26:19 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id MKzXV6EQUx4E; Sun, 5 Nov 2006 23:26:18 +0800 (CST) Received: from [192.168.1.32] (unknown [61.49.184.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id AFB8DEB098A; Sun, 5 Nov 2006 23:26:17 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=C+teUmUr3g3cF6uzbS08PSmZAWTMxHHl+7zUGZ4Rk8Eks05pyfS8U41T2j18AhIM3 8YVfdfc674NdQesWJCf2w== Message-ID: <454E0297.7060606@delphij.net> Date: Sun, 05 Nov 2006 23:26:15 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: MQ References: <20061102102807.GA23553@zen.inc> <4549C93A.9080308@delphij.net> <200611021232.45858.max@love2party.net> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enigC79923A3673BE4961C389100" Cc: Max Laier , freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 15:26:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC79923A3673BE4961C389100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MQ wrote: [snip] >> >> By the way, maybe printf should get better synchronized. > When I was addressing some problems in the bge(4), the > ill-synchronized printf made my console freezing before > I restarted the machine. Are you really sure that it's the culprit of freezing your console (I think I did not understood the issue)? Would you please explain a bit so we will be able to evaluate whether we need a change before 6.2-RELEASE is out the door? Thanks in advance! Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigC79923A3673BE4961C389100 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFTgKXOfuToMruuMARA6GtAJ9y5mawrI7dkyq489pVWjxNQWDuYwCdGlvs N+Q/NSsegiatqS+5e+j6y3Q= =jeKA -----END PGP SIGNATURE----- --------------enigC79923A3673BE4961C389100-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 5 16:47:23 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C12E16A412 for ; Sun, 5 Nov 2006 16:47:23 +0000 (UTC) (envelope-from rsf@ns.live555.com) Received: from ns.live555.com (ns.live555.com [66.80.62.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id C078A43D64 for ; Sun, 5 Nov 2006 16:47:22 +0000 (GMT) (envelope-from rsf@ns.live555.com) Received: from ns.live555.com (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.13.6/8.13.6) with ESMTP id kA5GlM7P065852 for ; Sun, 5 Nov 2006 08:47:22 -0800 (PST) (envelope-from rsf@ns.live555.com) Received: (from rsf@localhost) by ns.live555.com (8.13.6/8.13.6/Submit) id kA5GlMIV065851; Sun, 5 Nov 2006 08:47:22 -0800 (PST) (envelope-from rsf) Mime-Version: 1.0 Message-Id: Date: Sun, 5 Nov 2006 08:47:18 -0800 To: freebsd-net@FreeBSD.ORG From: Ross Finlayson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Subject: Posting restrictions on this mailing list (for spam control)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 16:47:23 -0000 Am I the only person who's tired of all of the spam on this mailing list? Why is this mailing list not set up so that only subscribers to the list can post to it? This has been standard mailing list procedure for several years now. Ross. From owner-freebsd-net@FreeBSD.ORG Sun Nov 5 17:05:35 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D053B16A40F for ; Sun, 5 Nov 2006 17:05:35 +0000 (UTC) (envelope-from spadge@fromley.net) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA60F43D5C for ; Sun, 5 Nov 2006 17:05:34 +0000 (GMT) (envelope-from spadge@fromley.net) Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com with ESMTP id <20061105170526.BHZE1865.mtaout03-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Sun, 5 Nov 2006 17:05:26 +0000 Received: from tobermory.home ([86.0.166.176]) by aamtaout02-winn.ispmail.ntl.com with ESMTP id <20061105170523.LXQB23938.aamtaout02-winn.ispmail.ntl.com@tobermory.home>; Sun, 5 Nov 2006 17:05:23 +0000 Received: from [192.168.124.185] (jupiter.home [192.168.124.185]) by tobermory.home (Postfix) with ESMTP id 3A765A79DD; Sun, 5 Nov 2006 17:05:17 +0000 (GMT) Message-ID: <454E19CC.7040208@fromley.net> Date: Sun, 05 Nov 2006 17:05:16 +0000 From: Spadge User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Ross Finlayson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.ORG Subject: Re: Posting restrictions on this mailing list (for spam control)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 17:05:35 -0000 Ross Finlayson wrote: > Am I the only person who's tired of all of the spam on this mailing > list? Why is this mailing list not set up so that only subscribers to > the list can post to it? This has been standard mailing list procedure > for several years now. Spam is annoying, for sure. But I think every now and then spamassassin, or whatever system the board uses, dies, and on those days we get a bunch of spam. Usually, though, it's fixed pretty quickly ... until the next time. It's quite possible that, as the list members aren't moderated, the sending bots actually sign up. I'm not sure about this, though. I've not tested the list with an unsigned address, either, but it's quite possible you do have to be a member to post. :) -- Spadge "Intoccabile" www.fromley.com From owner-freebsd-net@FreeBSD.ORG Mon Nov 6 03:36:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1394516A412 for ; Mon, 6 Nov 2006 03:36:48 +0000 (UTC) (envelope-from wwwrun@srv05.is-net.de) Received: from srv05.is-net.de (srv05.is-net.de [85.239.116.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id F38B543D69 for ; Mon, 6 Nov 2006 03:36:46 +0000 (GMT) (envelope-from wwwrun@srv05.is-net.de) Received: by srv05.is-net.de (Postfix, from userid 30) id 9E0136D9F8; Mon, 6 Nov 2006 04:04:00 +0100 (CET) To: freebsd-net@freebsd.org From: Protect Your Account Content-Transfer-Encoding: 8bit Message-Id: <20061106030400.9E0136D9F8@srv05.is-net.de> Date: Mon, 6 Nov 2006 04:04:00 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Wellsfargo Security Center X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ofsrep.alert_cpw@wellsfargo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2006 03:36:48 -0000 [1]Wells Fargo [2]Wells Fargo Credit Card Dear valued WellsFargo ® member: Due to concerns, for the safety and integrity of the wellsfargo account we have issued this warning message : We have noticed that your Wells Fargo online account needs to be updated once again, please enter your online account information, because we have to verify all of the online accounts after we have updated our Wells Fargo Online Banking site. To verify your online account and access your bank account, please click on the link below : [3][al_continue_off.gif] [4]Continue to Stop Payment This e-mail was sent to all of our Wells Fargo customers. Recently, we have found that many accounts were hacked. For further information, please contact our Customer Services. Contact Us: If you have questions, please do not respond to this message using the 'Reply' button. Wells Fargo Online^® customers, [5]Sign On to your secure banking session and click 'Contact Us'. If you are not a Wells Fargo Online customer, [6]contact us here. Online Customer Service Code: 0610SVCCD42703 References 1. http://www.sgtgrind.de/news/db/ 2. http://www.sgtgrind.de/news/db/ 3. http://www.sgtgrind.de/news/db/ 4. http://www.sgtgrind.de/news/db/ 5. http://www.sgtgrind.de/news/db/ 6. http://www.wellsfargo.com/per/per_ask_us.jhtml?cid=12779736424 From owner-freebsd-net@FreeBSD.ORG Mon Nov 6 07:12:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D00D16A40F for ; Mon, 6 Nov 2006 07:12:24 +0000 (UTC) (envelope-from public@troback.com) Received: from mail.gelita.se (212-162-182-244.skbbip.com [212.162.182.244]) by mx1.FreeBSD.org (Postfix) with ESMTP id C98F543D53 for ; Mon, 6 Nov 2006 07:12:22 +0000 (GMT) (envelope-from public@troback.com) Received: from server25.gelita.swe (212-162-182-242.skbbip.com [212.162.182.242]) by mail.gelita.se (Postfix) with ESMTP id 1466D10FA28 for ; Mon, 6 Nov 2006 08:12:03 +0100 (CET) Date: Mon, 6 Nov 2006 08:12:02 +0100 From: Anders =?ISO-8859-1?Q?Trob=E4ck?= To: freebsd-net@freebsd.org Message-ID: <20061106081202.1c2c087d@server25.gelita.swe> In-Reply-To: <454E19CC.7040208@fromley.net> References: <454E19CC.7040208@fromley.net> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.10.6; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Troback-MailScanner-Information: Please contact the ISP for more information X-Troback-MailScanner: Found to be clean X-Troback-MailScanner-From: public@troback.com X-Spam-Status: No Subject: Re: Posting restrictions on this mailing list (for spam control)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2006 07:12:24 -0000 On Sun, 05 Nov 2006 17:05:16 +0000 Spadge wrote: > Ross Finlayson wrote: > > Am I the only person who's tired of all of the spam on this mailing=20 > > list? Why is this mailing list not set up so that only subscribers > > to the list can post to it? This has been standard mailing list > > procedure for several years now. >=20 > Spam is annoying, for sure. But I think every now and then > spamassassin, or whatever system the board uses, dies, and on those > days we get a bunch of spam. Usually, though, it's fixed pretty > quickly ... until the next time. >=20 > It's quite possible that, as the list members aren't moderated, the=20 > sending bots actually sign up. I'm not sure about this, though. I've > not tested the list with an unsigned address, either, but it's quite=20 > possible you do have to be a member to post. >=20 > :) >=20 >=20 This is a test from a unsigned address! Will know soon is is OK to do that:-) --=20 =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 Microsoft is not the answer. Microsoft is the question. And 'No' is the answer! -------------------------------------------- Anders Trob=E4ck http://www.troback.com From owner-freebsd-net@FreeBSD.ORG Mon Nov 6 08:41:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA61E16A416 for ; Mon, 6 Nov 2006 08:41:24 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 391C643D78 for ; Mon, 6 Nov 2006 08:41:20 +0000 (GMT) (envelope-from mav@mavhome.dp.ua) X-Spam-Level: 50 [XX] (100%) IP is in RBL Received: from [195.248.178.122] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 17800871; Mon, 06 Nov 2006 10:41:18 +0200 Message-ID: <454EF529.1040108@mavhome.dp.ua> Date: Mon, 06 Nov 2006 10:41:13 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wesley Morgan References: <1161998582.00625762.1161985201@10.7.7.3> In-Reply-To: <1161998582.00625762.1161985201@10.7.7.3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ppp and mpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2006 08:41:24 -0000 Wesley Morgan wrote: > I'm using a DSL connection and user-ppp, but would like to use mpd > instead. I never had a problem with bellsouth DSL but this version > doesn't seem to work for me. I've got basically a vanilla ppp.conf and > mpd.conf. The logs from ppp and mpd are attached (sorry for the length). > I'm sure it's some crazy option that I've overlooked, but I can't seem > to figure it out. If anyone can help I'd be quite grateful! Thanks! > And mpd.links: > set pppoe service "netracer" Are you sure in this line? In ppp.conf you did not specify this parameter. Your ISP may not support such service-name. As I can see on mpd log, mpd sends requests but does not recieve answers. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Mon Nov 6 11:08:04 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4585616A559 for ; Mon, 6 Nov 2006 11:08:04 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19D1D43D46 for ; Mon, 6 Nov 2006 11:08:03 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kA6B82Qp013960 for ; Mon, 6 Nov 2006 11:08:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kA6B81eb013954 for freebsd-net@FreeBSD.org; Mon, 6 Nov 2006 11:08:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Nov 2006 11:08:01 GMT Message-Id: <200611061108.kA6B81eb013954@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2006 11:08:04 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/52585 net [netinet] [patch] Kernel panic with ipfw2 and syncooki o kern/92552 net A serious bug in most network drivers from 5.X to 6.X f kern/93220 net [inet6] nd6_lookup: failed to add route for a neighbor s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n 9 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 6 12:09:37 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9B8116A417 for ; Mon, 6 Nov 2006 12:09:37 +0000 (UTC) (envelope-from beastie@mra.co.id) Received: from mx1.mra.co.id (fw.mra.co.id [202.57.14.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1186C43D77; Mon, 6 Nov 2006 12:09:16 +0000 (GMT) (envelope-from beastie@mra.co.id) Received: from localhost (localhost.mra.co.id [127.0.0.1]) by mx1.mra.co.id (Postfix) with ESMTP id 2F02A72393; Mon, 6 Nov 2006 19:19:38 +0700 (WIT) Received: from mx1.mra.co.id ([127.0.0.1]) by localhost (mx1.mra.co.id [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28777-22; Mon, 6 Nov 2006 19:19:37 +0700 (WIT) Received: from beastie.mra.co.id (unknown [172.16.0.228]) by mx1.mra.co.id (Postfix) with ESMTP id EE8D672461; Mon, 6 Nov 2006 19:19:36 +0700 (WIT) From: Muhammad Reza To: freebsd-net@freebsd.org, freebsd-question@freebsd.org Content-Type: text/plain Date: Mon, 06 Nov 2006 08:15:40 +0700 Message-Id: <1162775740.16879.8.camel@beastie.mra.co.id> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-8) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mra.co.id Cc: Subject: pf.conf + altq problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2006 12:09:37 -0000 Dear All. I start with the simple rule set in my pf bridge machine to limit bandwidth 3Mbps from my server on lan to internet and from internet to my server on lan my_server_on_lan="172.16.0.228" internet="202.x.x.x" lan = "172.16.0.0/16" altq on xl1 bandwidth 100% cbq queue \ {int_out,dflt_out} queue int_out bandwidth 3Mb queue dflt_out bandwidth 16Kb cbq (default) altq on xl2 bandwidth 100% cbq queue {int_in,dflt_in} queue int_in bandwidth 3Mb queue dflt_in bandwidth 16Kb cbq (default) pass in on xl1 from any to $lan pass out on xl1 from $lan to any pass out on xl1 from $my_server_on_lan to $internet \ keep state queue (int_out) pass in on xl2 from $lan to any keep state pass out on xl2 from any to $lan keep state pass out on xl2 from $internet to $my_server_on_lan \ keep state queue (int_in) I have done some test with iperf with no luck. Is there something wrong with this rule set to acompilished my need ? Please help From owner-freebsd-net@FreeBSD.ORG Mon Nov 6 14:42:59 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C696616A416 for ; Mon, 6 Nov 2006 14:42:59 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DF2B43D69 for ; Mon, 6 Nov 2006 14:42:56 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (nwluzy@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kA6EgnSs088100; Mon, 6 Nov 2006 15:42:55 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kA6Egnci088099; Mon, 6 Nov 2006 15:42:49 +0100 (CET) (envelope-from olli) Date: Mon, 6 Nov 2006 15:42:49 +0100 (CET) Message-Id: <200611061442.kA6Egnci088099@lurza.secnetix.de> From: Oliver Fromme To: freebsd-net@FreeBSD.ORG, spadge@fromley.net In-Reply-To: <454E19CC.7040208@fromley.net> X-Newsgroups: list.freebsd-net User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 06 Nov 2006 15:42:55 +0100 (CET) Cc: Subject: Re: Posting restrictions on this mailing list (for spam control)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-chat@FreeBSD.ORG, spadge@fromley.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2006 14:42:59 -0000 Spadge wrote: > Ross Finlayson wrote: > > Am I the only person who's tired of all of the spam on this mailing > > list? Why is this mailing list not set up so that only subscribers to > > the list can post to it? This has been standard mailing list procedure > > for several years now. > > Spam is annoying, for sure. But I think every now and then spamassassin, > or whatever system the board uses, dies, and on those days we get a > bunch of spam. Usually, though, it's fixed pretty quickly ... until the > next time. > > It's quite possible that, as the list members aren't moderated, the > sending bots actually sign up. I'm not sure about this, though. I've not > tested the list with an unsigned address, either, but it's quite > possible you do have to be a member to post. I'm not subsribed to any of the freebsd mailing lists, but I read many of them through an NNTP gateway. I can post to them, but some lists afre set up to require approval of mails by a moderator, so my mails are somewhat delayed, but that's not a big problem. I think -hackers, -current and -arch are the lists requiring approval. Best regards Oliver PS: Please reply to -chat (this is off-topic on -net). -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "[...] one observation we can make here is that Python makes an excellent pseudocoding language, with the wonderful attribute that it can actually be executed." -- Bruce Eckel From owner-freebsd-net@FreeBSD.ORG Mon Nov 6 18:11:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E53D216A4B3 for ; Mon, 6 Nov 2006 18:11:06 +0000 (UTC) (envelope-from mendonan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8404A43D6D for ; Mon, 6 Nov 2006 18:11:02 +0000 (GMT) (envelope-from mendonan@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so813037uge for ; Mon, 06 Nov 2006 10:11:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IQwINgfdIozG/oMMYSWik1YzDOqclpJsOLeeSRFdUOL6jvuAt9jmnIhRALc8jHLqY/plLBhFUFKd74X2S/o0Xkhwo31v+SkMxefXS+wxoWA3am02GgaL0bsK+oDQOJ2EC37NG01XPeiCtgzwUGvcoYWUtqeaVmfxGSY890duJn4= Received: by 10.78.193.19 with SMTP id q19mr7061036huf.1162836660371; Mon, 06 Nov 2006 10:11:00 -0800 (PST) Received: by 10.78.200.16 with HTTP; Mon, 6 Nov 2006 10:11:00 -0800 (PST) Message-ID: <94c7120b0611061011v6ff0dcbfh34778d4760a619cf@mail.gmail.com> Date: Tue, 7 Nov 2006 02:11:00 +0800 From: "Senandung Mendonan" To: "David Christensen" , freebsd-net@freebsd.org In-Reply-To: <94c7120b0610112005g62c0a137j97a3adf0d97c2ba5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <94c7120b0608181236j2475301ds1379510f94b12d34@mail.gmail.com> <09BFF2FA5EAB4A45B6655E151BBDD90301D42713@NT-IRVA-0750.brcm.ad.broadcom.com> <94c7120b0608210209o482fef7ev1b4922d0597af666@mail.gmail.com> <94c7120b0610112005g62c0a137j97a3adf0d97c2ba5@mail.gmail.com> Cc: Subject: Re: Problem with IBM NetXtreme 1000-T GigaEthernet Adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2006 18:11:07 -0000 Hi David / list, Just to drop a note that this situation still persists, even with the latest 6.2-BETA3. I have issued a pr. In addition, I'm willing to send you (or anyone in the list) the NIC in question for troubleshooting. Would very much welcome a helping hand.. Thanks... :) On 10/12/06, Senandung Mendonan wrote: > David / list, > > Some new developments/leads on this issue:- > > On 8/21/06, Senandung Mendonan wrote: > > > > > If you could attach a dump of dmesg that shows the messages from the > > > driver that might help too. > > > > Here's the dmesg for the dual-port version:- > > > > pci5: on pcib4 > > bge0: mem > > 0xdcff0000-0xdcffffff irq 48 at device 1.0 on pci5 > > miibus0: on bge0 > > brgphy0: on miibus0 > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > > 1000baseTX-FDX, auto > > bge0: Ethernet address: 00:10:18:11:2a:0d > > bge1: mem > > 0xdcfe0000-0xdcfeffff irq 49 at device 1.1 on pci5 > > miibus1: on bge1 > > brgphy1: on miibus1 > > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > > 1000baseTX-FDX, auto > > bge1: Ethernet address: 00:10:18:11:2a:0a > > > > > > After deploying on a few servers, we realized some of the servers work > OK, and some not, although the cards are apparently same model, with > same dmesg shown above. > > Upon closer inspection, we found out that the two NICs' chipsets > differ in minor revision:- > > 1. The working NIC:- > > Broadcom BCM5704CKRB TS0341 P13 706741 B (manufactured 23/12/2004, > older revision of the same BCM5704C chipset supported by the FreeBSD > bge driver. > > ( Picture: http://absolute-p.ath.cx/wp-content/uploads/2006/10/old-23-12-2004.jpg > ) > > 2. The intermittent NIC:- > > Broadcom BCM5704CKRB CS0424 P20 723153B B (unknown manufacture date, > but probably newer than the working NIC). > > ( Picture: http://absolute-p.ath.cx/wp-content/uploads/2006/10/new.jpg ) > > I have yet to try a 6.2 kernel, the site has no internet connections > and a bit far, so takes a while for me to try that. In the meantime, > perhaps with the chipset details you have some ideas? > > Thanks. > > --mendonan > "Yang mimpikan secangkir kopi panas dengan selimut.." > (Dreaming of a cup of hot coffee, and a blanket..") > -- --mendonan "Yang mimpikan secangkir kopi panas dengan selimut.." (Dreaming of a cup of hot coffee, and a blanket..") From owner-freebsd-net@FreeBSD.ORG Mon Nov 6 19:57:16 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB14B16A40F for ; Mon, 6 Nov 2006 19:57:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23B1643D68 for ; Mon, 6 Nov 2006 19:57:10 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8DCDF46D4F; Mon, 6 Nov 2006 14:57:10 -0500 (EST) Date: Mon, 6 Nov 2006 19:57:10 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Spadge In-Reply-To: <454E19CC.7040208@fromley.net> Message-ID: <20061106195524.P39454@fledge.watson.org> References: <454E19CC.7040208@fromley.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.ORG Subject: Re: Posting restrictions on this mailing list (for spam control)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2006 19:57:16 -0000 On Sun, 5 Nov 2006, Spadge wrote: > Ross Finlayson wrote: >> Am I the only person who's tired of all of the spam on this mailing list? >> Why is this mailing list not set up so that only subscribers to the list >> can post to it? This has been standard mailing list procedure for several >> years now. > > Spam is annoying, for sure. But I think every now and then spamassassin, or > whatever system the board uses, dies, and on those days we get a bunch of > spam. Usually, though, it's fixed pretty quickly ... until the next time. > > It's quite possible that, as the list members aren't moderated, the sending > bots actually sign up. I'm not sure about this, though. I've not tested the > list with an unsigned address, either, but it's quite possible you do have > to be a member to post. Once in a while, the spam filtering on FreeBSD.org keels over and the level of spam briefly increases until it's fixed. Over the weekend, the FreeBSD.org hardware was relocated to a rolling rack in preparation for it to be moved to a different colo, since Yahoo! is vacating the current colo it's sitting in. Disruption of this type often results in a window where spamassassin isn't processing in-bound mail, so it bypasses spam filtering; I expect this is probably what happened with respect to a bump in the spam rate in the last day or two. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Mon Nov 6 21:08:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5EC316A407 for ; Mon, 6 Nov 2006 21:08:42 +0000 (UTC) (envelope-from amarat@ksu.ru) Received: from zealot.ksu.ru (zealot.ksu.ru [194.85.245.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3988D43D4C for ; Mon, 6 Nov 2006 21:08:41 +0000 (GMT) (envelope-from amarat@ksu.ru) Received: from [127.0.0.1] (localhost.lnet [127.0.0.1]) by zealot.ksu.ru (8.13.8/8.13.8) with ESMTP id kA6L8X8J081047 for ; Tue, 7 Nov 2006 00:08:34 +0300 (MSK) (envelope-from amarat@ksu.ru) Message-ID: <454FA451.2030407@ksu.ru> Date: Tue, 07 Nov 2006 00:08:33 +0300 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.13) Gecko/20060514 X-Accept-Language: ru, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: a very strange netstat output and problem when using transparent proxy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2006 21:08:43 -0000 Hello! I've encountered a very strange situation about two hours ago. I use squid as transparent proxy and forward all the packets from port 80 to port 8000. Problem is, first of all, I have a lot of ierrs on interface when looking to interface stats using netstat. The second problem is far more serious: after a short period of time I have a completely frozen system that can only send data, but very rarely receive and generates a huge amount of ierrs on interface. ipfw rules are as follows: 00001 allow ip from any to any via lo0 00002 deny ip from any to 127.0.0.0/8 00003 deny ip from 127.0.0.0/8 to any 00010 fwd xx.xx.xx.xx,8000 tcp from any to me dst-port 80 65535 allow ip from any to any problem with ierrs disappears after I delete rule with forward, but I need this rule :( -- SY, Marat From owner-freebsd-net@FreeBSD.ORG Mon Nov 6 23:33:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3E0216A4C8 for ; Mon, 6 Nov 2006 23:33:46 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA8A043D58 for ; Mon, 6 Nov 2006 23:33:45 +0000 (GMT) (envelope-from antinvidia@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so891658uge for ; Mon, 06 Nov 2006 15:33:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=namkUyF9vknoeVJWKgKuQYpPkfoTtqiz0xgycLsG7O8S6cWPiPrL74Ij0v3kx3bQu15SqkZJfg/6Ijg5zBYIqUEC7IF/hR+BjcfY6PM5wswZKJ/hP5ZV64/rIHYhf0WQQTN47zn9VEVMzD8lGEGTtCWJdniXxidRzWnPqF2Y//8= Received: by 10.78.203.13 with SMTP id a13mr7438405hug.1162856024125; Mon, 06 Nov 2006 15:33:44 -0800 (PST) Received: by 10.78.167.2 with HTTP; Mon, 6 Nov 2006 15:33:44 -0800 (PST) Message-ID: Date: Mon, 6 Nov 2006 23:33:44 +0000 From: MQ To: freebsd-net@freebsd.org In-Reply-To: <20061106195524.P39454@fledge.watson.org> MIME-Version: 1.0 References: <454E19CC.7040208@fromley.net> <20061106195524.P39454@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Posting restrictions on this mailing list (for spam control)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2006 23:33:46 -0000 2006/11/6, Robert Watson : > > > On Sun, 5 Nov 2006, Spadge wrote: > > > Ross Finlayson wrote: > >> Am I the only person who's tired of all of the spam on this mailing > list? > >> Why is this mailing list not set up so that only subscribers to the > list > >> can post to it? This has been standard mailing list procedure for > several > >> years now. > > > > Spam is annoying, for sure. But I think every now and then spamassassin, > or > > whatever system the board uses, dies, and on those days we get a bunch > of > > spam. Usually, though, it's fixed pretty quickly ... until the next > time. > > > > It's quite possible that, as the list members aren't moderated, the > sending > > bots actually sign up. I'm not sure about this, though. I've not tested > the > > list with an unsigned address, either, but it's quite possible you do > have > > to be a member to post. > > Once in a while, the spam filtering on FreeBSD.org keels over and the > level of > spam briefly increases until it's fixed. Over the weekend, the > FreeBSD.org > hardware was relocated to a rolling rack in preparation for it to be moved > to > a different colo, since Yahoo! is vacating the current colo it's sitting > in. > Disruption of this type often results in a window where spamassassin isn't > processing in-bound mail, so it bypasses spam filtering; I expect this is > probably what happened with respect to a bump in the spam rate in the last > day > or two. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to The mailing list denied all the mail from my previous mail box provided by Netease(NASDAQ: NTES) from China mainland, even I subscribed to -net, and asked me to wait the moderator's approval. But after I changed my mailbox to gmail, the filter never returned such message. I don't know why I can't post to -net even I subscribed to it. Maybe a misconfiguration? From owner-freebsd-net@FreeBSD.ORG Mon Nov 6 23:37:31 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEF3716A403 for ; Mon, 6 Nov 2006 23:37:31 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BDEF43D7F for ; Mon, 6 Nov 2006 23:37:19 +0000 (GMT) (envelope-from antinvidia@gmail.com) Received: by nf-out-0910.google.com with SMTP id n15so483090nfc for ; Mon, 06 Nov 2006 15:37:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=DP197OjCBrQaUZwpQ0mU2R5ZcSSMbyA4qaO5WSWPbwzkerMmkc8W9VtfI0egsAim/h1Sct16JzsW1YjqXr3CSEKdo3NaEcU3GSIbJxdDGquY8xH0k1OdoGizeIgpWt1qCU2Uu1Co7hDoKoNMd0t/+nAjrua16jRYeFxf+K6r0As= Received: by 10.78.172.20 with SMTP id u20mr7480484hue.1162856237125; Mon, 06 Nov 2006 15:37:17 -0800 (PST) Received: by 10.78.167.2 with HTTP; Mon, 6 Nov 2006 15:37:16 -0800 (PST) Message-ID: Date: Mon, 6 Nov 2006 23:37:16 +0000 From: MQ To: "Senandung Mendonan" In-Reply-To: <94c7120b0611061011v6ff0dcbfh34778d4760a619cf@mail.gmail.com> MIME-Version: 1.0 References: <94c7120b0608181236j2475301ds1379510f94b12d34@mail.gmail.com> <09BFF2FA5EAB4A45B6655E151BBDD90301D42713@NT-IRVA-0750.brcm.ad.broadcom.com> <94c7120b0608210209o482fef7ev1b4922d0597af666@mail.gmail.com> <94c7120b0610112005g62c0a137j97a3adf0d97c2ba5@mail.gmail.com> <94c7120b0611061011v6ff0dcbfh34778d4760a619cf@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Problem with IBM NetXtreme 1000-T GigaEthernet Adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2006 23:37:31 -0000 2006/11/6, Senandung Mendonan : > > Hi David / list, > > Just to drop a note that this situation still persists, even with the > latest 6.2-BETA3. I have issued a pr. In addition, I'm willing to send > you (or anyone in the list) the NIC in question for troubleshooting. > > Would very much welcome a helping hand.. > > Thanks... :) > > On 10/12/06, Senandung Mendonan wrote: > > David / list, > > > > Some new developments/leads on this issue:- > > > > On 8/21/06, Senandung Mendonan wrote: > > > > > > > If you could attach a dump of dmesg that shows the messages from the > > > > driver that might help too. > > > > > > Here's the dmesg for the dual-port version:- > > > > > > pci5: on pcib4 > > > bge0: mem > > > 0xdcff0000-0xdcffffff irq 48 at device 1.0 on pci5 > > > miibus0: on bge0 > > > brgphy0: on miibus0 > > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > > > 1000baseTX-FDX, auto > > > bge0: Ethernet address: 00:10:18:11:2a:0d > > > bge1: mem > > > 0xdcfe0000-0xdcfeffff irq 49 at device 1.1 on pci5 > > > miibus1: on bge1 > > > brgphy1: on miibus1 > > > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > > > 1000baseTX-FDX, auto > > > bge1: Ethernet address: 00:10:18:11:2a:0a > > > > > > > > > > After deploying on a few servers, we realized some of the servers work > > OK, and some not, although the cards are apparently same model, with > > same dmesg shown above. > > > > Upon closer inspection, we found out that the two NICs' chipsets > > differ in minor revision:- > > > > 1. The working NIC:- > > > > Broadcom BCM5704CKRB TS0341 P13 706741 B (manufactured 23/12/2004, > > older revision of the same BCM5704C chipset supported by the FreeBSD > > bge driver. > > > > ( Picture: > http://absolute-p.ath.cx/wp-content/uploads/2006/10/old-23-12-2004.jpg > > ) > > > > 2. The intermittent NIC:- > > > > Broadcom BCM5704CKRB CS0424 P20 723153B B (unknown manufacture date, > > but probably newer than the working NIC). > > > > ( Picture: http://absolute-p.ath.cx/wp-content/uploads/2006/10/new.jpg ) > > > > I have yet to try a 6.2 kernel, the site has no internet connections > > and a bit far, so takes a while for me to try that. In the meantime, > > perhaps with the chipset details you have some ideas? > > > > Thanks. > > > > --mendonan > > "Yang mimpikan secangkir kopi panas dengan selimut.." > > (Dreaming of a cup of hot coffee, and a blanket..") > > > > > -- > --mendonan > "Yang mimpikan secangkir kopi panas dengan selimut.." > (Dreaming of a cup of hot coffee, and a blanket..") > _______________________________________________ > 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" > Would you please have a short test on the DEVICE_POLLING facility, and post the kern.polling.lost_polls after booting for a while here? From owner-freebsd-net@FreeBSD.ORG Tue Nov 7 00:14:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4723C16A415 for ; Tue, 7 Nov 2006 00:14:01 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E40D43D73 for ; Tue, 7 Nov 2006 00:13:02 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A69E9.dip.t-dialin.net [84.154.105.233]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id kA70Cxxl028062; Tue, 7 Nov 2006 01:13:00 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.13.6/8.13.6) with ESMTP id kA70CvSS005011; Tue, 7 Nov 2006 01:12:58 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost [127.0.0.1]) by fire.jhs.private (8.13.6/8.13.6) with ESMTP id kA70CvRb087920; Tue, 7 Nov 2006 01:12:57 +0100 (CET) (envelope-from jhs@fire.jhs.private) Message-Id: <200611070012.kA70CvRb087920@fire.jhs.private> To: MQ From: "Julian Stacey" Organization: http://berklix.com BSD Unix C Net Consultancy, Munich/Muenchen User-agent: EXMH http://beedub.com/exmh/ on FreeBSD http://freebsd.org X-URL: http://berklix.com X-Fallback: jhs@mail.brierdr.com, jhs@freebsd.org, jhs@berklix.net In-reply-to: Your message of "Mon, 06 Nov 2006 23:33:44 GMT." Date: Tue, 07 Nov 2006 01:12:57 +0100 Sender: jhs@flat.berklix.net Cc: freebsd-net@freebsd.org Subject: Re: Posting restrictions on this mailing list (for spam control)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2006 00:14:01 -0000 > The mailing list denied all the mail from my previous mail box provided by > Netease(NASDAQ: NTES) from China mainland, even I subscribed to -net, and > asked me to wait the moderator's approval. But after I changed my mailbox to > gmail, the filter never returned such message. I don't know why I can't post > to -net even I subscribed to it. Maybe a misconfiguration? Maybe your sender address is getting mapped to something else when it leaves China, & then freebsd.org thinks mail is not from sub'd address ? Could be the problem is on the China national internet gateway that vets what goes in & out of China. It may be someone in China needs to tell someone on the China gate that @freebsd.org lists are just technology lists & quite safe to pass. -- Julian Stacey. BSD Unix C Net Consultancy, Munich/Muenchen http://berklix.com Mail Ascii, not HTML. Ihr Rauch = mein allergischer Kopfschmerz. http://berklix.org/free-software From owner-freebsd-net@FreeBSD.ORG Tue Nov 7 02:13:50 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D94EF16A403 for ; Tue, 7 Nov 2006 02:13:50 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from ms-smtp-04.southeast.rr.com (ms-smtp-04.southeast.rr.com [24.25.9.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8078943D53 for ; Tue, 7 Nov 2006 02:13:48 +0000 (GMT) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (cpe-024-211-118-154.sc.res.rr.com [24.211.118.154]) by ms-smtp-04.southeast.rr.com (8.13.6/8.13.6) with ESMTP id kA72DkH9016720; Mon, 6 Nov 2006 21:13:46 -0500 (EST) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.13.8/8.13.8) with ESMTP id kA72DjCJ065321; Mon, 6 Nov 2006 21:13:46 -0500 (EST) (envelope-from morganw@chemikals.org) Date: Mon, 6 Nov 2006 21:13:45 -0500 (EST) From: Wesley Morgan To: Alexander Motin In-Reply-To: <454EF529.1040108@mavhome.dp.ua> Message-ID: <20061106211224.N51655@volatile.chemikals.org> References: <1161998582.00625762.1161985201@10.7.7.3> <454EF529.1040108@mavhome.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: freebsd-net@freebsd.org Subject: Re: ppp and mpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2006 02:13:50 -0000 On Mon, 6 Nov 2006, Alexander Motin wrote: > Wesley Morgan wrote: >> I'm using a DSL connection and user-ppp, but would like to use mpd instead. >> I never had a problem with bellsouth DSL but this version doesn't seem to >> work for me. I've got basically a vanilla ppp.conf and mpd.conf. The logs >> from ppp and mpd are attached (sorry for the length). I'm sure it's some >> crazy option that I've overlooked, but I can't seem to figure it out. If >> anyone can help I'd be quite grateful! Thanks! > >> And mpd.links: >> set pppoe service "netracer" > > Are you sure in this line? In ppp.conf you did not specify this parameter. > Your ISP may not support such service-name. As I can see on mpd log, mpd > sends requests but does not recieve answers. I'm pretty sure I tried that before, but for good measure I tried it again... No dice, unfortunately. -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Tue Nov 7 05:15:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB6BB16A403; Tue, 7 Nov 2006 05:15:51 +0000 (UTC) (envelope-from sivakumar.subramani@wipro.com) Received: from wip-ectls-mx1.wipro.com (wip-ectls-mx1.wipro.com [203.91.193.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D014543D60; Tue, 7 Nov 2006 05:15:50 +0000 (GMT) (envelope-from sivakumar.subramani@wipro.com) Received: from wip-ectls-mx1.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 88DFC220452; Tue, 7 Nov 2006 10:45:57 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ectls-mx1.wipro.com (Postfix) with ESMTP id 7BE422203FA; Tue, 7 Nov 2006 10:45:57 +0530 (IST) Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 10:39:44 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Nov 2006 10:39:23 +0530 Message-ID: <821C7AD2A9F78942B86059792262577315B072@blr-m3-msg.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Regarding Jumbo frame implementation in bge Thread-Index: AccCKuWHHs83d+2ySZGPKZxVGjgg7Q== From: To: , X-OriginalArrivalTime: 07 Nov 2006 05:09:44.0457 (UTC) FILETIME=[F02AD790:01C7022A] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Regarding Jumbo frame implementation in bge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2006 05:15:51 -0000 Hi, =0D In bge driver, we have BGE_JUMBO_FRAMELEN defined to 9018. if_bgereg.h:#define BGE_JUMBO_FRAMELEN 9018 =0D This macro is used to allocate the memory for jumbo buffer. If I have a MTU size of 2000, still bge will allocate the jumbo buffer of size BGE_JUMBO_FRAMELEN. Instead can we make the size to be depend on the MTU. I mean instead of using BGE_JUMBO_FRAMELEN macro we can use MTU + IP header + CRC for Jumbo buffer size. =0D Any reason for allocating a hard coded 9018 size all Jumbo MTU frame (whether it is 9000 / 2000)? =0D Thanks, ~Siva The information contained in this electronic message and any attachments to= this message are intended for the exclusive use of the addressee(s) and= may contain proprietary, confidential or privileged information. If you= are not the intended recipient, you should not disseminate, distribute or= copy this e-mail. Please notify the sender immediately and destroy all= copies of this message and any attachments.=0D WARNING: Computer viruses can be transmitted via email. The recipient= should check this email and any attachments for the presence of viruses.= The company accepts no liability for any damage caused by any virus= transmitted by this email. =0D www.wipro.com From owner-freebsd-net@FreeBSD.ORG Tue Nov 7 13:58:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A74216A403 for ; Tue, 7 Nov 2006 13:58:58 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96AE143D81 for ; Tue, 7 Nov 2006 13:58:49 +0000 (GMT) (envelope-from mav@mavhome.dp.ua) X-Spam-Level: 50 [XX] (100%) IP is in RBL Received: from [195.248.178.122] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 17837154; Tue, 07 Nov 2006 15:58:48 +0200 Message-ID: <45509112.2050204@mavhome.dp.ua> Date: Tue, 07 Nov 2006 15:58:42 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Volodymyr Kostyrko References: <1162614203.00630092.1162603801@10.7.7.3> In-Reply-To: <1162614203.00630092.1162603801@10.7.7.3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, mpd-users@lists.sourceforge.net Subject: Re: mpd4 on sparc64 problem (maybe netgraph involved) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2006 13:58:58 -0000 I think it can be big/small-endian problem. I can't check it as I do not have such hardware. Send me please previous part of log with LCP negotiation. Or even all logs with "log +all". Volodymyr Kostyrko wrote: > I have a host machine (i386) with many i386 clients and one sparc64 all > configured the same way. All i386 client work just fine, while sparc64 > one refuses to do so. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Tue Nov 7 16:28:17 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D2ED16A4F4 for ; Tue, 7 Nov 2006 16:28:17 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20A3143D77 for ; Tue, 7 Nov 2006 16:27:13 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (sjivid@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kA7GR6Y8059316; Tue, 7 Nov 2006 17:27:12 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kA7GR6LB059312; Tue, 7 Nov 2006 17:27:06 +0100 (CET) (envelope-from olli) Date: Tue, 7 Nov 2006 17:27:06 +0100 (CET) Message-Id: <200611071627.kA7GR6LB059312@lurza.secnetix.de> From: Oliver Fromme To: freebsd-net@FreeBSD.ORG, amarat@ksu.ru In-Reply-To: <454FA451.2030407@ksu.ru> X-Newsgroups: list.freebsd-net User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 07 Nov 2006 17:27:12 +0100 (CET) Cc: Subject: Re: a very strange netstat output and problem when using transparent proxy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@FreeBSD.ORG, amarat@ksu.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2006 16:28:17 -0000 Marat N.Afanasyev wrote: > I've encountered a very strange situation about two hours ago. I use > squid as transparent proxy and forward all the packets from port 80 to > port 8000. Problem is, first of all, I have a lot of ierrs on interface > when looking to interface stats using netstat. What kind of interface is that? Excerpt from dmesg, ifconfig and netstat -i might be useful. In general, errors on the interface usually indicate a hardware error (NIC, cables, port). However, it might also be a driver bug. > The second problem is far > more serious: after a short period of time I have a completely frozen > system that can only send data, but very rarely receive and generates a > huge amount of ierrs on interface. > > ipfw rules are as follows: > > 00001 allow ip from any to any via lo0 > 00002 deny ip from any to 127.0.0.0/8 > 00003 deny ip from 127.0.0.0/8 to any > 00010 fwd xx.xx.xx.xx,8000 tcp from any to me dst-port 80 > 65535 allow ip from any to any > > problem with ierrs disappears after I delete rule with forward, but I > need this rule :( In that rule, is "xx.xx.xx.xx" an IP address configured on your NIC, or is it 127.0.0.1? If the former, try to replace it with 127.0.0.1 and check if that improves the situation. However, the FWD line should not cause ierrs on the NIC. If you're sure that your hardware is good, then there's probably a bug somewhere. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. C++: "an octopus made by nailing extra legs onto a dog" -- Steve Taylor, 1998 From owner-freebsd-net@FreeBSD.ORG Tue Nov 7 16:39:10 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E9E416A403 for ; Tue, 7 Nov 2006 16:39:10 +0000 (UTC) (envelope-from amarat@ksu.ru) Received: from zealot.ksu.ru (zealot.ksu.ru [194.85.245.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AD8343D6D for ; Tue, 7 Nov 2006 16:39:02 +0000 (GMT) (envelope-from amarat@ksu.ru) Received: from [127.0.0.1] (localhost.lnet [127.0.0.1]) by zealot.ksu.ru (8.13.8/8.13.8) with ESMTP id kA7Gcvos088472; Tue, 7 Nov 2006 19:38:58 +0300 (MSK) (envelope-from amarat@ksu.ru) Message-ID: <4550B6A1.9090207@ksu.ru> Date: Tue, 07 Nov 2006 19:38:57 +0300 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.13) Gecko/20060514 X-Accept-Language: ru, en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG, amarat@ksu.ru References: <200611071627.kA7GR6LB059312@lurza.secnetix.de> In-Reply-To: <200611071627.kA7GR6LB059312@lurza.secnetix.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: a very strange netstat output and problem when using transparent proxy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2006 16:39:10 -0000 Oliver Fromme wrote: > Marat N.Afanasyev wrote: > > I've encountered a very strange situation about two hours ago. I use > > squid as transparent proxy and forward all the packets from port 80 to > > port 8000. Problem is, first of all, I have a lot of ierrs on interface > > when looking to interface stats using netstat. > > What kind of interface is that? Excerpt from dmesg, > ifconfig and netstat -i might be useful. bge0: flags=8843 mtu 1500 options=1b inet6 fe80::250:45ff:fe5f:4f78%bge0 prefixlen 64 scopeid 0x1 inet xx.xx.xx.xx netmask 0xffffffc0 broadcast xx.xx.xx.xx ether 00:50:45:5f:4f:78 media: Ethernet autoselect (100baseTX ) status: active bge0 1500 00:50:45:5f:4f:78 2341018 799 3062828 0 0 % uptime 7:34PM up 40 mins, 3 users, load averages: 0.14, 0.16, 0.08 Hardware is clean. Each of my boxes with broadcom 5704 has the same problem. Patchcords are no longer than 4 feet, plugged into catalyst 2960 directly without patchpanels. > In general, errors on the interface usually indicate a > hardware error (NIC, cables, port). However, it might > also be a driver bug. > > > The second problem is far > > more serious: after a short period of time I have a completely frozen > > system that can only send data, but very rarely receive and generates a > > huge amount of ierrs on interface. > > > > ipfw rules are as follows: > > > > 00001 allow ip from any to any via lo0 > > 00002 deny ip from any to 127.0.0.0/8 > > 00003 deny ip from 127.0.0.0/8 to any > > 00010 fwd xx.xx.xx.xx,8000 tcp from any to me dst-port 80 > > 65535 allow ip from any to any > > > > problem with ierrs disappears after I delete rule with forward, but I > > need this rule :( > > In that rule, is "xx.xx.xx.xx" an IP address configured > on your NIC, or is it 127.0.0.1? If the former, try to > replace it with 127.0.0.1 and check if that improves the > situation. Real IP address. I've already switched forward off and make squid listen on 80 instead. Problem persists. > > However, the FWD line should not cause ierrs on the NIC. > If you're sure that your hardware is good, then there's > probably a bug somewhere. > > Best regards > Oliver > I can say that i was finally wrong. problem is caused not by ipfw, as i think, but rather with broadcom 5704 based NIC. This NIC somehow drops Ethernet frames. I'm still wandering, why. -- SY, Marat From owner-freebsd-net@FreeBSD.ORG Tue Nov 7 16:59:53 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84C3216A403; Tue, 7 Nov 2006 16:59:53 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2ED2A43D45; Tue, 7 Nov 2006 16:59:52 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by rtp-iport-2.cisco.com with ESMTP; 07 Nov 2006 11:59:51 -0500 X-IronPort-AV: i="4.09,397,1157342400"; d="scan'208"; a="109013701:sNHT53981928" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA7Gxo1Y013076; Tue, 7 Nov 2006 08:59:50 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA7GxoW4028904; Tue, 7 Nov 2006 08:59:50 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 08:59:50 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 08:59:50 -0800 Message-ID: <4550BB5F.3040101@cisco.com> Date: Tue, 07 Nov 2006 11:59:11 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sivakumar.subramani@wipro.com References: <821C7AD2A9F78942B86059792262577315B072@blr-m3-msg.wipro.com> In-Reply-To: <821C7AD2A9F78942B86059792262577315B072@blr-m3-msg.wipro.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 16:59:50.0447 (UTC) FILETIME=[2350FBF0:01C7028E] DKIM-Signature: a=rsa-sha1; q=dns; l=1055; t=1162918790; x=1163782790; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Regarding=20Jumbo=20frame=20implementation=20in=20bge; X=v=3Dcisco.com=3B=20h=3DNUeMyZUQSQYJ+TclegbSlkBq1hc=3D; b=TmJcSIIr+qLlQKdTXzL+yewBysPQPunH041FXNRjARGjLx6kdDH5th7aG++OiM1frxK98YXK lOA0gkuCHU/QX+1DlFqnsJaHy2maknh6dPiLIRrZHhpVkKRV7ZqL/4ES; Authentication-Results: sj-dkim-3.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Regarding Jumbo frame implementation in bge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2006 16:59:53 -0000 sivakumar.subramani@wipro.com wrote: > Hi, > > In bge driver, we have BGE_JUMBO_FRAMELEN defined to 9018. > if_bgereg.h:#define BGE_JUMBO_FRAMELEN 9018 > > This macro is used to allocate the memory for jumbo buffer. If I have > a MTU size of 2000, still bge will allocate the jumbo buffer of size > BGE_JUMBO_FRAMELEN. Instead can we make the size to be depend on the > MTU. I mean instead of using BGE_JUMBO_FRAMELEN macro we can use MTU > + IP header + CRC for Jumbo buffer size. > > Any reason for allocating a hard coded 9018 size all Jumbo MTU frame > (whether it is 9000 / 2000)? > > Thanks, ~Siva > Sivakumar: Allocations are done via the zone managers.. and thus setup at kernel boot. A value like the MTU is set dynamically... So doing something like this would be questionable IMO.. I am sure it could be done.. but I don't see the value. In theory you have a waste for just a short time.. before its m_free'd R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Tue Nov 7 20:20:02 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC80C16A40F for ; Tue, 7 Nov 2006 20:20:02 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02E4C43D70 for ; Tue, 7 Nov 2006 20:20:01 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (dapatm@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kA7KJtOn073277; Tue, 7 Nov 2006 21:20:00 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kA7KJsAm073276; Tue, 7 Nov 2006 21:19:54 +0100 (CET) (envelope-from olli) Date: Tue, 7 Nov 2006 21:19:54 +0100 (CET) Message-Id: <200611072019.kA7KJsAm073276@lurza.secnetix.de> From: Oliver Fromme To: freebsd-net@FreeBSD.ORG, amarat@ksu.ru In-Reply-To: <4550B6A1.9090207@ksu.ru> X-Newsgroups: list.freebsd-net User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 07 Nov 2006 21:20:00 +0100 (CET) Cc: Subject: Re: a very strange netstat output and problem when using transparent proxy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@FreeBSD.ORG, amarat@ksu.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2006 20:20:02 -0000 Marat N.Afanasyev wrote: > bge0: flags=8843 mtu 1500 Ok, I also have a machine with bge(4) NIC within reach. I've had a look at it for similar symptoms (see below). > bge0 1500 00:50:45:5f:4f:78 2341018 799 3062828 > 0 0 799 is not good, but I wouldn't call it "huge amount of ierrs". Is that a typical number, or was that output taken before the problem (network freeze) appears? > % uptime > 7:34PM up 40 mins, 3 users, load averages: 0.14, 0.16, 0.08 Ok, 799 ierrs after 40 minuted uptime is definitely not good. :-) > Real IP address. I've already switched forward off and make squid listen > on 80 instead. Problem persists. OK, so it's a NIC problem, not IPFW-related. Here's output from my machine with bge(4) NIC: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll bge0 1500 00:16:35:... 7808595 35 3451475 0 0 Uptime is 8 days, the machine is only moderately loaded, but gets quite some amount of NFS traffic (as a client). OS is FreeBSD 6.2-PRELELEASE as of October 19th. Whie 35 ierrs in 8 days isn't much, I think it still indicates a problem somewhere. It should really be 0. (I haven't experienced any freezes or other problems, though.) Maybe you should ask on the -stable mailing list for others with bge(4) NICs to check. It looks like a bug in the driver. Oh by the way, do you have polling enabled? Try to switch in on (if disabled) or off (if enabled) and check whether it improves the situation for you. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "File names are infinite in length, where infinity is set to 255 characters." -- Peter Collinson, "The Unix File System" From owner-freebsd-net@FreeBSD.ORG Tue Nov 7 20:57:49 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A30716A416 for ; Tue, 7 Nov 2006 20:57:49 +0000 (UTC) (envelope-from amarat@ksu.ru) Received: from zealot.ksu.ru (zealot.ksu.ru [194.85.245.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E52343D4C for ; Tue, 7 Nov 2006 20:57:46 +0000 (GMT) (envelope-from amarat@ksu.ru) Received: from [127.0.0.1] (localhost.lnet [127.0.0.1]) by zealot.ksu.ru (8.13.8/8.13.8) with ESMTP id kA7KviH7089854; Tue, 7 Nov 2006 23:57:45 +0300 (MSK) (envelope-from amarat@ksu.ru) Message-ID: <4550F348.8040509@ksu.ru> Date: Tue, 07 Nov 2006 23:57:44 +0300 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.13) Gecko/20060514 X-Accept-Language: ru, en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG, amarat@ksu.ru References: <200611072019.kA7KJsAm073276@lurza.secnetix.de> In-Reply-To: <200611072019.kA7KJsAm073276@lurza.secnetix.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: a very strange netstat output and problem when using transparent proxy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2006 20:57:49 -0000 Oliver Fromme wrote: > Marat N.Afanasyev wrote: > > bge0: flags=8843 mtu 1500 > > Ok, I also have a machine with bge(4) NIC within reach. > I've had a look at it for similar symptoms (see below). > > > bge0 1500 00:50:45:5f:4f:78 2341018 799 3062828 > > 0 0 > > 799 is not good, but I wouldn't call it "huge amount of > ierrs". Is that a typical number, or was that output > taken before the problem (network freeze) appears? more typical is the following: % netstat -I bge0 -w 60 input (bge0) output packets errs bytes packets errs bytes colls 151993 241 111011660 172436 0 120848541 0 169867 388 118858096 192997 0 135783627 0 130524 407 91213775 145884 0 110857756 0 327168 1637 214730921 397193 0 275486626 0 385627 1027 254274520 471177 0 333456526 0 300184 720 198432049 367100 0 271325679 0 261095 5525 166910652 324112 0 251708900 0 278257 11998 176453071 349975 0 268865328 0 314383 8617 203347024 393589 0 301819857 0 195408 11647 129989509 246718 0 195720356 0 7163 23787 6087244 13165 0 7694485 0 2485 24786 1743165 6571 0 4015170 0 2202 26175 1117627 6225 0 3992217 0 and oops. none of two interfaces can any more process any incoming packet. ping drops increase to 99% > > > % uptime > > 7:34PM up 40 mins, 3 users, load averages: 0.14, 0.16, 0.08 > > Ok, 799 ierrs after 40 minuted uptime is definitely not > good. :-) > > > Real IP address. I've already switched forward off and make squid listen > > on 80 instead. Problem persists. > > OK, so it's a NIC problem, not IPFW-related. > > Here's output from my machine with bge(4) NIC: > > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > bge0 1500 00:16:35:... 7808595 35 3451475 0 0 > > Uptime is 8 days, the machine is only moderately loaded, > but gets quite some amount of NFS traffic (as a client). > OS is FreeBSD 6.2-PRELELEASE as of October 19th. as I said before, this problem persists on all my machines with 5704. > Whie 35 ierrs in 8 days isn't much, I think it still > indicates a problem somewhere. It should really be 0. > (I haven't experienced any freezes or other problems, > though.) > > Maybe you should ask on the -stable mailing list for > others with bge(4) NICs to check. It looks like a bug > in the driver. > > Oh by the way, do you have polling enabled? Try to > switch in on (if disabled) or off (if enabled) and check > whether it improves the situation for you. > > Best regards > Oliver > polling cannot be "safely" turned on smp, without eating a lot of cpu to interrupt processing. So, I run away from polling. -- SY, Marat From owner-freebsd-net@FreeBSD.ORG Tue Nov 7 21:06:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A41DD16A5F8 for ; Tue, 7 Nov 2006 21:06:55 +0000 (UTC) (envelope-from www@plaza.domeneshop.no) Received: from mx01.domeneshop.no (mx01.domeneshop.no [194.63.248.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2028B43D5A for ; Tue, 7 Nov 2006 21:06:53 +0000 (GMT) (envelope-from www@plaza.domeneshop.no) Received: from plaza.domeneshop.no (plaza.domeneshop.no [194.63.248.44]) by mx01.domeneshop.no (8.13.8/8.13.8) with ESMTP id kA7L3qkH019856 for ; Tue, 7 Nov 2006 22:06:52 +0100 Received: from plaza.domeneshop.no (localhost [127.0.0.1]) by plaza.domeneshop.no (8.13.8/8.13.8) with ESMTP id kA7KwJPk008238 for ; Tue, 7 Nov 2006 21:58:19 +0100 Received: (from www@localhost) by plaza.domeneshop.no (8.13.8/8.13.8/Submit) id kA7KwJFP008237; Tue, 7 Nov 2006 21:58:19 +0100 Date: Tue, 7 Nov 2006 21:58:19 +0100 Message-Id: <200611072058.kA7KwJFP008237@plaza.domeneshop.no> To: freebsd-net@freebsd.org X-Message-Key: d3d3LnB1bmtkaXNhc3RlcnMuY29tIC9nYWxsZXJ5L3RlbXBsYXRlcy9kZWZhdWx0Ly5waHAucGhw From: "JPMorgan Chase & Co." Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=1.2 required=4.0 X-Spam-Report: 1.2 hits, 4.0 required; * 0.6 REPLY_TO_EMPTY Reply-To: is empty * -0.0 SPF_HELO_PASS SPF: HELO matches SPF record * -0.5 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.1 HTML_TAG_EXIST_TBODY BODY: HTML has "tbody" tag * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.5 HTML_FONT_FACE_BAD BODY: HTML font face is not a word * 0.0 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.5 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag X-Virus-Scanned: by moam (http://www.moam.net/) X-Moam-Version: 0.93 MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Important Information Regarding Your Banking Account X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2006 21:06:55 -0000 [1][chase.gif] Dear Chase customer, As the Internet and information technology enable us to expand our services,we are committed to maintaining the trust customers have placed in us for protecting the privacy and security of information we have about you. In order to protect your information against unauthorized access, identity theft and account fraud we earnestly ask you to update your profile. WARNING: PLEASE REMEMBER YOU NEED TO CONFIRM ALL FIELDS OF THE FORM TO AVOID ACCOUNT BLOCK To resubmit your information, please click the link below: [2]Click here to update your profile If you received this notice and you are not the authorized account holder, please be aware that it is in violation of our policy to represent oneself as another Chase user. Such action may also be in violation of local, national, and/or international law. Chase is committed to assist law enforcement with any inquiries related to attempts to misappropriate personal information with the intent to commit fraud or theft. Information will be provided at the request of law enforcement agencies to ensure that perpetrators are prosecuted to the fullest extent of the law. Thank you for your time! © 2006 JPMorgan Chase & Co. _________________________________________________________________ References 1. file://localhost/tmp/tmpG_ZGjG.html 2. http://alphainfo.be/online.banking.account// From owner-freebsd-net@FreeBSD.ORG Tue Nov 7 23:38:05 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA62F16A416 for ; Tue, 7 Nov 2006 23:38:05 +0000 (UTC) (envelope-from landonf@threerings.net) Received: from smtp.earth.threerings.net (mail.threerings.net [64.127.109.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA07143D76 for ; Tue, 7 Nov 2006 23:38:03 +0000 (GMT) (envelope-from landonf@threerings.net) Received: from [192.168.54.11] (timor.sea.earth.threerings.net [192.168.54.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.earth.threerings.net (Postfix) with ESMTP id AFDFF6709 for ; Tue, 7 Nov 2006 15:38:02 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--48118304" To: freebsd-net@freebsd.org From: Landon Fuller Date: Tue, 7 Nov 2006 15:37:55 -0800 X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) Subject: [patch] tun(4) and tap(4) if_clone support. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2006 23:38:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1--48118304 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Nick Barkas (snb@threerings.net) and I have added interface cloning support to the tun(4) and tap(4) drivers. We maintained backwards-compatible support for devfs cloning, which is now disabled by default -- it can be re-enabled via a sysctl. Interfaces that are created via devfs cloning may still be removed via ifconfig destroy. The latest patch is available here http://www.opendarwin.org/~landonf/code/patch-tuntap_ifclone I've submitted kern/105228 with the patch, and I'd be most appreciative of comments/suggestions. Thanks, Landon Fuller --Apple-Mail-1--48118304 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFURjWlplZCE/15mMRAl4zAJ99/vsUb5McBn4Nnh26TjeWhjBWywCfW3rp Qhe36gBCw2+1nQ76Z8O9+g4= =5Mj1 -----END PGP SIGNATURE----- --Apple-Mail-1--48118304-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 8 10:29:49 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A725216A536 for ; Wed, 8 Nov 2006 10:29:49 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7018143EA0 for ; Wed, 8 Nov 2006 10:28:54 +0000 (GMT) (envelope-from antinvidia@gmail.com) Received: by nf-out-0910.google.com with SMTP id p77so158953nfc for ; Wed, 08 Nov 2006 02:28:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=M6ofoY+OKt5jGgavu8imHGgk02zcM9BN7jfc+ZStz9+R41Lq+u2t6wfsasPPch6DG3pLuaOdU2+uzse/nVl4MGvoznA2j0alwC88UaxbmQjHZLzAS9vPZIOZ0hPARW0okkQpeu/69o/M6pu2lkYhfp2zX+rVBRVXJAAy9fTSUWs= Received: by 10.78.128.11 with SMTP id a11mr7545212hud.1162981732561; Wed, 08 Nov 2006 02:28:52 -0800 (PST) Received: by 10.78.167.2 with HTTP; Wed, 8 Nov 2006 02:28:52 -0800 (PST) Message-ID: Date: Wed, 8 Nov 2006 10:28:52 +0000 From: MQ To: "Marat N.Afanasyev" In-Reply-To: <4550F348.8040509@ksu.ru> MIME-Version: 1.0 References: <200611072019.kA7KJsAm073276@lurza.secnetix.de> <4550F348.8040509@ksu.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: a very strange netstat output and problem when using transparent proxy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2006 10:29:49 -0000 2006/11/7, Marat N.Afanasyev : > > Oliver Fromme wrote: > > Marat N.Afanasyev wrote: > > > bge0: flags=8843 mtu 1500 > > > > Ok, I also have a machine with bge(4) NIC within reach. > > I've had a look at it for similar symptoms (see below). > > > > > bge0 1500 00:50:45:5f:4f:78 2341018 799 3062828 > > > 0 0 > > > > 799 is not good, but I wouldn't call it "huge amount of > > ierrs". Is that a typical number, or was that output > > taken before the problem (network freeze) appears? > > more typical is the following: > > % netstat -I bge0 -w 60 > input (bge0) output > packets errs bytes packets errs bytes colls > 151993 241 111011660 172436 0 120848541 0 > 169867 388 118858096 192997 0 135783627 0 > 130524 407 91213775 145884 0 110857756 0 > 327168 1637 214730921 397193 0 275486626 0 > 385627 1027 254274520 471177 0 333456526 0 > 300184 720 198432049 367100 0 271325679 0 > 261095 5525 166910652 324112 0 251708900 0 > 278257 11998 176453071 349975 0 268865328 0 > 314383 8617 203347024 393589 0 301819857 0 > 195408 11647 129989509 246718 0 195720356 0 > 7163 23787 6087244 13165 0 7694485 0 > 2485 24786 1743165 6571 0 4015170 0 > 2202 26175 1117627 6225 0 3992217 0 > > and oops. none of two interfaces can any more process any incoming > packet. ping drops increase to 99% > > > > > > % uptime > > > 7:34PM up 40 mins, 3 users, load averages: 0.14, 0.16, 0.08 > > > > Ok, 799 ierrs after 40 minuted uptime is definitely not > > good. :-) > > > > > Real IP address. I've already switched forward off and make squid > listen > > > on 80 instead. Problem persists. > > > > OK, so it's a NIC problem, not IPFW-related. > > > > Here's output from my machine with bge(4) NIC: > > > > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > > bge0 1500 00:16:35:... 7808595 35 3451475 0 0 > > > > Uptime is 8 days, the machine is only moderately loaded, > > but gets quite some amount of NFS traffic (as a client). > > OS is FreeBSD 6.2-PRELELEASE as of October 19th. > > as I said before, this problem persists on all my machines with 5704. > > > Whie 35 ierrs in 8 days isn't much, I think it still > > indicates a problem somewhere. It should really be 0. > > (I haven't experienced any freezes or other problems, > > though.) > > > > Maybe you should ask on the -stable mailing list for > > others with bge(4) NICs to check. It looks like a bug > > in the driver. > > > > Oh by the way, do you have polling enabled? Try to > > switch in on (if disabled) or off (if enabled) and check > > whether it improves the situation for you. > > > > Best regards > > Oliver > > > polling cannot be "safely" turned on smp, without eating a lot of cpu to > interrupt processing. So, I run away from polling. > > -- > SY, Marat > _______________________________________________ > 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" > Maybe bge(4) has some problems with it. At least I have found that on my laptop and servers, the bge_tick() is time-consuming sometimes, and may result lost_polls increasing abnormally. So I won't enable device polling before the problem is addressed and fixed. To your problem, I'm not sure whether fwd rule was used properly. Perhaps divert may help? From owner-freebsd-net@FreeBSD.ORG Wed Nov 8 13:37:00 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E2A316A416 for ; Wed, 8 Nov 2006 13:37:00 +0000 (UTC) (envelope-from massimo@cedoc.mo.it) Received: from insomma.datacode.it (ip-174-86.sn2.eutelia.it [83.211.174.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6A9343D6D for ; Wed, 8 Nov 2006 13:36:45 +0000 (GMT) (envelope-from massimo@cedoc.mo.it) Received: from localhost (localhost.datacode.it [127.0.0.1]) by insomma.datacode.it (Postfix) with SMTP id 28AAA2C90C for ; Wed, 8 Nov 2006 14:36:43 +0100 (CET) Received: from insomma.datacode.it (localhost.datacode.it [127.0.0.1]) by insomma.datacode.it (Postfix) with ESMTP id 0B7112C90A; Wed, 8 Nov 2006 14:36:41 +0100 (CET) Received: from massimo.datacode.it (massimo.datacode.it [192.168.1.13]) by insomma.datacode.it (Postfix) with ESMTP id BEC902C906; Wed, 8 Nov 2006 14:36:41 +0100 (CET) From: Massimo Lusetti To: net@freebsd.org Content-Type: text/plain Organization: CEDOC - Modena Date: Wed, 08 Nov 2006 14:36:41 +0100 Message-Id: <1162993001.4305.37.camel@massimo.datacode.it> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: hackers@freebsd.org Subject: New wpi driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2006 13:37:00 -0000 Hi all, I'm pleased to tell you i got the latest wpi driver from Damien Bergamini to work properly on a latest -stable on an Acer laptop. Some history: I didn't do anything special, only report some problems on the misc@openbsd about this new driver on the recently 4.0 release and Damien was kind enough to respond me, the problem were related to the switch on my laptop used to turn on/off the receiver being an ACPI-only switch, this cause the driver to not work properly due to openbsd acpi issues on the laptop. Then Damien ask if i would like to have the FreeBSD version of the driver since i told him the switch work properly on FreeBSD, this all end up me having the driver working smoothly on FreeBSD. The driver as provided by Damien compiled without any issues on my stable, no need to put it under any special directory or what else. Obviously the driver is BSD licensed and obviously is an unsupported version of the driver so not complain to the author if this fail for you. For make this all clear i quote word from the author: --- No problem. It's BSD-licensed, you can redistribute it freely. I just don't want to hear complaints from users if it doesn't work. I don't provide any "support" for the FreeBSD version of wpi(4). --- The driver is available here: http://www.datacode.it/wpi-freebsd/wpi-freebsd.tgz If anyone from FreeBSD team or else is willing to put it on a host with more bandwidth it's more then welcome. Here is the relevant part from the dmesg and ifconfig. wpi0: mem 0xd2100000-0xd2100fff irq 19 at device 0.0 on pci5 channel 1 pwr1 0x007d pwr2 0x007c channel 2 pwr1 0x007b pwr2 0x007e channel 3 pwr1 0x009c pwr2 0x009d channel 4 pwr1 0x009e pwr2 0x009c channel 5 pwr1 0x0000 pwr2 0x0000 channel 6 pwr1 0x0075 pwr2 0x0076 channel 7 pwr1 0x0075 pwr2 0x0074 channel 8 pwr1 0x0077 pwr2 0x0076 channel 9 pwr1 0x0075 pwr2 0x0077 channel 10 pwr1 0x0000 pwr2 0x0000 channel 11 pwr1 0x0001 pwr2 0x0001 channel 12 pwr1 0x0001 pwr2 0x0001 channel 13 pwr1 0x0001 pwr2 0x0001 channel 14 pwr1 0x0001 pwr2 0x0001 wpi0: Ethernet address: 00:13:02:18:e5:b2 wpi0: flags=8802 mtu 1500 ether 00:13:02:18:e5:b2 media: IEEE 802.11 Wireless Ethernet autoselect status: no carrier ssid "" channel 1 authmode OPEN privacy OFF txpowmax 100 bmiss 7 protmode CTS Regards -- Massimo.run(); From owner-freebsd-net@FreeBSD.ORG Wed Nov 8 14:34:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35D2816A407 for ; Wed, 8 Nov 2006 14:34:42 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AB9543E01 for ; Wed, 8 Nov 2006 14:33:10 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from db2.internal (db2.internal [10.202.2.12]) by frontend1.messagingengine.com (Postfix) with ESMTP id E5DAADC13ED; Wed, 8 Nov 2006 09:33:01 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by db2.internal (MEProxy); Wed, 08 Nov 2006 09:33:03 -0500 X-Sasl-enc: tQYMA8AwW5IGw5PjGu4a/qXBd+nNab1T82vmCIifBBKe 1162996383 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id B663910C96; Wed, 8 Nov 2006 09:33:02 -0500 (EST) Message-ID: <4551EA9C.5050309@FreeBSD.org> Date: Wed, 08 Nov 2006 14:33:00 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: Landon Fuller References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [patch] tun(4) and tap(4) if_clone support. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2006 14:34:42 -0000 Landon Fuller wrote: > Nick Barkas (snb@threerings.net) and I have added interface cloning > support to the tun(4) and tap(4) drivers. > > We maintained backwards-compatible support for devfs cloning, which is > now disabled by default -- it can be re-enabled via a sysctl. > Interfaces that are created via devfs cloning may still be removed via > ifconfig destroy. > > The latest patch is available here > http://www.opendarwin.org/~landonf/code/patch-tuntap_ifclone > > I've submitted kern/105228 with the patch, and I'd be most > appreciative of comments/suggestions. Interesting stuff. If it eliminates a race on creation, that has to be a good thing; I may have run into this race in the past month or two. It would however change tap/tun behaviour in that currently I have a few scripts which use dd(1) to force the device node to be created. This is undocumented behaviour specific to its devfs implementation which perhaps I shouldn't be relying upon, before I go on to create a bridge from several tap instances (which are then hooked up to QEMU virtual machines). Good work! BMS From owner-freebsd-net@FreeBSD.ORG Wed Nov 8 17:00:34 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB9E616A403 for ; Wed, 8 Nov 2006 17:00:34 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id D681A43D53 for ; Wed, 8 Nov 2006 17:00:33 +0000 (GMT) (envelope-from mav@mavhome.dp.ua) X-Spam-Level: 50 [XX] (100%) IP is in RBL Received: from [195.248.178.122] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 17911840; Wed, 08 Nov 2006 19:00:32 +0200 Message-ID: <45520D29.1080700@mavhome.dp.ua> Date: Wed, 08 Nov 2006 19:00:25 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Volodymyr Kostyrko References: <1162614203.00630092.1162603801@10.7.7.3> In-Reply-To: <1162614203.00630092.1162603801@10.7.7.3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, mpd-users@lists.sourceforge.net Subject: Re: mpd4 on sparc64 problem (maybe netgraph involved) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2006 17:00:34 -0000 Volodymyr Kostyrko wrote: > I have a host machine (i386) with many i386 clients and one sparc64 all > configured the same way. All i386 client work just fine, while sparc64 > one refuses to do so. There is a bug in LCP negotiation in mpd4_0b5 on 64bit big-endian platforms like sparc64. I have commited required patches info mpd CVS on sourceforge.net. Patched version is successfully tested on i386, amd64 and sparc64 platforms. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Wed Nov 8 17:55:53 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA68516A4EF for ; Wed, 8 Nov 2006 17:55:53 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E7CF43DF0 for ; Wed, 8 Nov 2006 17:54:59 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 744BEEB4E8A; Thu, 9 Nov 2006 01:54:55 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id u++3Ef-BI3zN; Thu, 9 Nov 2006 01:54:51 +0800 (CST) Received: from [192.168.1.32] (unknown [221.216.127.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 6D669EB4845; Thu, 9 Nov 2006 01:54:51 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=Vm8Dm9mxgJMvr/cDcaFkEsDCk03Q7++L5v7M+f7FX4aEUiSnhGMcHC8jn5wA5plGw VWaHfppWWJTxSSP/y98vA== Message-ID: <455219E6.6090001@delphij.net> Date: Thu, 09 Nov 2006 01:54:46 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: MQ References: <454E19CC.7040208@fromley.net> <20061106195524.P39454@fledge.watson.org> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig2F2E7DB3514A1E186A4AF2E4" Cc: freebsd-net@freebsd.org Subject: Re: Posting restrictions on this mailing list (for spam control)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2006 17:55:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2F2E7DB3514A1E186A4AF2E4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MQ wrote: [snip] > The mailing list denied all the mail from my previous mail box provide= d by > Netease(NASDAQ: NTES) from China mainland, even I subscribed to -net, a= nd > asked me to wait the moderator's approval. But after I changed my > mailbox to > gmail, the filter never returned such message. I don't know why I can't= > post > to -net even I subscribed to it. Maybe a misconfiguration? No. At least, not misconfiguration at FreeBSD.org side. I have discussed the situation with David (the postmaster@) and this seems to be caused by misconfiguration and wrong implementation of the e-mail standards by NTES, which in turn caused SpamAssassin to provide false positives (personally I do not think that they should be considered as false positives, they are REAL problems that should be addressed and corrected). Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig2F2E7DB3514A1E186A4AF2E4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFUhnmOfuToMruuMARAzGJAJ9JVhDLMwzAbuCzmHUpoS07Q2DE6wCfSF35 dkCB2HrmjdEFZ0LbbsqlXGI= =rhwa -----END PGP SIGNATURE----- --------------enig2F2E7DB3514A1E186A4AF2E4-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 9 01:19:05 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 101CF16A416 for ; Thu, 9 Nov 2006 01:19:05 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33A9743D4C for ; Thu, 9 Nov 2006 01:19:04 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so25115nzh for ; Wed, 08 Nov 2006 17:19:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=hhGDK6G8zL3TeNtAlEyvbiGZGewTxN1vSX6Mia6LdUz5bfwOZeAkCZTjWVDACaTi6hq9YhCSZHPqmU/xug2hv6uq1FYLRPcQGPZydrtsvzvCRJ4RqneIDxqfiyzDrUw3CWtGrfiPhY3Leqt94XAu+cu11rfRMjlom2p2Lha78Js= Received: by 10.35.99.6 with SMTP id b6mr614488pym.1163035143153; Wed, 08 Nov 2006 17:19:03 -0800 (PST) Received: by 10.35.118.6 with HTTP; Wed, 8 Nov 2006 17:19:02 -0800 (PST) Message-ID: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> Date: Wed, 8 Nov 2006 17:19:02 -0800 From: "Jack Vogel" To: "Scott Long" , "Gleb Smirnoff" , "John Baldwin" , RelEng , "Prafulla Deuskar" , freebsd-stable@freebsd.org, freebsd-net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_35052_20023030.1163035142787" Cc: Subject: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 01:19:05 -0000 ------=_Part_35052_20023030.1163035142787 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline This patch is an evolution of the last one I sent out. It has a couple of minor corrections, like a bad forward decl in the header. The last patch has had quite a bit of testing and all reports have been positive. The only complaint was from Gleb who says he needs to keep his beloved infinite for loop in the interrupt handler, well I have a better one for you Gleb, keep reading. I have also been doing some extreme stress testing using SmartBits, and discovered the driver as it stands is really not able to take extreme receive side pounding, Scott pointed out that this is why the FAST_INTR work was done :) There were some people that had stability issues with that work, but there were also many that did not. I actually merged the FAST code onto my last patch, and ran the SB stress and found it really was able to gracefully handle that load, way to go Scott :) I've pondered this situation, and this patch I'm including here today is the result. Here's what it does: If you drop it in place, compile it, and go... you will get the code that has been tested for a week, it uses the older style interrupts, it has the watchdog and other SMP fixes so its been proven. BUT, I've added the FAST_INTR changes back into the code, so if you go into your Makefile and add -DEM_FAST_INTR you will then get the taskqueue stuff. So, Gleb, rather than replace the infinite for loop that no one thinks is a good idea, you can just define FAST_INTR again, and you should be good to go. I see this as the best thing for the 6.2 RELEASE, it lets us keep moving forward, people that want max performance can define EM_FAST_INTR and help us wring out any problems, it also will mean that I will have our Intel test group start using this code. But for those that just want a stable driver the standard compile will still give them that. The patch I'm including is against BETA3. Let me know of your concerns or issues. Cheers, Jack ------=_Part_35052_20023030.1163035142787 Content-Type: text/x-patch; name="proposed-6.2.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="proposed-6.2.patch" X-Attachment-Id: f_euaw91bp ZGlmZiAtTmF1ciBzdGFibGUvZGV2L2VtL2lmX2VtLmMgbmV3cGF0Y2gvZGV2L2VtL2lmX2VtLmMK LS0tIHN0YWJsZS9kZXYvZW0vaWZfZW0uYwlXZWQgTm92ICA4IDIzOjQyOjIwIDIwMDYKKysrIG5l d3BhdGNoL2Rldi9lbS9pZl9lbS5jCVdlZCBOb3YgIDggMjM6NDQ6MTYgMjAwNgpAQCAtMjA0LDcg KzIwNCw3IEBACiBzdGF0aWMgdm9pZAllbV9zdGFydChzdHJ1Y3QgaWZuZXQgKik7CiBzdGF0aWMg dm9pZAllbV9zdGFydF9sb2NrZWQoc3RydWN0IGlmbmV0ICppZnApOwogc3RhdGljIGludAllbV9p b2N0bChzdHJ1Y3QgaWZuZXQgKiwgdV9sb25nLCBjYWRkcl90KTsKLXN0YXRpYyB2b2lkCWVtX3dh dGNoZG9nKHN0cnVjdCBpZm5ldCAqKTsKK3N0YXRpYyB2b2lkCWVtX3dhdGNoZG9nKHN0cnVjdCBh ZGFwdGVyICopOwogc3RhdGljIHZvaWQJZW1faW5pdCh2b2lkICopOwogc3RhdGljIHZvaWQJZW1f aW5pdF9sb2NrZWQoc3RydWN0IGFkYXB0ZXIgKik7CiBzdGF0aWMgdm9pZAllbV9zdG9wKHZvaWQg Kik7CkBAIC0yMTIsNiArMjEyLDggQEAKIHN0YXRpYyBpbnQJZW1fbWVkaWFfY2hhbmdlKHN0cnVj dCBpZm5ldCAqKTsKIHN0YXRpYyB2b2lkCWVtX2lkZW50aWZ5X2hhcmR3YXJlKHN0cnVjdCBhZGFw dGVyICopOwogc3RhdGljIGludAllbV9hbGxvY2F0ZV9wY2lfcmVzb3VyY2VzKHN0cnVjdCBhZGFw dGVyICopOworc3RhdGljIGludAllbV9hbGxvY2F0ZV9pbnRyKHN0cnVjdCBhZGFwdGVyICopOwor c3RhdGljIHZvaWQJZW1fZnJlZV9pbnRyKHN0cnVjdCBhZGFwdGVyICopOwogc3RhdGljIHZvaWQJ ZW1fZnJlZV9wY2lfcmVzb3VyY2VzKHN0cnVjdCBhZGFwdGVyICopOwogc3RhdGljIHZvaWQJZW1f bG9jYWxfdGltZXIodm9pZCAqKTsKIHN0YXRpYyBpbnQJZW1faGFyZHdhcmVfaW5pdChzdHJ1Y3Qg YWRhcHRlciAqKTsKQEAgLTI1Myw4ICsyNTUsNyBAQAogc3RhdGljIGludAllbV84MjU0N19maWZv X3dvcmthcm91bmQoc3RydWN0IGFkYXB0ZXIgKiwgaW50KTsKIHN0YXRpYyB2b2lkCWVtXzgyNTQ3 X3VwZGF0ZV9maWZvX2hlYWQoc3RydWN0IGFkYXB0ZXIgKiwgaW50KTsKIHN0YXRpYyBpbnQJZW1f ODI1NDdfdHhfZmlmb19yZXNldChzdHJ1Y3QgYWRhcHRlciAqKTsKLXN0YXRpYyB2b2lkCWVtXzgy NTQ3X21vdmVfdGFpbCh2b2lkICphcmcpOwotc3RhdGljIHZvaWQJZW1fODI1NDdfbW92ZV90YWls X2xvY2tlZChzdHJ1Y3QgYWRhcHRlciAqKTsKK3N0YXRpYyB2b2lkCWVtXzgyNTQ3X21vdmVfdGFp bCh2b2lkICopOwogc3RhdGljIGludAllbV9kbWFfbWFsbG9jKHN0cnVjdCBhZGFwdGVyICosIGJ1 c19zaXplX3QsCiAJCXN0cnVjdCBlbV9kbWFfYWxsb2MgKiwgaW50KTsKIHN0YXRpYyB2b2lkCWVt X2RtYV9mcmVlKHN0cnVjdCBhZGFwdGVyICosIHN0cnVjdCBlbV9kbWFfYWxsb2MgKik7CkBAIC0y NjcsMTEgKzI2OCwxOCBAQAogc3RhdGljIGludAllbV9zeXNjdGxfaW50X2RlbGF5KFNZU0NUTF9I QU5ETEVSX0FSR1MpOwogc3RhdGljIHZvaWQJZW1fYWRkX2ludF9kZWxheV9zeXNjdGwoc3RydWN0 IGFkYXB0ZXIgKiwgY29uc3QgY2hhciAqLAogCQljb25zdCBjaGFyICosIHN0cnVjdCBlbV9pbnRf ZGVsYXlfaW5mbyAqLCBpbnQsIGludCk7CitzdGF0aWMgdm9pZAllbV9hZGRfcnhfcHJvY2Vzc19s aW1pdChzdHJ1Y3QgYWRhcHRlciAqLCBjb25zdCBjaGFyICosCisJCWNvbnN0IGNoYXIgKiwgaW50 ICosIGludCk7CisjaWZkZWYgRU1fRkFTVF9JTlRSCitzdGF0aWMgdm9pZAllbV9pbnRyX2Zhc3Qo dm9pZCAqKTsKK3N0YXRpYyB2b2lkCWVtX2hhbmRsZV9yeHR4KHZvaWQgKmNvbnRleHQsIGludCBw ZW5kaW5nKTsKK3N0YXRpYyB2b2lkCWVtX2hhbmRsZV9saW5rKHZvaWQgKmNvbnRleHQsIGludCBw ZW5kaW5nKTsKKyNlbHNlIC8qIExlZ2FjeSBJbnRlcnJ1cHQgSGFuZGxpbmcgKi8KIHN0YXRpYyB2 b2lkCWVtX2ludHIodm9pZCAqKTsKLQogI2lmZGVmIERFVklDRV9QT0xMSU5HCiBzdGF0aWMgcG9s bF9oYW5kbGVyX3QgZW1fcG9sbDsKLSNlbmRpZgorI2VuZGlmIC8qIERFVklDRV9QT0xMSU5HICov CisjZW5kaWYgLyogRU1fRkFTVF9JTlRSICovCiAKIC8qKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKICAqICBGcmVlQlNE IERldmljZSBJbnRlcmZhY2UgRW50cnkgUG9pbnRzCkBAIC0zMjEsNiArMzI5LDEwIEBACiBUVU5B QkxFX0lOVCgiaHcuZW0udHhkIiwgJmVtX3R4ZCk7CiBUVU5BQkxFX0lOVCgiaHcuZW0uc21hcnRf cHdyX2Rvd24iLCAmZW1fc21hcnRfcHdyX2Rvd24pOwogCisvKiBIb3cgbWFueSBwYWNrZXRzIHJ4 ZW9mIHRyaWVzIHRvIGNsZWFuIGF0IGEgdGltZSAqLworc3RhdGljIGludCBlbV9yeF9wcm9jZXNz X2xpbWl0ID0gMTAwOworVFVOQUJMRV9JTlQoImh3LmVtLnJ4X3Byb2Nlc3NfbGltaXQiLCAmZW1f cnhfcHJvY2Vzc19saW1pdCk7CisKIC8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKICAqICBEZXZpY2UgaWRlbnRpZmlj YXRpb24gcm91dGluZQogICoKQEAgLTQwNiw4ICs0MTgsOCBAQAogCSAgICBPSURfQVVUTywgInN0 YXRzIiwgQ1RMVFlQRV9JTlR8Q1RMRkxBR19SVywgYWRhcHRlciwgMCwKIAkgICAgZW1fc3lzY3Rs X3N0YXRzLCAiSSIsICJTdGF0aXN0aWNzIik7CiAKLQljYWxsb3V0X2luaXQoJmFkYXB0ZXItPnRp bWVyLCBDQUxMT1VUX01QU0FGRSk7Ci0JY2FsbG91dF9pbml0KCZhZGFwdGVyLT50eF9maWZvX3Rp bWVyLCBDQUxMT1VUX01QU0FGRSk7CisJY2FsbG91dF9pbml0X210eCgmYWRhcHRlci0+dGltZXIs ICZhZGFwdGVyLT5tdHgsIDApOworCWNhbGxvdXRfaW5pdF9tdHgoJmFkYXB0ZXItPnR4X2ZpZm9f dGltZXIsICZhZGFwdGVyLT5tdHgsIDApOwogCiAJLyogRGV0ZXJtaW5lIGhhcmR3YXJlIHJldmlz aW9uICovCiAJZW1faWRlbnRpZnlfaGFyZHdhcmUoYWRhcHRlcik7CkBAIC00MzIsNiArNDQ0LDEx IEBACiAJCSAgICBlbV90eF9hYnNfaW50X2RlbGF5X2RmbHQpOwogCX0KIAorCS8qIFN5c2N0bHMg Zm9yIGxpbWl0aW5nIHRoZSBhbW91bnQgb2Ygd29yayBkb25lIGluIHRoZSB0YXNrcXVldWUgKi8K KwllbV9hZGRfcnhfcHJvY2Vzc19saW1pdChhZGFwdGVyLCAicnhfcHJvY2Vzc2luZ19saW1pdCIs CisJICAgICJtYXggbnVtYmVyIG9mIHJ4IHBhY2tldHMgdG8gcHJvY2VzcyIsICZhZGFwdGVyLT5y eF9wcm9jZXNzX2xpbWl0LAorCSAgICBlbV9yeF9wcm9jZXNzX2xpbWl0KTsKKwogCS8qCiAJICog VmFsaWRhdGUgbnVtYmVyIG9mIHRyYW5zbWl0IGFuZCByZWNlaXZlIGRlc2NyaXB0b3JzLiBJdAog CSAqIG11c3Qgbm90IGV4Y2VlZCBoYXJkd2FyZSBtYXhpbXVtLCBhbmQgbXVzdCBiZSBtdWx0aXBs ZQpAQCAtNTU0LDYgKzU3MSw4IEBACiAJLyogU2V0dXAgT1Mgc3BlY2lmaWMgbmV0d29yayBpbnRl cmZhY2UgKi8KIAllbV9zZXR1cF9pbnRlcmZhY2UoZGV2LCBhZGFwdGVyKTsKIAorCWVtX2FsbG9j YXRlX2ludHIoYWRhcHRlcik7CisKIAkvKiBJbml0aWFsaXplIHN0YXRpc3RpY3MgKi8KIAllbV9j bGVhcl9od19jbnRycygmYWRhcHRlci0+aHcpOwogCWVtX3VwZGF0ZV9zdGF0c19jb3VudGVycyhh ZGFwdGVyKTsKQEAgLTU4Niw2ICs2MDUsNyBAQAogCWVtX2RtYV9mcmVlKGFkYXB0ZXIsICZhZGFw dGVyLT50eGRtYSk7CiBlcnJfdHhfZGVzYzoKIGVycl9wY2k6CisJZW1fZnJlZV9pbnRyKGFkYXB0 ZXIpOwogCWVtX2ZyZWVfcGNpX3Jlc291cmNlcyhhZGFwdGVyKTsKIAlFTV9MT0NLX0RFU1RST1ko YWRhcHRlcik7CiAKQEAgLTYxNSw2ICs2MzUsNyBAQAogCQlldGhlcl9wb2xsX2RlcmVnaXN0ZXIo aWZwKTsKICNlbmRpZgogCisJZW1fZnJlZV9pbnRyKGFkYXB0ZXIpOwogCUVNX0xPQ0soYWRhcHRl cik7CiAJYWRhcHRlci0+aW5fZGV0YWNoID0gMTsKIAllbV9zdG9wKGFkYXB0ZXIpOwpAQCAtNjIy LDYgKzY0Myw5IEBACiAJRU1fVU5MT0NLKGFkYXB0ZXIpOwogCWV0aGVyX2lmZGV0YWNoKGFkYXB0 ZXItPmlmcCk7CiAKKwljYWxsb3V0X2RyYWluKCZhZGFwdGVyLT50aW1lcik7CisJY2FsbG91dF9k cmFpbigmYWRhcHRlci0+dHhfZmlmb190aW1lcik7CisKIAllbV9mcmVlX3BjaV9yZXNvdXJjZXMo YWRhcHRlcik7CiAJYnVzX2dlbmVyaWNfZGV0YWNoKGRldik7CiAJaWZfZnJlZShpZnApOwpAQCAt NzM5LDcgKzc2Myw3IEBACiAJCUJQRl9NVEFQKGlmcCwgbV9oZWFkKTsKIAogCQkvKiBTZXQgdGlt ZW91dCBpbiBjYXNlIGhhcmR3YXJlIGhhcyBwcm9ibGVtcyB0cmFuc21pdHRpbmcuICovCi0JCWlm cC0+aWZfdGltZXIgPSBFTV9UWF9USU1FT1VUOworCQlhZGFwdGVyLT53YXRjaGRvZ190aW1lciA9 IEVNX1RYX1RJTUVPVVQ7CiAJfQogfQogCkBAIC05NDAsMzUgKzk2NCw0NiBAQAogfQogCiAvKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqCi0gKiAgV2F0Y2hkb2cgZW50cnkgcG9pbnQKKyAqICBXYXRjaGRvZyB0aW1lcjoK ICAqCi0gKiAgVGhpcyByb3V0aW5lIGlzIGNhbGxlZCB3aGVuZXZlciBoYXJkd2FyZSBxdWl0cyB0 cmFuc21pdHRpbmcuCisgKiAgVGhpcyByb3V0aW5lIGlzIGNhbGxlZCBmcm9tIHRoZSBsb2NhbCB0 aW1lciBldmVyeSBzZWNvbmQuCisgKiAgQXMgbG9uZyBhcyB0cmFuc21pdCBkZXNjcmlwdG9ycyBh cmUgYmVpbmcgY2xlYW5lZCB0aGUgdmFsdWUKKyAqICBpcyBub24temVybyBhbmQgd2UgZG8gbm90 aGluZy4gUmVhY2hpbmcgMCBpbmRpY2F0ZXMgYSB0eCBoYW5nCisgKiAgYW5kIHdlIHRoZW4gcmVz ZXQgdGhlIGRldmljZS4KICAqCiAgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KIAogc3RhdGljIHZvaWQKLWVtX3dh dGNoZG9nKHN0cnVjdCBpZm5ldCAqaWZwKQorZW1fd2F0Y2hkb2coc3RydWN0IGFkYXB0ZXIgKmFk YXB0ZXIpCiB7Ci0Jc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIgPSBpZnAtPmlmX3NvZnRjOwogCi0J RU1fTE9DSyhhZGFwdGVyKTsKKwlFTV9MT0NLX0FTU0VSVChhZGFwdGVyKTsKKworCS8qCisJKiog VGhlIHRpbWVyIGlzIHNldCB0byA1IGV2ZXJ5IHRpbWUgc3RhcnQgcXVldWVzIGEgcGFja2V0Lgor CSoqIFRoZW4gdHhlb2Yga2VlcHMgcmVzZXR0aW5nIHRvIDUgYXMgbG9uZyBhcyBpdCBjbGVhbnMg YXQKKwkqKiBsZWFzdCBvbmUgZGVzY3JpcHRvci4KKwkqKiBGaW5hbGx5LCBhbnl0aW1lIGFsbCBk ZXNjcmlwdG9ycyBhcmUgY2xlYW4gdGhlIHRpbWVyIGlzCisJKiogc2V0IHRvIDAuCisJKi8KKwlp ZiAoYWRhcHRlci0+d2F0Y2hkb2dfdGltZXIgPT0gMCB8fCAtLWFkYXB0ZXItPndhdGNoZG9nX3Rp bWVyKQorCQlyZXR1cm47CisKIAkvKiBJZiB3ZSBhcmUgaW4gdGhpcyByb3V0aW5lIGJlY2F1c2Ug b2YgcGF1c2UgZnJhbWVzLCB0aGVuCiAJICogZG9uJ3QgcmVzZXQgdGhlIGhhcmR3YXJlLgogCSAq LwogCWlmIChFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcsIFNUQVRVUykgJiBFMTAwMF9TVEFU VVNfVFhPRkYpIHsKLQkJaWZwLT5pZl90aW1lciA9IEVNX1RYX1RJTUVPVVQ7Ci0JCUVNX1VOTE9D SyhhZGFwdGVyKTsKKwkJYWRhcHRlci0+d2F0Y2hkb2dfdGltZXIgPSBFTV9UWF9USU1FT1VUOwog CQlyZXR1cm47CiAJfQogCiAJaWYgKGVtX2NoZWNrX2Zvcl9saW5rKCZhZGFwdGVyLT5odykgPT0g MCkKIAkJZGV2aWNlX3ByaW50ZihhZGFwdGVyLT5kZXYsICJ3YXRjaGRvZyB0aW1lb3V0IC0tIHJl c2V0dGluZ1xuIik7CiAKLQlpZnAtPmlmX2Rydl9mbGFncyAmPSB+SUZGX0RSVl9SVU5OSU5HOwor CWFkYXB0ZXItPmlmcC0+aWZfZHJ2X2ZsYWdzICY9IH5JRkZfRFJWX1JVTk5JTkc7CiAJYWRhcHRl ci0+d2F0Y2hkb2dfZXZlbnRzKys7CiAKIAllbV9pbml0X2xvY2tlZChhZGFwdGVyKTsKLQlFTV9V TkxPQ0soYWRhcHRlcik7CiB9CiAKIC8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKQEAgLTExMTcsNiArMTE1MiwxMSBA QAogCiAKICNpZmRlZiBERVZJQ0VfUE9MTElORworLyoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgorICoKKyAqICBMZWdh Y3kgcG9sbGluZyByb3V0aW5lICAKKyAqCisgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLwogc3RhdGljIHZvaWQKIGVt X3BvbGwoc3RydWN0IGlmbmV0ICppZnAsIGVudW0gcG9sbF9jbWQgY21kLCBpbnQgY291bnQpCiB7 CkBAIC0xMTQ5LDExICsxMTg5LDE0IEBACiB9CiAjZW5kaWYgLyogREVWSUNFX1BPTExJTkcgKi8K IAorI2lmbmRlZiBFTV9GQVNUX0lOVFIKIC8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKICAqCi0gKiAgSW50ZXJydXB0 IFNlcnZpY2Ugcm91dGluZSAgCisgKiAgTGVnYWN5IEludGVycnVwdCBTZXJ2aWNlIHJvdXRpbmUg IAogICoKICAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKiovCisjZGVmaW5lIEVNX01BWF9JTlRSIDEwCisKIHN0YXRpYyB2 b2lkCiBlbV9pbnRyKHZvaWQgKmFyZykKIHsKQEAgLTExNjIsNyArMTIwNSw2IEBACiAJdWludDMy X3QJcmVnX2ljcjsKIAogCUVNX0xPQ0soYWRhcHRlcik7Ci0KIAlpZnAgPSBhZGFwdGVyLT5pZnA7 CiAKICNpZmRlZiBERVZJQ0VfUE9MTElORwpAQCAtMTE3MiwyOCArMTIxNCwyNCBAQAogCX0KICNl bmRpZiAvKiBERVZJQ0VfUE9MTElORyAqLwogCi0JZm9yICg7OykgewotCQlyZWdfaWNyID0gRTEw MDBfUkVBRF9SRUcoJmFkYXB0ZXItPmh3LCBJQ1IpOwotCQlpZiAoYWRhcHRlci0+aHcubWFjX3R5 cGUgPj0gZW1fODI1NzEgJiYKLQkJICAgIChyZWdfaWNyICYgRTEwMDBfSUNSX0lOVF9BU1NFUlRF RCkgPT0gMCkKLQkJCWJyZWFrOwotCQllbHNlIGlmIChyZWdfaWNyID09IDApCi0JCQlicmVhazsK KwlyZWdfaWNyID0gRTEwMDBfUkVBRF9SRUcoJmFkYXB0ZXItPmh3LCBJQ1IpOwogCi0JCS8qCi0J CSAqIFhYWDogc29tZSBsYXB0b3BzIHRyaWdnZXIgc2V2ZXJhbCBzcHVyaW91cyBpbnRlcnJ1cHRz Ci0JCSAqIG9uIGVtKDQpIHdoZW4gaW4gdGhlIHJlc3VtZSBjeWNsZS4gVGhlIElDUiByZWdpc3Rl cgotCQkgKiByZXBvcnRzIGFsbC1vbmVzIHZhbHVlIGluIHRoaXMgY2FzZS4gUHJvY2Vzc2luZyBz dWNoCi0JCSAqIGludGVycnVwdHMgd291bGQgbGVhZCB0byBhIGZyZWV6ZS4gSSBkb24ndCBrbm93 IHdoeS4KLQkJICovCi0JCWlmIChyZWdfaWNyID09IDB4ZmZmZmZmZmYpCi0JCQlicmVhazsKKwlp ZiAoKHJlZ19pY3IgPT0gMCkgfHwgKGFkYXB0ZXItPmh3Lm1hY190eXBlID49IGVtXzgyNTcxICYm CisJICAgIChyZWdfaWNyICYgRTEwMDBfSUNSX0lOVF9BU1NFUlRFRCkgPT0gMCkgfHwKKwkvKgor CSAqIFhYWDogc29tZSBsYXB0b3BzIHRyaWdnZXIgc2V2ZXJhbCBzcHVyaW91cyBpbnRlcnJ1cHRz CisJICogb24gZW0oNCkgd2hlbiBpbiB0aGUgcmVzdW1lIGN5Y2xlLiBUaGUgSUNSIHJlZ2lzdGVy CisJICogcmVwb3J0cyBhbGwtb25lcyB2YWx1ZSBpbiB0aGlzIGNhc2UuIFByb2Nlc3Npbmcgc3Vj aAorCSAqIGludGVycnVwdHMgd291bGQgbGVhZCB0byBhIGZyZWV6ZS4gSSBkb24ndCBrbm93IHdo eS4KKwkgKi8KKwkgICAgKHJlZ19pY3IgPT0gMHhmZmZmZmZmZikpCisJCWdvdG8gbGVhdmluZzsK IAorCWZvciAoaW50IGkgPSAwO2kgPCBFTV9NQVhfSU5UUjsgKytpKSB7CiAJCWlmIChpZnAtPmlm X2Rydl9mbGFncyAmIElGRl9EUlZfUlVOTklORykgewotCQkJZW1fcnhlb2YoYWRhcHRlciwgLTEp OworCQkJZW1fcnhlb2YoYWRhcHRlciwgYWRhcHRlci0+cnhfcHJvY2Vzc19saW1pdCk7CiAJCQll bV90eGVvZihhZGFwdGVyKTsKIAkJfQotCiAJCS8qIExpbmsgc3RhdHVzIGNoYW5nZSAqLwogCQlp ZiAocmVnX2ljciAmIChFMTAwMF9JQ1JfUlhTRVEgfCBFMTAwMF9JQ1JfTFNDKSkgewogCQkJY2Fs bG91dF9zdG9wKCZhZGFwdGVyLT50aW1lcik7CkBAIC0xMjA4LDEzICsxMjQ2LDExMCBAQAogCQkJ YWRhcHRlci0+cnhfb3ZlcnJ1bnMrKzsKIAl9CiAKK2xlYXZpbmc6CiAJaWYgKGlmcC0+aWZfZHJ2 X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5HICYmCiAJICAgICFJRlFfRFJWX0lTX0VNUFRZKCZpZnAt PmlmX3NuZCkpCiAJCWVtX3N0YXJ0X2xvY2tlZChpZnApOworCUVNX1VOTE9DSyhhZGFwdGVyKTsK K30KIAorI2Vsc2UgIC8qIEVNX0ZBU1RfSU5UUiAqLworCitzdGF0aWMgdm9pZAorZW1faGFuZGxl X2xpbmsodm9pZCAqY29udGV4dCwgaW50IHBlbmRpbmcpCit7CisJc3RydWN0IGFkYXB0ZXIJKmFk YXB0ZXIgPSBjb250ZXh0OworCXN0cnVjdCBpZm5ldCAqaWZwOworCisJaWZwID0gYWRhcHRlci0+ aWZwOworCisJRU1fTE9DSyhhZGFwdGVyKTsKKworCWNhbGxvdXRfc3RvcCgmYWRhcHRlci0+dGlt ZXIpOworCWFkYXB0ZXItPmh3LmdldF9saW5rX3N0YXR1cyA9IDE7CisJZW1fY2hlY2tfZm9yX2xp bmsoJmFkYXB0ZXItPmh3KTsKKwllbV91cGRhdGVfbGlua19zdGF0dXMoYWRhcHRlcik7CisJY2Fs bG91dF9yZXNldCgmYWRhcHRlci0+dGltZXIsIGh6LCBlbV9sb2NhbF90aW1lciwgYWRhcHRlcik7 CiAJRU1fVU5MT0NLKGFkYXB0ZXIpOwogfQogCitzdGF0aWMgdm9pZAorZW1faGFuZGxlX3J4dHgo dm9pZCAqY29udGV4dCwgaW50IHBlbmRpbmcpCit7CisJc3RydWN0IGFkYXB0ZXIJKmFkYXB0ZXIg PSBjb250ZXh0OworCXN0cnVjdCBpZm5ldAkqaWZwOworCisJTkVUX0xPQ0tfR0lBTlQoKTsKKwlp ZnAgPSBhZGFwdGVyLT5pZnA7CisKKwkvKgorCSAqIFRPRE86CisJICogSXQgc2hvdWxkIGJlIHBv c3NpYmxlIHRvIHJ1biB0aGUgdHggY2xlYW4gbG9vcCB3aXRob3V0IHRoZSBsb2NrLgorCSAqLwor CWlmIChpZnAtPmlmX2Rydl9mbGFncyAmIElGRl9EUlZfUlVOTklORykgeworCQlpZiAoZW1fcnhl b2YoYWRhcHRlciwgYWRhcHRlci0+cnhfcHJvY2Vzc19saW1pdCkgIT0gMCkKKwkJCXRhc2txdWV1 ZV9lbnF1ZXVlKGFkYXB0ZXItPnRxLCAmYWRhcHRlci0+cnh0eF90YXNrKTsKKwkJRU1fTE9DSyhh ZGFwdGVyKTsKKwkJZW1fdHhlb2YoYWRhcHRlcik7CisKKwkJaWYgKCFJRlFfRFJWX0lTX0VNUFRZ KCZpZnAtPmlmX3NuZCkpCisJCQllbV9zdGFydF9sb2NrZWQoaWZwKTsKKwkJRU1fVU5MT0NLKGFk YXB0ZXIpOworCX0KKworCWVtX2VuYWJsZV9pbnRyKGFkYXB0ZXIpOworCU5FVF9VTkxPQ0tfR0lB TlQoKTsKK30KKworLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKgorICoKKyAqICBGYXN0IEludGVycnVwdCBTZXJ2aWNl IHJvdXRpbmUgIAorICoKKyAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCitzdGF0aWMgdm9pZAorZW1faW50cl9mYXN0 KHZvaWQgKmFyZykKK3sKKwlzdHJ1Y3QgYWRhcHRlcgkqYWRhcHRlciA9IGFyZzsKKwlzdHJ1Y3Qg aWZuZXQJKmlmcDsKKwl1aW50MzJfdAlyZWdfaWNyOworCisJaWZwID0gYWRhcHRlci0+aWZwOwor CisJcmVnX2ljciA9IEUxMDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgSUNSKTsKKworCS8qIEhv dCBlamVjdD8gICovCisJaWYgKHJlZ19pY3IgPT0gMHhmZmZmZmZmZikKKwkJcmV0dXJuOworCisJ LyogRGVmaW5pdGVseSBub3Qgb3VyIGludGVycnVwdC4gICovCisJaWYgKHJlZ19pY3IgPT0gMHgw KQorCQlyZXR1cm47CisKKwkvKgorCSAqIFN0YXJ0aW5nIHdpdGggdGhlIDgyNTcxIGNoaXAsIGJp dCAzMSBzaG91bGQgYmUgdXNlZCB0bworCSAqIGRldGVybWluZSB3aGV0aGVyIHRoZSBpbnRlcnJ1 cHQgYmVsb25ncyB0byB1cy4KKwkgKi8KKwlpZiAoYWRhcHRlci0+aHcubWFjX3R5cGUgPj0gZW1f ODI1NzEgJiYKKwkgICAgKHJlZ19pY3IgJiBFMTAwMF9JQ1JfSU5UX0FTU0VSVEVEKSA9PSAwKQor CQlyZXR1cm47CisKKwkvKgorCSAqIE1hc2sgaW50ZXJydXB0cyB1bnRpbCB0aGUgdGFza3F1ZXVl IGlzIGZpbmlzaGVkIHJ1bm5pbmcuICBUaGlzIGlzCisJICogY2hlYXAsIGp1c3QgYXNzdW1lIHRo YXQgaXQgaXMgbmVlZGVkLiAgVGhpcyBhbHNvIHdvcmtzIGFyb3VuZCB0aGUKKwkgKiBNU0kgbWVz c2FnZSByZW9yZGVyaW5nIGVycmF0YSBvbiBjZXJ0YWluIHN5c3RlbXMuCisJICovCisJZW1fZGlz YWJsZV9pbnRyKGFkYXB0ZXIpOworCXRhc2txdWV1ZV9lbnF1ZXVlKGFkYXB0ZXItPnRxLCAmYWRh cHRlci0+cnh0eF90YXNrKTsKKworCS8qIExpbmsgc3RhdHVzIGNoYW5nZSAqLworCWlmIChyZWdf aWNyICYgKEUxMDAwX0lDUl9SWFNFUSB8IEUxMDAwX0lDUl9MU0MpKQorCQl0YXNrcXVldWVfZW5x dWV1ZSh0YXNrcXVldWVfZmFzdCwgJmFkYXB0ZXItPmxpbmtfdGFzayk7CisKKwlpZiAocmVnX2lj ciAmIEUxMDAwX0lDUl9SWE8pCisJCWFkYXB0ZXItPnJ4X292ZXJydW5zKys7Cit9CisjZW5kaWYg LyogRU1fRkFTVF9JTlRSICovCisKIC8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKICAqCiAgKiAgTWVkaWEgSW9jdGwg Y2FsbGJhY2sKQEAgLTEzNjgsMjIgKzE1MDMsMTUgQEAKICAgICAgICAgICovCiAJaWYgKGFkYXB0 ZXItPm51bV90eF9kZXNjX2F2YWlsIDw9IEVNX1RYX0NMRUFOVVBfVEhSRVNIT0xEKSB7CiAJCWVt X3R4ZW9mKGFkYXB0ZXIpOwotCQlpZiAoYWRhcHRlci0+bnVtX3R4X2Rlc2NfYXZhaWwgPD0gRU1f VFhfQ0xFQU5VUF9USFJFU0hPTEQpIHsKKwkJLyogTm93IGRvIHdlIGF0IGxlYXN0IGhhdmUgYSBt aW5pbWFsPyAqLworCQlpZiAoYWRhcHRlci0+bnVtX3R4X2Rlc2NfYXZhaWwgPD0gRU1fVFhfT1Bf VEhSRVNIT0xEKSB7CiAJCQlhZGFwdGVyLT5ub190eF9kZXNjX2F2YWlsMSsrOwotCQkJcmV0dXJu KEVOT0JVRlMpOworCQkJcmV0dXJuIChFTk9CVUZTKTsKIAkJfQotICAgICAgICB9Ci0KLQkvKgot CSAqIENhcHR1cmUgdGhlIGZpcnN0IGRlc2NyaXB0b3IgaW5kZXgsCi0JICogdGhpcyBkZXNjcmlw dG9yIHdpbGwgaGF2ZSB0aGUgaW5kZXgKLQkgKiBvZiB0aGUgRU9QIHdoaWNoIGlzIHRoZSBvbmx5 IG9uZSB0aGF0Ci0JICogbm93IGdldHMgYSBET05FIGJpdCB3cml0ZWJhY2suCi0JICovCi0JZmly c3QgPSBhZGFwdGVyLT5uZXh0X2F2YWlsX3R4X2Rlc2M7CisJfQogCi0gICAgICAgIC8qIEZpbmQg b3V0IGlmIHdlIGFyZSBpbiB2bGFuIG1vZGUgKi8KLSAgICAgICAgbXRhZyA9IFZMQU5fT1VUUFVU X1RBRyhpZnAsIG1faGVhZCk7CisJLyogRmluZCBvdXQgaWYgd2UgYXJlIGluIHZsYW4gbW9kZS4g Ki8KKwltdGFnID0gVkxBTl9PVVRQVVRfVEFHKGlmcCwgbV9oZWFkKTsKIAogCS8qCiAJICogV2hl biBvcGVyYXRpbmcgaW4gcHJvbWlzY3VvdXMgbW9kZSwgaGFyZHdhcmUgZW5jYXBzdWxhdGlvbiBm b3IKQEAgLTE0MzMsNiArMTU2MSwxNCBAQAogCQkJcmV0dXJuIChFTk9CVUZTKTsKIAl9CiAKKwkv KgorCSAqIENhcHR1cmUgdGhlIGZpcnN0IGRlc2NyaXB0b3IgaW5kZXgsCisJICogdGhpcyBkZXNj cmlwdG9yIHdpbGwgaGF2ZSB0aGUgaW5kZXgKKwkgKiBvZiB0aGUgRU9QIHdoaWNoIGlzIHRoZSBv bmx5IG9uZSB0aGF0CisJICogbm93IGdldHMgYSBET05FIGJpdCB3cml0ZWJhY2suCisJICovCisJ Zmlyc3QgPSBhZGFwdGVyLT5uZXh0X2F2YWlsX3R4X2Rlc2M7CisKICAgICAgICAgLyoKICAgICAg ICAgICogTWFwIHRoZSBwYWNrZXQgZm9yIERNQS4KICAgICAgICAgICovCkBAIC0xNDUyLDYgKzE1 ODgsOCBAQAogCQkJcmV0dXJuIChFTk9CVUZTKTsKIAkJfQogCQkqbV9oZWFkcCA9IG07CisJCW1f aGVhZCA9ICptX2hlYWRwOworCiAJCS8qIFRyeSBpdCBhZ2FpbiAqLwogCQllcnJvciA9IGJ1c19k bWFtYXBfbG9hZF9tYnVmX3NnKGFkYXB0ZXItPnR4dGFnLCB0eF9idWZmZXItPm1hcCwKIAkJICAg ICptX2hlYWRwLCBzZWdzLCAmbnNlZ3MsIEJVU19ETUFfTk9XQUlUKTsKQEAgLTE2MzgsNyArMTc3 Niw3IEBACiAJICAgIEJVU19ETUFTWU5DX1BSRVJFQUQgfCBCVVNfRE1BU1lOQ19QUkVXUklURSk7 CiAJaWYgKGFkYXB0ZXItPmh3Lm1hY190eXBlID09IGVtXzgyNTQ3ICYmCiAJICAgIGFkYXB0ZXIt PmxpbmtfZHVwbGV4ID09IEhBTEZfRFVQTEVYKQotCQllbV84MjU0N19tb3ZlX3RhaWxfbG9ja2Vk KGFkYXB0ZXIpOworCQllbV84MjU0N19tb3ZlX3RhaWwoYWRhcHRlcik7CiAJZWxzZSB7CiAJCUUx MDAwX1dSSVRFX1JFRygmYWRhcHRlci0+aHcsIFREVCwgaSk7CiAJCWlmIChhZGFwdGVyLT5ody5t YWNfdHlwZSA9PSBlbV84MjU0NykKQEAgLTE2NjIsOCArMTgwMCw5IEBACiAgKgogICoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKiovCiBzdGF0aWMgdm9pZAotZW1fODI1NDdfbW92ZV90YWlsX2xvY2tlZChzdHJ1Y3QgYWRh cHRlciAqYWRhcHRlcikKK2VtXzgyNTQ3X21vdmVfdGFpbCh2b2lkICphcmcpCiB7CisJc3RydWN0 IGFkYXB0ZXIgKmFkYXB0ZXIgPSBhcmc7CiAJdWludDE2X3QgaHdfdGR0OwogCXVpbnQxNl90IHN3 X3RkdDsKIAlzdHJ1Y3QgZW1fdHhfZGVzYyAqdHhfZGVzYzsKQEAgLTE2OTYsMTYgKzE4MzUsNiBA QAogCX0JCiB9CiAKLXN0YXRpYyB2b2lkCi1lbV84MjU0N19tb3ZlX3RhaWwodm9pZCAqYXJnKQot ewotCXN0cnVjdCBhZGFwdGVyICphZGFwdGVyID0gYXJnOwotCi0JRU1fTE9DSyhhZGFwdGVyKTsK LQllbV84MjU0N19tb3ZlX3RhaWxfbG9ja2VkKGFkYXB0ZXIpOwotCUVNX1VOTE9DSyhhZGFwdGVy KTsKLX0KLQogc3RhdGljIGludAogZW1fODI1NDdfZmlmb193b3JrYXJvdW5kKHN0cnVjdCBhZGFw dGVyICphZGFwdGVyLCBpbnQgbGVuKQogewkKQEAgLTE4OTMsNyArMjAyMiw3IEBACiAJc3RydWN0 IGFkYXB0ZXIJKmFkYXB0ZXIgPSBhcmc7CiAJc3RydWN0IGlmbmV0CSppZnAgPSBhZGFwdGVyLT5p ZnA7CiAKLQlFTV9MT0NLKGFkYXB0ZXIpOworCUVNX0xPQ0tfQVNTRVJUKGFkYXB0ZXIpOwogCiAJ ZW1fY2hlY2tfZm9yX2xpbmsoJmFkYXB0ZXItPmh3KTsKIAllbV91cGRhdGVfbGlua19zdGF0dXMo YWRhcHRlcik7CkBAIC0xOTAxLDEwICsyMDMwLDE0IEBACiAJaWYgKGVtX2Rpc3BsYXlfZGVidWdf c3RhdHMgJiYgaWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcpCiAJCWVtX3ByaW50 X2h3X3N0YXRzKGFkYXB0ZXIpOwogCWVtX3NtYXJ0c3BlZWQoYWRhcHRlcik7CisJLyoKKwkgKiBF YWNoIHNlY29uZCB3ZSBjaGVjayB0aGUgd2F0Y2hkb2cgdG8gCisJICogcHJvdGVjdCBhZ2FpbnN0 IGhhcmR3YXJlIGhhbmdzLgorCSAqLworCWVtX3dhdGNoZG9nKGFkYXB0ZXIpOwogCiAJY2FsbG91 dF9yZXNldCgmYWRhcHRlci0+dGltZXIsIGh6LCBlbV9sb2NhbF90aW1lciwgYWRhcHRlcik7CiAK LQlFTV9VTkxPQ0soYWRhcHRlcik7CiB9CiAKIHN0YXRpYyB2b2lkCkBAIC0yMDg2LDMwICsyMjE5 LDkwIEBACiAJCSAgICAiaW50ZXJydXB0XG4iKTsKIAkJcmV0dXJuIChFTlhJTyk7CiAJfQotCWlm IChidXNfc2V0dXBfaW50cihkZXYsIGFkYXB0ZXItPnJlc19pbnRlcnJ1cHQsCi0JICAgIElOVFJf VFlQRV9ORVQgfCBJTlRSX01QU0FGRSwKLQkgICAgKHZvaWQgKCopKHZvaWQgKikpIGVtX2ludHIs IGFkYXB0ZXIsCi0JICAgICZhZGFwdGVyLT5pbnRfaGFuZGxlcl90YWcpKSB7Ci0JCWRldmljZV9w cmludGYoZGV2LCAiRXJyb3IgcmVnaXN0ZXJpbmcgaW50ZXJydXB0IGhhbmRsZXIhXG4iKTsKLQkJ cmV0dXJuKEVOWElPKTsKLQl9CiAKIAlhZGFwdGVyLT5ody5iYWNrID0gJmFkYXB0ZXItPm9zZGVw OwogCiAJcmV0dXJuICgwKTsKIH0KIAorLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgorICoKKyAqICBTZXR1cCB0aGUg YXBwcm9wcmlhdGUgSW50ZXJydXB0IGhhbmRsZXJzLgorICoKKyAqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLworaW50 CitlbV9hbGxvY2F0ZV9pbnRyKHN0cnVjdCBhZGFwdGVyICphZGFwdGVyKQoreworCWRldmljZV90 IGRldiA9IGFkYXB0ZXItPmRldjsKKwlpbnQgZXJyb3I7CisKKwkvKiBNYW51YWxseSB0dXJuIG9m ZiBhbGwgaW50ZXJydXB0cyAqLworCUUxMDAwX1dSSVRFX1JFRygmYWRhcHRlci0+aHcsIElNQywg MHhmZmZmZmZmZik7CisKKyNpZm5kZWYgRU1fRkFTVF9JTlRSCisJLyogV2UgZG8gTGVnYWN5IHNl dHVwICovCisJaWYgKGFkYXB0ZXItPmludF9oYW5kbGVyX3RhZyA9PSBOVUxMICYmCisJICAgIChl cnJvciA9IGJ1c19zZXR1cF9pbnRyKGRldiwgYWRhcHRlci0+cmVzX2ludGVycnVwdCwKKwkgICAg SU5UUl9UWVBFX05FVCB8IElOVFJfTVBTQUZFLCBlbV9pbnRyLCBhZGFwdGVyLAorCSAgICAmYWRh cHRlci0+aW50X2hhbmRsZXJfdGFnKSkgIT0gMCkgeworCQlkZXZpY2VfcHJpbnRmKGRldiwgIkZh aWxlZCB0byByZWdpc3RlciBpbnRlcnJ1cHQgaGFuZGxlciIpOworCQlyZXR1cm4gKGVycm9yKTsK Kwl9CisKKyNlbHNlIC8qIEVNX0ZBU1RfSU5UUiAqLworCS8qCisJICogVHJ5IGFsbG9jYXRpbmcg YSBmYXN0IGludGVycnVwdCBhbmQgdGhlIGFzc29jaWF0ZWQgZGVmZXJyZWQKKwkgKiBwcm9jZXNz aW5nIGNvbnRleHRzLgorCSAqLworCVRBU0tfSU5JVCgmYWRhcHRlci0+cnh0eF90YXNrLCAwLCBl bV9oYW5kbGVfcnh0eCwgYWRhcHRlcik7CisJVEFTS19JTklUKCZhZGFwdGVyLT5saW5rX3Rhc2ss IDAsIGVtX2hhbmRsZV9saW5rLCBhZGFwdGVyKTsKKwlhZGFwdGVyLT50cSA9IHRhc2txdWV1ZV9j cmVhdGVfZmFzdCgiZW1fdGFza3EiLCBNX05PV0FJVCwKKwkgICAgdGFza3F1ZXVlX3RocmVhZF9l bnF1ZXVlLCAmYWRhcHRlci0+dHEpOworCXRhc2txdWV1ZV9zdGFydF90aHJlYWRzKCZhZGFwdGVy LT50cSwgMSwgUElfTkVULCAiJXMgdGFza3EiLAorCSAgICBkZXZpY2VfZ2V0X25hbWV1bml0KGFk YXB0ZXItPmRldikpOworCWlmICgoZXJyb3IgPSBidXNfc2V0dXBfaW50cihkZXYsIGFkYXB0ZXIt PnJlc19pbnRlcnJ1cHQsCisJICAgIElOVFJfVFlQRV9ORVQgfCBJTlRSX0ZBU1QsIGVtX2ludHJf ZmFzdCwgYWRhcHRlciwKKwkgICAgJmFkYXB0ZXItPmludF9oYW5kbGVyX3RhZykpICE9IDApIHsK KwkJZGV2aWNlX3ByaW50ZihkZXYsICJGYWlsZWQgdG8gcmVnaXN0ZXIgZmFzdCBpbnRlcnJ1cHQg IgorCQkJICAgICJoYW5kbGVyOiAlZFxuIiwgZXJyb3IpOworCQl0YXNrcXVldWVfZnJlZShhZGFw dGVyLT50cSk7CisJCWFkYXB0ZXItPnRxID0gTlVMTDsKKwkJcmV0dXJuIChlcnJvcik7CisJfQor I2VuZGlmIC8qIEVNX0ZBU1RfSU5UUiAqLworCisJZW1fZW5hYmxlX2ludHIoYWRhcHRlcik7CisJ cmV0dXJuICgwKTsKK30KKwogc3RhdGljIHZvaWQKLWVtX2ZyZWVfcGNpX3Jlc291cmNlcyhzdHJ1 Y3QgYWRhcHRlciAqYWRhcHRlcikKK2VtX2ZyZWVfaW50cihzdHJ1Y3QgYWRhcHRlciAqYWRhcHRl cikKIHsKIAlkZXZpY2VfdCBkZXYgPSBhZGFwdGVyLT5kZXY7CiAKIAlpZiAoYWRhcHRlci0+cmVz X2ludGVycnVwdCAhPSBOVUxMKSB7CiAJCWJ1c190ZWFyZG93bl9pbnRyKGRldiwgYWRhcHRlci0+ cmVzX2ludGVycnVwdCwKIAkJCWFkYXB0ZXItPmludF9oYW5kbGVyX3RhZyk7CisJCWFkYXB0ZXIt PmludF9oYW5kbGVyX3RhZyA9IE5VTEw7CisJfQorI2lmZGVmIEVNX0ZBU1RfSU5UUgorCWlmIChh ZGFwdGVyLT50cSAhPSBOVUxMKSB7CisJCXRhc2txdWV1ZV9kcmFpbihhZGFwdGVyLT50cSwgJmFk YXB0ZXItPnJ4dHhfdGFzayk7CisJCXRhc2txdWV1ZV9kcmFpbih0YXNrcXVldWVfZmFzdCwgJmFk YXB0ZXItPmxpbmtfdGFzayk7CisJCXRhc2txdWV1ZV9mcmVlKGFkYXB0ZXItPnRxKTsKKwkJYWRh cHRlci0+dHEgPSBOVUxMOworCX0KKyNlbmRpZgorfQorCitzdGF0aWMgdm9pZAorZW1fZnJlZV9w Y2lfcmVzb3VyY2VzKHN0cnVjdCBhZGFwdGVyICphZGFwdGVyKQoreworCWRldmljZV90IGRldiA9 IGFkYXB0ZXItPmRldjsKKworCWlmIChhZGFwdGVyLT5yZXNfaW50ZXJydXB0ICE9IE5VTEwpCiAJ CWJ1c19yZWxlYXNlX3Jlc291cmNlKGRldiwgU1lTX1JFU19JUlEsCiAJCSAgICAwLCBhZGFwdGVy LT5yZXNfaW50ZXJydXB0KTsKLQl9CiAKIAlpZiAoYWRhcHRlci0+cmVzX21lbW9yeSAhPSBOVUxM KQogCQlidXNfcmVsZWFzZV9yZXNvdXJjZShkZXYsIFNZU19SRVNfTUVNT1JZLApAQCAtMjIyOSw3 ICsyNDIyLDggQEAKIAlpZnAtPmlmX2ZsYWdzID0gSUZGX0JST0FEQ0FTVCB8IElGRl9TSU1QTEVY IHwgSUZGX01VTFRJQ0FTVDsKIAlpZnAtPmlmX2lvY3RsID0gZW1faW9jdGw7CiAJaWZwLT5pZl9z dGFydCA9IGVtX3N0YXJ0OwotCWlmcC0+aWZfd2F0Y2hkb2cgPSBlbV93YXRjaGRvZzsKKwlpZnAt PmlmX3RpbWVyID0gMDsJLyogRGlzYWJsZSBuZXQgbGF5ZXIgd2F0Y2hkb2cgKi8KKwlpZnAtPmlm X3dhdGNoZG9nID0gTlVMTDsKIAlJRlFfU0VUX01BWExFTigmaWZwLT5pZl9zbmQsIGFkYXB0ZXIt Pm51bV90eF9kZXNjIC0gMSk7CiAJaWZwLT5pZl9zbmQuaWZxX2Rydl9tYXhsZW4gPSBhZGFwdGVy LT5udW1fdHhfZGVzYyAtIDE7CiAJSUZRX1NFVF9SRUFEWSgmaWZwLT5pZl9zbmQpOwpAQCAtMjQ1 MywyNiArMjY0NywxOSBAQAogewogCWRldmljZV90IGRldiA9IGFkYXB0ZXItPmRldjsKIAlzdHJ1 Y3QgZW1fYnVmZmVyICp0eF9idWZmZXI7Ci0JYnVzX3NpemVfdCBzaXplLCBzZWdzaXplOwogCWlu dCBlcnJvciwgaTsKIAotI2lmZGVmIEVNX1RTTwotCXNpemUgPSBFTV9UU09fU0laRTsKLQlzZWdz aXplID0gUEFHRV9TSVpFOwotI2Vsc2UKLQlzZWdzaXplID0gc2l6ZSA9IHJvdW5kdXAyKGFkYXB0 ZXItPmh3Lm1heF9mcmFtZV9zaXplLCBNQ0xCWVRFUyk7Ci0jZW5kaWYKIAkvKgotCSAqIFNldHVw IERNQSBkZXNjcmlwdG9yIGFyZWFzLgorCSAqIENyZWF0ZSBETUEgdGFncyBmb3IgdHggZGVzY3Jp cHRvcnMKIAkgKi8KIAlpZiAoKGVycm9yID0gYnVzX2RtYV90YWdfY3JlYXRlKE5VTEwsCQkvKiBw YXJlbnQgKi8KIAkJCQkxLCAwLAkJCS8qIGFsaWdubWVudCwgYm91bmRzICovCiAJCQkJQlVTX1NQ QUNFX01BWEFERFIsCS8qIGxvd2FkZHIgKi8KIAkJCQlCVVNfU1BBQ0VfTUFYQUREUiwJLyogaGln aGFkZHIgKi8KIAkJCQlOVUxMLCBOVUxMLAkJLyogZmlsdGVyLCBmaWx0ZXJhcmcgKi8KLQkJCQlz aXplLAkJCS8qIG1heHNpemUgKi8KKwkJCQlFTV9UU09fU0laRSwJCS8qIG1heHNpemUgKi8KIAkJ CQlFTV9NQVhfU0NBVFRFUiwJCS8qIG5zZWdtZW50cyAqLwotCQkJCXNlZ3NpemUsCQkvKiBtYXhz ZWdzaXplICovCisJCQkJUEFHRV9TSVpFLAkJLyogbWF4c2Vnc2l6ZSAqLwogCQkJCTAsCQkJLyog ZmxhZ3MgKi8KIAkJCQlOVUxMLAkJLyogbG9ja2Z1bmMgKi8KIAkJCQlOVUxMLAkJLyogbG9ja2Fy ZyAqLwpAQCAtMjQ4OSw2ICsyNjc2LDcgQEAKIAkJZ290byBmYWlsOwogCX0KIAorCS8qIENyZWF0 ZSB0aGUgZGVzY3JpcHRvciBidWZmZXIgZG1hIG1hcHMgKi8KIAl0eF9idWZmZXIgPSBhZGFwdGVy LT50eF9idWZmZXJfYXJlYTsKIAlmb3IgKGkgPSAwOyBpIDwgYWRhcHRlci0+bnVtX3R4X2Rlc2M7 IGkrKykgewogCQllcnJvciA9IGJ1c19kbWFtYXBfY3JlYXRlKGFkYXB0ZXItPnR4dGFnLCAwLCAm dHhfYnVmZmVyLT5tYXApOwpAQCAtMjUxNyw2ICsyNzA1LDcgQEAKIAlzdHJ1Y3QgZW1fYnVmZmVy ICp0eF9idWZmZXI7CiAJaW50IGk7CiAKKwkvKiBDbGVhciB0aGUgb2xkIHJpbmcgY29udGVudHMg Ki8KIAliemVybyhhZGFwdGVyLT50eF9kZXNjX2Jhc2UsCiAJICAgIChzaXplb2Yoc3RydWN0IGVt X3R4X2Rlc2MpKSAqIGFkYXB0ZXItPm51bV90eF9kZXNjKTsKIApAQCAtMjg1Nyw4ICszMDQ2LDEw IEBACiAgICAgICAgIGVvcF9kZXNjID0gJmFkYXB0ZXItPnR4X2Rlc2NfYmFzZVtsYXN0XTsKIAog CS8qCi0JICogTm93IGNhY3VsYXRlIHRoZSB0ZXJtaW5hdGluZyBpbmRleAotCSAqIGZvciB0aGUg Y2xlYW51cCBsb29wIGJlbG93CisJICogV2hhdCB0aGlzIGRvZXMgaXMgZ2V0IHRoZSBpbmRleCBv ZiB0aGUKKwkgKiBmaXJzdCBkZXNjcmlwdG9yIEFGVEVSIHRoZSBFT1Agb2YgdGhlIAorCSAqIGZp cnN0IHBhY2tldCwgdGhhdCB3YXkgd2UgY2FuIGRvIHRoZQorCSAqIHNpbXBsZSBjb21wYXJpc29u IG9uIHRoZSBpbm5lciB3aGlsZSBsb29wLgogCSAqLwogCWlmICgrK2xhc3QgPT0gYWRhcHRlci0+ bnVtX3R4X2Rlc2MpIGxhc3QgPSAwOwogCWRvbmUgPSBsYXN0OwpAQCAtMjkxNSwxMCArMzEwNiwx MiBAQAogICAgICAgICAgKi8KICAgICAgICAgaWYgKG51bV9hdmFpbCA+IEVNX1RYX0NMRUFOVVBf VEhSRVNIT0xEKSB7ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgIGlmcC0+aWZfZHJ2 X2ZsYWdzICY9IH5JRkZfRFJWX09BQ1RJVkU7CisJCS8qIEFsbCBjbGVhbiwgdHVybiBvZmYgdGhl IHRpbWVyICovCiAgICAgICAgICAgICAgICAgaWYgKG51bV9hdmFpbCA9PSBhZGFwdGVyLT5udW1f dHhfZGVzYykKLSAgICAgICAgICAgICAgICAgICAgICAgIGlmcC0+aWZfdGltZXIgPSAwOworCQkJ YWRhcHRlci0+d2F0Y2hkb2dfdGltZXIgPSAwOworCQkvKiBTb21lIGNsZWFuZWQsIHJlc2V0IHRo ZSB0aW1lciAqLwogICAgICAgICAgICAgICAgIGVsc2UgaWYgKG51bV9hdmFpbCAhPSBhZGFwdGVy LT5udW1fdHhfZGVzY19hdmFpbCkKLSAgICAgICAgICAgICAgICAgICAgICAgIGlmcC0+aWZfdGlt ZXIgPSBFTV9UWF9USU1FT1VUOworCQkJYWRhcHRlci0+d2F0Y2hkb2dfdGltZXIgPSBFTV9UWF9U SU1FT1VUOwogICAgICAgICB9CiAgICAgICAgIGFkYXB0ZXItPm51bV90eF9kZXNjX2F2YWlsID0g bnVtX2F2YWlsOwogICAgICAgICByZXR1cm47CkBAIC0zMzY5LDkgKzM1NjIsMTQgQEAKIAkJCWkg PSAwOwogCQlpZiAobSAhPSBOVUxMKSB7CiAJCQlhZGFwdGVyLT5uZXh0X3J4X2Rlc2NfdG9fY2hl Y2sgPSBpOworI2lmbmRlZiBFTV9GQVNUX0lOVFIKIAkJCUVNX1VOTE9DSyhhZGFwdGVyKTsKIAkJ CSgqaWZwLT5pZl9pbnB1dCkoaWZwLCBtKTsKIAkJCUVNX0xPQ0soYWRhcHRlcik7CisjZWxzZQor CQkJLyogQWxyZWFkeSBydW5uaW5nIHVubG9ja2VkICovCisJCQkoKmlmcC0+aWZfaW5wdXQpKGlm cCwgbSk7CisjZW5kaWYKIAkJCWkgPSBhZGFwdGVyLT5uZXh0X3J4X2Rlc2NfdG9fY2hlY2s7CiAJ CX0KIAkJY3VycmVudF9kZXNjID0gJmFkYXB0ZXItPnJ4X2Rlc2NfYmFzZVtpXTsKQEAgLTM3OTYs NiArMzk5NCw4IEBACiAJICAgIGFkYXB0ZXItPm1idWZfY2x1c3Rlcl9mYWlsZWQpOwogCWRldmlj ZV9wcmludGYoZGV2LCAiRHJpdmVyIGRyb3BwZWQgcGFja2V0cyA9ICVsZFxuIiwKIAkgICAgYWRh cHRlci0+ZHJvcHBlZF9wa3RzKTsKKwlkZXZpY2VfcHJpbnRmKGRldiwgIkRyaXZlciB0eCBkbWEg ZmFpbHVyZSBpbiBlbmNhcCA9ICVsZFxuIiwKKwkJYWRhcHRlci0+bm9fdHhfZG1hX3NldHVwKTsK IH0KIAogc3RhdGljIHZvaWQKQEAgLTM5NTIsNCArNDE1MiwxNCBAQAogCSAgICBTWVNDVExfQ0hJ TERSRU4oZGV2aWNlX2dldF9zeXNjdGxfdHJlZShhZGFwdGVyLT5kZXYpKSwKIAkgICAgT0lEX0FV VE8sIG5hbWUsIENUTFRZUEVfSU5UfENUTEZMQUdfUlcsCiAJICAgIGluZm8sIDAsIGVtX3N5c2N0 bF9pbnRfZGVsYXksICJJIiwgZGVzY3JpcHRpb24pOworfQorCitzdGF0aWMgdm9pZAorZW1fYWRk X3J4X3Byb2Nlc3NfbGltaXQoc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIsIGNvbnN0IGNoYXIgKm5h bWUsCisJY29uc3QgY2hhciAqZGVzY3JpcHRpb24sIGludCAqbGltaXQsIGludCB2YWx1ZSkKK3sK KwkqbGltaXQgPSB2YWx1ZTsKKwlTWVNDVExfQUREX0lOVChkZXZpY2VfZ2V0X3N5c2N0bF9jdHgo YWRhcHRlci0+ZGV2KSwKKwkgICAgU1lTQ1RMX0NISUxEUkVOKGRldmljZV9nZXRfc3lzY3RsX3Ry ZWUoYWRhcHRlci0+ZGV2KSksCisJICAgIE9JRF9BVVRPLCBuYW1lLCBDVExUWVBFX0lOVHxDVExG TEFHX1JXLCBsaW1pdCwgdmFsdWUsIGRlc2NyaXB0aW9uKTsKIH0KZGlmZiAtTmF1ciBzdGFibGUv ZGV2L2VtL2lmX2VtLmggbmV3cGF0Y2gvZGV2L2VtL2lmX2VtLmgKLS0tIHN0YWJsZS9kZXYvZW0v aWZfZW0uaAlXZWQgTm92ICA4IDIzOjQyOjMwIDIwMDYKKysrIG5ld3BhdGNoL2Rldi9lbS9pZl9l bS5oCVRodSBOb3YgIDkgMDA6MDc6MTUgMjAwNgpAQCAtMTUwLDEwICsxNTAsMTEgQEAKICNkZWZp bmUgRU1fVFhfVElNRU9VVCAgICAgICAgICAgICAgICAgICA1ICAgIC8qIHNldCB0byA1IHNlY29u ZHMgKi8KIAogLyoKLSAqIFRoaXMgcGFyYW1ldGVyIGNvbnRyb2xzIHdoZW4gdGhlIGRyaXZlciBj YWxscyB0aGUgcm91dGluZSB0byByZWNsYWltCisgKiBUaGVzZSBwYXJhbWV0ZXJzIGNvbnRyb2xz IHdoZW4gdGhlIGRyaXZlciBjYWxscyB0aGUgcm91dGluZSB0byByZWNsYWltCiAgKiB0cmFuc21p dCBkZXNjcmlwdG9ycy4KICAqLwogI2RlZmluZSBFTV9UWF9DTEVBTlVQX1RIUkVTSE9MRAkJKGFk YXB0ZXItPm51bV90eF9kZXNjIC8gOCkKKyNkZWZpbmUgRU1fVFhfT1BfVEhSRVNIT0xECQkoYWRh cHRlci0+bnVtX3R4X2Rlc2MgLyAzMikKIAogLyoKICAqIFRoaXMgcGFyYW1ldGVyIGNvbnRyb2xz IHdoZXRoZXIgb3Igbm90IGF1dG9uZWdvdGF0aW9uIGlzIGVuYWJsZWQuCkBAIC0yMjAsNyArMjIx LDcgQEAKICNkZWZpbmUgRU1fQkFSX01FTV9UWVBFXzMyQklUCQkweDAwMDAwMDAwCiAjZGVmaW5l IEVNX0JBUl9NRU1fVFlQRV82NEJJVAkJMHgwMDAwMDAwNAogLyoKLSAqIEJhY2t3YXJkIGNvbXBh dGliaWxpdHkgaGFjaworICogQmFja3dhcmQgY29tcGF0aWJpbGl0eSB3b3JrYXJvdW5kCiAgKi8K ICNpZiAhZGVmaW5lZChQQ0lSX0NJUykKICNkZWZpbmUgUENJUl9DSVMJUENJUl9DQVJEQlVTQ0lT CkBAIC0yOTIsNyArMjkzLDcgQEAKIAlPRkZMT0FEX1VEUF9JUAogfSBYU1VNX0NPTlRFWFRfVDsK IAotc3RydWN0IGFkYXB0ZXIgYWRhcHRlcjsJCS8qIFhYWDogdWdseSBmb3J3YXJkIGRlY2xhcmF0 aW9uICovCitzdHJ1Y3QgYWRhcHRlcjsKIHN0cnVjdCBlbV9pbnRfZGVsYXlfaW5mbyB7CiAJc3Ry dWN0IGFkYXB0ZXIgKmFkYXB0ZXI7CS8qIEJhY2stcG9pbnRlciB0byB0aGUgYWRhcHRlciBzdHJ1 Y3QgKi8KIAlpbnQgb2Zmc2V0OwkJCS8qIFJlZ2lzdGVyIG9mZnNldCB0byByZWFkL3dyaXRlICov CkBAIC0zMjgsMTAgKzMyOSwxNyBAQAogCXN0cnVjdCBpZm1lZGlhCW1lZGlhOwogCXN0cnVjdCBj YWxsb3V0CXRpbWVyOwogCXN0cnVjdCBjYWxsb3V0CXR4X2ZpZm9fdGltZXI7CisJaW50CQl3YXRj aGRvZ190aW1lcjsKIAlpbnQJCWlvX3JpZDsKIAlpbnQJCWlmX2ZsYWdzOwogCXN0cnVjdCBtdHgJ bXR4OwogCWludAkJZW1faW5zZXJ0X3ZsYW5faGVhZGVyOworCisjaWZkZWYgRU1fRkFTVF9JTlRS CisJc3RydWN0IHRhc2sJbGlua190YXNrOworCXN0cnVjdCB0YXNrCXJ4dHhfdGFzazsKKwlzdHJ1 Y3QgdGFza3F1ZXVlICp0cTsKKyNlbmRpZgogCS8qIEluZm8gYWJvdXQgdGhlIGJvYXJkIGl0c2Vs ZiAqLwogCXVpbnQzMl90CXBhcnRfbnVtOwogCXVpbnQ4X3QJCWxpbmtfYWN0aXZlOwo= ------=_Part_35052_20023030.1163035142787-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 9 04:35:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6956B16A40F for ; Thu, 9 Nov 2006 04:35:39 +0000 (UTC) (envelope-from smw2010@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE10C43D5C for ; Thu, 9 Nov 2006 04:35:36 +0000 (GMT) (envelope-from smw2010@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so52347nzh for ; Wed, 08 Nov 2006 20:35:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Oa0lbQtCKFGsW7k2cpIyWN2MSkD6QfzMy6srJ7kMC9zEevxvrm5iZmUverUCwdwZHsz9/MlQ2IVA+TQIqPxJs0NeJC2Ee7ZSB9AH28o59RD80cHDFg2+gKs+cLgOj/nCWs5DK//oSOI3nkToKyeNoZ2glW7EC2plprt5giF043c= Received: by 10.65.239.14 with SMTP id q14mr496113qbr.1163046935560; Wed, 08 Nov 2006 20:35:35 -0800 (PST) Received: by 10.65.241.10 with HTTP; Wed, 8 Nov 2006 20:35:35 -0800 (PST) Message-ID: Date: Thu, 9 Nov 2006 15:35:35 +1100 From: "Sam Wun" To: "Jack Vogel" In-Reply-To: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> MIME-Version: 1.0 References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Scott Long , RelEng , John Baldwin , freebsd-net , freebsd-stable@freebsd.org Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 04:35:39 -0000 Without introduced this new patch, can I still use sysctl to maximise its performance like FAST_INTR? S On 11/9/06, Jack Vogel wrote: > > This patch is an evolution of the last one I sent out. It has > a couple of minor corrections, like a bad forward decl in > the header. > > The last patch has had quite a bit of testing and all reports > have been positive. The only complaint was from Gleb who > says he needs to keep his beloved infinite for loop in the > interrupt handler, well I have a better one for you Gleb, keep > reading. > > I have also been doing some extreme stress testing using > SmartBits, and discovered the driver as it stands is really > not able to take extreme receive side pounding, Scott > pointed out that this is why the FAST_INTR work was done :) > > There were some people that had stability issues with that > work, but there were also many that did not. I actually > merged the FAST code onto my last patch, and ran the > SB stress and found it really was able to gracefully handle > that load, way to go Scott :) > > I've pondered this situation, and this patch I'm including here > today is the result. Here's what it does: > > If you drop it in place, compile it, and go... you will get the > code that has been tested for a week, it uses the older > style interrupts, it has the watchdog and other SMP fixes > so its been proven. > > BUT, I've added the FAST_INTR changes back into the code, so > if you go into your Makefile and add -DEM_FAST_INTR you will > then get the taskqueue stuff. > > So, Gleb, rather than replace the infinite for loop that no one > thinks is a good idea, you can just define FAST_INTR again, > and you should be good to go. > > I see this as the best thing for the 6.2 RELEASE, it lets us > keep moving forward, people that want max performance > can define EM_FAST_INTR and help us wring out any > problems, it also will mean that I will have our Intel test > group start using this code. But for those that just want > a stable driver the standard compile will still give them that. > > The patch I'm including is against BETA3. Let me know of > your concerns or issues. > > Cheers, > > Jack > > > _______________________________________________ > 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" > > > From owner-freebsd-net@FreeBSD.ORG Thu Nov 9 05:30:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE6C916A70C for ; Thu, 9 Nov 2006 05:30:43 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2169B43D5A for ; Thu, 9 Nov 2006 05:30:43 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so59806nzh for ; Wed, 08 Nov 2006 21:30:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UIB0X2XJ2/tOyzMa8T7gozdaovn7mV6NDfDcrGGWrhX1cTKVFiyDZLGdSsng2Y7Ig/xgn1DJMbqzzzkVVfriVm9+iZ/gKJ7vvNvTrEovaSvdKXozIYxwfFhA4y2dF2dxbwmYCnflZwDdRef24AIPxlZrGG890Y68itt9xeTgdB8= Received: by 10.35.31.14 with SMTP id i14mr85807pyj.1163049843788; Wed, 08 Nov 2006 21:24:03 -0800 (PST) Received: by 10.35.118.6 with HTTP; Wed, 8 Nov 2006 21:24:03 -0800 (PST) Message-ID: <2a41acea0611082124x4143289emb0c3e0dee3e50ecc@mail.gmail.com> Date: Wed, 8 Nov 2006 21:24:03 -0800 From: "Jack Vogel" To: "Sam Wun" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> Cc: Scott Long , RelEng , John Baldwin , freebsd-net , freebsd-stable@freebsd.org Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 05:30:43 -0000 On 11/8/06, Sam Wun wrote: > Without introduced this new patch, can I still use sysctl to maximise its > performance like FAST_INTR? > > S Not sure if I'm understanding you, but let me try. You cannot attain the same receive performance without the patch. When I use SmartBits and blast UDP packets at TWO fiber PCI-E NICS and set it to 70% utilization of the line it will just BURY the system, meaning that the shell on the console will appear wedged. Once you stop the test it recovers, but during it its totally consumed handling interrupts. Perhaps with careful tweaking of everything you can make things better, but if so that goes beyond my tuning knowledge. Just one NIC will be OK, and if I drop the utilization down to 45% its ok, but 50 and up and we go into the tank, as it were :) If you compile with EM_FAST_INTR then the system will continue to operate quite well with the same load. Now, this is one kind of load, and there is still other types that work just fine without FAST_INTR, and without the patch you can still use sysctl to adjust tuning parameters as your needs vary. BUT, I do not believe you can do as well as you can with FAST_INTR on, this is why I wanted to get this code back into the driver conditionally before RELEASE. Does that answer your question Sam? Regards, Jack > > On 11/9/06, Jack Vogel < jfvogel@gmail.com> wrote: > > > > This patch is an evolution of the last one I sent out. It has > > a couple of minor corrections, like a bad forward decl in > > the header. > > > > The last patch has had quite a bit of testing and all reports > > have been positive. The only complaint was from Gleb who > > says he needs to keep his beloved infinite for loop in the > > interrupt handler, well I have a better one for you Gleb, keep > > reading. > > > > I have also been doing some extreme stress testing using > > SmartBits, and discovered the driver as it stands is really > > not able to take extreme receive side pounding, Scott > > pointed out that this is why the FAST_INTR work was done :) > > > > There were some people that had stability issues with that > > work, but there were also many that did not. I actually > > merged the FAST code onto my last patch, and ran the > > SB stress and found it really was able to gracefully handle > > that load, way to go Scott :) > > > > I've pondered this situation, and this patch I'm including here > > today is the result. Here's what it does: > > > > If you drop it in place, compile it, and go... you will get the > > code that has been tested for a week, it uses the older > > style interrupts, it has the watchdog and other SMP fixes > > so its been proven. > > > > BUT, I've added the FAST_INTR changes back into the code, so > > if you go into your Makefile and add -DEM_FAST_INTR you will > > then get the taskqueue stuff. > > > > So, Gleb, rather than replace the infinite for loop that no one > > thinks is a good idea, you can just define FAST_INTR again, > > and you should be good to go. > > > > I see this as the best thing for the 6.2 RELEASE, it lets us > > keep moving forward, people that want max performance > > can define EM_FAST_INTR and help us wring out any > > problems, it also will mean that I will have our Intel test > > group start using this code. But for those that just want > > a stable driver the standard compile will still give them that. > > > > The patch I'm including is against BETA3. Let me know of > > your concerns or issues. > > > > Cheers, > > > > Jack > > > > > > _______________________________________________ > > 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" > > > > > > > > From owner-freebsd-net@FreeBSD.ORG Thu Nov 9 08:01:52 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C689D16A417 for ; Thu, 9 Nov 2006 08:01:52 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id A309543D94 for ; Thu, 9 Nov 2006 08:01:33 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id 10EB65A1C15 for ; Thu, 9 Nov 2006 19:01:30 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 924D527407 for ; Thu, 9 Nov 2006 19:01:28 +1100 (EST) Date: Thu, 9 Nov 2006 19:01:27 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: net@freebsd.org Message-ID: <20061109171151.T60086@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: fix for interrupt handling in bge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 08:01:52 -0000 bge_intr(), at least for a BCM5705, has races and foot shootings which result in it sometimes returning without handling all the interrupt events that it has acked. Then the interrupt doesn't repeat, and the unhandled events don't get handled a new event (or possibly a timeout) generates a new interrupt. There seems to be no timeout, so on systems where there is not much network activity except by threads waiting for the unhandled events, the unhandled events don't get handled until much later. This activity occurred for benchmarking a kernel build: - build time on ffs: 30 seconds - build time on nfs: 42 seconds (with system mostly idle except for the build) - 38-42 seconds (while doing like editing) - 35 seconds (with ping -i 0.01 to generate new events) - 33 seconds (with the following fix): %%% Index: if_bge.c =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.151 diff -u -2 -r1.151 if_bge.c --- if_bge.c 19 Oct 2006 08:03:22 -0000 1.151 +++ if_bge.c 8 Nov 2006 14:05:25 -0000 @@ -2884,11 +2884,17 @@ /* + * Ack the interrupt by writing something to BGE_MBX_IRQ0_LO. Don't + * disable interrupts by writing nonzero like we used to, since with + * our current organization this just gives complications for + * re-enabling interrupts. We used to have races instead of the + * necessary complications. + */ + CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0); + + /* * Do the mandatory PCI flush as well as get the link status. */ statusword = CSR_READ_4(sc, BGE_MAC_STS) & BGE_MACSTAT_LINK_CHANGED; - /* Ack interrupt and stop others from occuring. */ - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1); - /* Make sure the descriptor ring indexes are coherent. */ bus_dmamap_sync(sc->bge_cdata.bge_status_tag, @@ -2910,7 +2916,4 @@ } - /* Re-enable interrupts. */ - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0); - if (ifp->if_drv_flags & IFF_DRV_RUNNING && !IFQ_DRV_IS_EMPTY(&ifp->if_snd)) %%% The first race is that the ack was done after the "mandatory PCI flush". This resulted in acking all interrupt events that occur before some indeterminate future time (depending on when the write is flushed). This was relatively harmless, since we acked again later. However, the patch removes the later ack since it is too hard to avoid the races in the later one, so it might now be important to do the first ack correctly. It might be unimportant because if we handle any interrupt event then we will flush the write as a side effect of reading something. Anyway, flushing the write correctly just involves moving the ack before the flush, so it is free. The first foot shooting is that the hardware design apparently (?) encourages this race by requiring (?) a write instead of a read for the ack. The second foot shooting is that we disabled interrupts. Interrupts are already disabled (for all devices sharing the interrupt), so with the current organization disabling them for the device does nothing except encourage the race for re-enabling interrupts. The fix is to not disable interrupts. I think this has the minor disadvantage of generating a new interrupt for any events that occur while we are handling the old ones, even if we handle some of the new ones too. The second race is that re-enabling interrupts also acks interripts. This resulted in acking all interrupt events that occur before the time that the device sees the ack, including any that occurred after we finished looking for events to handle. Since we don't loop, the race window can be almost as large as the total interrupt handling time (e.g., if we handle 0 rx events and many tx events, and a new rx event occurs while we are handling the tx events). The fix is to avoid this complication. The complication would have to be handled to use a task queue. The Linux tg3 driver uses something like a task queue. tg3 also does a status check, so a status check is apparently not too costly like a comment in previous versions of bge said. Without a status check, shared interrupts would work especially poorly, and looping until all events have been handled wouldn't work. With a task queue, the method for re-enabling interrupts would probably need to be: enable_interrupts_and_ack_as_an_unwanted_side effect(); if ((statuscheck() & HAVE_INTERRUPT_EVENTS) == 0) return; disable_interrupts_and_ack_as_an_unnecessary_side effect(); continue; The third race is that we didn't even flush the problematic ack for re-enabling interrupts. This resulted in acking all interrupt events that occur before some indeterminate future time over which we have no control at all. It is possible that bge is depending on these bugs for accidental interrupt moderation. I just noticed that bge (5705) with these patches gets 5-20 times as many interrupts as bge (5701) without these patches and with a much older kernel. The 5701 has about half the ping latency of the 5705 but is otherwise slower including having a lower pps despite or because of being on a faster bus with a newer kernel. Bruce From owner-freebsd-net@FreeBSD.ORG Thu Nov 9 11:58:07 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E93516A407; Thu, 9 Nov 2006 11:58:07 +0000 (UTC) (envelope-from flz@xbsd.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id B650C43D75; Thu, 9 Nov 2006 11:58:03 +0000 (GMT) (envelope-from flz@xbsd.org) Received: from smtp.xbsd.org (unknown [82.233.2.192]) by smtp5-g19.free.fr (Postfix) with ESMTP id E76CE27B58; Thu, 9 Nov 2006 12:58:02 +0100 (CET) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id 3447211585; Thu, 9 Nov 2006 12:58:02 +0100 (CET) Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12724-05; Thu, 9 Nov 2006 12:57:33 +0100 (CET) Received: from [192.168.99.200] (guest35.usr.dsi.unimi.it [159.149.159.235]) by smtp.xbsd.org (Postfix) with ESMTP id C227711415; Thu, 9 Nov 2006 12:57:32 +0100 (CET) In-Reply-To: <1162993001.4305.37.camel@massimo.datacode.it> References: <1162993001.4305.37.camel@massimo.datacode.it> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Florent Thoumie Date: Thu, 9 Nov 2006 11:57:28 +0000 To: Massimo Lusetti X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: amavisd-new at xbsd.org Cc: hackers@freebsd.org, net@freebsd.org Subject: Re: New wpi driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 11:58:07 -0000 On Nov 8, 2006, at 1:36 PM, Massimo Lusetti wrote: > Hi all, > I'm pleased to tell you i got the latest wpi driver from Damien > Bergamini to work properly on a latest -stable on an Acer laptop. Nice work! > The driver is available here: > http://www.datacode.it/wpi-freebsd/wpi-freebsd.tgz > If anyone from FreeBSD team or else is willing to put it on a host > with > more bandwidth it's more then welcome. I've mirrored it at http://people.freebsd.org/~flz/local/wpi/wpi- freebsd-20061109.tgz. -- Florent Thoumie flz@FreeBSD.org FreeBSD Committer From owner-freebsd-net@FreeBSD.ORG Thu Nov 9 15:36:56 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57F3516A416; Thu, 9 Nov 2006 15:36:56 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3151343D6B; Thu, 9 Nov 2006 15:36:48 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kA9FamFS023231; Thu, 9 Nov 2006 10:36:48 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kA9FaltD018819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Nov 2006 10:36:47 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611091536.kA9FaltD018819@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 09 Nov 2006 10:36:51 -0500 To: "Jack Vogel" , freebsd-stable@freebsd.org, freebsd-net From: Mike Tancsa In-Reply-To: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.co m> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 15:36:56 -0000 At 08:19 PM 11/8/2006, Jack Vogel wrote: >BUT, I've added the FAST_INTR changes back into the code, so >if you go into your Makefile and add -DEM_FAST_INTR you will >then get the taskqueue stuff. It certainly does make a difference performance wise. I did some quick testing with netperf and netrate. Back to back boxes, using an AMD x2 with bge nic and one intel box CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2009.27-MHz 686-class CPU) CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (2144.01-MHz 686-class CPU) The intel is a DG965SS with integrated em nic, the AMD a Tyan with integrated bge. Both running SMP kernels with pf built in, no inet6. Intel box as sender. In this test its with the patch from yesterday. The first set with the patch as is, the second test with -DEM_FAST_INTR. TCP STREAM TEST to 192.168.44.1 : +/-2.5% @ 99% conf. Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 57344 57344 4096 62.19 858.16 57344 57344 4096 62.19 934.58 TCP STREAM TEST to 192.168.44.1 : +/-2.5% @ 99% conf. Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 32768 32768 4096 62.27 551.46 32768 32768 4096 62.26 788.56 TCP REQUEST/RESPONSE TEST to 192.168.44.1 : +/-2.5% @ 99% conf. Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 32768 65536 1 1 62.26 2999.88 32768 65536 32768 65536 1 1 62.31 6165.46 32768 65536 UDP REQUEST/RESPONSE TEST to 192.168.44.1 : +/-2.5% @ 99% conf. Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 9216 41600 1 1 62.30 3170.25 9216 41600 9216 41600 1 1 62.34 6170.81 9216 41600 UDP REQUEST/RESPONSE TEST to 192.168.44.1 : +/-2.5% @ 99% conf. Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 9216 41600 516 4 62.28 2999.17 9216 41600 9216 41600 516 4 62.33 6031.56 9216 41600 UDP UNIDIRECTIONAL SEND TEST to 192.168.44.1 : +/-2.5% @ 99% conf. Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 32768 4096 60.00 1743632 24778919 952.25 41600 60.00 1742801 951.79 32768 4096 60.00 1743633 24722456 952.25 41600 60.00 1742828 951.81 UDP UNIDIRECTIONAL SEND TEST to 192.168.44.1 : +/-2.5% @ 99% conf. Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 32768 1024 60.00 6831370 28639884 932.70 41600 60.00 6828166 932.27 32768 1024 60.00 6831369 28465662 932.70 41600 60.00 6828086 932.26 Intel box as receiver, bge0/AMD as sender First set of results using stock em driver from 6.2beta2 second set of results using first patch 3rd set using taskqueue enabled /usr/local/netperf/netperf -t TCP_STREAM -l 60 -H 192.168.44.244 -i 10,3 -I 99,5 -- -s 57344 -S 57344 -m 4096 TCP STREAM TEST to 192.168.44.244 : +/-2.5% @ 99% conf. Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 57344 57344 4096 60.00 680.24 57344 57344 4096 60.00 680.34 57344 57344 4096 60.00 680.54 TCP STREAM TEST to 192.168.44.244 : +/-2.5% @ 99% conf. Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 32768 32768 4096 60.00 496.72 32768 32768 4096 60.00 499.87 32768 32768 4096 60.00 677.63 TCP REQUEST/RESPONSE TEST to 192.168.44.244 : +/-2.5% @ 99% conf. Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 32768 65536 1 1 60.00 2999.61 32768 65536 32768 65536 1 1 60.00 2999.50 32768 65536 32768 65536 1 1 60.00 6163.75 32768 65536 UDP REQUEST/RESPONSE TEST to 192.168.44.244 : +/-2.5% @ 99% conf. Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 9216 41600 1 1 60.00 3099.52 9216 41600 9216 41600 1 1 60.00 3102.97 9216 41600 9216 41600 1 1 60.00 6178.13 9216 41600 UDP REQUEST/RESPONSE TEST to 192.168.44.244 : +/-2.5% @ 99% conf. Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 9216 41600 516 4 60.00 2956.58 9216 41600 9216 41600 516 4 60.00 2956.15 9216 41600 9216 41600 516 4 60.00 6075.79 9216 41600 /usr/local/netperf/netperf -t UDP_STREAM -l 60 -H 192.168.44.244 -i 10,3 -I 99,5 -- -s 32768 -S 32768 -m 4096 UDP UNIDIRECTIONAL SEND TEST to 192.168.44.244 : +/-2.5% @ 99% conf. Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 32768 4096 60.00 1340178 20058972 731.91 41600 60.00 1340178 731.90 32768 4096 60.00 1340076 19963473 731.85 41600 60.00 1340076 731.85 32768 4096 60.00 1340497 20167227 732.09 41600 60.00 1340497 732.09 UDP UNIDIRECTIONAL SEND TEST to 192.168.44.244 : +/-2.5% @ 99% conf. Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 32768 1024 60.00 5468540 29141343 746.64 41600 60.00 5468538 746.63 32768 1024 60.00 5469132 29805133 746.71 41600 60.00 5469132 746.71 32768 1024 60.00 5468372 30181335 746.61 41600 60.00 5468372 746.61 From owner-freebsd-net@FreeBSD.ORG Thu Nov 9 15:51:28 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8410516A494; Thu, 9 Nov 2006 15:51:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3409B43D55; Thu, 9 Nov 2006 15:51:25 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kA9FpIBT037111; Thu, 9 Nov 2006 08:51:24 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45534E76.6020906@samsco.org> Date: Thu, 09 Nov 2006 08:51:18 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Mike Tancsa References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> In-Reply-To: <200611091536.kA9FaltD018819@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 15:51:28 -0000 Mike Tancsa wrote: > At 08:19 PM 11/8/2006, Jack Vogel wrote: > >> BUT, I've added the FAST_INTR changes back into the code, so >> if you go into your Makefile and add -DEM_FAST_INTR you will >> then get the taskqueue stuff. > > It certainly does make a difference performance wise. I did some quick > testing with netperf and netrate. Back to back boxes, using an AMD x2 > with bge nic and one intel box > > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2009.27-MHz > 686-class CPU) > CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (2144.01-MHz > 686-class CPU) > > The intel is a DG965SS with integrated em nic, the AMD a Tyan with > integrated bge. Both running SMP kernels with pf built in, no inet6. > > > Intel box as sender. In this test its with the patch from yesterday. The > first set with the patch as is, the second test with -DEM_FAST_INTR. > Thanks for the tests. One thing to note is that Gleb reported a higher rate of dropped packets with INTR_FAST. He is the only one who has reported this, so I'd like to find out if there is something unique to his environment, or if there is a larger problem to be addressed. There are ways that we can change the driver to not drop any packets at all for Gleb, but they expose the system to risk if there is ever an accidental (or malicious) RX flood on the interface. Scott From owner-freebsd-net@FreeBSD.ORG Thu Nov 9 17:51:10 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C06DA16A407 for ; Thu, 9 Nov 2006 17:51:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B24E43D5A for ; Thu, 9 Nov 2006 17:51:10 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kA9Hnu59013911 for ; Thu, 9 Nov 2006 10:49:57 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 09 Nov 2006 10:50:29 -0700 (MST) Message-Id: <20061109.105029.58456455.imp@bsdimp.com> To: net@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 09 Nov 2006 10:49:57 -0700 (MST) Cc: Subject: IPv6 IOL certification? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 17:51:10 -0000 Does anybody know if the FreeBSD ipv6 stack has passed the IOL Silver or Gold levels from the University of New Hampshire? Warner From owner-freebsd-net@FreeBSD.ORG Thu Nov 9 20:28:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AE5216A412; Thu, 9 Nov 2006 20:28:26 +0000 (UTC) (envelope-from landonf@threerings.net) Received: from smtp.earth.threerings.net (mail.threerings.net [64.127.109.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id A423B43D8B; Thu, 9 Nov 2006 20:28:09 +0000 (GMT) (envelope-from landonf@threerings.net) Received: from [192.168.54.11] (timor.sea.earth.threerings.net [192.168.54.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.earth.threerings.net (Postfix) with ESMTP id ABB556667; Thu, 9 Nov 2006 12:28:08 -0800 (PST) In-Reply-To: <4551EA9C.5050309@FreeBSD.org> References: <4551EA9C.5050309@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-26-113292544" Message-Id: <5D887638-9717-4186-86DF-1B09C7F3181F@threerings.net> Content-Transfer-Encoding: 7bit From: Landon Fuller Date: Thu, 9 Nov 2006 12:28:06 -0800 To: Bruce M. Simpson X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org Subject: Re: [patch] tun(4) and tap(4) if_clone support. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 20:28:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-26-113292544 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 8, 2006, at 06:33, Bruce M. Simpson wrote: > Landon Fuller wrote: >> Nick Barkas (snb@threerings.net) and I have added interface >> cloning support to the tun(4) and tap(4) drivers. >> >> We maintained backwards-compatible support for devfs cloning, >> which is now disabled by default -- it can be re-enabled via a >> sysctl. Interfaces that are created via devfs cloning may still be >> removed via ifconfig destroy. >> >> The latest patch is available here >> http://www.opendarwin.org/~landonf/code/patch-tuntap_ifclone >> >> I've submitted kern/105228 with the patch, and I'd be most >> appreciative of comments/suggestions. > > Interesting stuff. If it eliminates a race on creation, that has to > be a good thing; I may have run into this race in the past month or > two. It would however change tap/tun behaviour in that currently I > have a few scripts which use dd(1) to force the device node to be > created. This is undocumented behaviour specific to its devfs > implementation which perhaps I shouldn't be relying upon, before I > go on to create a bridge from several tap instances (which are then > hooked up to QEMU virtual machines). I disabled the devfs support by default with deprecation in mind, but there's no other reason it couldn't be default-enabled. What's the race you've run into? > Good work! Cheers! -landonf --Apple-Mail-26-113292544 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFU49YlplZCE/15mMRAhQKAJ9raxDQtFgBR+8PBCO+in1nbIS+ngCdFQzo 6JX6EeGNjMN1SupRLOlp7UU= =lJ6W -----END PGP SIGNATURE----- --Apple-Mail-26-113292544-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 9 21:39:40 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C116316A4CA; Thu, 9 Nov 2006 21:39:40 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B39D43D99; Thu, 9 Nov 2006 21:39:23 +0000 (GMT) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id 493449A1859; Thu, 9 Nov 2006 22:39:22 +0100 (CET) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8WXBRDbsVLY2; Thu, 9 Nov 2006 22:39:17 +0100 (CET) Received: from [192.168.2.186] (catv-50635cb6.catv.broadband.hu [80.99.92.182]) by server.t-hosting.hu (Postfix) with ESMTP id ED9C09A1856; Thu, 9 Nov 2006 22:39:16 +0100 (CET) Message-ID: <4553A000.7070407@FreeBSD.org> Date: Thu, 09 Nov 2006 22:39:12 +0100 From: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Florent Thoumie References: <1162993001.4305.37.camel@massimo.datacode.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, Massimo Lusetti , net@freebsd.org Subject: Re: New wpi driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 21:39:40 -0000 Florent Thoumie wrote: > On Nov 8, 2006, at 1:36 PM, Massimo Lusetti wrote: > >> Hi all, >> I'm pleased to tell you i got the latest wpi driver from Damien >> Bergamini to work properly on a latest -stable on an Acer laptop. > > Nice work! Unfortunately, it seems that this is still that unfinished driver from Damien, that circulates on the net everywhere, but it only works for some lucky people. As for me, I get an error message when loading the module, that it could not allocate resources. -- Cheers, Gabor From owner-freebsd-net@FreeBSD.ORG Thu Nov 9 21:43:05 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCC5D16A4D8; Thu, 9 Nov 2006 21:43:05 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F21443D7E; Thu, 9 Nov 2006 21:42:21 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kA9Lg3Xd036047; Thu, 9 Nov 2006 16:42:03 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kA9Lg2o2020411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Nov 2006 16:42:02 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611092142.kA9Lg2o2020411@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 09 Nov 2006 16:42:06 -0500 To: "Jack Vogel" , freebsd-stable@freebsd.org, freebsd-net From: Mike Tancsa In-Reply-To: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.co m> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean Cc: Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 21:43:06 -0000 At 08:19 PM 11/8/2006, Jack Vogel wrote: >BUT, I've added the FAST_INTR changes back into the code, so >if you go into your Makefile and add -DEM_FAST_INTR you will >then get the taskqueue stuff. Not sure why you would want FAST_INTR and polling in at the same time, but I found that the two are mutually exclusive cd /usr/obj/usr/src/sys/pioneer; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel all -DNO_MODULES_OBJ cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/dev/em/if_em.c /usr/src/sys/dev/em/if_em.c: In function `em_ioctl': /usr/src/sys/dev/em/if_em.c:931: error: `em_poll' undeclared (first use in this function) /usr/src/sys/dev/em/if_em.c:931: error: (Each undeclared identifier is reported only once /usr/src/sys/dev/em/if_em.c:931: error: for each function it appears in.) /usr/src/sys/dev/em/if_em.c: At top level: /usr/src/sys/dev/em/if_em.c:1164: warning: 'em_poll' defined but not used *** Error code 1 Stop in /usr/obj/usr/src/sys/pioneer. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From owner-freebsd-net@FreeBSD.ORG Thu Nov 9 22:01:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4601C16A40F; Thu, 9 Nov 2006 22:01:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EC3A43D6D; Thu, 9 Nov 2006 22:00:53 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kA9M0rXt038408; Thu, 9 Nov 2006 17:00:53 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kA9M0q1E020473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Nov 2006 17:00:52 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611092200.kA9M0q1E020473@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 09 Nov 2006 17:00:56 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <45534E76.6020906@samsco.org> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 22:01:20 -0000 At 10:51 AM 11/9/2006, Scott Long wrote: >Mike Tancsa wrote: >>At 08:19 PM 11/8/2006, Jack Vogel wrote: >> >>>BUT, I've added the FAST_INTR changes back into the code, so >>>if you go into your Makefile and add -DEM_FAST_INTR you will >>>then get the taskqueue stuff. >>It certainly does make a difference performance wise. I did some >>quick testing with netperf and netrate. Back to back boxes, using >>an AMD x2 with bge nic and one intel box >>CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2009.27-MHz >>686-class CPU) >>CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (2144.01-MHz >>686-class CPU) >>The intel is a DG965SS with integrated em nic, the AMD a Tyan with >>integrated bge. Both running SMP kernels with pf built in, no inet6. >> >>Intel box as sender. In this test its with the patch from >>yesterday. The first set with the patch as is, the second test with >>-DEM_FAST_INTR. > >Thanks for the tests. One thing to note is that Gleb reported a higher >rate of dropped packets with INTR_FAST. He is the only one who has >reported this, so I'd like to find out if there is something unique to >his environment, or if there is a larger problem to be addressed. There >are ways that we can change the driver to not drop any packets at all >for Gleb, but they expose the system to risk if there is ever an >accidental (or malicious) RX flood on the interface. With a high rate of packets, I am able to live lock the box. I setup the following b1a ------| b2a -----R1 ------------b1b |-------------b2b R1 has PCIe dual port em PRO/1000 PT em0: port 0x9000-0x901f mem 0xd7020000-0xd703ffff,0xd7000000-0xd701ffff irq 1 7 at device 0.0 on pci6 em0: Ethernet address: 00:15:17:0b:70:98 em0: [FAST] em1: port 0x9400-0x941f mem 0xd7040000-0xd705ffff,0xd7060000-0xd707ffff irq 1 8 at device 0.1 on pci6 em1: Ethernet address: 00:15:17:0b:70:99 em1: [FAST] b1a = 192.168.44.1 onboard bge0 b1b = 192.168.88.218 - onboard em 82547EI Gigabit Ethernet Controller b2a = 192.168.88.176 single port PCIe em0 b2b = 192.168.44.244 onboard em0 (DG965SS) R1 has 192.168.44.223 and 192.168.88.223. Routing across R1 with b1a blasting b1b and b2a blastin b2b with netrate will lock up R1 even though the total throughput is only 500Mb. While on b1a # ./netblast 192.168.88.218 500 10 1000 I see the following on R1 (bge1 is my management interface) R1 # ifstat -b em0 em1 bge1 Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out 273770.1 0.00 0.00 237269.1 1.40 3.51 273509.8 0.00 0.00 237040.2 1.73 2.76 273694.9 0.00 0.00 237202.6 0.94 2.34 274258.6 0.00 0.00 237690.4 1.40 2.34 273623.8 0.00 0.00 237140.7 0.94 2.34 If I start up the netblast on b2b or on b2a (either direction, doesnt matter) R1 locks up. This was with R1 in an SMP config. Without INTR_FAST, it doesnt work as fast, but R1 does not lock up, or at least lock me out of my management interface. ---Mike From owner-freebsd-net@FreeBSD.ORG Thu Nov 9 22:20:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 488DA16A492 for ; Thu, 9 Nov 2006 22:20:20 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F9E043DDC for ; Thu, 9 Nov 2006 22:19:54 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so200940wra for ; Thu, 09 Nov 2006 14:19:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=a2YvCPkOYSfO7wHPhOGSD2TTyBLtzgpx5Xhohg3ZOc0809k9kOmpHs8SEWJvL6UWWJcwq/9PPWWBFect2k+o5CKhyzlsVZG8GBLg480YrfqwND4JKkwOs7Szta1xIGmUw5REMTiqedeMgcG0h7f9idBTLSGh7KueGwc25Hf1+Rs= Received: by 10.35.50.1 with SMTP id c1mr1876557pyk.1163110397170; Thu, 09 Nov 2006 14:13:17 -0800 (PST) Received: by 10.35.118.6 with HTTP; Thu, 9 Nov 2006 14:13:16 -0800 (PST) Message-ID: <2a41acea0611091413x5e06e0cdie0c490628e599444@mail.gmail.com> Date: Thu, 9 Nov 2006 14:13:16 -0800 From: "Jack Vogel" To: "Mike Tancsa" In-Reply-To: <200611092142.kA9Lg2o2020411@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611092142.kA9Lg2o2020411@lava.sentex.ca> Cc: freebsd-net , freebsd-stable@freebsd.org Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 22:20:20 -0000 Yes, they are incompatible, I suppose there should be something that makes it impossible to do, but not building should be a clue :) Jack On 11/9/06, Mike Tancsa wrote: > At 08:19 PM 11/8/2006, Jack Vogel wrote: > > >BUT, I've added the FAST_INTR changes back into the code, so > >if you go into your Makefile and add -DEM_FAST_INTR you will > >then get the taskqueue stuff. > > Not sure why you would want FAST_INTR and polling in at the same > time, but I found that the two are mutually exclusive > > cd > /usr/obj/usr/src/sys/pioneer; MAKEOBJDIRPREFIX=/usr/obj > MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac > _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp INSTALL="sh > /usr/src/tools/install.sh" > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > make KERNEL=kernel all -DNO_MODULES_OBJ > cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. > -I/usr/src/sys -I/usr/src/sys/contrib/altq > -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf > -I/usr/src/sys/dev/ath -I/usr/src/sys/contrib/ngatm > -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=8000 --param > inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -ffreestanding -Werror /usr/src/sys/dev/em/if_em.c > /usr/src/sys/dev/em/if_em.c: In function `em_ioctl': > /usr/src/sys/dev/em/if_em.c:931: error: `em_poll' undeclared (first > use in this function) > /usr/src/sys/dev/em/if_em.c:931: error: (Each undeclared identifier > is reported only once > /usr/src/sys/dev/em/if_em.c:931: error: for each function it appears in.) > /usr/src/sys/dev/em/if_em.c: At top level: > /usr/src/sys/dev/em/if_em.c:1164: warning: 'em_poll' defined but not used > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/pioneer. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 01:50:22 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50A2F16A4D4 for ; Fri, 10 Nov 2006 01:50:22 +0000 (UTC) (envelope-from suz@alaxala.net) Received: from pc1.alaxala.net (pc1.alaxala.net [203.178.142.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 662A543D7C for ; Fri, 10 Nov 2006 01:50:13 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from localhost (localhost [127.0.0.1]) by pc1.alaxala.net (Postfix) with ESMTP id 67E81B90D; Fri, 10 Nov 2006 10:50:11 +0900 (JST) X-Virus-Scanned: amavisd-new at alaxala.net Received: from pc1.alaxala.net ([127.0.0.1]) by localhost (pc1.alaxala.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tapVSiVaiRDQ; Fri, 10 Nov 2006 10:50:05 +0900 (JST) Received: from flora220.uki-uki.net (dhcp65-21.ietf67.org [130.129.65.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pc1.alaxala.net (Postfix) with ESMTP id 35688B82E; Fri, 10 Nov 2006 10:50:04 +0900 (JST) Date: Thu, 09 Nov 2006 17:49:57 -0800 Message-ID: From: SUZUKI Shinsuke To: imp@bsdimp.com X-cite: xcite 1.33 In-Reply-To: <20061109.105029.58456455.imp@bsdimp.com> References: <20061109.105029.58456455.imp@bsdimp.com> User-Agent: Wanderlust/2.15.1 (Almost Unreal) Emacs/22.0 Mule/5.0 (SAKAKI) Organization: Networking Technology Development Dept., ALAXALA Networks Corporation MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: net@freebsd.org Subject: Re: IPv6 IOL certification? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 01:50:22 -0000 Hi, >>>>> On Thu, 09 Nov 2006 10:50:29 -0700 (MST) >>>>> imp@bsdimp.com("M. Warner Losh") said: > Does anybody know if the FreeBSD ipv6 stack has passed the IOL Silver > or Gold levels from the University of New Hampshire? You mean the IPv6 Ready Logo program? (http://www.ipv6ready.org/) Pure FreeBSD hasn't received either Logo yet, but KAME on FreeBSD5 (most of them has already been merged to 6-Stable) has received Silver(Phase 1) and Gold(Phase2) logo as a host and a router. http://www.kame.net/newsletter/20060331/ Judging from my experience in this logo acquisition work, here's the expected IPv6 implementation status regarding -current and 6-stable. [Silver Logo] you can get the logo for host and router (all you have to do is to submit the log of the required testings to the logo committee). [Gold Logo] you can get the logo for router, but cannot for host. It is due to a lack of the following patch, which is necessary to pass the gold logo testing (but not merged, since it still needs some refinement (i.e. handling against an I/F address with /128 prefixlen, too generic function name). http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/icmp6.c.diff?r1=1.410;r2=1.411 http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/in6.c.diff?r1=1.402;r2=1.403 Thanks, ---- SUZUKI, Shinsuke @ KAME Project From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 01:58:48 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A50316A407 for ; Fri, 10 Nov 2006 01:58:48 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C5C243D49 for ; Fri, 10 Nov 2006 01:58:47 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from impact.jinmei.org (unknown [2001:200:1b1:1010:81f2:b730:7856:3a81]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 57CAC15218; Fri, 10 Nov 2006 10:58:46 +0900 (JST) Date: Fri, 10 Nov 2006 10:58:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "M. Warner Losh" In-Reply-To: <20061109.105029.58456455.imp@bsdimp.com> References: <20061109.105029.58456455.imp@bsdimp.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: net@freebsd.org Subject: Re: IPv6 IOL certification? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 01:58:48 -0000 >>>>> On Thu, 09 Nov 2006 10:50:29 -0700 (MST), >>>>> "M. Warner Losh" said: > Does anybody know if the FreeBSD ipv6 stack has passed the IOL Silver > or Gold levels from the University of New Hampshire? I don't have a direct answer to this question, but you might be interested in the fact that KAME snapshots that base the FreeBSD IPv6 stack passed "IPv6-ready logo" tests. See http://www.ipv6ready.org/ for more details. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 08:27:17 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 569F616A47C for ; Fri, 10 Nov 2006 08:27:17 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EFA243D49 for ; Fri, 10 Nov 2006 08:27:16 +0000 (GMT) (envelope-from antinvidia@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so421304uge for ; Fri, 10 Nov 2006 00:27:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=GcpsmJXaIJtICXGzrfa+uR9W7uwh03yEfb8tF6rQGWj/lbWTGUFg8yKvXhJdOLdh96miDUsG1hhDRcbhSO3UhDBo36gDr9LM89WfxBcJL89muEzB5RK//T4pUEFl0MSwUrSXN4r6lYrpcjHRufSZOJ6r06G55l5Ey7B6JP3IqCw= Received: by 10.78.157.8 with SMTP id f8mr2362089hue.1163147234926; Fri, 10 Nov 2006 00:27:14 -0800 (PST) Received: by 10.78.167.2 with HTTP; Fri, 10 Nov 2006 00:27:14 -0800 (PST) Message-ID: Date: Fri, 10 Nov 2006 08:27:14 +0000 From: MQ To: "LI Xin" In-Reply-To: <455219E6.6090001@delphij.net> MIME-Version: 1.0 References: <454E19CC.7040208@fromley.net> <20061106195524.P39454@fledge.watson.org> <455219E6.6090001@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Posting restrictions on this mailing list (for spam control)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 08:27:17 -0000 2006/11/8, LI Xin : > > MQ wrote: > [snip] > > The mailing list denied all the mail from my previous mail box provided > by > > Netease(NASDAQ: NTES) from China mainland, even I subscribed to -net, > and > > asked me to wait the moderator's approval. But after I changed my > > mailbox to > > gmail, the filter never returned such message. I don't know why I can't > > post > > to -net even I subscribed to it. Maybe a misconfiguration? > > No. At least, not misconfiguration at FreeBSD.org side. > > I have discussed the situation with David (the postmaster@) and this > seems to be caused by misconfiguration and wrong implementation of the > e-mail standards by NTES, which in turn caused SpamAssassin to provide > false positives (personally I do not think that they should be > considered as false positives, they are REAL problems that should be > addressed and corrected). > > Cheers, > -- > Xin LI < delphij@delphij.net> http://www.delphij.net/ > FreeBSD - The Power to Serve! > > > > Ok, I see. But the messages return by SpamAssissin is really confusing. It is asking that I subscribe the mailing list, but actually that can't help. From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 08:55:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92BED16A40F for ; Fri, 10 Nov 2006 08:55:41 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id D34BE43D4C for ; Fri, 10 Nov 2006 08:55:40 +0000 (GMT) (envelope-from antinvidia@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so425190uge for ; Fri, 10 Nov 2006 00:55:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=GUOPKByo7pq+9lqQE4PiiSjITcO71szLwRIY1K7B1O8qaumwcLkmheYtEM4HxcTxsH4MJqbEiKiBf3xS4uPs2mi1NOwBsHisFLKgcVOHEFAjPTzvjzkEkEPDIlypsYdeL/7VJQioMjofU4Pd9Eao3VdS9FOCgJTDrOJVwJ6pmT4= Received: by 10.78.117.10 with SMTP id p10mr2385984huc.1163148940039; Fri, 10 Nov 2006 00:55:40 -0800 (PST) Received: by 10.78.167.2 with HTTP; Fri, 10 Nov 2006 00:55:39 -0800 (PST) Message-ID: Date: Fri, 10 Nov 2006 08:55:39 +0000 From: MQ To: "Bruce Evans" In-Reply-To: <20061105214041.F44623@delplex.bde.org> MIME-Version: 1.0 References: <20061102142543.GC70915@lor.one-eyed-alien.net> <20061103141732.GA87515@lor.one-eyed-alien.net> <20061105011849.GB6669@lor.one-eyed-alien.net> <20061105214041.F44623@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 08:55:41 -0000 2006/11/5, Bruce Evans : > > On Sat, 4 Nov 2006, Brooks Davis wrote: > > > On Sat, Nov 04, 2006 at 02:46:30AM +0000, MQ wrote: > >> 2006/11/3, Brooks Davis : > > >>> The particular definition used is excedingly ugly. At a minimum there > >>> needs to be a define or a constant "16" for the lenght rather than the > >>> 4*sizeof("123") nonsense. > > The `4*sizeof "123"' is not nonsense. It is better than the userland > version > at the time it was committed. The userland version hard-coded the size as > 18 (sic). The current userland version still hard-codes 18, but now > actually needs it to print an error message of length 17. The uglyness in > `4*sizeof "123"' is just that it has 3 formatting style bugs (missing > spaces > around binary operator, space after sizeof, and missing parentheses for > sizeof) and depends on the storage for a '.' being the same as the storage > for the the '\0' terminator. I would write it as sizeof("255.255.255.255 > "). > > >> Oh, I see. This kind of definition is really annoying, and hard to keep > all > >> the > >> occurrences consistent. Maybe a better way is use a macro to make that > >> clear? > >> > >> #define IPV4_ADDRSZ (4 * sizeof "123") > >> char buf[IPV4_ADDRSZ]; > > This is less clear, since it takes twice as much code to obfuscate the > size in a macro for no benefits since the macro is only used once. > > >> This "ugly" definition comes from inet_ntoa() in > /sys/libkern/inet_ntoa.c, > >> I just copied the style without too much consideration, it's my fault. > > > > I'd just use 16. The inet_ntoa function is frankly inane. It attempts > > to support chars that aren't 8 bits which would break so much stuff it > > isn't funny. > > No, it assumes 8-bit chars. It's masking with 0xff is apparently copied > from an old implementation that used plain chars. The userland > implementation at the time it was committed does that, but uses a macro > to do the masking and is missing lots of style bugs. > > The userland version now calls inet_ntop(). This is missing the design > bug of using a static buffer. It calls inet_ntop4() for the ipv4 case. > This is closer to being non-ugly: > > % static const char * > % inet_ntop4(const u_char *src, char *dst, socklen_t size) > % { > % static const char fmt[] = "%u.%u.%u.%u"; > % char tmp[sizeof "255.255.255.255"]; > % int l; > % > % l = snprintf(tmp, sizeof(tmp), fmt, src[0], src[1], src[2], > src[3]); > % if (l <= 0 || (socklen_t) l >= size) { > % errno = ENOSPC; > % return (NULL); > % } > % strlcpy(dst, tmp, size); > % return (dst); > % } > > I would write this as: > > %%% > CTASSERT(CHAR_BIT == 8); /* else src would be misintepreted */ > > static const char * > inet_ntop4(const u_char *src, char *dst, socklen_t size) > { > int n; > > n = snprintf(dst, size, "%u.%u.%u.%u", src[0], src[1], src[2], > src[3]); > assert(n >= 0); /* CHAR_BIT == 8 imples 0 < n <= 16 */ > if ((u_int)n >= size) { > errno = ENOSPC; > return (NULL); > } > return (dst); > } > %%% > > This is closer to the version in RELENG_6 than the current version. It > doesn't use tmp[]] to preserve dst on error, and fixes the bounds checking > without introducing several style bugs and not actually fixing the bounds > checking. The old version was: > > if ((socklen_t)snprintf(dst, size, fmt, src[0], src[1], src[2], > src[3] > >= size) { > ... > } > > This is good enough since 0 < l <= 16 implies that the preposterou case > (l <= 0) and the preposterous broken case ((socklen_t)l != l) can't > happen, but it is easier to use correct bounds checking than to understant > why bugs in the bounds checking are harmless. > > Bruce > I don't know why the ret array in the userland version of the inet_ntoa should be 17. The length of the message itself is 17, and an \0 is needed for the str* to work. By the way, 4 * sizeof("123") chars should be always enough to contain an IPv4 address, no matter how many bits consititute a char. From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 09:37:56 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A6FF16A47C for ; Fri, 10 Nov 2006 09:37:56 +0000 (UTC) (envelope-from massimo@cedoc.mo.it) Received: from insomma.datacode.it (ip-174-86.sn2.eutelia.it [83.211.174.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE8E643D4C for ; Fri, 10 Nov 2006 09:37:54 +0000 (GMT) (envelope-from massimo@cedoc.mo.it) Received: from localhost (localhost.datacode.it [127.0.0.1]) by insomma.datacode.it (Postfix) with SMTP id DCB512C906 for ; Fri, 10 Nov 2006 10:37:50 +0100 (CET) Received: from insomma.datacode.it (localhost.datacode.it [127.0.0.1]) by insomma.datacode.it (Postfix) with ESMTP id 31E0E2C90A; Fri, 10 Nov 2006 10:37:48 +0100 (CET) Received: from massimo.datacode.it (massimo.datacode.it [192.168.1.13]) by insomma.datacode.it (Postfix) with ESMTP id 7D1FD2C906; Fri, 10 Nov 2006 10:37:47 +0100 (CET) From: Massimo Lusetti To: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= In-Reply-To: <4553A000.7070407@FreeBSD.org> References: <1162993001.4305.37.camel@massimo.datacode.it> <4553A000.7070407@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Organization: CEDOC - Modena Date: Fri, 10 Nov 2006 10:37:48 +0100 Message-Id: <1163151468.4328.6.camel@massimo.datacode.it> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: net@freebsd.org, hackers@freebsd.org, Florent Thoumie Subject: Re: New wpi driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 09:37:56 -0000 On Thu, 2006-11-09 at 22:39 +0100, Gábor Kövesdán wrote: > Unfortunately, it seems that this is still that unfinished driver from > Damien, that circulates on the net everywhere, but it only works for > some lucky people. As for me, I get an error message when loading the > module, that it could not allocate resources. I don't think it's "that unfinished driver from Damien" classify it correctly, as stated it's an unsupported version so case where it will not work are expected. Feel free to improve it or wait when some FreeBSD developer will port and maintain it. Thanks Florent for mirroring. -- Massimo.run(); From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 10:39:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C2BA16A415 for ; Fri, 10 Nov 2006 10:39:07 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 820E243D5A for ; Fri, 10 Nov 2006 10:39:06 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id EBFD35A1EE2; Fri, 10 Nov 2006 21:39:04 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 765638C18; Fri, 10 Nov 2006 21:39:03 +1100 (EST) Date: Fri, 10 Nov 2006 21:38:57 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: MQ In-Reply-To: Message-ID: <20061110210358.B64521@delplex.bde.org> References: <20061102142543.GC70915@lor.one-eyed-alien.net> <20061103141732.GA87515@lor.one-eyed-alien.net> <20061105011849.GB6669@lor.one-eyed-alien.net> <20061105214041.F44623@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 10:39:07 -0000 On Fri, 10 Nov 2006, MQ wrote: > 2006/11/5, Bruce Evans : >> >> On Sat, 4 Nov 2006, Brooks Davis wrote: >> >> > On Sat, Nov 04, 2006 at 02:46:30AM +0000, MQ wrote: >> >> 2006/11/3, Brooks Davis : >> >> >>> The particular definition used is excedingly ugly. At a minimum there >> >>> needs to be a define or a constant "16" for the lenght rather than the >> >>> 4*sizeof("123") nonsense. >> >> The `4*sizeof "123"' is not nonsense. It is better than the userland >> version >> at the time it was committed. The userland version hard-coded the size as >> 18 (sic). The current userland version still hard-codes 18, but now >> actually needs it to print an error message of length 17. The uglyness in >> `4*sizeof "123"' is just that it has 3 formatting style bugs (missing >> ... >> > I'd just use 16. The inet_ntoa function is frankly inane. It attempts >> > to support chars that aren't 8 bits which would break so much stuff it >> > isn't funny. >> >> No, it assumes 8-bit chars. It's masking with 0xff is apparently copied >> from an old implementation that used plain chars. The userland >> implementation at the time it was committed does that, but uses a macro >> to do the masking and is missing lots of style bugs. >> >> The userland version now calls inet_ntop(). This is missing the design >> bug of using a static buffer. It calls inet_ntop4() for the ipv4 case. >> This is closer to being non-ugly: >> >> % static const char * >> % inet_ntop4(const u_char *src, char *dst, socklen_t size) >> % { >> % static const char fmt[] = "%u.%u.%u.%u"; >> % char tmp[sizeof "255.255.255.255"]; >> % int l; >> % >> % l = snprintf(tmp, sizeof(tmp), fmt, src[0], src[1], src[2], >> src[3]); >> % if (l <= 0 || (socklen_t) l >= size) { >> % errno = ENOSPC; >> % return (NULL); >> % } >> % strlcpy(dst, tmp, size); >> % return (dst); >> % } >> >> I would write this as: >> >> %%% >> CTASSERT(CHAR_BIT == 8); /* else src would be misintepreted */ >> >> static const char * >> inet_ntop4(const u_char *src, char *dst, socklen_t size) >> { >> int n; >> >> n = snprintf(dst, size, "%u.%u.%u.%u", src[0], src[1], src[2], >> src[3]); >> assert(n >= 0); /* CHAR_BIT == 8 imples 0 < n <= 16 */ >> ... > I don't know why the ret array in the userland version of the inet_ntoa > should be 17. The length of the message itself is 17, and an \0 is needed > for the str* to work. Yes, it needs to be 18 for the error message. I wrote "18 (sic)" because 18 is a surprising value. Anyone who knows what an inet address is would expect a length of 16. But programmers shouldn't be counting bytes in strings and mentally computing max(16, 18) and hard-coding that. The magic 16 won't change, but the 18 might. Spelling 16/18 as a macro and hard-coding 16/18 in the macro would be even worse, since the value is only used onece. > By the way, 4 * sizeof("123") chars should be always enough to contain an > IPv4 address, no matter how many bits consititute a char. It's enough for an ipv4 address, but inet_ntop4() is a library routine so it shouldn't crash on invalid input. With 8-bit chars, it happens that there is no invalid input for u_char *src (except a src array with less than 4 chars in it). With >= 10-bit chars, the result could be "1023.1023.1023.1023", which isn't an ipv4 address and is too large for a 16-18 byte buffer. inet_ntop4() needs to ensure that this and some other errors don't occur. It uses mainly snprintf(), but with snprintf() another set of errors and out-of-bounds values can occur in theory, and inet_ntop4()'s handling of these is not quite right. Bruce From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 11:12:51 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BCB716A416; Fri, 10 Nov 2006 11:12:51 +0000 (UTC) (envelope-from flz@xbsd.org) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6A2C43D62; Fri, 10 Nov 2006 11:12:42 +0000 (GMT) (envelope-from flz@xbsd.org) Received: from smtp.xbsd.org (unknown [82.233.2.192]) by smtp1-g19.free.fr (Postfix) with ESMTP id C177668A0F; Fri, 10 Nov 2006 12:12:41 +0100 (CET) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id 4614D114F6; Fri, 10 Nov 2006 12:12:41 +0100 (CET) Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30380-07; Fri, 10 Nov 2006 12:12:19 +0100 (CET) Received: from [10.0.0.142] (unknown [81.74.42.155]) by smtp.xbsd.org (Postfix) with ESMTP id 1BC9A11415; Fri, 10 Nov 2006 12:12:17 +0100 (CET) In-Reply-To: <4553A000.7070407@FreeBSD.org> References: <1162993001.4305.37.camel@massimo.datacode.it> <4553A000.7070407@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Florent Thoumie Date: Fri, 10 Nov 2006 11:12:09 +0000 To: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: amavisd-new at xbsd.org Cc: Massimo Lusetti , hackers@freebsd.org, net@freebsd.org Subject: Re: New wpi driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 11:12:51 -0000 On Nov 9, 2006, at 9:39 PM, G=E1bor K=F6vesd=E1n wrote: > Florent Thoumie wrote: >> On Nov 8, 2006, at 1:36 PM, Massimo Lusetti wrote: >> >>> Hi all, >>> I'm pleased to tell you i got the latest wpi driver from Damien >>> Bergamini to work properly on a latest -stable on an Acer laptop. >> >> Nice work! > Unfortunately, it seems that this is still that unfinished driver =20 > from Damien, that circulates on the net everywhere, but it only =20 > works for some lucky people. As for me, I get an error message when =20= > loading the module, that it could not allocate resources. Haven't taken my 3945 "powered" laptop in Milan, so I haven't had the =20= chance to try it yet. Is it the same as the one we can find in =20 deischen public space on freefall? --=20 Florent Thoumie flz@FreeBSD.org FreeBSD Committer From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 11:13:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9419316A403; Fri, 10 Nov 2006 11:13:55 +0000 (UTC) (envelope-from khetan@os.org.za) Received: from gauntlet.os.org.za (gauntlet.os.org.za [196.35.70.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id A74E643D49; Fri, 10 Nov 2006 11:13:53 +0000 (GMT) (envelope-from khetan@os.org.za) Received: from localhost (localhost [127.0.0.1]) by gauntlet.os.org.za (Postfix) with ESMTP id 3394067941; Fri, 10 Nov 2006 13:13:50 +0200 (SAST) X-Virus-Scanned: amavisd-new at os.org.za Received: from gauntlet.os.org.za ([127.0.0.1]) by localhost (gauntlet.os.org.za [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9RlMsGDSb9kR; Fri, 10 Nov 2006 13:13:43 +0200 (SAST) Received: from khetangajjar (dustpuppy.is.co.za [196.14.169.11]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: khetan) by gauntlet.os.org.za (Postfix) with ESMTP id 010A06792D; Fri, 10 Nov 2006 13:13:43 +0200 (SAST) From: "Khetan Gajjar" To: "'Bjoern A. Zeeb'" Date: Fri, 10 Nov 2006 13:13:42 +0200 Message-ID: <013d01c704b9$483bfbe0$0525010a@af.didata.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb8M/1PK0ObsksmRoK5O2n99DMC+QIgTvqw In-Reply-To: <20061030143114.I2462@maildrop.int.zabbadoz.net> Cc: "'George V. Neville-Neil'" , freebsd-net@freebsd.org Subject: RE: Path MTU discovery broken in IPSec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 11:13:55 -0000 Hi Bjoern. My apologies for the delay in response. > and no rules specific to ICMP? The only ICMP-specific rules allow everything through; [host1] ~# ipfw show | grep icmp 01700 35776 3023614 pipe 25 icmp from any to table(1) in via em0 01701 35776 3023614 skipto 1999 icmp from any to table(1) in via em0 01702 35009 2970684 pipe 26 icmp from table(1) to any out via em0 01703 35009 2970684 skipto 1999 icmp from table(1) to any out via em0 02004 37204 3144438 allow icmp from any to table(1) in via em0 02005 41289 3498204 allow icmp from table(1) to any out via em0 And similarly for host2; [host2] ~# ipfw show | grep icmp 01700 21550 1789832 pipe 25 icmp from any to table(1) in via fxp0 01701 21550 1789832 skipto 1999 icmp from any to table(1) in via fxp0 01702 21190 1770208 pipe 26 icmp from table(1) to any out via fxp0 01703 21190 1770208 skipto 1999 icmp from table(1) to any out via fxp0 02004 22899 1903148 allow icmp from any to table(1) in via fxp0 02005 27470 2297728 allow icmp from table(1) to any out via fxp0 > can you start trying with ping -s 1000 and going up to see when it > starts to fail? Try to find out exactly. It appears to be fine up until between 8000 and 9000, without any issues. Up to 8000, its appears to be fine. [host1] ~# ping -s 8000 citadel.os.org.za PING host2 (y.y.y.y): 8000 data bytes 8008 bytes from y.y.y.y: icmp_seq=0 ttl=112 time=533.652 ms 8008 bytes from y.y.y.y: icmp_seq=1 ttl=112 time=544.826 ms 8008 bytes from y.y.y.y: icmp_seq=2 ttl=112 time=531.899 ms 8008 bytes from y.y.y.y: icmp_seq=3 ttl=112 time=581.185 ms 8008 bytes from y.y.y.y: icmp_seq=4 ttl=112 time=674.831 ms 8008 bytes from y.y.y.y: icmp_seq=5 ttl=112 time=674.271 ms ^C --- host2 ping statistics --- 7 packets transmitted, 6 packets received, 14% packet loss round-trip min/avg/max/stddev = 531.899/590.111/674.831/61.870 ms By 9000, it starts to drop packets. [host1] ~# ping -s 9000 host2 PING host2 (y.y.y.y): 9000 data bytes 9008 bytes from y.y.y.y: icmp_seq=0 ttl=112 time=554.908 ms 9008 bytes from y.y.y.y: icmp_seq=2 ttl=112 time=527.464 ms 9008 bytes from y.y.y.y: icmp_seq=3 ttl=112 time=553.512 ms 9008 bytes from y.y.y.y: icmp_seq=4 ttl=112 time=755.606 ms 9008 bytes from y.y.y.y: icmp_seq=5 ttl=112 time=484.681 ms 9008 bytes from y.y.y.y: icmp_seq=6 ttl=112 time=485.256 ms 9008 bytes from y.y.y.y: icmp_seq=7 ttl=112 time=488.802 ms 9008 bytes from y.y.y.y: icmp_seq=8 ttl=112 time=491.750 ms 9008 bytes from y.y.y.y: icmp_seq=9 ttl=112 time=493.689 ms 9008 bytes from y.y.y.y: icmp_seq=11 ttl=112 time=547.049 ms 9008 bytes from y.y.y.y: icmp_seq=12 ttl=112 time=668.788 ms 9008 bytes from y.y.y.y: icmp_seq=13 ttl=112 time=479.957 ms 9008 bytes from y.y.y.y: icmp_seq=14 ttl=112 time=478.519 ms 9008 bytes from y.y.y.y: icmp_seq=15 ttl=112 time=479.967 ms 9008 bytes from y.y.y.y: icmp_seq=16 ttl=112 time=480.166 ms 9008 bytes from y.y.y.y: icmp_seq=17 ttl=112 time=492.812 ms ^C --- host2 ping statistics --- 18 packets transmitted, 16 packets received, 11% packet loss round-trip min/avg/max/stddev = 478.519/528.933/755.606/75.693 ms At 15000, it is fairly horrendous [host1] ~# ping -s 15000 host2 PING host2 (y.y.y.y): 15000 data bytes 15008 bytes from y.y.y.y: icmp_seq=1 ttl=112 time=510.439 ms 15008 bytes from y.y.y.y: icmp_seq=2 ttl=112 time=497.274 ms 15008 bytes from y.y.y.y: icmp_seq=5 ttl=112 time=536.947 ms 15008 bytes from y.y.y.y: icmp_seq=6 ttl=112 time=567.623 ms 15008 bytes from y.y.y.y: icmp_seq=7 ttl=112 time=534.828 ms 15008 bytes from y.y.y.y: icmp_seq=8 ttl=112 time=534.521 ms 15008 bytes from y.y.y.y: icmp_seq=13 ttl=112 time=574.470 ms 15008 bytes from y.y.y.y: icmp_seq=16 ttl=112 time=588.514 ms 15008 bytes from y.y.y.y: icmp_seq=17 ttl=112 time=575.090 ms 15008 bytes from y.y.y.y: icmp_seq=21 ttl=112 time=548.478 ms ^C --- host2 ping statistics --- 23 packets transmitted, 10 packets received, 56% packet loss round-trip min/avg/max/stddev = 497.274/546.818/588.514/28.122 ms > Also could you post the relevant netstat -rnW output? On host1; [host1] ~# netstat -rnW Routing tables Internet: Destination Gateway Flags Refs Use Mtu Netif Expire default x.x.x.1 UGS 0 705597552 1000 em0 127.0.0.1 127.0.0.1 UH 0 2887710 16384 lo0 x.x.x link#1 UC 0 0 1500 em0 x.x.x.1 00:00:0c:07:ac:0a UHLW 2 72598 1500 em0 1110 x.x.x.x 00:12:3f:ec:d1:ce UHLW 1 28404610 1500 lo0 Internet6: Destination Gateway Flags Refs Use Mtu Netif Expire ::1 ::1 UH 0 0 16384 lo0 fe80::%em0/64 link#1 UC 0 0 1500 em0 fe80::212:3fff:feec:d1ce%em0 00:12:3f:ec:d1:ce UHL 0 0 1500 lo0 fe80::%lo0/64 fe80::1%lo0 U 0 0 16384 lo0 fe80::1%lo0 fe80::1%lo0 UHL 0 0 16384 lo0 ff01:1::/32 link#1 UC 0 0 1500 em0 ff01:3::/32 ::1 UC 0 0 16384 lo0 ff02::%em0/32 link#1 UC 0 0 1500 em0 ff02::%lo0/32 ::1 UC 0 0 16384 lo0 And on host2; [host2] ~# netstat -rnW Routing tables Internet: Destination Gateway Flags Refs Use Mtu Netif Expire default y.y.y.185 UGS 0 187571667 1500 fxp0 127.0.0.1 127.0.0.1 UH 0 8689214 16384 lo0 y.y.y.185 00:0f:34:b7:dc:7f UHLW 2 72625 1500 fxp0 747 y.y.y.y 00:02:b3:eb:21:db UHLW 1 43334553 1500 lo0 Internet6: Destination Gateway Flags Refs Use Mtu Netif Expire ::1 ::1 UH 0 0 16384 lo0 fe80::%fxp0/64 link#1 UC 0 0 1500 fxp0 fe80::202:b3ff:feeb:21db%fxp0 00:02:b3:eb:21:db UHL 0 0 1500 lo0 fe80::%lo0/64 fe80::1%lo0 U 0 0 16384 lo0 fe80::1%lo0 fe80::1%lo0 UHL 0 0 16384 lo0 ff01:1::/32 link#1 UC 0 0 1500 fxp0 ff01:3::/32 ::1 UC 0 0 16384 lo0 ff02::%fxp0/32 link#1 UC 0 0 1500 fxp0 ff02::%lo0/32 ::1 UC 0 0 16384 lo0 Thanks for your assistance! -- Khetan Gajjar From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 12:13:13 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B59AA16A417; Fri, 10 Nov 2006 12:13:13 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id D652B43D58; Fri, 10 Nov 2006 12:13:12 +0000 (GMT) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id 456059A195A; Fri, 10 Nov 2006 13:13:11 +0100 (CET) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5Z17vAa+4N64; Fri, 10 Nov 2006 13:13:05 +0100 (CET) Received: from [192.168.2.186] (catv-50635cb6.catv.broadband.hu [80.99.92.182]) by server.t-hosting.hu (Postfix) with ESMTP id 345D79A1924; Fri, 10 Nov 2006 13:13:05 +0100 (CET) Message-ID: <45546CC7.5070302@FreeBSD.org> Date: Fri, 10 Nov 2006 13:12:55 +0100 From: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Florent Thoumie References: <1162993001.4305.37.camel@massimo.datacode.it> <4553A000.7070407@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Massimo Lusetti , hackers@freebsd.org, net@freebsd.org Subject: Re: New wpi driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 12:13:13 -0000 Florent Thoumie wrote: > > On Nov 9, 2006, at 9:39 PM, Gábor Kövesdán wrote: > >> Florent Thoumie wrote: >>> On Nov 8, 2006, at 1:36 PM, Massimo Lusetti wrote: >>> >>>> Hi all, >>>> I'm pleased to tell you i got the latest wpi driver from Damien >>>> Bergamini to work properly on a latest -stable on an Acer laptop. >>> >>> Nice work! >> Unfortunately, it seems that this is still that unfinished driver >> from Damien, that circulates on the net everywhere, but it only works >> for some lucky people. As for me, I get an error message when loading >> the module, that it could not allocate resources. > > Haven't taken my 3945 "powered" laptop in Milan, so I haven't had the > chance to try it yet. Is it the same as the one we can find in > deischen public space on freefall? > > Well, not actually. I compared them, and this one is different, but unfortunately still produces the same error for me on a Fujitsu-Siemens Amilo Pi 1556 01. -- Cheers, Gabor From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 13:59:37 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8541516A492; Fri, 10 Nov 2006 13:59:37 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B4F843D45; Fri, 10 Nov 2006 13:59:36 +0000 (GMT) (envelope-from max@love2party.net) Received: from [81.74.42.155] (helo=[10.0.0.243]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GiWul3Y9j-0004Xc; Fri, 10 Nov 2006 14:59:31 +0100 From: Max Laier To: freebsd-hackers@freebsd.org Date: Fri, 10 Nov 2006 14:59:19 +0100 User-Agent: KMail/1.9.4 References: <1162993001.4305.37.camel@massimo.datacode.it> <4553A000.7070407@FreeBSD.org> <1163151468.4328.6.camel@massimo.datacode.it> In-Reply-To: <1163151468.4328.6.camel@massimo.datacode.it> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200611101459.20117.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-net@freebsd.org, Massimo Lusetti , =?utf-8?q?G=C3=A1bor_K=C3=B6vesd=C3=A1n?= , Florent Thoumie Subject: Re: New wpi driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 13:59:37 -0000 On Friday 10 November 2006 10:37, Massimo Lusetti wrote: > On Thu, 2006-11-09 at 22:39 +0100, G=C3=A1bor K=C3=B6vesd=C3=A1n wrote: > > Unfortunately, it seems that this is still that unfinished driver from > > Damien, that circulates on the net everywhere, but it only works for > > some lucky people. As for me, I get an error message when loading the > > module, that it could not allocate resources. > > I don't think it's "that unfinished driver from Damien" classify it > correctly, as stated it's an unsupported version so case where it will > not work are expected. Feel free to improve it or wait when some FreeBSD > developer will port and maintain it. I agree. On top of that, a more detailed error report would be preferable.= =20 =46rom what you put above, it seems that you are out of sufficient continou= s=20 memory at the point where you enable the hardware. Try enabling it before= =20 bringing up X11 etc. > Thanks Florent for mirroring. =2D- Max From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 15:09:10 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7311A16A403; Fri, 10 Nov 2006 15:09:10 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6523743D69; Fri, 10 Nov 2006 15:09:06 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id kAAF8mZ6049131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Nov 2006 18:08:48 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id kAAF8ePJ049130; Fri, 10 Nov 2006 18:08:40 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 10 Nov 2006 18:08:40 +0300 From: Gleb Smirnoff To: Barry Boes Message-ID: <20061110150840.GK32700@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Barry Boes , jfv@FreeBSD.org, Scott Long , John Baldwin , RelEng , Prafulla Deuskar , freebsd-stable@freebsd.org, freebsd-net References: <17748.37662.708865.764722@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <17748.37662.708865.764722@gargle.gargle.HOWL> User-Agent: Mutt/1.5.6i Cc: Scott Long , RelEng , John Baldwin , freebsd-net , Gleb Smirnoff , Prafulla Deuskar , jfv@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: EM stability X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 15:09:10 -0000 Hello Barry, On Fri, Nov 10, 2006 at 08:56:30AM -0600, Barry Boes wrote: B> I see you listed on the EM stability issues list. I have a Tyan B> H1000S with dual em ports on 6.1, and it won't stay up 5 minutes B> without EM watchdog resets unless I use giant locks. B> Is there any way you'd like me to help you with testing the updated B> drivers? Yes, please upgrade to the latemost RELENG_6 via cvsup, build a new kernel and report whether the problem is fixed or not. You see, I have added a o lot of people and two mailing lists to Cc. Please do not remove them, when replying. Thanks! -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 15:47:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35B2D16A47C for ; Fri, 10 Nov 2006 15:47:24 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id F093C43D49 for ; Fri, 10 Nov 2006 15:47:22 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so466136wxc for ; Fri, 10 Nov 2006 07:47:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=SIkV+vHjmcbECYJMYmL72jXFHl20ZgsEmQdVBJ1mpUnDMccxSmfkjc4l6ww0PYDnJEE6WF4UEsjC2EtDHy6MtaJICds1+t8zYczB7yyRZEBkWMdzbuz3eKUvk8r2wU7Bt1lA1jhJwRquQm7UQCqXDFI6N9gVN1R4HGPHc3XfVnQ= Received: by 10.70.74.6 with SMTP id w6mr3274029wxa.1163173641874; Fri, 10 Nov 2006 07:47:21 -0800 (PST) Received: by 10.70.12.2 with HTTP; Fri, 10 Nov 2006 07:47:21 -0800 (PST) Message-ID: <3bbf2fe10611100747l386a624cpd72d04b62a0681e7@mail.gmail.com> Date: Fri, 10 Nov 2006 16:47:21 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Max Laier" In-Reply-To: <200611101459.20117.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline References: <1162993001.4305.37.camel@massimo.datacode.it> <4553A000.7070407@FreeBSD.org> <1163151468.4328.6.camel@massimo.datacode.it> <200611101459.20117.max@love2party.net> X-Google-Sender-Auth: 1f08d947640195d3 Cc: freebsd-hackers@freebsd.org, Massimo Lusetti , Florent Thoumie , =?UTF-8?Q?G=C3=A1bor_K=C3=B6vesd=C3=A1n?= , freebsd-net@freebsd.org Subject: Re: New wpi driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 15:47:24 -0000 MjAwNi8xMS8xMCwgTWF4IExhaWVyIDxtYXhAbG92ZTJwYXJ0eS5uZXQ+Ogo+IE9uIEZyaWRheSAx MCBOb3ZlbWJlciAyMDA2IDEwOjM3LCBNYXNzaW1vIEx1c2V0dGkgd3JvdGU6Cj4gPiBPbiBUaHUs IDIwMDYtMTEtMDkgYXQgMjI6MzkgKzAxMDAsIEfDoWJvciBLw7Z2ZXNkw6FuIHdyb3RlOgo+ID4g PiBVbmZvcnR1bmF0ZWx5LCBpdCBzZWVtcyB0aGF0IHRoaXMgaXMgc3RpbGwgdGhhdCB1bmZpbmlz aGVkIGRyaXZlciBmcm9tCj4gPiA+IERhbWllbiwgdGhhdCBjaXJjdWxhdGVzIG9uIHRoZSBuZXQg ZXZlcnl3aGVyZSwgYnV0IGl0IG9ubHkgd29ya3MgZm9yCj4gPiA+IHNvbWUgbHVja3kgcGVvcGxl LiBBcyBmb3IgbWUsIEkgZ2V0IGFuIGVycm9yIG1lc3NhZ2Ugd2hlbiBsb2FkaW5nIHRoZQo+ID4g PiBtb2R1bGUsIHRoYXQgaXQgY291bGQgbm90IGFsbG9jYXRlIHJlc291cmNlcy4KPiA+Cj4gPiBJ IGRvbid0IHRoaW5rIGl0J3MgInRoYXQgdW5maW5pc2hlZCBkcml2ZXIgZnJvbSBEYW1pZW4iIGNs YXNzaWZ5IGl0Cj4gPiBjb3JyZWN0bHksIGFzIHN0YXRlZCBpdCdzIGFuIHVuc3VwcG9ydGVkIHZl cnNpb24gc28gY2FzZSB3aGVyZSBpdCB3aWxsCj4gPiBub3Qgd29yayBhcmUgZXhwZWN0ZWQuIEZl ZWwgZnJlZSB0byBpbXByb3ZlIGl0IG9yIHdhaXQgd2hlbiBzb21lIEZyZWVCU0QKPiA+IGRldmVs b3BlciB3aWxsIHBvcnQgYW5kIG1haW50YWluIGl0Lgo+Cj4gSSBhZ3JlZS4gIE9uIHRvcCBvZiB0 aGF0LCBhIG1vcmUgZGV0YWlsZWQgZXJyb3IgcmVwb3J0IHdvdWxkIGJlIHByZWZlcmFibGUuCj4g RnJvbSB3aGF0IHlvdSBwdXQgYWJvdmUsIGl0IHNlZW1zIHRoYXQgeW91IGFyZSBvdXQgb2Ygc3Vm ZmljaWVudCBjb250aW5vdXMKPiBtZW1vcnkgYXQgdGhlIHBvaW50IHdoZXJlIHlvdSBlbmFibGUg dGhlIGhhcmR3YXJlLiAgVHJ5IGVuYWJsaW5nIGl0IGJlZm9yZQo+IGJyaW5naW5nIHVwIFgxMSBl dGMuCgpFdmVuIGlmIEknbSBub3QgdG90YWxseSBhd2FyZSBhYm91dCB3aGF0IHByb2JsZW0gYXJl IGdhYm9yQCBpcyBoYXZpbmcKYXQgdGhlIG1vbWVudCwgc29tZSB0aW1lIGFnbyBJIHN0YXJ0ZWQg bG9va2luZyBhdCB0aGUgY29kZSBhbmQgb25lCmRpZmZlcmVuY2UgYmV0d2VlbiBpcGkgYW5kIHdw aSBpcyBpbiByaW5ncyB0aGV5IHVzZSAoYW5kIHRoZWlyCmFsbG9jYXRpb24pIGFuZCBhZ2FpbiBp biB0aGUgdXNhZ2Ugb2YgYSBzaGFyZWQgRE1BIG1lbW9yeSBwYWdlIGJldHdlZW4KdGhlIGhvc3Qg YW5kIHRoZSBOSUMuCgpNYXliZSB0aGlzIGlzIG5vdCBkb25lIGluIHRoZSByaWdodCB3YXkgaW4g dGhlIERhbWllbidzIGRyaXZlciBhbmQKdGhpcyBpcyBiZWFjYXVzZSBnYWJvciB3b3VsZCBoYXZp bmcgYWxsb2NhdGlvbiBwcm9ibGVtcy4KCkF0dGlsaW8KClBTOiBJIHdpbGwgdHJ5IHRvIGxvb2sg YXQgdGhlIGNvZGUgcG9zdGVkIGFib3ZlIEFTQVAuLi4KCgotLSAKUGVhY2UgY2FuIG9ubHkgYmUg YWNoaWV2ZWQgYnkgdW5kZXJzdGFuZGluZyAtIEEuIEVpbnN0ZWluCg== From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 15:51:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CD8016A47C for ; Fri, 10 Nov 2006 15:51:43 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22EFA43D78 for ; Fri, 10 Nov 2006 15:51:35 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so467043wxc for ; Fri, 10 Nov 2006 07:51:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=li1w6KGL0ckaDs6JfopwaauP+n5mXu/5pLhsFzMrbcKLIxN83eG1htc5IORgnFNRE6fgmzB6Va9nfNwSCwQQ+CcBj2bUp1T9NYOW82qiN31E8fXdPDVZkDzJEQ3ZTHdOrrWwA0DhyMbCxaHqvMOtJ3d/p5g1ZeoAOfJh/LYc95I= Received: by 10.70.33.10 with SMTP id g10mr3290736wxg.1163173895032; Fri, 10 Nov 2006 07:51:35 -0800 (PST) Received: by 10.70.12.2 with HTTP; Fri, 10 Nov 2006 07:51:34 -0800 (PST) Message-ID: <3bbf2fe10611100751i77e9c8afle0aed1e794062f4f@mail.gmail.com> Date: Fri, 10 Nov 2006 16:51:34 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Max Laier" In-Reply-To: <3bbf2fe10611100747l386a624cpd72d04b62a0681e7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline References: <1162993001.4305.37.camel@massimo.datacode.it> <4553A000.7070407@FreeBSD.org> <1163151468.4328.6.camel@massimo.datacode.it> <200611101459.20117.max@love2party.net> <3bbf2fe10611100747l386a624cpd72d04b62a0681e7@mail.gmail.com> X-Google-Sender-Auth: 93c68a4113db3a88 Cc: freebsd-hackers@freebsd.org, Massimo Lusetti , Florent Thoumie , =?UTF-8?Q?G=C3=A1bor_K=C3=B6vesd=C3=A1n?= , freebsd-net@freebsd.org Subject: Re: New wpi driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 15:51:43 -0000 MjAwNi8xMS8xMCwgQXR0aWxpbyBSYW8gPGF0dGlsaW9AZnJlZWJzZC5vcmc+Ogo+IDIwMDYvMTEv MTAsIE1heCBMYWllciA8bWF4QGxvdmUycGFydHkubmV0PjoKPiA+IE9uIEZyaWRheSAxMCBOb3Zl bWJlciAyMDA2IDEwOjM3LCBNYXNzaW1vIEx1c2V0dGkgd3JvdGU6Cj4gPiA+IE9uIFRodSwgMjAw Ni0xMS0wOSBhdCAyMjozOSArMDEwMCwgR8OhYm9yIEvDtnZlc2TDoW4gd3JvdGU6Cj4gPiA+ID4g VW5mb3J0dW5hdGVseSwgaXQgc2VlbXMgdGhhdCB0aGlzIGlzIHN0aWxsIHRoYXQgdW5maW5pc2hl ZCBkcml2ZXIgZnJvbQo+ID4gPiA+IERhbWllbiwgdGhhdCBjaXJjdWxhdGVzIG9uIHRoZSBuZXQg ZXZlcnl3aGVyZSwgYnV0IGl0IG9ubHkgd29ya3MgZm9yCj4gPiA+ID4gc29tZSBsdWNreSBwZW9w bGUuIEFzIGZvciBtZSwgSSBnZXQgYW4gZXJyb3IgbWVzc2FnZSB3aGVuIGxvYWRpbmcgdGhlCj4g PiA+ID4gbW9kdWxlLCB0aGF0IGl0IGNvdWxkIG5vdCBhbGxvY2F0ZSByZXNvdXJjZXMuCj4gPiA+ Cj4gPiA+IEkgZG9uJ3QgdGhpbmsgaXQncyAidGhhdCB1bmZpbmlzaGVkIGRyaXZlciBmcm9tIERh bWllbiIgY2xhc3NpZnkgaXQKPiA+ID4gY29ycmVjdGx5LCBhcyBzdGF0ZWQgaXQncyBhbiB1bnN1 cHBvcnRlZCB2ZXJzaW9uIHNvIGNhc2Ugd2hlcmUgaXQgd2lsbAo+ID4gPiBub3Qgd29yayBhcmUg ZXhwZWN0ZWQuIEZlZWwgZnJlZSB0byBpbXByb3ZlIGl0IG9yIHdhaXQgd2hlbiBzb21lIEZyZWVC U0QKPiA+ID4gZGV2ZWxvcGVyIHdpbGwgcG9ydCBhbmQgbWFpbnRhaW4gaXQuCj4gPgo+ID4gSSBh Z3JlZS4gIE9uIHRvcCBvZiB0aGF0LCBhIG1vcmUgZGV0YWlsZWQgZXJyb3IgcmVwb3J0IHdvdWxk IGJlIHByZWZlcmFibGUuCj4gPiBGcm9tIHdoYXQgeW91IHB1dCBhYm92ZSwgaXQgc2VlbXMgdGhh dCB5b3UgYXJlIG91dCBvZiBzdWZmaWNpZW50IGNvbnRpbm91cwo+ID4gbWVtb3J5IGF0IHRoZSBw b2ludCB3aGVyZSB5b3UgZW5hYmxlIHRoZSBoYXJkd2FyZS4gIFRyeSBlbmFibGluZyBpdCBiZWZv cmUKPiA+IGJyaW5naW5nIHVwIFgxMSBldGMuCj4KPiBFdmVuIGlmIEknbSBub3QgdG90YWxseSBh d2FyZSBhYm91dCB3aGF0IHByb2JsZW0gYXJlIGdhYm9yQCBpcyBoYXZpbmcKPiBhdCB0aGUgbW9t ZW50LCBzb21lIHRpbWUgYWdvIEkgc3RhcnRlZCBsb29raW5nIGF0IHRoZSBjb2RlIGFuZCBvbmUK PiBkaWZmZXJlbmNlIGJldHdlZW4gaXBpIGFuZCB3cGkgaXMgaW4gcmluZ3MgdGhleSB1c2UgKGFu ZCB0aGVpcgo+IGFsbG9jYXRpb24pIGFuZCBhZ2FpbiBpbiB0aGUgdXNhZ2Ugb2YgYSBzaGFyZWQg RE1BIG1lbW9yeSBwYWdlIGJldHdlZW4KPiB0aGUgaG9zdCBhbmQgdGhlIE5JQy4KCnMvaXBpL2l3 aS4KCkF0dGlsaW8KCgotLSAKUGVhY2UgY2FuIG9ubHkgYmUgYWNoaWV2ZWQgYnkgdW5kZXJzdGFu ZGluZyAtIEEuIEVpbnN0ZWluCg== From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 19:14:57 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20CB116A492 for ; Fri, 10 Nov 2006 19:14:57 +0000 (UTC) (envelope-from bab@acciodata.com) Received: from smtpauth02.prod.mesa1.secureserver.net (smtpauth02.prod.mesa1.secureserver.net [64.202.165.182]) by mx1.FreeBSD.org (Postfix) with SMTP id 961B643D53 for ; Fri, 10 Nov 2006 19:14:54 +0000 (GMT) (envelope-from bab@acciodata.com) Received: (qmail 22269 invoked from network); 10 Nov 2006 19:14:54 -0000 Received: from unknown (66.68.10.54) by smtpauth02-04.prod.mesa1.secureserver.net (64.202.165.182) with ESMTP; 10 Nov 2006 19:14:53 -0000 Received: from bravo.acciodata.com (bab@localhost [127.0.0.1]) by bravo.acciodata.com (8.13.8/8.13.6) with ESMTP id kAAJErd8051115; Fri, 10 Nov 2006 13:14:53 -0600 (CST) (envelope-from bab@bravo.acciodata.com) Received: (from bab@localhost) by bravo.acciodata.com (8.13.6/8.13.4/Submit) id kAAJEqxs051112; Fri, 10 Nov 2006 13:14:52 -0600 (CST) (envelope-from bab) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17748.53164.372871.270153@gargle.gargle.HOWL> Date: Fri, 10 Nov 2006 13:14:52 -0600 To: Gleb Smirnoff In-Reply-To: <20061110150840.GK32700@cell.sick.ru> References: <17748.37662.708865.764722@gargle.gargle.HOWL> <20061110150840.GK32700@cell.sick.ru> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid From: Barry Boes Cc: Scott Long , RelEng , John Baldwin , freebsd-net , Barry Boes , Prafulla Deuskar , jfv@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: EM stability X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Barry Boes List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 19:14:57 -0000 So far so good. I updated to the latest, including jfv's revision 1.65.2.21 from this AM. With the 6.1 ISO distribution, I would get watchdogs within seconds of starting a file transfer (except giant locked which worked fine). With RELENG_6 I've transfered 100's of GB via ftp and NFS over both ethernet ports and no problems yet. Thanks for all the hard work! Barry Gleb Smirnoff writes: > Hello Barry, > > On Fri, Nov 10, 2006 at 08:56:30AM -0600, Barry Boes wrote: > B> I see you listed on the EM stability issues list. I have a Tyan > B> H1000S with dual em ports on 6.1, and it won't stay up 5 minutes > B> without EM watchdog resets unless I use giant locks. > B> Is there any way you'd like me to help you with testing the updated > B> drivers? > > Yes, please upgrade to the latemost RELENG_6 via cvsup, build a new > kernel and report whether the problem is fixed or not. > > You see, I have added a o lot of people and two mailing lists to Cc. > Please do not remove them, when replying. Thanks! > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 19:50:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0707616A412 for ; Fri, 10 Nov 2006 19:50:08 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A20243D81 for ; Fri, 10 Nov 2006 19:49:54 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so517214wxc for ; Fri, 10 Nov 2006 11:49:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=d2L2XuoEB63I12Dr9HfSwRkjjsCY+YerDepOAURywj87kKjuuoawz5r5SZ9k+MSrAlI55ZzL3crpWHuN6yMr67YBLq4oK/DLZiJUw1Mo027nxt3v0xp8IHQZmaGLLPFH9CwO6TkTaafP+r6HSrPNKmlJRZUbMYX96S1BoFy7C2o= Received: by 10.70.109.12 with SMTP id h12mr3677018wxc.1163188192481; Fri, 10 Nov 2006 11:49:52 -0800 (PST) Received: by 10.70.12.2 with HTTP; Fri, 10 Nov 2006 11:49:52 -0800 (PST) Message-ID: <3bbf2fe10611101149y72f29285s517f5e40a5b8f3e0@mail.gmail.com> Date: Fri, 10 Nov 2006 20:49:52 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Max Laier" In-Reply-To: <3bbf2fe10611100751i77e9c8afle0aed1e794062f4f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline References: <1162993001.4305.37.camel@massimo.datacode.it> <4553A000.7070407@FreeBSD.org> <1163151468.4328.6.camel@massimo.datacode.it> <200611101459.20117.max@love2party.net> <3bbf2fe10611100747l386a624cpd72d04b62a0681e7@mail.gmail.com> <3bbf2fe10611100751i77e9c8afle0aed1e794062f4f@mail.gmail.com> X-Google-Sender-Auth: 0292fb96362c32b4 Cc: freebsd-hackers@freebsd.org, Massimo Lusetti , Florent Thoumie , =?UTF-8?Q?G=C3=A1bor_K=C3=B6vesd=C3=A1n?= , freebsd-net@freebsd.org Subject: Re: New wpi driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 19:50:09 -0000 MjAwNi8xMS8xMCwgQXR0aWxpbyBSYW8gPGF0dGlsaW9AZnJlZWJzZC5vcmc+Ogo+IDIwMDYvMTEv MTAsIEF0dGlsaW8gUmFvIDxhdHRpbGlvQGZyZWVic2Qub3JnPjoKPiA+IDIwMDYvMTEvMTAsIE1h eCBMYWllciA8bWF4QGxvdmUycGFydHkubmV0PjoKPiA+ID4gT24gRnJpZGF5IDEwIE5vdmVtYmVy IDIwMDYgMTA6MzcsIE1hc3NpbW8gTHVzZXR0aSB3cm90ZToKPiA+ID4gPiBPbiBUaHUsIDIwMDYt MTEtMDkgYXQgMjI6MzkgKzAxMDAsIEfDoWJvciBLw7Z2ZXNkw6FuIHdyb3RlOgo+ID4gPiA+ID4g VW5mb3J0dW5hdGVseSwgaXQgc2VlbXMgdGhhdCB0aGlzIGlzIHN0aWxsIHRoYXQgdW5maW5pc2hl ZCBkcml2ZXIgZnJvbQo+ID4gPiA+ID4gRGFtaWVuLCB0aGF0IGNpcmN1bGF0ZXMgb24gdGhlIG5l dCBldmVyeXdoZXJlLCBidXQgaXQgb25seSB3b3JrcyBmb3IKPiA+ID4gPiA+IHNvbWUgbHVja3kg cGVvcGxlLiBBcyBmb3IgbWUsIEkgZ2V0IGFuIGVycm9yIG1lc3NhZ2Ugd2hlbiBsb2FkaW5nIHRo ZQo+ID4gPiA+ID4gbW9kdWxlLCB0aGF0IGl0IGNvdWxkIG5vdCBhbGxvY2F0ZSByZXNvdXJjZXMu Cj4gPiA+ID4KPiA+ID4gPiBJIGRvbid0IHRoaW5rIGl0J3MgInRoYXQgdW5maW5pc2hlZCBkcml2 ZXIgZnJvbSBEYW1pZW4iIGNsYXNzaWZ5IGl0Cj4gPiA+ID4gY29ycmVjdGx5LCBhcyBzdGF0ZWQg aXQncyBhbiB1bnN1cHBvcnRlZCB2ZXJzaW9uIHNvIGNhc2Ugd2hlcmUgaXQgd2lsbAo+ID4gPiA+ IG5vdCB3b3JrIGFyZSBleHBlY3RlZC4gRmVlbCBmcmVlIHRvIGltcHJvdmUgaXQgb3Igd2FpdCB3 aGVuIHNvbWUgRnJlZUJTRAo+ID4gPiA+IGRldmVsb3BlciB3aWxsIHBvcnQgYW5kIG1haW50YWlu IGl0Lgo+ID4gPgo+ID4gPiBJIGFncmVlLiAgT24gdG9wIG9mIHRoYXQsIGEgbW9yZSBkZXRhaWxl ZCBlcnJvciByZXBvcnQgd291bGQgYmUgcHJlZmVyYWJsZS4KPiA+ID4gRnJvbSB3aGF0IHlvdSBw dXQgYWJvdmUsIGl0IHNlZW1zIHRoYXQgeW91IGFyZSBvdXQgb2Ygc3VmZmljaWVudCBjb250aW5v dXMKPiA+ID4gbWVtb3J5IGF0IHRoZSBwb2ludCB3aGVyZSB5b3UgZW5hYmxlIHRoZSBoYXJkd2Fy ZS4gIFRyeSBlbmFibGluZyBpdCBiZWZvcmUKPiA+ID4gYnJpbmdpbmcgdXAgWDExIGV0Yy4KPiA+ Cj4gPiBFdmVuIGlmIEknbSBub3QgdG90YWxseSBhd2FyZSBhYm91dCB3aGF0IHByb2JsZW0gYXJl IGdhYm9yQCBpcyBoYXZpbmcKPiA+IGF0IHRoZSBtb21lbnQsIHNvbWUgdGltZSBhZ28gSSBzdGFy dGVkIGxvb2tpbmcgYXQgdGhlIGNvZGUgYW5kIG9uZQo+ID4gZGlmZmVyZW5jZSBiZXR3ZWVuIGlw aSBhbmQgd3BpIGlzIGluIHJpbmdzIHRoZXkgdXNlIChhbmQgdGhlaXIKPiA+IGFsbG9jYXRpb24p IGFuZCBhZ2FpbiBpbiB0aGUgdXNhZ2Ugb2YgYSBzaGFyZWQgRE1BIG1lbW9yeSBwYWdlIGJldHdl ZW4KPiA+IHRoZSBob3N0IGFuZCB0aGUgTklDLgo+Cj4gcy9pcGkvaXdpLgoKT2sgSSBnYXZlIGEg cXVpY2sgbG9vayBhdCB0aGUgY29kZSBhbmQgZ2Fib3JAIHByb2JsZW0gaXMgYWJvdXQKbWVtb3J5 LW1hcHBlZCBJL08gcmVzb3VyY2UgYWxsb2NhdGlvbi4KCkZpcnN0IG9mIGFsbCwgV1BJX1BDSV9C QVIwIG1pZ2h0IG5vdCBiZSBkZWZpbmVkIGluIHRoaXMgd2F5LCBidXQgaXQKc2hvdWxkIHJlYWxs eSB1c2UgUENJUl9CQVIoKSBtYWNyby4KVGhlbiwgcHJvYmFiaWxseSwgZ2Fib3IncyBkZXZpY2Ug SS9PIHNwYWNlIGlzIHJlbGF0aXZlIHRvIGFub3RoZXIgQkFSLApzbyBzaW1wbHkgdHJ5IGFsbCA2 IHVzaW5nIFBDSVJfQkFSKG4pIHdoZXJlIG4gcmFuZ2UgaXMgMC02IHVudGlsIGl0CmRvZXMgYWxs b2NhdGUuCgpBdHRpbGlvCgpQUzogSSB3b3VsZCBsaWtlIHRoYXQgdGhlIGNvZGUgd2lsbCBiZXR0 ZXIgZm9sbG93IHN0bHllKDkpIHRvby4uLgoKLS0gClBlYWNlIGNhbiBvbmx5IGJlIGFjaGlldmVk IGJ5IHVuZGVyc3RhbmRpbmcgLSBBLiBFaW5zdGVpbgo= From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 20:00:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A71C16A4A0 for ; Fri, 10 Nov 2006 20:00:45 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99B3843F52 for ; Fri, 10 Nov 2006 19:57:47 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so518647wxc for ; Fri, 10 Nov 2006 11:57:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ryu8eUTa46QYMRnuMnppY7DPoA8xU9wfDu4+Er+1YtnGbWBv/HY1RVaZEw+JgABVS0djlFeIQDq24b+bD2EyLpsdPTdEgrx5K8zVOFG6IK1AosgREvqTibHoBb9DyJ+vtSnXW7ykued7T60r6ZWlDCoCG8XIqj7UbWSE0KJxQns= Received: by 10.70.90.18 with SMTP id n18mr3718138wxb.1163188664677; Fri, 10 Nov 2006 11:57:44 -0800 (PST) Received: by 10.70.12.2 with HTTP; Fri, 10 Nov 2006 11:57:44 -0800 (PST) Message-ID: <3bbf2fe10611101157p13296002ic974d45c3fe95e09@mail.gmail.com> Date: Fri, 10 Nov 2006 20:57:44 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Max Laier" In-Reply-To: <3bbf2fe10611101149y72f29285s517f5e40a5b8f3e0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1162993001.4305.37.camel@massimo.datacode.it> <4553A000.7070407@FreeBSD.org> <1163151468.4328.6.camel@massimo.datacode.it> <200611101459.20117.max@love2party.net> <3bbf2fe10611100747l386a624cpd72d04b62a0681e7@mail.gmail.com> <3bbf2fe10611100751i77e9c8afle0aed1e794062f4f@mail.gmail.com> <3bbf2fe10611101149y72f29285s517f5e40a5b8f3e0@mail.gmail.com> X-Google-Sender-Auth: 93e8c797357ed415 Cc: freebsd-hackers@freebsd.org, Massimo Lusetti , Florent Thoumie , =?UTF-8?Q?G=C3=A1bor_K=C3=B6vesd=C3=A1n?= , freebsd-net@freebsd.org Subject: Re: New wpi driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 20:00:45 -0000 > First of all, WPI_PCI_BAR0 might not be defined in this way, but it > should really use PCIR_BAR() macro. > Then, probabilly, gabor's device I/O space is relative to another BAR, > so simply try all 6 using PCIR_BAR(n) where n range is 0-6 until it > does allocate. Sorry, n ranges 0-5... (as I said before 6 different address spaces). Today it seems I'm absolutely sleeping... (probabilly I'm too angry to have not parecipied at EuroBSDCon...). Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 20:04:47 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5ACC816A412; Fri, 10 Nov 2006 20:04:47 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E347743D5E; Fri, 10 Nov 2006 20:04:46 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAAK4jC8021922; Fri, 10 Nov 2006 15:04:45 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kAAK4iO9027778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Nov 2006 15:04:45 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611102004.kAAK4iO9027778@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 10 Nov 2006 15:04:51 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <200611092200.kA9M0q1E020473@lava.sentex.ca> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 20:04:47 -0000 At 05:00 PM 11/9/2006, Mike Tancsa wrote: >At 10:51 AM 11/9/2006, Scott Long wrote: >>Mike Tancsa wrote: >>>At 08:19 PM 11/8/2006, Jack Vogel wrote: >>> >>>>BUT, I've added the FAST_INTR changes back into the code, so >>>>if you go into your Makefile and add -DEM_FAST_INTR you will >>>>then get the taskqueue stuff. >>>It certainly does make a difference performance wise. I did some >>>quick testing with netperf and netrate. Back to back boxes, using >>>an AMD x2 with bge nic and one intel box >>>CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2009.27-MHz >>>686-class CPU) >>>CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (2144.01-MHz >>>686-class CPU) >>>The intel is a DG965SS with integrated em nic, the AMD a Tyan >>>with integrated bge. Both running SMP kernels with pf built in, no inet6. >>> >>>Intel box as sender. In this test its with the patch from >>>yesterday. The first set with the patch as is, the second test >>>with -DEM_FAST_INTR. >> >>Thanks for the tests. One thing to note is that Gleb reported a higher >>rate of dropped packets with INTR_FAST. He is the only one who has >>reported this, so I'd like to find out if there is something unique to >>his environment, or if there is a larger problem to be addressed. There >>are ways that we can change the driver to not drop any packets at all >>for Gleb, but they expose the system to risk if there is ever an >>accidental (or malicious) RX flood on the interface. > >With a high rate of packets, I am able to live lock the box. I >setup the following Some more tests. I tried again with what was committed to today's RELENG_6. I am guessing its pretty well the same patch. Polling is the only way to avoid livelock at a high pps rate. Does anyone know of any simple tools to measure end to end packet loss ? Polling will end up dropping some packets and I want to be able to compare. Same hardware from the previous post. SMP kernel fastfwd pf ipfw FAST_INTR streams np (Mb) x x x 2 livelock x x x x 2 468 livelock x x 2 453 lost packets, box sluggish x x x 2 lost packets, box sluggish x 2 468 lost packets, box sluggish x x 2 468 livelock x x x 2 468 livelock 2 475 livelock x 2 livelock P 2 OK P x 2 OK P x 2 OK The P is for Uniproc, but with Polling enabled (also kern.polling.idle_poll=1) UP single stream 58Kpps, no polling in kernel [bsd6-32bit]# ./netblast 192.168.44.1 500 10 10 start: 1163184051.627479975 finish: 1163184061.628200458 send calls: 5869051 send errors: 0 approx send rate: 586905 approx error rate: 0 with polling [bsd6-32bit]# ./netblast 192.168.44.1 500 10 10 start: 1163184606.651001121 finish: 1163184616.651288588 send calls: 5866199 send errors: 1 approx send rate: 586619 approx error rate: 0 With polling and 2 streams at the same time (a lot of pps! and its still totally responsive!!) [r6-32bit]# ./netblast 192.168.88.218 500 10 10 start: 1163184712.103954688 finish: 1163184722.104388542 send calls: 4528941 send errors: 0 approx send rate: 452894 approx error rate: 0 [r6-32bit]# [bsd6-32bit]# ./netblast 192.168.44.1 500 10 20 start: 1163184793.172036336 finish: 1163184813.173028921 send calls: 11550594 send errors: 0 approx send rate: 577529 approx error rate: 0 [bsd6-32bit]# polling, 2 streams at the same time [bsd6-32bit]# ./netblast 192.168.44.1 500 10 20 start: 1163185058.477137404 finish: 1163185078.478025226 send calls: 11679831 send errors: 0 approx send rate: 583991 approx error rate: 0 [bsd6-32bit]# ./netblast 192.168.44.1 500 10 20 start: 1163185167.969551943 finish: 1163185187.970435295 send calls: 11706825 send errors: 0 approx send rate: 585341 approx error rate: 0 [bsd6-32bit]# From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 22:00:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32C8816A416 for ; Fri, 10 Nov 2006 22:00:11 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id C758A43D58 for ; Fri, 10 Nov 2006 22:00:09 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so389869nzh for ; Fri, 10 Nov 2006 14:00:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AGDlr4nGvQYI0uMgvjozr2l0E2l2W9VW2njjUJg/WWo/zoCZ43HUNvouHJ2Hso2q0Xd8iK4s6JiJ/sTpmL9QiZSvhb4Zj8fDQCbTS5y0S+t18YZ6QqoPSc7/bKbat7l2OdmmMqZt72B/JKk9ztQrmNhUeGuyTRrWBmkvTiZDuPI= Received: by 10.35.111.14 with SMTP id o14mr4214122pym.1163196008397; Fri, 10 Nov 2006 14:00:08 -0800 (PST) Received: by 10.35.118.6 with HTTP; Fri, 10 Nov 2006 14:00:07 -0800 (PST) Message-ID: <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> Date: Fri, 10 Nov 2006 14:00:08 -0800 From: "Jack Vogel" To: "Mike Tancsa" In-Reply-To: <200611102004.kAAK4iO9027778@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> Cc: freebsd-net , Scott Long , freebsd-stable@freebsd.org Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 22:00:11 -0000 On 11/10/06, Mike Tancsa wrote: > > Some more tests. I tried again with what was committed to today's > RELENG_6. I am guessing its pretty well the same patch. Polling is > the only way to avoid livelock at a high pps rate. Does anyone know > of any simple tools to measure end to end packet loss ? Polling will > end up dropping some packets and I want to be able to compare. Same > hardware from the previous post. The commit WAS the last patch I posted. SO, making sure I understood you, you are saying that POLLING is doing better than FAST_INTR, or only better than the legacy code that went in with my merge? Jack From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 22:21:13 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F0D616A407; Fri, 10 Nov 2006 22:21:13 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95AB243D55; Fri, 10 Nov 2006 22:21:07 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAAML6ht044474; Fri, 10 Nov 2006 17:21:06 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kAAML6ol028630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Nov 2006 17:21:06 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611102221.kAAML6ol028630@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 10 Nov 2006 17:21:12 -0500 To: "Jack Vogel" From: Mike Tancsa In-Reply-To: <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.co m> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net , Scott Long , freebsd-stable@freebsd.org Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 22:21:13 -0000 At 05:00 PM 11/10/2006, Jack Vogel wrote: >On 11/10/06, Mike Tancsa wrote: >> >>Some more tests. I tried again with what was committed to today's >>RELENG_6. I am guessing its pretty well the same patch. Polling is >>the only way to avoid livelock at a high pps rate. Does anyone know >>of any simple tools to measure end to end packet loss ? Polling will >>end up dropping some packets and I want to be able to compare. Same >>hardware from the previous post. > >The commit WAS the last patch I posted. SO, making sure I understood you, >you are saying that POLLING is doing better than FAST_INTR, or only >better than the legacy code that went in with my merge? Hi, The last set of tests I posted are ONLY with what is in today's RELENG_6-- i.e. the latest commit. I did a few variations on the driver-- first with #define EM_FAST_INTR 1 in if_em.c one without and one with polling in the kernel. With a decent packet rate passing through, the box will lockup. Not sure if I am just hitting the limits of the PCIe bus, or interrupt moderation is not kicking in, or this is a case of "Doctor, it hurts when I send a lot of packets through"... "Well, dont do that" Using polling prevents the lockup, but it will of course drop packets. This is for firewalls with a fairly high bandwidth rate, as well as I need it to be able to survive a decent DDoS attack. I am not looking for 1Mpps, but something more than 100Kpps ---Mike From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 22:29:47 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99D4516A416 for ; Fri, 10 Nov 2006 22:29:47 +0000 (UTC) (envelope-from bab@acciodata.com) Received: from smtpout09-04.prod.mesa1.secureserver.net (smtpout09-04.prod.mesa1.secureserver.net [64.202.165.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 1CB9E43DE9 for ; Fri, 10 Nov 2006 22:28:45 +0000 (GMT) (envelope-from bab@acciodata.com) Received: (qmail 5976 invoked from network); 10 Nov 2006 22:28:32 -0000 Received: from unknown (66.68.10.54) by smtpout09-04.prod.mesa1.secureserver.net (64.202.165.17) with ESMTP; 10 Nov 2006 22:28:32 -0000 Received: from bravo.acciodata.com (bab@localhost [127.0.0.1]) by bravo.acciodata.com (8.13.8/8.13.6) with ESMTP id kAAMSV22079453; Fri, 10 Nov 2006 16:28:31 -0600 (CST) (envelope-from bab@bravo.acciodata.com) Received: (from bab@localhost) by bravo.acciodata.com (8.13.6/8.13.4/Submit) id kAAMSUbC079450; Fri, 10 Nov 2006 16:28:30 -0600 (CST) (envelope-from bab) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17748.64782.579350.492909@gargle.gargle.HOWL> Date: Fri, 10 Nov 2006 16:28:30 -0600 To: Gleb Smirnoff In-Reply-To: <17748.53164.372871.270153@gargle.gargle.HOWL> References: <17748.37662.708865.764722@gargle.gargle.HOWL> <20061110150840.GK32700@cell.sick.ru> <17748.53164.372871.270153@gargle.gargle.HOWL> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid From: Barry Boes Cc: Scott Long , RelEng , John Baldwin , freebsd-net , Barry Boes , Prafulla Deuskar , jfv@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: EM stability X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Barry Boes List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 22:29:47 -0000 Luck ran out. Hard "must press the reset button" hang. No console messages. The system was idle at the time. Is there anything you'd like me to do to attempt to narrow down the problem or get debugging output? I do not know if the freeze was related to em or something else. -Barry Barry Boes writes: > > So far so good. I updated to the latest, including jfv's revision > 1.65.2.21 from this AM. > > With the 6.1 ISO distribution, I would get watchdogs within seconds of > starting a file transfer (except giant locked which worked fine). > > With RELENG_6 I've transfered 100's of GB via ftp and NFS over both > ethernet ports and no problems yet. > > Thanks for all the hard work! > Barry > > > > Gleb Smirnoff writes: > > Hello Barry, > > > > On Fri, Nov 10, 2006 at 08:56:30AM -0600, Barry Boes wrote: > > B> I see you listed on the EM stability issues list. I have a Tyan > > B> H1000S with dual em ports on 6.1, and it won't stay up 5 minutes > > B> without EM watchdog resets unless I use giant locks. > > B> Is there any way you'd like me to help you with testing the updated > > B> drivers? > > > > Yes, please upgrade to the latemost RELENG_6 via cvsup, build a new > > kernel and report whether the problem is fixed or not. > > > > You see, I have added a o lot of people and two mailing lists to Cc. > > Please do not remove them, when replying. Thanks! > > > > -- > > Totus tuus, Glebius. > > GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 22:45:57 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48F7E16A415; Fri, 10 Nov 2006 22:45:57 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAE7B43D79; Fri, 10 Nov 2006 22:45:50 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id kAAMjXhr051243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Nov 2006 01:45:34 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id kAAMjXTv051242; Sat, 11 Nov 2006 01:45:33 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 11 Nov 2006 01:45:33 +0300 From: Gleb Smirnoff To: Barry Boes Message-ID: <20061110224533.GM32700@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Barry Boes , jfv@FreeBSD.org, Scott Long , John Baldwin , RelEng , Prafulla Deuskar , freebsd-stable@FreeBSD.org, freebsd-net References: <17748.37662.708865.764722@gargle.gargle.HOWL> <20061110150840.GK32700@cell.sick.ru> <17748.53164.372871.270153@gargle.gargle.HOWL> <17748.64782.579350.492909@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <17748.64782.579350.492909@gargle.gargle.HOWL> User-Agent: Mutt/1.5.6i Cc: Scott Long , RelEng , John Baldwin , freebsd-net , Prafulla Deuskar , jfv@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: EM stability X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 22:45:57 -0000 On Fri, Nov 10, 2006 at 04:28:30PM -0600, Barry Boes wrote: B> B> Luck ran out. Hard "must press the reset button" hang. No console B> messages. The system was idle at the time. B> Is there anything you'd like me to do to attempt to narrow down the B> problem or get debugging output? I do not know if the freeze was B> related to em or something else. In cases like this you need to prepare a kernel with debugger compiled in and try to exit into the debugger, when the hang occurs. You can try keyboard debugger sequence, and if it fails try serial break. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Nov 10 22:47:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64DA016A412 for ; Fri, 10 Nov 2006 22:47:59 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 159B843D8F for ; Fri, 10 Nov 2006 22:47:57 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so396946nzh for ; Fri, 10 Nov 2006 14:47:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ulq0JdwSd8PVaXtsLylH9246tCBt0gC2+PDI9y2U+UklT95atvBVOZorJzMAyY3x4Ztdd62ur0Ut0wG+y2B02fnAhqP3yKfdLfH535xcpIVWl7JhjXuPzA/RQ4bG94AY4RKxHiL4MMBfmQIPWWHf0VUjAIDXXyA40eLohUBT3d8= Received: by 10.35.115.18 with SMTP id s18mr4302744pym.1163198877087; Fri, 10 Nov 2006 14:47:57 -0800 (PST) Received: by 10.35.118.6 with HTTP; Fri, 10 Nov 2006 14:47:56 -0800 (PST) Message-ID: <2a41acea0611101447j29acdc3k820276de92204735@mail.gmail.com> Date: Fri, 10 Nov 2006 14:47:56 -0800 From: "Jack Vogel" To: "Barry Boes" In-Reply-To: <17748.64782.579350.492909@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <17748.37662.708865.764722@gargle.gargle.HOWL> <20061110150840.GK32700@cell.sick.ru> <17748.53164.372871.270153@gargle.gargle.HOWL> <17748.64782.579350.492909@gargle.gargle.HOWL> Cc: Scott Long , RelEng , John Baldwin , freebsd-net , jfv@freebsd.org, freebsd-stable@freebsd.org Subject: Re: EM stability X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 22:47:59 -0000 On 11/10/06, Barry Boes wrote: > > Luck ran out. Hard "must press the reset button" hang. No console > messages. The system was idle at the time. > Is there anything you'd like me to do to attempt to narrow down the > problem or get debugging output? I do not know if the freeze was > related to em or something else. Is this a machine running some graphic head? If not can you see anything on the console? Are you sure the machine is dead, like can you get in over the network... ? One thing I often do when you are dealing with unpredictable hangs is run 'vmstat 3' on one of the virtual terminals. You might also define the kernel debugger into your kernel, its best to have a serial console for this, I've seen the hardware console be locked but the serial will still work. The only way we will track this down is thru repetitive reproduction I'm afraid. Jack From owner-freebsd-net@FreeBSD.ORG Sat Nov 11 01:49:32 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93CF416A403 for ; Sat, 11 Nov 2006 01:49:32 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF47B43D45 for ; Sat, 11 Nov 2006 01:49:31 +0000 (GMT) (envelope-from antinvidia@gmail.com) Received: by nf-out-0910.google.com with SMTP id p77so996850nfc for ; Fri, 10 Nov 2006 17:49:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=nx8vtOMZ5XUGKBoXwsj6V0oca23RXJsmiRxcoTLNcgfLH2/Dsk8aLEsaimFCnFpprImeQ3wURt0NPdth/9uabubvTNp74nrBvOQtDOQl6lUYf2Nqys0hLeSWt2Q1/UnfFu00WzvL6tXKBAipo7CBsHufB9ERYMgEFZqzb8sg8jA= Received: by 10.78.204.7 with SMTP id b7mr3354152hug.1163209770057; Fri, 10 Nov 2006 17:49:30 -0800 (PST) Received: by 10.78.167.2 with HTTP; Fri, 10 Nov 2006 17:49:29 -0800 (PST) Message-ID: Date: Sat, 11 Nov 2006 01:49:29 +0000 From: MQ To: "Bruce Evans" In-Reply-To: <20061110210358.B64521@delplex.bde.org> MIME-Version: 1.0 References: <20061102142543.GC70915@lor.one-eyed-alien.net> <20061103141732.GA87515@lor.one-eyed-alien.net> <20061105011849.GB6669@lor.one-eyed-alien.net> <20061105214041.F44623@delplex.bde.org> <20061110210358.B64521@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2006 01:49:32 -0000 2006/11/10, Bruce Evans : > > On Fri, 10 Nov 2006, MQ wrote: > > > 2006/11/5, Bruce Evans : > >> > >> On Sat, 4 Nov 2006, Brooks Davis wrote: > >> > >> > On Sat, Nov 04, 2006 at 02:46:30AM +0000, MQ wrote: > >> >> 2006/11/3, Brooks Davis : > >> > >> >>> The particular definition used is excedingly ugly. At a minimum > there > >> >>> needs to be a define or a constant "16" for the lenght rather than > the > >> >>> 4*sizeof("123") nonsense. > >> > >> The `4*sizeof "123"' is not nonsense. It is better than the userland > >> version > >> at the time it was committed. The userland version hard-coded the size > as > >> 18 (sic). The current userland version still hard-codes 18, but now > >> actually needs it to print an error message of length 17. The uglyness > in > >> `4*sizeof "123"' is just that it has 3 formatting style bugs (missing > >> ... > > >> > I'd just use 16. The inet_ntoa function is frankly inane. It > attempts > >> > to support chars that aren't 8 bits which would break so much stuff > it > >> > isn't funny. > >> > >> No, it assumes 8-bit chars. It's masking with 0xff is apparently > copied > >> from an old implementation that used plain chars. The userland > >> implementation at the time it was committed does that, but uses a macro > >> to do the masking and is missing lots of style bugs. > >> > >> The userland version now calls inet_ntop(). This is missing the design > >> bug of using a static buffer. It calls inet_ntop4() for the ipv4 case. > >> This is closer to being non-ugly: > >> > >> % static const char * > >> % inet_ntop4(const u_char *src, char *dst, socklen_t size) > >> % { > >> % static const char fmt[] = "%u.%u.%u.%u"; > >> % char tmp[sizeof "255.255.255.255"]; > >> % int l; > >> % > >> % l = snprintf(tmp, sizeof(tmp), fmt, src[0], src[1], src[2], > >> src[3]); > >> % if (l <= 0 || (socklen_t) l >= size) { > >> % errno = ENOSPC; > >> % return (NULL); > >> % } > >> % strlcpy(dst, tmp, size); > >> % return (dst); > >> % } > >> > >> I would write this as: > >> > >> %%% > >> CTASSERT(CHAR_BIT == 8); /* else src would be misintepreted */ > >> > >> static const char * > >> inet_ntop4(const u_char *src, char *dst, socklen_t size) > >> { > >> int n; > >> > >> n = snprintf(dst, size, "%u.%u.%u.%u", src[0], src[1], src[2], > >> src[3]); > >> assert(n >= 0); /* CHAR_BIT == 8 imples 0 < n <= 16 */ > >> ... > > > I don't know why the ret array in the userland version of the inet_ntoa > > should be 17. The length of the message itself is 17, and an \0 is > needed > > for the str* to work. > > Yes, it needs to be 18 for the error message. I wrote "18 (sic)" because > 18 is a surprising value. Anyone who knows what an inet address is would > expect a length of 16. But programmers shouldn't be counting bytes in > strings and mentally computing max(16, 18) and hard-coding that. The > magic 16 won't change, but the 18 might. Spelling 16/18 as a macro > and hard-coding 16/18 in the macro would be even worse, since the value is > only used onece. > > > By the way, 4 * sizeof("123") chars should be always enough to contain > an > > IPv4 address, no matter how many bits consititute a char. > > It's enough for an ipv4 address, but inet_ntop4() is a library routine > so it shouldn't crash on invalid input. With 8-bit chars, it happens > that there is no invalid input for u_char *src (except a src array with > less than 4 chars in it). With >= 10-bit chars, the result could be > "1023.1023.1023.1023", which isn't an ipv4 address and is too large > for a 16-18 byte buffer. inet_ntop4() needs to ensure that this and > some other errors don't occur. It uses mainly snprintf(), but with > snprintf() another set of errors and out-of-bounds values can occur > in theory, and inet_ntop4()'s handling of these is not quite right. > > Bruce > I see. Though inet_ntoa in the userland will never result in a buffer overflow, it may return a invalid result to the caller. The inet_ntoa in the kernel use an and with 0xff to ensure the reuslt is always a IPv4 Address, so in this aspect, it's better than that in the userland. I really agree with you that the use of a hard-coded macro is a bad idea. It's still confusing and less portable than that calculated by the compiler. From owner-freebsd-net@FreeBSD.ORG Sat Nov 11 04:50:05 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCDAD16A403; Sat, 11 Nov 2006 04:50:05 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from ms-smtp-01.southeast.rr.com (ms-smtp-01.southeast.rr.com [24.25.9.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49EC943D68; Sat, 11 Nov 2006 04:50:05 +0000 (GMT) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (cpe-024-211-118-154.sc.res.rr.com [24.211.118.154]) by ms-smtp-01.southeast.rr.com (8.13.6/8.13.6) with ESMTP id kAB4o1wF003993; Fri, 10 Nov 2006 23:50:02 -0500 (EST) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.13.8/8.13.8) with ESMTP id kAB4nv6u030272; Fri, 10 Nov 2006 23:49:59 -0500 (EST) (envelope-from morganw@chemikals.org) Date: Fri, 10 Nov 2006 23:49:57 -0500 (EST) From: Wesley Morgan To: Florent Thoumie In-Reply-To: Message-ID: <20061110234827.C19234@volatile.chemikals.org> References: <1162993001.4305.37.camel@massimo.datacode.it> <4553A000.7070407@FreeBSD.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1276279953-1163220597=:19234" X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: Massimo Lusetti , =?iso-8859-1?Q?G=E1bor_K=F6vesd=E1n?= , net@freebsd.org Subject: Re: New wpi driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2006 04:50:05 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1276279953-1163220597=:19234 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 10 Nov 2006, Florent Thoumie wrote: > > On Nov 9, 2006, at 9:39 PM, Gábor Kövesdán wrote: > >> Florent Thoumie wrote: >>> On Nov 8, 2006, at 1:36 PM, Massimo Lusetti wrote: >>> >>>> Hi all, >>>> I'm pleased to tell you i got the latest wpi driver from Damien >>>> Bergamini to work properly on a latest -stable on an Acer laptop. >>> >>> Nice work! >> Unfortunately, it seems that this is still that unfinished driver from >> Damien, that circulates on the net everywhere, but it only works for some >> lucky people. As for me, I get an error message when loading the module, >> that it could not allocate resources. > > Haven't taken my 3945 "powered" laptop in Milan, so I haven't had the chance > to try it yet. Is it the same as the one we can find in deischen public space > on freefall? It's very similar to the version I already had, the diff is maybe 10 lines. I realize the driver itself is beta, but I have also found the 3945 "card" to be a general piece of crap compared to my atheros pccard in terms of throughput and stability (in both windows and freebsd). -- This .signature sanitized for your protection --0-1276279953-1163220597=:19234-- From owner-freebsd-net@FreeBSD.ORG Sat Nov 11 06:42:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59F5116A40F; Sat, 11 Nov 2006 06:42:43 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A946243D6A; Sat, 11 Nov 2006 06:42:40 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kAB6gXjO056329; Fri, 10 Nov 2006 23:42:38 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <455570D8.6070000@samsco.org> Date: Fri, 10 Nov 2006 23:42:32 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Mike Tancsa References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> In-Reply-To: <200611102221.kAAML6ol028630@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ADVANCE_FEE_1,ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2006 06:42:43 -0000 Mike Tancsa wrote: > At 05:00 PM 11/10/2006, Jack Vogel wrote: >> On 11/10/06, Mike Tancsa wrote: >>> >>> Some more tests. I tried again with what was committed to today's >>> RELENG_6. I am guessing its pretty well the same patch. Polling is >>> the only way to avoid livelock at a high pps rate. Does anyone know >>> of any simple tools to measure end to end packet loss ? Polling will >>> end up dropping some packets and I want to be able to compare. Same >>> hardware from the previous post. >> >> The commit WAS the last patch I posted. SO, making sure I understood you, >> you are saying that POLLING is doing better than FAST_INTR, or only >> better than the legacy code that went in with my merge? > > Hi, > The last set of tests I posted are ONLY with what is in today's > RELENG_6-- i.e. the latest commit. I did a few variations on the > driver-- first with > #define EM_FAST_INTR 1 > in if_em.c > > one without > > and one with polling in the kernel. > > With a decent packet rate passing through, the box will lockup. Not > sure if I am just hitting the limits of the PCIe bus, or interrupt > moderation is not kicking in, or this is a case of "Doctor, it hurts > when I send a lot of packets through"... "Well, dont do that" > > Using polling prevents the lockup, but it will of course drop packets. > This is for firewalls with a fairly high bandwidth rate, as well as I > need it to be able to survive a decent DDoS attack. I am not looking > for 1Mpps, but something more than 100Kpps > > ---Mike Hi, Thanks for all of the data. I know that a good amount of testing was done with single stream stress tests, but it's not clear how much was done with multiple streams prior to your efforts. So, I'm not terribly surprised by your results. I'm still a bit unclear on the exact topology of your setup, so if could explain it some more in private email, I'd appreciate it. For the short term, I don't think that there is anything that can be magically tweaked that will safely give better results. I know that Gleb has some ideas on a fairly simple change for the non-INTR_FAST, non-POLLING case, but I and several others worry that it's not robust in the face of real-world network problems. For the long term, I have a number of ideas for improving both the RX and TX paths in the driver. Some of it is specific to the if_em driver, some involve improvements in the FFWD and PFIL_HOOKS code as well as the driver. What will help me is if you can hook up a serial console to your machine and see if it can be made to drop to the debugger while it is under load and otherwise unresponsive. If you can, getting a process dump might help confirm where each CPU is spending its time. Scott From owner-freebsd-net@FreeBSD.ORG Sat Nov 11 07:08:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55B5316A47C for ; Sat, 11 Nov 2006 07:08:43 +0000 (UTC) (envelope-from clay@milos.co.za) Received: from bart.milos.co.za (bart.milos.co.za [196.38.18.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4861343D5E for ; Sat, 11 Nov 2006 07:08:40 +0000 (GMT) (envelope-from clay@milos.co.za) Received: (qmail 8049 invoked by uid 89); 11 Nov 2006 07:08:38 -0000 Received: from unknown (HELO claylaptop) (clay@milos.za.net@192.168.3.254) by bart.milos.co.za with SMTP; 11 Nov 2006 07:08:38 -0000 Message-ID: <007d01c70560$356577b0$9603a8c0@claylaptop> From: "Clayton Milos" To: References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com><200611091536.kA9FaltD018819@lava.sentex.ca><45534E76.6020906@samsco.org><200611092200.kA9M0q1E020473@lava.sentex.ca><200611102004.kAAK4iO9027778@lava.sentex.ca><2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com><200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> Date: Sat, 11 Nov 2006 09:08:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Cc: freebsd-net , Scott Long , Jack Vogel , Mike Tancsa Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2006 07:08:43 -0000 ----- Original Message ----- From: "Scott Long" To: "Mike Tancsa" Cc: "freebsd-net" ; ; ; "Jack Vogel" Sent: Saturday, November 11, 2006 8:42 AM Subject: Re: Proposed 6.2 em RELEASE patch > Mike Tancsa wrote: >> At 05:00 PM 11/10/2006, Jack Vogel wrote: >>> On 11/10/06, Mike Tancsa wrote: >>>> >>>> Some more tests. I tried again with what was committed to today's >>>> RELENG_6. I am guessing its pretty well the same patch. Polling is >>>> the only way to avoid livelock at a high pps rate. Does anyone know >>>> of any simple tools to measure end to end packet loss ? Polling will >>>> end up dropping some packets and I want to be able to compare. Same >>>> hardware from the previous post. >>> >>> The commit WAS the last patch I posted. SO, making sure I understood >>> you, >>> you are saying that POLLING is doing better than FAST_INTR, or only >>> better than the legacy code that went in with my merge? >> >> Hi, >> The last set of tests I posted are ONLY with what is in today's >> RELENG_6-- i.e. the latest commit. I did a few variations on the driver-- >> first with >> #define EM_FAST_INTR 1 >> in if_em.c >> >> one without >> >> and one with polling in the kernel. >> >> With a decent packet rate passing through, the box will lockup. Not sure >> if I am just hitting the limits of the PCIe bus, or interrupt moderation >> is not kicking in, or this is a case of "Doctor, it hurts when I send a >> lot of packets through"... "Well, dont do that" >> >> Using polling prevents the lockup, but it will of course drop packets. >> This is for firewalls with a fairly high bandwidth rate, as well as I >> need it to be able to survive a decent DDoS attack. I am not looking for >> 1Mpps, but something more than 100Kpps >> >> ---Mike > > Hi, > > Thanks for all of the data. I know that a good amount of testing was > done with single stream stress tests, but it's not clear how much was > done with multiple streams prior to your efforts. So, I'm not terribly > surprised by your results. I'm still a bit unclear on the exact > topology of your setup, so if could explain it some more in private > email, I'd appreciate it. > > For the short term, I don't think that there is anything that can be > magically tweaked that will safely give better results. I know that > Gleb has some ideas on a fairly simple change for the non-INTR_FAST, > non-POLLING case, but I and several others worry that it's not robust > in the face of real-world network problems. > > For the long term, I have a number of ideas for improving both the RX > and TX paths in the driver. Some of it is specific to the if_em driver, > some involve improvements in the FFWD and PFIL_HOOKS code as well as the > driver. What will help me is if you can hook up a serial console to > your machine and see if it can be made to drop to the debugger while it > is under load and otherwise unresponsive. If you can, getting a process > dump might help confirm where each CPU is spending its time. > > Scott I applied Jack's patch to the em driver and all seemed well until xl was giving me the same issues. Thanks Jack on my machine your first patch looks 100% Since my box does not take too much load and to me a slightly more loaded machine is better than an unstable one i re-complied the kernel without SMP so I have a dual CPU system with only one of the CPU's working. I've smacked it with about 50G of data using samba and FTP and it didn't blink. I am however using a fxp card for the live IP side but the xl's are still in the kernel and getting picked up. I have just not configured them with IP's for traffic. I don't think this is the issue tho. I'd say there's something to do with the SMP code that is causing these issues. I have another box with SMP on it. Same kind of setup with a Tyan Tiger instead of a Thunder motherboard. 2 Fxp NICs in it. Most of the time it's stable but if i throw a lot of traffic at it it locks up too. Next time it does I will post the console message, but there is no warnings about watchdog timeouts far as I can remember. It's running 5.5-RELEASE-p8 with SMP enabled. -Clay From owner-freebsd-net@FreeBSD.ORG Sat Nov 11 10:06:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30AFF16A403 for ; Sat, 11 Nov 2006 10:06:48 +0000 (UTC) (envelope-from misho@interbgc.com) Received: from mail.interbgc.com (mx01.cablebg.net [217.9.224.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 69BFF43D4C for ; Sat, 11 Nov 2006 10:06:46 +0000 (GMT) (envelope-from misho@interbgc.com) Received: (qmail 31298 invoked from network); 11 Nov 2006 10:06:45 -0000 Received: from misho@interbgc.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(0.0/8.0):. Processed in 1.908091 secs); 11 Nov 2006 10:06:45 -0000 X-Spam-Status: No, hits=0.0 required=8.0 Received: from 85-130-33-242.1698539.ddns.cablebg.net (HELO misho) (85.130.33.242) by mx01.interbgc.com with SMTP; 11 Nov 2006 10:06:43 -0000 Message-ID: <001701c70579$16b152d0$f2218255@misho> From: "Mihail Balikov" To: "Scott Long" References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com><200611091536.kA9FaltD018819@lava.sentex.ca><45534E76.6020906@samsco.org><200611092200.kA9M0q1E020473@lava.sentex.ca><200611102004.kAAK4iO9027778@lava.sentex.ca><2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com><200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> Date: Sat, 11 Nov 2006 12:06:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Cc: freebsd-net , Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mihail Balikov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2006 10:06:48 -0000 Our routers are with 2 em NICs, doing about 100kkps. Without kernel polling system become unstable, it seems that default interrupts moderation on em is 10000 intr/sec. I have made some modification in kernel to decrease packet drops when polling is enabled - modify clock routines to allow high clock rate only for polling (5000 polls/sec) - remove netisr_poll_more - loop in ether_poll() untill there's ready packets Small optimization in em(): - add CSUM_IP checksum offloading on transmit - call em_txeof if there's more than 32 busy packet - remove E1000_TXD_CMD_RS (Report Status) and check (TDH == adapter->oldest_used_tx_desc). This should reduce PCI overhead, but adds one more PCI read on every em_txoef() call. OS: FreeBSD 4.11, em() is almost up to date with HEAD. ----- Original Message ----- From: "Scott Long" To: "Mike Tancsa" Cc: "freebsd-net" ; ; "Jack Vogel" Sent: Saturday, November 11, 2006 8:42 AM Subject: Re: Proposed 6.2 em RELEASE patch > Mike Tancsa wrote: > > At 05:00 PM 11/10/2006, Jack Vogel wrote: > >> On 11/10/06, Mike Tancsa wrote: > >>> > >>> Some more tests. I tried again with what was committed to today's > >>> RELENG_6. I am guessing its pretty well the same patch. Polling is > >>> the only way to avoid livelock at a high pps rate. Does anyone know > >>> of any simple tools to measure end to end packet loss ? Polling will > >>> end up dropping some packets and I want to be able to compare. Same > >>> hardware from the previous post. > >> > >> The commit WAS the last patch I posted. SO, making sure I understood you, > >> you are saying that POLLING is doing better than FAST_INTR, or only > >> better than the legacy code that went in with my merge? > > > > Hi, > > The last set of tests I posted are ONLY with what is in today's > > RELENG_6-- i.e. the latest commit. I did a few variations on the > > driver-- first with > > #define EM_FAST_INTR 1 > > in if_em.c > > > > one without > > > > and one with polling in the kernel. > > > > With a decent packet rate passing through, the box will lockup. Not > > sure if I am just hitting the limits of the PCIe bus, or interrupt > > moderation is not kicking in, or this is a case of "Doctor, it hurts > > when I send a lot of packets through"... "Well, dont do that" > > > > Using polling prevents the lockup, but it will of course drop packets. > > This is for firewalls with a fairly high bandwidth rate, as well as I > > need it to be able to survive a decent DDoS attack. I am not looking > > for 1Mpps, but something more than 100Kpps > > > > ---Mike > > Hi, > > Thanks for all of the data. I know that a good amount of testing was > done with single stream stress tests, but it's not clear how much was > done with multiple streams prior to your efforts. So, I'm not terribly > surprised by your results. I'm still a bit unclear on the exact > topology of your setup, so if could explain it some more in private > email, I'd appreciate it. > > For the short term, I don't think that there is anything that can be > magically tweaked that will safely give better results. I know that > Gleb has some ideas on a fairly simple change for the non-INTR_FAST, > non-POLLING case, but I and several others worry that it's not robust > in the face of real-world network problems. > > For the long term, I have a number of ideas for improving both the RX > and TX paths in the driver. Some of it is specific to the if_em driver, > some involve improvements in the FFWD and PFIL_HOOKS code as well as the > driver. What will help me is if you can hook up a serial console to > your machine and see if it can be made to drop to the debugger while it > is under load and otherwise unresponsive. If you can, getting a process > dump might help confirm where each CPU is spending its time. > > Scott > _______________________________________________ > 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" > From owner-freebsd-net@FreeBSD.ORG Sat Nov 11 11:47:17 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E315416A40F for ; Sat, 11 Nov 2006 11:47:17 +0000 (UTC) (envelope-from niki@totalterror.net) Received: from sellinet.net (galileo.sellinet.net [82.199.192.2]) by mx1.FreeBSD.org (Postfix) with SMTP id E596C43D58 for ; Sat, 11 Nov 2006 11:47:16 +0000 (GMT) (envelope-from niki@totalterror.net) Received: (qmail 26690 invoked by uid 1009); 11 Nov 2006 13:47:14 +0200 Received: from niki@totalterror.net by galileo by uid 1002 with qmail-scanner-1.22 (spamassassin: 3.0.3. Clear:RC:1(82.199.197.152):. Processed in 0.049931 secs); 11 Nov 2006 11:47:14 -0000 Received: from unknown (HELO tormentor.totalterror.net) (82.199.197.152) by galileo.sellinet.net with SMTP; 11 Nov 2006 13:47:14 +0200 Received: (qmail 44021 invoked from network); 11 Nov 2006 11:47:13 -0000 Received: from qmail by qscan (mail filter); 11 Nov 2006 11:47:13 +0000 Received: from unknown (HELO ?10.0.0.3?) (10.0.0.3) by tormentor.totalterror.net with SMTP; 11 Nov 2006 11:47:13 -0000 Message-ID: <4555B841.4030105@totalterror.net> Date: Sat, 11 Nov 2006 13:47:13 +0200 From: Nikolay Denev User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: pf table synchronization between redundant routers (pfsync?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2006 11:47:18 -0000 Hi all, I'm thinking about adding support for pfsync to synchronize pf tables, so it can be used on redundant firewalls/routers setup. At first glance it looks fairly simple, just send/receive a message containing the table name, the prefix, and the action "add" or "remove". Has anyone tried something like this? The other thing that comes to my mind is for example a patched routed, that will work on pftables, instead of the kernel routing table? P.S: I know about pftabled, but i'm searching about different solution. -- Niki From owner-freebsd-net@FreeBSD.ORG Sat Nov 11 12:05:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 345F016A47C; Sat, 11 Nov 2006 12:05:18 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FD1D43D5D; Sat, 11 Nov 2006 12:05:12 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kABC5BfX013224; Sat, 11 Nov 2006 07:05:11 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kABC59gP032197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Nov 2006 07:05:09 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611111205.kABC59gP032197@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 11 Nov 2006 07:05:17 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <455570D8.6070000@samsco.org> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2006 12:05:18 -0000 At 01:42 AM 11/11/2006, Scott Long wrote: >surprised by your results. I'm still a bit unclear on the exact >topology of your setup, so if could explain it some more in private >email, I'd appreciate it. Hi, I made a quick diagram of the test setup that should make it more clear http://www.tancsa.com/blast.jpg Basically 5 boxes (plus my workstation for out of band access), the main one being tested is the box marked R2 which has a 2 port PCIe em NIC (Pro 1000PT) in the motherboard's 4X slot. I have 2 test boxes as UDP senders and 2 test boxes as UDP receivers, and all the packets flow through the 2 interfaces of R2. With one stream of packets being blasted across, the box is dropping some packets even on its OOB management interface. With 2, its totally unresponsive. Only with polling am I able to continue to work on the box via the OOB interface while one and even 2 streams of UDP packets are blasting across. However, in polling mode some amount of packets are being dropped and I guess I need to better understand how many. My goal in all this is to have a firewall / router that can withstand a high pps workload that will still be reachable OOB when under attack or even under high workload. To measure how many packets are dropped I was looking at making a modified netreceive to count the packets it gets so I can test to see if polling mode will be adequate for my needs. Lets say the max pps the box can handle is X, either in polling or non polling modes. As the box approaches X and gets pushed beyond X, I guess the ideal situation for my needs would be that it drops some packets on the busiest interface so that it can still function and service its other needs, be that network, disk, whatever. But my question is, is X the same for polling and non polling modes. >For the short term, I don't think that there is anything that can be >magically tweaked that will safely give better results. I know that >Gleb has some ideas on a fairly simple change for the non-INTR_FAST, >non-POLLING case, but I and several others worry that it's not robust >in the face of real-world network problems. > >For the long term, I have a number of ideas for improving both the RX >and TX paths in the driver. Some of it is specific to the if_em driver, >some involve improvements in the FFWD and PFIL_HOOKS code as well as the >driver. What will help me is if you can hook up a serial console to >your machine and see if it can be made to drop to the debugger while it >is under load and otherwise unresponsive. If you can, getting a process >dump might help confirm where each CPU is spending its time. Yes, I will see what I can do over the weekend. I have some changes to babysit again tomorrow night and will see what I can do between cycles. ---Mike