From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 19 04:50:24 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 055AF16A422; Sun, 19 Feb 2006 04:50:24 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A9F143D45; Sun, 19 Feb 2006 04:50:22 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp143-122.lns2.adl2.internode.on.net [59.167.143.122]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k1J4o7Uc031712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Feb 2006 15:20:13 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Sun, 19 Feb 2006 15:00:03 +1030 User-Agent: KMail/1.9.1 References: <20060218.102145.26324437.imp@bsdimp.com> <20060218225139.V58463@mp2.macomnet.net> In-Reply-To: <20060218225139.V58463@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3425472.HfHhdacoDR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200602191500.05171.doconnor@gsoft.com.au> X-Spam-Score: -2.157 () AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: hackers@freebsd.org Subject: Re: Bad block -> file mapping X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2006 04:50:24 -0000 --nextPart3425472.HfHhdacoDR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 19 February 2006 06:26, Maxim Konovalov wrote: > > I know I need to get a new disk. In the mean time, I need to cope > > with these errors in a sane manner... > > May http://tinyurl.com/c7dr4 help? Ooh nice! Has anyone ported it? Looks like NetBSD's fsdb is structured pretty=20 differently. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3425472.HfHhdacoDR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD9/RN5ZPcIHs/zowRAoPAAKCgewtq5mUylloueBYOHrJEDp6X1wCcCmhz +bSdigyuWGayg/xnaSXQwl0= =a0RK -----END PGP SIGNATURE----- --nextPart3425472.HfHhdacoDR-- From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 19 04:50:24 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 055AF16A422; Sun, 19 Feb 2006 04:50:24 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A9F143D45; Sun, 19 Feb 2006 04:50:22 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp143-122.lns2.adl2.internode.on.net [59.167.143.122]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k1J4o7Uc031712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Feb 2006 15:20:13 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Sun, 19 Feb 2006 15:00:03 +1030 User-Agent: KMail/1.9.1 References: <20060218.102145.26324437.imp@bsdimp.com> <20060218225139.V58463@mp2.macomnet.net> In-Reply-To: <20060218225139.V58463@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3425472.HfHhdacoDR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200602191500.05171.doconnor@gsoft.com.au> X-Spam-Score: -2.157 () AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: hackers@freebsd.org Subject: Re: Bad block -> file mapping X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2006 04:50:24 -0000 --nextPart3425472.HfHhdacoDR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 19 February 2006 06:26, Maxim Konovalov wrote: > > I know I need to get a new disk. In the mean time, I need to cope > > with these errors in a sane manner... > > May http://tinyurl.com/c7dr4 help? Ooh nice! Has anyone ported it? Looks like NetBSD's fsdb is structured pretty=20 differently. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3425472.HfHhdacoDR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD9/RN5ZPcIHs/zowRAoPAAKCgewtq5mUylloueBYOHrJEDp6X1wCcCmhz +bSdigyuWGayg/xnaSXQwl0= =a0RK -----END PGP SIGNATURE----- --nextPart3425472.HfHhdacoDR-- From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 19 10:54:44 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C77D616A420 for ; Sun, 19 Feb 2006 10:54:44 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id F29BF43D48 for ; Sun, 19 Feb 2006 10:54:43 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.4/8.13.3) with ESMTP id k1JAsdIZ012318 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 19 Feb 2006 11:54:39 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.4/8.13.3/Submit) id k1JAscUu012316 for hackers@freebsd.org; Sun, 19 Feb 2006 11:54:38 +0100 (CET) Date: Sun, 19 Feb 2006 11:54:38 +0100 From: Divacky Roman To: hackers@freebsd.org Message-ID: <20060219105438.GA12265@stud.fit.vutbr.cz> References: <20060218171718.GA73133@stud.fit.vutbr.cz> <20060218172152.GB11874@britannica.bec.de> <20060218173908.GA73913@stud.fit.vutbr.cz> <20060218214329.GF69162@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060218214329.GF69162@funkthat.com> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 Cc: Subject: Re: different behaviour on fbsd and linux X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2006 10:54:44 -0000 On Sat, Feb 18, 2006 at 01:43:30PM -0800, John-Mark Gurney wrote: > Divacky Roman wrote this message on Sat, Feb 18, 2006 at 18:39 +0100: > > On Sat, Feb 18, 2006 at 06:21:52PM +0100, joerg@britannica.bec.de wrote: > > > On Sat, Feb 18, 2006 at 06:17:18PM +0100, Divacky Roman wrote: > > > > execl("/bin/ls", NULL); > > > > > > This is wrong. You must specify arg0 != NULL (POSIX says so) and you > > > must NULL-terminate the *following* list. > > > > > > E.g.: > > > execl("/bin/ls", "/bin/ls", NULL); > > > is what you want to do. > > > > > > ah.. thnx.. the man page should be updated with "he > > first argument, by convention, should point to the file name associated > > with the file being executed." > > > > s/should/must then > > Nope.. it need not be the same.. in cases like this: > execl("/usr/bin/gzip", "gunzip", NULL); > > will give you gunzip behavior because the gzip binary looks at argv[0] > and changes it's behavior based upon what it finds.. look at crunchgen > for the ability to combine different programs into one binary... ok.. but I'd appreciate info that it cannot be NULL ;( From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 19 11:30:04 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AE3B16A420 for ; Sun, 19 Feb 2006 11:30:04 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id 652FD43D46 for ; Sun, 19 Feb 2006 11:30:02 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: from falcon.midgard.homeip.net (83.253.29.241) by pne-smtpout2-sn1.fre.skanova.net (7.2.070) id 43EC2A6A002199B3 for hackers@freebsd.org; Sun, 19 Feb 2006 12:30:01 +0100 Received: (qmail 12712 invoked by uid 1001); 19 Feb 2006 12:30:01 +0100 Date: Sun, 19 Feb 2006 12:30:01 +0100 From: Erik Trulsson To: Divacky Roman Message-ID: <20060219113001.GA12683@falcon.midgard.homeip.net> Mail-Followup-To: Divacky Roman , hackers@freebsd.org References: <20060218171718.GA73133@stud.fit.vutbr.cz> <20060218172152.GB11874@britannica.bec.de> <20060218173908.GA73913@stud.fit.vutbr.cz> <20060218214329.GF69162@funkthat.com> <20060219105438.GA12265@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060219105438.GA12265@stud.fit.vutbr.cz> User-Agent: Mutt/1.5.11 Cc: hackers@freebsd.org Subject: Re: different behaviour on fbsd and linux X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2006 11:30:04 -0000 On Sun, Feb 19, 2006 at 11:54:38AM +0100, Divacky Roman wrote: > On Sat, Feb 18, 2006 at 01:43:30PM -0800, John-Mark Gurney wrote: > > Divacky Roman wrote this message on Sat, Feb 18, 2006 at 18:39 +0100: > > > On Sat, Feb 18, 2006 at 06:21:52PM +0100, joerg@britannica.bec.de wrote: > > > > On Sat, Feb 18, 2006 at 06:17:18PM +0100, Divacky Roman wrote: > > > > > execl("/bin/ls", NULL); > > > > > > > > This is wrong. You must specify arg0 != NULL (POSIX says so) and you > > > > must NULL-terminate the *following* list. > > > > > > > > E.g.: > > > > execl("/bin/ls", "/bin/ls", NULL); > > > > is what you want to do. > > > > > > > > > ah.. thnx.. the man page should be updated with "he > > > first argument, by convention, should point to the file name associated > > > with the file being executed." > > > > > > s/should/must then > > > > Nope.. it need not be the same.. in cases like this: > > execl("/usr/bin/gzip", "gunzip", NULL); > > > > will give you gunzip behavior because the gzip binary looks at argv[0] > > and changes it's behavior based upon what it finds.. look at crunchgen > > for the ability to combine different programs into one binary... > > ok.. but I'd appreciate info that it cannot be NULL ;( It is in the manpage if you read carefully. execl(8) says: [...] int execl(const char *path, const char *arg, ... /*, (char *)0 */); [...] The const char *arg and subsequent ellipses in the execl(), execlp(), and execle() functions can be thought of as arg0, arg1, ..., argn. Together they describe a list of one or more pointers to null-terminated strings that represent the argument list available to the executed program. The first argument, by convention, should point to the file name associated with the file being executed. The list of arguments must be terminated by a NULL pointer. [...] Note that it says "one or more pointers to null-terminated strings". NULL is not a pointer to a null-terminated string, which means that you must have at least one non-NULL pointer before the teminating NULL. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 19 16:59:50 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D23E816A420 for ; Sun, 19 Feb 2006 16:59:50 +0000 (GMT) (envelope-from bachi@te-clan.ch) Received: from te-clan.ch (ns1.te-clan.ch [217.118.194.40]) by mx1.FreeBSD.org (Postfix) with SMTP id 1AE0643D45 for ; Sun, 19 Feb 2006 16:59:49 +0000 (GMT) (envelope-from bachi@te-clan.ch) Received: (qmail 35648 invoked from network); 19 Feb 2006 16:58:54 -0000 Received: from unknown (HELO ?10.0.0.241?) (80.219.57.164) by te-clan.ch with SMTP; 19 Feb 2006 16:58:54 -0000 From: Andreas Bachmann To: hackers@freebsd.org Content-Type: text/plain Date: Sun, 19 Feb 2006 17:59:47 +0100 Message-Id: <1140368387.28785.63.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Subject: dladdr in executable and shared object X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2006 16:59:51 -0000 Hello! Want to have a runtime stacktrace like in a java environment. Why will dladdr get an incorrect dli_fname, when I execute a standalone (without shared object) program? http://bachi.te-clan.ch/freebsd/i386-freebsd-backtrace.c http://bachi.te-clan.ch/freebsd/i386-freebsd-backtrace.result When I create a shared object and link it with a executable, all functions in the shared object will be resolved, but all other functions will get an incorrect result. http://bachi.te-clan.ch/freebsd/i386-freebsd-backtrace-lib.c http://bachi.te-clan.ch/freebsd/i386-freebsd-backtrace-load.c http://bachi.te-clan.ch/freebsd/i386-freebsd-backtrace-lib.result In solaris also standalone programs will get correct dli_fname... http://bachi.te-clan.ch/freebsd/sparc-solaris-backtrace.c http://bachi.te-clan.ch/freebsd/sparc-solaris-backtrace.result I think the whole dynamic linking functions are buggy. dlsym will also not work. http://bachi.te-clan.ch/freebsd/i386-freebsd-dlsym.c http://bachi.te-clan.ch/freebsd/i386-freebsd-dlsym.result Is this a gap and will be implemented/fixed? Are there other functions to translate addresses to symbols on runtime? greets Andreas From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 19 17:22:33 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4E0216A420; Sun, 19 Feb 2006 17:22:33 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4338143D45; Sun, 19 Feb 2006 17:22:33 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (unknown [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id 9C58535707; Sun, 19 Feb 2006 18:22:27 +0100 (CET) Received: by britannica.bec.de (Postfix, from userid 1000) id 0BA1C6C771; Sun, 19 Feb 2006 18:22:23 +0100 (CET) Date: Sun, 19 Feb 2006 18:22:23 +0100 From: joerg@britannica.bec.de To: freebsd-hackers@freebsd.org, hackers@freebsd.org Message-ID: <20060219172223.GA12772@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <1140368387.28785.63.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1140368387.28785.63.camel@localhost> User-Agent: Mutt/1.5.11 Cc: Subject: Re: dladdr in executable and shared object X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2006 17:22:33 -0000 On Sun, Feb 19, 2006 at 05:59:47PM +0100, Andreas Bachmann wrote: > I think the whole dynamic linking functions are buggy. First of all, calm down. Second, do your home work. By default the necessary dynamic linkage section is not present in executables, only shared libraries. Try -Wl,-E instead. Joerg From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 19 17:22:33 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4E0216A420; Sun, 19 Feb 2006 17:22:33 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4338143D45; Sun, 19 Feb 2006 17:22:33 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (unknown [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id 9C58535707; Sun, 19 Feb 2006 18:22:27 +0100 (CET) Received: by britannica.bec.de (Postfix, from userid 1000) id 0BA1C6C771; Sun, 19 Feb 2006 18:22:23 +0100 (CET) Date: Sun, 19 Feb 2006 18:22:23 +0100 From: joerg@britannica.bec.de To: freebsd-hackers@freebsd.org, hackers@freebsd.org Message-ID: <20060219172223.GA12772@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <1140368387.28785.63.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1140368387.28785.63.camel@localhost> User-Agent: Mutt/1.5.11 Cc: Subject: Re: dladdr in executable and shared object X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2006 17:22:33 -0000 On Sun, Feb 19, 2006 at 05:59:47PM +0100, Andreas Bachmann wrote: > I think the whole dynamic linking functions are buggy. First of all, calm down. Second, do your home work. By default the necessary dynamic linkage section is not present in executables, only shared libraries. Try -Wl,-E instead. Joerg From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 19 21:45:36 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0D4216A420 for ; Sun, 19 Feb 2006 21:45:36 +0000 (GMT) (envelope-from bachi@te-clan.ch) Received: from te-clan.ch (ns1.te-clan.ch [217.118.194.40]) by mx1.FreeBSD.org (Postfix) with SMTP id 03A5843D48 for ; Sun, 19 Feb 2006 21:45:35 +0000 (GMT) (envelope-from bachi@te-clan.ch) Received: (qmail 36306 invoked from network); 19 Feb 2006 21:44:40 -0000 Received: from unknown (HELO ?10.0.0.241?) (80.219.57.164) by te-clan.ch with SMTP; 19 Feb 2006 21:44:40 -0000 From: Andreas Bachmann To: hackers@freebsd.org In-Reply-To: <20060219172223.GA12772@britannica.bec.de> References: <1140368387.28785.63.camel@localhost> <20060219172223.GA12772@britannica.bec.de> Content-Type: text/plain Date: Sun, 19 Feb 2006 22:45:27 +0100 Message-Id: <1140385527.28785.76.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Subject: Re: dladdr in executable and shared object X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2006 21:45:36 -0000 Hi Joerg Ahh... Thank you. When I compile with the Sun Compiler, the dynamic linking section will be present by default. In the GNU compiler, as you wrote, it must be explicit specific. Andreas On Sun, 2006-02-19 at 18:22 +0100, joerg@britannica.bec.de wrote: > On Sun, Feb 19, 2006 at 05:59:47PM +0100, Andreas Bachmann wrote: > > I think the whole dynamic linking functions are buggy. > > First of all, calm down. Second, do your home work. > By default the necessary dynamic linkage section is not present in > executables, only shared libraries. Try -Wl,-E instead. > > Joerg > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 17:27:35 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E978016A420 for ; Mon, 20 Feb 2006 17:27:35 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D45A43D53 for ; Mon, 20 Feb 2006 17:27:34 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.4/8.13.3) with ESMTP id k1KHRUoF061942 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 20 Feb 2006 18:27:30 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.4/8.13.3/Submit) id k1KHRUUc061941 for hackers@freebsd.org; Mon, 20 Feb 2006 18:27:30 +0100 (CET) Date: Mon, 20 Feb 2006 18:27:30 +0100 From: Divacky Roman To: hackers@freebsd.org Message-ID: <20060220172730.GA61906@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 Cc: Subject: LDFLAGS setting X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2006 17:27:36 -0000 hi is is possible to set global LDFLAGS as its possible with CFLAGS? thnx roman From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 17:43:42 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A965416A422 for ; Mon, 20 Feb 2006 17:43:41 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2469243D7C for ; Mon, 20 Feb 2006 17:43:32 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) (authenticated bits=128) by igloo.linux.gr (8.13.5/8.13.5/Debian-3) with ESMTP id k1KHh94f007703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Feb 2006 19:43:13 +0200 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id k1KHgpR8035606; Mon, 20 Feb 2006 19:42:51 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id k1KHgpiO035605; Mon, 20 Feb 2006 19:42:51 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Mon, 20 Feb 2006 19:42:50 +0200 From: Giorgos Keramidas To: Divacky Roman Message-ID: <20060220174250.GA35343@flame.pc> References: <20060220172730.GA61906@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060220172730.GA61906@stud.fit.vutbr.cz> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.359, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.84, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr Cc: hackers@freebsd.org Subject: Re: LDFLAGS setting X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2006 17:43:43 -0000 On 2006-02-20 18:27, Divacky Roman wrote: > hi > > is is possible to set global LDFLAGS as its possible with CFLAGS? Yes, but why would you want to do this? It is very likely to create dependencies with libraries that are not really used by all programs. From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 17:39:07 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 552E916A4A6 for ; Mon, 20 Feb 2006 17:39:07 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from viefep12-int.chello.at (viefep12-int.chello.at [213.46.255.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23C2743D49 for ; Mon, 20 Feb 2006 17:39:05 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from [192.168.2.186] (really [80.98.231.227]) by viefep12-int.chello.at (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20060220173903.ICGC24993.viefep12-int.chello.at@[192.168.2.186]>; Mon, 20 Feb 2006 18:39:03 +0100 Message-ID: <43F9FEB5.7020106@t-hosting.hu> Date: Mon, 20 Feb 2006 18:39:01 +0100 From: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Divacky Roman References: <20060220172730.GA61906@stud.fit.vutbr.cz> In-Reply-To: <20060220172730.GA61906@stud.fit.vutbr.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 20 Feb 2006 17:51:29 +0000 Cc: hackers@freebsd.org Subject: Re: LDFLAGS setting X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2006 17:39:07 -0000 Divacky Roman wrote: >hi > >is is possible to set global LDFLAGS as its possible with CFLAGS? > >thnx > >roman > > > Yes, set it as you set CFLAGS in make.conf, but it depends on the particular software whether it respects this macro or not. If this doesn't work for a software, you have to dig in the Makefile and set LDFLAGS there to enforce your custom LDFLAGS. Anyway, you can set any macro in make.conf and the whole content of the file will be exported when running make, but note that this happens before processing a particular Makefile, so Makefiles can override your make.conf. Look at any Makefile. It'll override LDFLAGS if you find a line like this: LDFLAGS=-bla -bla And your make.conf will get priority if you see this: LDFLAGS?=-bla -bla There is also a third case. In this case these parameters will be appended to your default: LDFLAGS+=-bla -bla Gabor Kovesdan From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 21:53:45 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A469F16A420; Mon, 20 Feb 2006 21:53:45 +0000 (GMT) (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 4237243D46; Mon, 20 Feb 2006 21:53:40 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k1KLrcDi082670; Mon, 20 Feb 2006 14:53:38 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43FA3A6D.4010903@samsco.org> Date: Mon, 20 Feb 2006 14:53:49 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: re@freebsd.org Subject: FreeBSD 6.1-BETA2/FreeBSD 5.5-BETA2 Available X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2006 21:53:45 -0000 Announcement ------------ The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 6.1-BETA2 and FreeBSD 5.5-BETA2. Both FreeBSD 6.1 and FreeBSD 5.5 are meant to be a refinement of their respective branches with few dramatic changes. A lot of bugfixes have been made, some drivers have been updated, and some areas have been tweaked for better performance, etc. but no large changes have been made to the basic architecture. The FreeBSD 5.5 Release is being done for people who are unable to make the jump to FreeBSD 6.X at this time. We do encourage people to make that transition as soon as possible, though. There have been some updates made between FreeBSD 5.4 and FreeBSD 5.5 but not all of the bugfixes done to RELENG_6 have been backported to RELENG_5. This will almost certainly be the last 5.X release. We encourage people to help with testing so any final bugs can be identified and worked out. Availability of ISO images is given below. If you have an older system you want to update using the normal CVS/cvsup source based upgrade the branch tag to use is RELENG_6 for 6.1 and RELENG_5 for 5.5, though that will change later in the release cycle when we start doing the Release Candidates. Problem reports can be submitted using the send-pr(1) command. The list of open issues and things still being worked on are on the todo list: http://www.freebsd.org/releases/6.1R/todo.html http://www.freebsd.org/releases/5.5R/todo.html Known Issues ------------ The DHCP problem that affected the 6.1-BETA1 installer has been fixed. Several critical fixes were made to the ATA subsystem after the BETA2 builds started, so please check for newer updates before reporting problems. The Intel 2200/2915 Wireless is known to have a number of stability problems that are being worked on right now. Work is also in progress to make ht-plug of USB memory devices more reliable. Updated packages for all architectures might not be available yet. Availability ------------ The BETA2 ISOs and FTP support are available on most of the FreeBSD Mirror sites. A list of the mirror sites is available here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html The MD5s are: MD5 (5.5-BETA2-amd64-bootonly.iso) = a2333f7f2184e2899c7317202843fab6 MD5 (5.5-BETA2-amd64-disc1.iso) = 1c5efbe2276c94890a6e8efb152f55d5 MD5 (5.5-BETA2-amd64-disc2.iso) = bd1e55d73401d6160d2bc1eaef90348c MD5 (5.5-BETA2-i386-bootonly.iso) = 26fba5024002189a3d0bc8be58a62bc8 MD5 (5.5-BETA2-i386-disc1.iso) = 5fc65d29cd7139dadd20e207b16c81f1 MD5 (5.5-BETA2-i386-disc2.iso) = 24ca73eb276887fa5c90fa670e3b5e64 MD5 (5.5-BETA2-sparc64-bootonly.iso) = 8835b89782db79fe042b3d365c9e63ea MD5 (5.5-BETA2-sparc64-disc1.iso) = 58712a0f7e30e19bfdd52ca5961050db MD5 (5.5-BETA2-sparc64-disc2.iso) = 1e350504487f0f51fbe590eb830ad3f4 MD5 (5.5-BETA2-alpha-bootonly.iso) = 8ec56c534a22ee5a57af88b01fe3bf76 MD5 (5.5-BETA2-alpha-disc1.iso) = 9abd0f971d2928c95dfff8e0808bbc2c MD5 (5.5-BETA2-pc98-disc1.iso) = 92d7862ed1b77989fe1545346b9c2cef MD5 (6.1-BETA2-amd64-bootonly.iso) = c9d59cadf063e3a67626c1e5477b27bb MD5 (6.1-BETA2-amd64-disc1.iso) = e471a79dbcfbea829c8ab6caa9683e61 MD5 (6.1-BETA2-amd64-disc2.iso) = 29367aa8f31a4af3e49d110574f25319 MD5 (6.1-BETA2-i386-bootonly.iso) = cd77279cdf230e4b37c2d579d2a01cc1 MD5 (6.1-BETA2-i386-disc1.iso) = 3267d7794079d3b803f5f5f004cf04f1 MD5 (6.1-BETA2-i386-disc2.iso) = f47ad00c0240320661a78320befdeaa1 MD5 (6.1-BETA2-sparc64-bootonly.iso) = fc070774c0516391f7176518a0b0fabc MD5 (6.1-BETA2-sparc64-disc1.iso) = 540aa7abd4f51ea93138086f886e11de MD5 (6.1-BETA2-sparc64-disc2.iso) = 0d29f1554eb53a8748b9ec280868c460 MD5 (6.1-BETA2-alpha-bootonly.iso) = 923056c4b9c249f5393530ca62618aa6 MD5 (6.1-BETA2-alpha-disc1.iso) = fab96d1ee15340e5e8c639066f313751 MD5 (6.1-BETA2-pc98-disc1.iso) = 95be33fe72af53e9d6140b85385dc8c8 MD5 (6.1-BETA2-ia64-bootonly.iso) = 8eceddde4826e30480933cd05d306084 MD5 (6.1-BETA2-ia64-disc1.iso) = b034fce6098c6c203db379511174c729 MD5 (6.1-BETA2-ia64-livefs.iso) = 2592fa45458555862063b49e2946c16d The SHA256s are: SHA256 (5.5-BETA2-amd64-bootonly.iso) = 2616b50051eb8213877d4ba506b6f72f218870dffd40d1000b6d022d398d7f09 SHA256 (5.5-BETA2-amd64-disc1.iso) = 603a590632679cf3151ab183da4b53dde241e4990b335f396902cc5c5c5ff531 SHA256 (5.5-BETA2-amd64-disc2.iso) = 0834e6d5e024db45793ff92b4e436d5c466213bd05b6c1091380d58822c5fb0b SHA256 (5.5-BETA2-i386-bootonly.iso) = b5709ee350faf8010db5eac0db0639945045212bc3e3ac96ed42b3433d698b32 SHA256 (5.5-BETA2-i386-disc1.iso) = 012356396548d81840dbe004c5b125b1d5725e239728c920e41b786a539c67b9 SHA256 (5.5-BETA2-i386-disc2.iso) = 567d8321f609f99da8864a48b862a647ebc65ab9bb28b8b3f79a8d86cf108d9d SHA256 (5.5-BETA2-sparc64-bootonly.iso) = f713b1ba0eff3596b57ee22d629e4940e2a61eddf5bb207aa8597158be269851 SHA256 (5.5-BETA2-sparc64-disc1.iso) = 50375e00fb40d3e3d56dd6b2f3321916a5324f349ddb1c8e4ec904fd13eaa4e8 SHA256 (5.5-BETA2-sparc64-disc2.iso) = 0b502ddc7af1bc061ca102d265f5024006b8b70c0b892a32fcaa4d546a5d91d6 SHA256 (5.5-BETA2-alpha-bootonly.iso) = bf2010bdf6edf2b4a28459a420a011a6ed12182b8cc975dcd1d699ab5e41ee23 SHA256 (5.5-BETA2-alpha-disc1.iso) = 4b8923da0b3e589af36c33c40875c58b7f4657b5a3bee76007cb6f9515f9ba69 SHA256 (5.5-BETA2-pc98-disc1.iso) = 09dac64bf4b6087853a52e2bf9ac4f12399f0f82e9d08e6d1af35495e547ec28 SHA256 (6.1-BETA2-amd64-bootonly.iso) = 4ad1936fec7c0a31a034c0566e8082860e310cdf76284b3126fbdb38a9ce69d1 SHA256 (6.1-BETA2-amd64-disc1.iso) = 22149007427843fed8a015bf7a62f09c45f7396a65eb06cc179cad4cc049be70 SHA256 (6.1-BETA2-amd64-disc2.iso) = 91adbb123a76b59134a205634d1290b08cda94e5a05ac983fae7aa6dad341ee8 SHA256 (6.1-BETA2-i386-bootonly.iso) = c4cd8c60095361f343c007718b324dc755290006bd2dff32551a5243d76cad27 SHA256 (6.1-BETA2-i386-disc1.iso) = b5c3e06eb257c6d685c8834f6f25e02a13512450675c07a52c420c033da9e303 SHA256 (6.1-BETA2-i386-disc2.iso) = a2589767a19b18fd0a8d45f44d6a730c830ed821c89573d13c10356ea4bef59c SHA256 (6.1-BETA2-sparc64-bootonly.iso) = fa429ecfa8c8d69162c6c678b514d93a69a7b57fca53f618b98b446bacdcc951 SHA256 (6.1-BETA2-sparc64-disc1.iso) = a5d54609e783b6653be384eeaa820a00073531485fa77a6c8a80a8ef7639ee38 SHA256 (6.1-BETA2-sparc64-disc2.iso) = 0a522124bde19e8558637894ed7ec94fcd7e85ca094817dfcbc8a2992056aa90 SHA256 (6.1-BETA2-alpha-bootonly.iso) = a3dec79cf3057e5cf6717b60c8c0c1f572743d251d49f612b5e27f6c0a3f6cd0 SHA256 (6.1-BETA2-alpha-disc1.iso) = 608141f3211c86fddf70f3e3efe9d2d77e779a3755b9e9b1cd1b222130121dc0 SHA256 (6.1-BETA2-pc98-disc1.iso) = b7b2b7f38e4495cb69a39ca0bcb2901659e102b77826ac067626f97dacfb0dc1 SHA256 (6.1-BETA2-ia64-bootonly.iso) = 94b257e208bf8d0e2e3e968a7186a377e66de263a893f40a995969a2d88371ad SHA256 (6.1-BETA2-ia64-disc1.iso) = 36d29439851f4abc0c87e6b9e3400aeb6f2bad2ac43e152781333c39ee906b7e SHA256 (6.1-BETA2-ia64-livefs.iso) = b750064a2972571595ea82bc37e63819b9b8932d1dc657bff5e5eb6898bb0ca7 From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 21 09:23:28 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C14A516A420 for ; Tue, 21 Feb 2006 09:23:28 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id C200743D4C for ; Tue, 21 Feb 2006 09:23:27 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.4/8.13.3) with ESMTP id k1L9NOwe023907 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 21 Feb 2006 10:23:24 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.4/8.13.3/Submit) id k1L9NOjp023906 for hackers@freebsd.org; Tue, 21 Feb 2006 10:23:24 +0100 (CET) Date: Tue, 21 Feb 2006 10:23:24 +0100 From: Divacky Roman To: hackers@freebsd.org Message-ID: <20060221092324.GA23739@stud.fit.vutbr.cz> References: <20060220172730.GA61906@stud.fit.vutbr.cz> <20060220174250.GA35343@flame.pc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060220174250.GA35343@flame.pc> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 Cc: Subject: Re: LDFLAGS setting X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2006 09:23:28 -0000 On Mon, Feb 20, 2006 at 07:42:50PM +0200, Giorgos Keramidas wrote: > On 2006-02-20 18:27, Divacky Roman wrote: > > hi > > > > is is possible to set global LDFLAGS as its possible with CFLAGS? > > Yes, but why would you want to do this? It is very likely to create > dependencies with libraries that are not really used by all programs. I was just curious. man ld promises some optimizations and thats what I am interested in: LDFLAGS=-O1 --sort-common -z combreloc --relax but this doesnt seem to work with autoconf :( roman From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 21 12:26:08 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BC3616A422 for ; Tue, 21 Feb 2006 12:26:08 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C9B743D5F for ; Tue, 21 Feb 2006 12:26:04 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) (authenticated bits=128) by igloo.linux.gr (8.13.5/8.13.5/Debian-3) with ESMTP id k1LCPlG6022449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Feb 2006 14:25:55 +0200 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id k1LCPQXR024011; Tue, 21 Feb 2006 14:25:26 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id k1LCPQuw024010; Tue, 21 Feb 2006 14:25:26 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Tue, 21 Feb 2006 14:25:25 +0200 From: Giorgos Keramidas To: Divacky Roman Message-ID: <20060221122525.GB7564@flame.pc> References: <20060220172730.GA61906@stud.fit.vutbr.cz> <20060220174250.GA35343@flame.pc> <20060221092324.GA23739@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060221092324.GA23739@stud.fit.vutbr.cz> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.366, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.83, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr Cc: hackers@freebsd.org Subject: Re: LDFLAGS setting X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2006 12:26:08 -0000 On 2006-02-21 10:23, Divacky Roman wrote: >On Mon, Feb 20, 2006 at 07:42:50PM +0200, Giorgos Keramidas wrote: >>On 2006-02-20 18:27, Divacky Roman wrote: >>> hi >>> >>> is is possible to set global LDFLAGS as its possible with CFLAGS? >> >> Yes, but why would you want to do this? It is very likely to create >> dependencies with libraries that are not really used by all programs. > > I was just curious. man ld promises some optimizations and thats what I am > interested in: LDFLAGS=-O1 --sort-common -z combreloc --relax > > but this doesnt seem to work with autoconf :( That's a bug in the specific autoconf-based build infrastructure you are using LDFLAGS with. Autotools-based build processes are notorious for being complex, very convoluted and stupidly riddled with assumptions about what the current environment looks or works like. It's not very surprising that you found something that ignores LDFLAGS in the enrivonment :( From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 21 16:55:00 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55EE716A420 for ; Tue, 21 Feb 2006 16:55:00 +0000 (GMT) (envelope-from rea@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (rea.mbslab.kiae.ru [144.206.177.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC3F343D46 for ; Tue, 21 Feb 2006 16:54:59 +0000 (GMT) (envelope-from rea@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (localhost [127.0.0.1]) by rea.mbslab.kiae.ru (Postfix) with ESMTP id DDAB3BE5F for ; Tue, 21 Feb 2006 19:54:56 +0300 (MSK) Received: by rea.mbslab.kiae.ru (Postfix, from userid 1000) id BB5E9BDC6; Tue, 21 Feb 2006 19:54:56 +0300 (MSK) Date: Tue, 21 Feb 2006 19:54:56 +0300 From: FreeLSD To: hackers@freebsd.org Message-ID: <20060221165456.GZ44603@rea.mbslab.kiae.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: mutt-ng/devel-r581 (FreeBSD) X-AV-Checked: Yes! Cc: Subject: FreeBSD-6 and em interface speed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2006 16:55:00 -0000 Good day! I've obtained the following strang results with the em Ethernet interface speeds on a 6.1-PRERELEASE: Polling on: UDP stream to FreeBSD: 327843.84 Kbit/sec, TCP stream to FreeBSD: 524550.12 Kbit/sec. Polling off: UDP stream to FreeBSD: 740409.38 Kbit/sec, TCP stream to FreeBSD: 794348.44 Kbit/sec. It is funny that TCP speed is greater than UDP. It can be related to the hardware, not to the OS, because I've seen such behaviour on a linux-2.6. But on linux-2.4 with the same hardware as for FreeBSD and with the same source host I've got UDP stream to Linux: 927891.44 Kbit/sec, TCP stream to Linux: 850202.50 Kbit/sec. The figures are higher and UDP rate > TCP rate. The questions: can anyone explain the relation 'TCP rate > UDP rate'? Why polling slows down the interface? And can FreeBSD stack can be tuned to get the Linux performance? Kernel config deviations from GENERIC: options SCHED_ULE options ADAPTIVE_GIANT device pf device pflog device pfsync System is running at hz = 1000. Thanks! -- rea I often think it's a pity that Noah and his party didn't miss the boat. -Mark Twain From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 21 17:33:59 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58A5816A420 for ; Tue, 21 Feb 2006 17:33:59 +0000 (GMT) (envelope-from wayne@manor.msen.com) Received: from manor.msen.com (manor.msen.com [148.59.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC46143D48 for ; Tue, 21 Feb 2006 17:33:58 +0000 (GMT) (envelope-from wayne@manor.msen.com) Received: from manor.msen.com (localhost [127.0.0.1]) by manor.msen.com (8.12.9p2/8.12.9) with ESMTP id k1LHXvc1051455 for ; Tue, 21 Feb 2006 12:33:58 -0500 (EST) (envelope-from wayne@manor.msen.com) Received: (from wayne@localhost) by manor.msen.com (8.12.9p2/8.12.9/Submit) id k1LHXvPs051454 for hackers@freebsd.org; Tue, 21 Feb 2006 12:33:57 -0500 (EST) (envelope-from wayne) Date: Tue, 21 Feb 2006 12:33:57 -0500 From: "Michael R. Wayne" To: hackers@freebsd.org Message-ID: <20060221173357.GE71757@manor.msen.com> Mail-Followup-To: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Infrequent disk system hang on 5.4-RELEASE-p8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2006 17:33:59 -0000 We have an older server, running 5.4-RELEASE-p8 and used primarily for email, which hangs every couple of weeks. The hang seems to be in the disk I/O system. Based on the times of the hangs, the triggering event seems to be running dump. We have a serial console set up, I broke to the debugger and got the following. Since the hang is in the disk I/O system, a dump is not possible. The many versions of inetd are likely due to users attempting to POP their email. Any suggestions or tips on how to track this down and get it resolved would be appreciated. Relevant dmesg info: ahc0: port 0xe400-0xe4ff mem 0xffafe000-0xffafefff irq 16 at device 11.0 on pci0 aic7896/97: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0xe800-0xe8ff mem 0xffaff000-0xffafffff irq 16 at device 11.1 on pci0 aic7896/97: Ultra2 Wide Channel B, SCSI Id=7, 32/253 SCBs da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 17522MB (35885168 512 byte sectors: 255H 63S/T 2233C) da1 at ahc1 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 35242MB (72176567 512 byte sectors: 255H 63S/T 4492C) da2 at ahc1 bus 0 target 1 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da2: 17522MB (35885168 512 byte sectors: 255H 63S/T 2233C) GEOM_MIRROR: Device gm0s1 created (id=520792649). GEOM_MIRROR: Device gm0s1: provider da0s1 detected. GEOM_MIRROR: Device gm0s2 created (id=3744871543). GEOM_MIRROR: Device gm0s2: provider da0s2 detected. GEOM_MIRROR: Device gm0s1: provider da2s1 detected. GEOM_MIRROR: Device gm0s1: provider da2s1 activated. GEOM_MIRROR: Device gm0s1: provider da0s1 activated. GEOM_MIRROR: Device gm0s1: provider mirror/gm0s1 launched. GEOM_MIRROR: Device gm0s2: provider da2s2 detected. GEOM_MIRROR: Device gm0s2: provider da2s2 activated. GEOM_MIRROR: Device gm0s2: provider da0s2 activated. GEOM_MIRROR: Device gm0s2: provider mirror/gm0s2 launched. db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 67487 c5ea98d4 0 551 551 0000100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67486 c3b8a1c4 0 551 551 0000100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67485 c634c710 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67484 c62931c4 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67483 c58a9388 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67482 c6293710 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67481 c58ab8d4 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67480 c6292c5c 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67479 c62938d4 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67478 c634f000 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67477 c62941c4 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67476 c5e55c5c 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67475 c5f1fe20 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67474 c5da854c 0 551 551 0000100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67473 c5f9ee20 0 551 551 0000100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67472 c58a9e20 0 551 551 0000100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67471 c602d8d4 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67470 c61191c4 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67469 c58ab1c4 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67468 c5f19a98 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67467 c58c3388 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67466 c5f1f388 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67465 c5f19000 0 442 67465 0000100 [SLPQ ufs 0xc3851c04][SLP] sshd 67464 c5fa68d4 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67463 c5eab54c 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67462 c6294000 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67461 c5fa6710 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67460 c6119000 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67459 c634c388 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67458 c5da8710 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67457 c3b8e388 0 551 551 0000100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67456 c62948d4 0 551 551 0000100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67455 c62921c4 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67454 c5f1954c 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67453 c5eab388 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67452 c5f171c4 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67451 c6294388 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67450 c60291c4 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67449 c5ea9710 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67448 c3b8ac5c 0 551 551 0000100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67447 c6293388 0 551 551 0000100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67446 c5f1fa98 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67445 c5e55e20 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67444 c6117710 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67443 c5fa7a98 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67442 c6026388 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67441 c5e5a1c4 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67440 c6119710 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67439 c5e5a000 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67438 c3b8e8d4 0 551 551 0000100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67437 c6293e20 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67436 c5dfee20 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67435 c5ea8e20 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67434 c5fa7388 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67433 c39dde20 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67432 c6118000 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67431 c58c31c4 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67430 c634fe20 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67429 c5f191c4 0 551 551 0000100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67428 c58a9c5c 0 551 551 0000100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67427 c63508d4 0 551 551 0000100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67426 c3b8ee20 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67425 c3b8ec5c 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67424 c5eabc5c 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67423 c5e5a54c 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67422 c39de710 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67421 c6117e20 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67420 c5da454c 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67419 c5e551c4 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67418 c5da88d4 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67417 c611ce20 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67416 c5e55000 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67415 c5f19c5c 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67414 c5f198d4 0 574 574 0000000 [SLPQ ufs 0xc3851c04][SLP] inetd 67413 c60261c4 0 551 551 0000100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67412 c6293c5c 0 574 67412 0004000 [SLPQ ufs 0xc3851c04][SLP] qpopper 67411 c58a9a98 0 574 67411 0004000 [SLPQ ufs 0xc3851c04][SLP] qpopper 67410 c38898d4 0 574 67410 0004000 [SLPQ suspfs 0xc37cac6c][SLP] qpopper 67409 c611c54c 0 574 67409 0004000 [SLPQ ufs 0xc38515d4][SLP] qpopper 67408 c634c1c4 0 574 67408 0004000 [SLPQ ufs 0xc3851c04][SLP] qpopper 67407 c5ea9000 0 574 67407 0004000 [SLPQ ufs 0xc3851c04][SLP] qpopper 67406 c58c3000 0 574 67406 0004000 [SLPQ ufs 0xc388d9f4][SLP] qpopper 67405 c5da41c4 2 67404 67401 0004100 [SLPQ ufs 0xc3851c04][SLP] mksnap_ffs 67404 c58c5a98 2 67403 67401 0004000 [SLPQ wait 0xc58c5a98][SLP] sh 67403 c5fa7e20 2 67402 67401 0004000 [SLPQ wait 0xc5fa7e20][SLP] dump 67402 c5fa71c4 2 67401 67401 0004000 [SLPQ piperd 0xc60fb600][SLP] gzip 67401 c5f19710 2 67400 67401 0004000 [SLPQ pause 0xc5f19748][SLP] tcsh 67400 c5e5554c 2 67398 67398 0000100 [SLPQ select 0xc08f1f44][SLP] sshd 67398 c611854c 0 442 67398 0000100 [SLPQ sbwait 0xc6273974][SLP] sshd 67322 c39dea98 0 551 551 0000100 [SLPQ ufs 0xc3851c04][SLP] sendmail 62457 c39dee20 0 514 514 0000100 [SLPQ accept 0xc3997916][SLP] perl5.8.6 62370 c5f1f710 0 514 514 0000100 [SLPQ accept 0xc3997916][SLP] perl5.8.6 61704 c58c5c5c 0 514 514 0000100 [SLPQ accept 0xc3997916][SLP] perl5.8.6 61031 c58a91c4 0 514 514 0000100 [SLPQ accept 0xc3997916][SLP] perl5.8.6 59856 c5da48d4 0 514 514 0000100 [SLPQ accept 0xc3997916][SLP] perl5.8.6 43502 c58c3710 5147 589 43502 0004002 [SLPQ ufs 0xc3851c04][SLP] tcsh 589 c38848d4 0 1 589 0004102 [SLPQ wait 0xc38848d4][SLP] login 588 c3884c5c 0 1 1 0004000 [SLPQ ufs 0xc3851c04][SLP] getty 587 c39dd000 0 1 1 0004000 [SLPQ ufs 0xc3851c04][SLP] getty 586 c3889e20 0 1 1 0004000 [SLPQ ufs 0xc3851c04][SLP] getty 574 c3884e20 0 1 574 0000000 [SLPQ select 0xc08f1f44][SLP] inetd 551 c39dd388 0 1 551 0000100 [SLPQ select 0xc08f1f44][SLP] sendmail 542 c39dda98 0 1 542 0008080 (threaded) spamass-milter thread 0xc628e000 ksegrp 0xc353aaf0 [SLPQ kserel 0xc353ab30][SLP] thread 0xc5fa1900 ksegrp 0xc353aaf0 [SLPQ select 0xc08f1f44][SLP] thread 0xc39e0900 ksegrp 0xc353a5b0 [SLPQ ksesigwait 0xc39ddb98][SLP] 532 c39de000 25 1 532 0000100 [SLPQ pause 0xc39de038][SLP] sendmail 527 c39ddc5c 0 521 521 0000001 [SLPQ lockf 0xc38193c0][SLP] saslauthd 526 c39dd710 0 521 521 0000001 [SLPQ lockf 0xc35e4c40][SLP] saslauthd 525 c39dd54c 0 521 521 0000001 [SLPQ lockf 0xc37e2580][SLP] saslauthd 524 c39dd1c4 0 521 521 0000001 [SLPQ lockf 0xc3819140][SLP] saslauthd 521 c3889c5c 0 1 521 0000001 [SLPQ accept 0xc3997b9e][SLP] saslauthd 514 c3889a98 0 1 514 0000000 [SLPQ pause 0xc3889ad0][SLP] perl5.8.6 499 c37eda98 65534 1 499 0000100 [SLPQ select 0xc08f1f44][SLP] spamd 493 c3889000 0 1 493 0000000 [SLPQ select 0xc08f1f44][SLP] rpc.dracd 484 c3884388 106 1 484 0008180 (threaded) clamav-milter thread 0xc5f1e900 ksegrp 0xc3448380 [SLPQ kserel 0xc34483c0][SLP] thread 0xc6032780 ksegrp 0xc3448380 [SLPQ select 0xc08f1f44][SLP] thread 0xc5df8780 ksegrp 0xc3448380 [SLPQ ufs 0xc3851c04][SLP] thread 0xc39d6900 ksegrp 0xc353ae00 [SLPQ ksesigwait 0xc3884488][SLP] 477 c3884710 106 1 477 0000100 [SLPQ pause 0xc3884748][SLP] freshclam 470 c388454c 106 1 470 0008180 (threaded) clamd thread 0xc5e34900 ksegrp 0xc3448310 [SLPQ kserel 0xc3448350][SLP] thread 0xc5e56000 ksegrp 0xc3448310 [SLPQ accept 0xc3924e26][SLP] thread 0xc3aa2000 ksegrp 0xc388abd0 [SLPQ ksesigwait 0xc388464c][SLP] 455 c3889388 0 1 455 0000000 [SLPQ ufs 0xc3851c04][SLP] cron 442 c38841c4 0 1 442 0000100 [SLPQ ufs 0xc3851c04][SLP] sshd 429 c3884000 0 1 429 0000000 [SLPQ select 0xc08f1f44][SLP] ntpd 338 c37ede20 0 1 338 0000000 [SLPQ select 0xc08f1f44][SLP] rpcbind 325 c3884a98 0 1 325 0000000 [SLPQ select 0xc08f1f44][SLP] syslogd 307 c38891c4 0 1 307 0000000 [SLPQ select 0xc08f1f44][SLP] devd 58 c353c54c 0 0 0 0000204 [SLPQ - 0xe67d4d18][SLP] schedcpu 57 c353c710 0 0 0 0000204 [SLPQ - 0xc08f996c][SLP] nfsiod 3 56 c353c8d4 0 0 0 0000204 [SLPQ - 0xc08f9968][SLP] nfsiod 2 55 c353ca98 0 0 0 0000204 [SLPQ - 0xc08f9964][SLP] nfsiod 1 54 c353cc5c 0 0 0 0000204 [SLPQ - 0xc08f9960][SLP] nfsiod 0 53 c353ce20 0 0 0 0000204 [SLPQ vlruwt 0xc353ce20][SLP] vnlru 52 c37ed000 0 0 0 0000204 [SLPQ syncer 0xc08ee6cc][SLP] syncer 51 c37ed1c4 0 0 0 0000204 [SLPQ psleep 0xc08f250c][SLP] bufdaemon 50 c37ed388 0 0 0 000020c [SLPQ pgzero 0xc09002d4][SLP] pagezero 49 c37ed54c 0 0 0 0000204 [SLPQ psleep 0xc0900328][SLP] vmdaemon 48 c37ed710 0 0 0 0000204 [SLPQ psleep 0xc09002e4][SLP] pagedaemon 47 c37ed8d4 0 0 0 0000204 [SLPQ m:w2 0xc37ea000][SLP] g_mirror gm0s2 46 c349ba98 0 0 0 0000204 [SLPQ m:w2 0xc37ea500][SLP] g_mirror gm0s1 45 c349bc5c 0 0 0 0000204 [IWAIT] swi0: sio 44 c349be20 0 0 0 0000204 [SLPQ - 0xc354223c][SLP] fdc0 43 c3538000 0 0 0 0000204 [SLPQ idle 0xc3540e00][SLP] aic_recovery1 9 c35381c4 0 0 0 0000204 [SLPQ idle 0xc3540e00][SLP] aic_recovery1 8 c3538388 0 0 0 0000204 [SLPQ idle 0xc3540400][SLP] aic_recovery0 7 c353854c 0 0 0 0000204 [SLPQ idle 0xc3540400][SLP] aic_recovery0 42 c3538710 0 0 0 0000204 [IWAIT] swi6: task queue 6 c35388d4 0 0 0 0000204 [SLPQ - 0xc352e3c0][SLP] kqueue taskq 41 c3538a98 0 0 0 0000204 [IWAIT] swi3: cambio 40 c3538c5c 0 0 0 0000204 [IWAIT] swi2: camnet 39 c3538e20 0 0 0 0000204 [IWAIT] swi6:+ 5 c353c000 0 0 0 0000204 [SLPQ - 0xc352ed80][SLP] thread taskq 38 c348a54c 0 0 0 0000204 [IWAIT] swi6:+ 37 c348a710 0 0 0 0000204 [SLPQ - 0xc08e4660][SLP] yarrow 4 c348a8d4 0 0 0 0000204 [SLPQ - 0xc08e8fa8][SLP] g_down 3 c348aa98 0 0 0 0000204 [SLPQ - 0xc08e8fa4][SLP] g_up 2 c348ac5c 0 0 0 0000204 [SLPQ - 0xc08e8f9c][SLP] g_event 36 c348ae20 0 0 0 0000204 [IWAIT] swi1: net 35 c349b000 0 0 0 0000204 [IWAIT] swi4: vm 34 c349b1c4 0 0 0 000020c [IWAIT] swi5: clock sio 33 c349b388 0 0 0 0000204 [IWAIT] irq0: clk 32 c349b54c 0 0 0 0000204 [IWAIT] irq22: 31 c349b710 0 0 0 0000204 [IWAIT] irq21: 30 c349b8d4 0 0 0 0000204 [IWAIT] irq20: 29 c34491c4 0 0 0 0000204 [IWAIT] irq19: fxp0 28 c3449388 0 0 0 0000204 [IWAIT] irq18: 27 c344954c 0 0 0 0000204 [IWAIT] irq17: 26 c3449710 0 0 0 0000204 [IWAIT] irq16: fxp1 ahc0+ 25 c34498d4 0 0 0 0000204 [IWAIT] irq15: ata1 24 c3449a98 0 0 0 0000204 [IWAIT] irq14: ata0 23 c3449c5c 0 0 0 0000204 [IWAIT] irq13: 22 c3449e20 0 0 0 0000204 [IWAIT] irq12: 21 c348a000 0 0 0 0000204 [IWAIT] irq11: 20 c348a1c4 0 0 0 0000204 [IWAIT] irq10: 19 c348a388 0 0 0 0000204 [IWAIT] irq9: 18 c3442000 0 0 0 0000204 [IWAIT] irq8: rtc 17 c34421c4 0 0 0 0000204 [IWAIT] irq7: ppc0 16 c3442388 0 0 0 0000204 [IWAIT] irq6: fdc0 15 c344254c 0 0 0 0000204 [IWAIT] irq5: 14 c3442710 0 0 0 0000204 [IWAIT] irq4: sio0 13 c34428d4 0 0 0 0000204 [IWAIT] irq3: sio1 12 c3442a98 0 0 0 0000204 [IWAIT] irq1: atkbd0 11 c3442c5c 0 0 0 000020c [CPU 0] idle 1 c3442e20 0 0 1 0004200 [SLPQ wait 0xc3442e20][SLP] init 10 c3449000 0 0 0 0000204 [SLPQ ktrace 0xc08ec8f8][SLP] ktrace 0 c08e90a0 0 0 0 0000200 [SLPQ sched 0xc08e90a0][SLP] swapper db> where Tracing pid 11 tid 100003 td 0xc3443480 kdb_enter(c08479e3) at kdb_enter+0x2b siointr1(c35d6000) at siointr1+0xd5 siointr(c35d6000) at siointr+0x38 intr_execute_handlers(c343dc90,e4d53cc8,4,e4d53d0c,c07b9483) at intr_execute_handlers+0x7d lapic_handle_intr(34) at lapic_handle_intr+0x2e Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc07c057d, esp = 0xe4d53d0c, ebp = 0xe4d53d0c --- cpu_idle_default(e4d53d20,c0604971,c3442c5c,e4d53d34,c0604720) at cpu_idle_default+0x5 cpu_idle(c3442c5c,e4d53d34,c0604720,0,e4d53d48) at cpu_idle+0x1f idle_proc(0,e4d53d48) at idle_proc+0x11 fork_exit(c0604960,0,e4d53d48) at fork_exit+0x74 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4d53d7c, ebp = 0 --- From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 21 19:17:50 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2BF716A420 for ; Tue, 21 Feb 2006 19:17:50 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C85443D46 for ; Tue, 21 Feb 2006 19:17:50 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) From: Nate Nielsen User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeLSD References: <20060221165456.GZ44603@rea.mbslab.kiae.ru> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Message-Id: <20060221192719.CD61EDCA992@mail.npubs.com> X-Virus-Scanned: ClamAV using ClamSMTP Date: Tue, 21 Feb 2006 19:27:22 +0000 (GMT) Cc: hackers@freebsd.org Subject: Re: FreeBSD-6 and em interface speed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nielsen@memberwebs.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2006 19:17:50 -0000 FreeLSD wrote: > Good day! > I've obtained the following strang results with the em Ethernet interface > speeds on a 6.1-PRERELEASE: > Polling on: > UDP stream to FreeBSD: 327843.84 Kbit/sec, > TCP stream to FreeBSD: 524550.12 Kbit/sec. > Polling off: > UDP stream to FreeBSD: 740409.38 Kbit/sec, > TCP stream to FreeBSD: 794348.44 Kbit/sec. Probably due to the test tool you're using. Does the tool serialize the UDP stream (ie: wait for a response for each packet)? In many cases polling will slow down an individual stream slightly, while upping the total throughput (hundreds of streams). In addition if your CPU and bus is fast enough to handle the interrupt rate (well behaved NICs mitigate interrupts) then polling will slow things down in most cases. BTW, this should go on freebsd-net. Cheers, Nate From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 21 21:49:57 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3081C16A422 for ; Tue, 21 Feb 2006 21:49:57 +0000 (GMT) (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 82E0743D5F for ; Tue, 21 Feb 2006 21:49:56 +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 3AD7F46B84; Tue, 21 Feb 2006 16:49:40 -0500 (EST) Date: Tue, 21 Feb 2006 21:53:41 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: FreeLSD In-Reply-To: <20060221165456.GZ44603@rea.mbslab.kiae.ru> Message-ID: <20060221215255.X37014@fledge.watson.org> References: <20060221165456.GZ44603@rea.mbslab.kiae.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@freebsd.org Subject: Re: FreeBSD-6 and em interface speed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2006 21:49:57 -0000 On Tue, 21 Feb 2006, FreeLSD wrote: > options SCHED_ULE I'd start by going back to SCHED_4BSD and seeing how that affects things. ULE is an experimental scheduler that may produce inconsistent or undesirable results depending on workload. Robert N M Watson From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 22 00:43:40 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06D0F16A470 for ; Wed, 22 Feb 2006 00:43:40 +0000 (GMT) (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 917C343D45 for ; Wed, 22 Feb 2006 00:43:39 +0000 (GMT) (envelope-from mike@sentex.net) Received: from BLUELAPIS.sentex.ca (cage.simianscience.com [64.7.134.1]) by smarthost2.sentex.ca (8.13.4/8.13.4) with SMTP id k1M0hbuj040597; Tue, 21 Feb 2006 19:43:37 -0500 (EST) (envelope-from mike@sentex.net) From: Mike Tancsa To: FreeLSD Date: Tue, 21 Feb 2006 19:43:42 -0500 Message-ID: References: <20060221165456.GZ44603@rea.mbslab.kiae.ru> In-Reply-To: <20060221165456.GZ44603@rea.mbslab.kiae.ru> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD-6 and em interface speed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 00:43:41 -0000 On Tue, 21 Feb 2006 19:54:56 +0300, in sentex.lists.freebsd.hackers you wrote: > Good day! > I've obtained the following strang results with the em Ethernet = interface >speeds on a 6.1-PRERELEASE: > Polling on: > UDP stream to FreeBSD: 327843.84 Kbit/sec, > TCP stream to FreeBSD: 524550.12 Kbit/sec. > Polling off: > UDP stream to FreeBSD: 740409.38 Kbit/sec, > TCP stream to FreeBSD: 794348.44 Kbit/sec. > > It is funny that TCP speed is greater than UDP. It can be related to = the >hardware, not to the OS, because I've seen such behaviour on a = linux-2.6. >But on linux-2.4 with the same hardware as for FreeBSD and with the same >source host I've got > UDP stream to Linux: 927891.44 Kbit/sec, > TCP stream to Linux: 850202.50 Kbit/sec. >The figures are higher and UDP rate > TCP rate. > I found that setting kern.polling.idle_poll=3D1 made a big difference to the forwarding rate. Also, on your tcp tests, try sysctl -w net.inet.tcp.inflight.enable=3D0 You might also adjust the amount of CPU allocated to userland when using polling. Without polling, I found I was able to livelock the middle box with just a dozen rules. I had=20 =46reeBSD boxA ------FreeBSD-B---FreeBSD-C Where=20 A =3D AMD 3800 with PCI-e BGE B =3D P4 3Ghz with PCI-X 82546EB Dual Port Gigabit=20 C =3D AMD 3800 with PCI-e BGE using netrate and iperf from A to C going across B, I had to switch to polling so as not to live lock B using /usr/src/tools/tools/netrate/netblast. Without ipfw or pflog, it was not an issue. but load up ipfw or pf, B would become unresponsive in non polling mode. > The questions: can anyone explain the relation 'TCP rate > UDP rate'? = Why >polling slows down the interface? And can FreeBSD stack can be tuned to >get the Linux performance? > > Kernel config deviations from GENERIC: >options SCHED_ULE get rid of that and use SCHED_4BSD ---Mike >options ADAPTIVE_GIANT >device pf >device pflog >device pfsync > > System is running at hz =3D 1000. > > Thanks! -------------------------------------------------------- Mike Tancsa, Sentex communications http://www.sentex.net Providing Internet Access since 1994 mike@sentex.net, (http://www.tancsa.com) From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 22 04:12:27 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7509B16A496 for ; Wed, 22 Feb 2006 04:12:27 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) Received: from mail.npubs.com (npubs.com [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3696E43D45 for ; Wed, 22 Feb 2006 04:12:26 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) From: Nate Nielsen User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Dowse References: <200602111542.aa07502@nowhere.iedowse.com> Content-Type: multipart/mixed; boundary="------------060408040104060004020008" Message-Id: <20060222042200.BC7B3DCAA07@mail.npubs.com> X-Virus-Scanned: ClamAV using ClamSMTP Date: Wed, 22 Feb 2006 04:22:01 +0000 (GMT) Cc: freebsd-hackers@freebsd.org, Scott Long Subject: Re: Panic Kernel Dump to umass device? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nielsen@memberwebs.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 04:12:27 -0000 This is a multi-part message in MIME format. --------------060408040104060004020008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ian Dowse wrote: > In message <43ED8E81.2060907@samsco.org>, Scott Long writes: > >>You're correct that dumping is meant to be done with interrupts and task >>switching disabled. The first thing that the umass driver is missing is >>a working CAM poll handler. Without this, there is no way for command >>completions to be seen when interrupts are disabled. Beyond that, I >>somewhat suspect that the USB stack expects to be able to push command >>completion work off to worker threads, at least for some situations, and >>that also will not work in the kernel dump environment. So, there is a >>lot of work needed to make this happen. > > > The USB stack supports polled operations, so it's actually not to > hard to make this work. Below is a patch I had in one of my local > trees that adds a CAM poll handler to the umass driver. I've just > tested this and it does seem to make kernel dumping work, but I > guess it might not be as reliable as dumping to other devices. As noted earlier the umass polling patch you posted works for dumping to a umass device via a uhci controller. After a little more fiddling I've managed to get it working on an ohci controller. Attached is a patch. This patch includes your patch above. Cheers, Nate --------------060408040104060004020008 Content-Type: text/x-patch; name="umass-ohci-dump.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="umass-ohci-dump.patch" Index: sys/dev/usb/umass.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/umass.c,v retrieving revision 1.122.2.6 diff -U3 -r1.122.2.6 umass.c --- sys/dev/usb/umass.c 29 Jan 2006 00:45:11 -0000 1.122.2.6 +++ sys/dev/usb/umass.c 22 Feb 2006 03:04:02 -0000 @@ -2643,21 +2643,17 @@ } } -/* umass_cam_poll - * all requests are handled through umass_cam_action, requests - * are never pending. So, nothing to do here. - */ Static void umass_cam_poll(struct cam_sim *sim) { -#ifdef USB_DEBUG struct umass_softc *sc = (struct umass_softc *) sim->softc; DPRINTF(UDMASS_SCSI, ("%s: CAM poll\n", USBDEVNAME(sc->sc_dev))); -#endif - /* nop */ + usbd_set_polling(sc->sc_udev, 1); + usbd_dopoll(sc->iface); + usbd_set_polling(sc->sc_udev, 0); } Index: sys/dev/usb/ohci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/ohci.c,v retrieving revision 1.154.2.2 diff -U3 -r1.154.2.2 ohci.c --- sys/dev/usb/ohci.c 29 Jan 2006 01:26:46 -0000 1.154.2.2 +++ sys/dev/usb/ohci.c 22 Feb 2006 03:04:05 -0000 @@ -3049,6 +3049,9 @@ splx(s); + if (sc->sc_bus.use_polling) + ohci_waitintr(sc, xfer); + return (USBD_IN_PROGRESS); } --------------060408040104060004020008-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 22 07:10:05 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E756216A420; Wed, 22 Feb 2006 07:10:05 +0000 (GMT) (envelope-from rea@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (rea.mbslab.kiae.ru [144.206.177.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D61743D49; Wed, 22 Feb 2006 07:10:05 +0000 (GMT) (envelope-from rea@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (localhost [127.0.0.1]) by rea.mbslab.kiae.ru (Postfix) with ESMTP id 71A41BDC1; Wed, 22 Feb 2006 10:10:04 +0300 (MSK) Received: by rea.mbslab.kiae.ru (Postfix, from userid 1000) id 4A529B95D; Wed, 22 Feb 2006 10:10:04 +0300 (MSK) Date: Wed, 22 Feb 2006 10:10:04 +0300 From: FreeLSD To: Robert Watson Message-ID: <20060222071004.GC44603@rea.mbslab.kiae.ru> References: <20060221165456.GZ44603@rea.mbslab.kiae.ru> <20060221215255.X37014@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20060221215255.X37014@fledge.watson.org> User-Agent: mutt-ng/devel-r581 (FreeBSD) X-AV-Checked: Yes! Cc: hackers@freebsd.org, mike@sentex.net Subject: Re: FreeBSD-6 and em interface speed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 07:10:06 -0000 > I'd start by going back to SCHED_4BSD and seeing how that affects things. ULE > is an experimental scheduler that may produce inconsistent or undesirable > results depending on workload. OK, I will. And I'll follow your next advice about the tcp_inflight and Mike's advice. Following Nate Nielsen I will post my next results to the freebsd-net. Thanks! -- rea BOFH excuse #51: Cosmic ray particles crashed through the hard disk platter From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 22 10:51:38 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F01F016A420 for ; Wed, 22 Feb 2006 10:51:38 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 612E043D5E for ; Wed, 22 Feb 2006 10:51:30 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id B2A6FBE30F for ; Wed, 22 Feb 2006 11:51:28 +0100 (CET) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03318-07 for ; Wed, 22 Feb 2006 11:51:23 +0100 (CET) Received: from firewall.demig (p5083C327.dip0.t-ipconnect.de [80.131.195.39]) by server.absolute-media.de (Postfix) with ESMTP id B5923BE665 for ; Wed, 22 Feb 2006 11:51:23 +0100 (CET) Received: from ws-ew-3 (ws-ew-3.demig.intra [192.168.1.72]) by firewall.demig (8.13.5/8.13.5) with SMTP id k1MAlWY5096661 for ; Wed, 22 Feb 2006 11:47:32 +0100 (CET) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: Date: Wed, 22 Feb 2006 11:47:33 +0100 Message-ID: <000001c6379d$63036d80$4801a8c0@ws-ew-3.demig.intra> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Subject: does ukbd delay break scan codes? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 10:51:39 -0000 Hello, while testing an older release of kbdmux under FreeBSD4 I am seeing some strange things: I have attached a primary ps/2 and a secondary usb keyboard. I run under X (which means that kbdmux is switched to return raw key codes only) and inspect kbdmux using some printfs and xconsole. >From time to time I 'freeze' the keyboard input of my X application by pressing e.g. Ctrl+Fn1 on the primary keyboard. I still see kbdmux returning scan codes. Unfreezing can be done by simply switching virtual consoles, which seems to somehow re-initialize the keyboard state. I still do not know where it comes from, but what I found so far is, that the usb keyboard (or ukbd driver) seems to delay the break codes for keys with prefix E0 (which may or may not have anything to do with my problem). E.g., I press Keypad-Enter and see E0 1C E0 ^prefix ^make code ^prefix and nothing else. As soon as I press e.g. Enter (any key works) I see 9C 1C 9C ^break code ^make code ^delayed break code. Does anyone have an idea where that may come from? Could it be a possible bug in ukbd's conversion code? (BTW: I compared ukbd.c of RELENG-4 against RELENG-6. There are no significant differences) My usb keyboard is a Cherry RS6000. Norbert From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 22 13:16:31 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3541E16A422 for ; Wed, 22 Feb 2006 13:16:31 +0000 (GMT) (envelope-from freebsd@voidmain.net) Received: from pgh.nepinc.com (pgh.nepinc.com [66.207.129.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CADD343D45 for ; Wed, 22 Feb 2006 13:16:30 +0000 (GMT) (envelope-from freebsd@voidmain.net) Received: from [192.168.97.222] (dhcp222.eng.nepinc.com [192.168.97.222]) (authenticated bits=0) by pgh.nepinc.com (8.12.11/8.12.11) with ESMTP id k1MDGTxw028388 for ; Wed, 22 Feb 2006 08:16:29 -0500 (EST) (envelope-from freebsd@voidmain.net) Message-ID: <43FC6421.3000206@voidmain.net> Date: Wed, 22 Feb 2006 08:16:17 -0500 From: Tom Grove Organization: VoidMain.net User-Agent: Thunderbird 1.5 (X11/20060210) MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Glade/GTK autogen issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd@voidmain.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 13:16:31 -0000 I'm trying to build a simple hello world using glade. I've actually built this code on this system before and now after a few months and several ports tree updates it doesn't work. When I run autogen.sh within the glade built directory I receive the following error: syntax error near unexpected token `PACKAGE,' I run: setenv ACLOCAL_FLAGS "-I /usr/local/share/aclocal -I /usr/X11R6/share/aclocal" before autogen.sh. Here's a little info about the system: 6.0-RELEASE FreeBSD 6.0-RELEASE autoconf-2.13.000227_5 autoconf-2.59_2 automake-1.4.6_2 libtool-1.3.5_2 libtool-1.5.22_1 Also, if anyone knows of something similar to glade as in gui designer with C as the development language I would really like to know about it. Thanks. -Tom From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 22 13:53:42 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 267C116A423 for ; Wed, 22 Feb 2006 13:53:42 +0000 (GMT) (envelope-from nvass@teledomenet.gr) Received: from matrix.teledomenet.gr (dns1.teledomenet.gr [213.142.128.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5640843D45 for ; Wed, 22 Feb 2006 13:53:40 +0000 (GMT) (envelope-from nvass@teledomenet.gr) Received: from iris ([192.168.1.71]) by matrix.teledomenet.gr (8.12.10/8.12.10) with ESMTP id k1MDrduq019512 for ; Wed, 22 Feb 2006 15:53:39 +0200 From: Nikos Vassiliadis Date: Wed, 22 Feb 2006 15:50:17 +0200 User-Agent: KMail/1.8.3 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: Multipart/Mixed; boundary="Boundary-00=_ZwG/D13V8eFC7T4" Message-Id: <200602221550.17842.nvass@teledomenet.gr> Subject: (feature change request) remove link-layer generated routes from netstat -r X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 13:53:42 -0000 --Boundary-00=_ZwG/D13V8eFC7T4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, netstat -r prints link-layer generated routes and many times the output becomes somehow obscure. For example: root@brad:0:/usr/home/src/FreeBSD-6/src/usr.bin/netstat# netstat -ranfinet Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.1.1.244 UGS 0 31016 rl0 10.1.1/24 link#1 UC 0 0 rl0 10.1.1.181 00:0f:1f:fb:02:f5 UHLW 1 0 rl0 10.1.1.182 00:e0:fc:38:d4:40 UHLW 1 0 rl0 10.1.1.183 00:e0:fc:65:07:fd UHLW 1 0 rl0 10.1.1.244 00:50:fc:fe:74:3b UHLW 2 1 rl0 10.1.1.254 00:0c:cf:70:50:06 UHLW 1 0 rl0 127.0.0.1 127.0.0.1 UH 0 1117 lo0 192.168.1 link#5 UC 0 0 fxp0 192.168.1.25 00:05:5d:4d:19:58 UHLW 1 0 fxp0 192.168.1.45 00:11:43:b6:a1:55 UHLW 1 0 fxp0 192.168.1.71 00:0c:f1:b9:38:50 UHLW 1 1645 fxp0 192.168.1.84 00:04:23:af:79:66 UHLW 1 0 fxp0 192.168.1.112 00:30:4f:21:3b:8a UHLW 1 0 fxp0 192.168.1.196 00:07:e9:40:1f:c5 UHLW 1 0 fxp0 192.168.1.199 00:e0:81:21:28:21 UHLW 1 0 fxp0 192.168.1.200 00:30:4f:03:88:03 UHLW 1 0 fxp0 when the information I was actually looking for is: root@brad:0:/usr/home/src/FreeBSD-6/src/usr.bin/netstat# netstat -rnfinet Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.1.1.244 UGS 0 31016 rl0 10.1.1/24 link#1 UC 0 0 rl0 127.0.0.1 127.0.0.1 UH 0 1117 lo0 192.168.1 link#5 UC 0 0 fxp0 root@brad:0:/usr/home/src/FreeBSD-6/src/usr.bin/netstat# The attachment patch ("cvs diff -u -rHEAD route.c" generated) prints link-layer generated routes when -a is specified and ignores them the rest of the time. Thoughts? POLA violation? Nikos --Boundary-00=_ZwG/D13V8eFC7T4 Content-Type: text/x-diff; charset="us-ascii"; name="route.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="route.c.patch" Index: route.c =================================================================== RCS file: /home/ncvs/src/usr.bin/netstat/route.c,v retrieving revision 1.76 diff -u -r1.76 route.c --- route.c 13 May 2005 16:31:10 -0000 1.76 +++ route.c 22 Feb 2006 13:35:39 -0000 @@ -285,11 +285,16 @@ int len; /* - * Don't print protocol-cloned routes unless -a. + * Don't print protocol-cloned routes and + * link-layer generated routes unless -a. */ - if (rt->rt_flags & RTF_WASCLONED && !aflag) { - kget(rt->rt_parent, parent); - if (parent.rt_flags & RTF_PRCLONING) + if (!aflag) { + if (rt->rt_flags & RTF_WASCLONED) { + kget(rt->rt_parent, parent); + if (parent.rt_flags & RTF_PRCLONING) + return; + } + if (rt->rt_flags & RTF_LLINFO) return; } @@ -712,11 +717,16 @@ sa_u addr, mask; /* - * Don't print protocol-cloned routes unless -a. + * Don't print protocol-cloned routes and + * link-layer generated routes unless -a. */ - if (rt->rt_flags & RTF_WASCLONED && !aflag) { - kget(rt->rt_parent, parent); - if (parent.rt_flags & RTF_PRCLONING) + if (!aflag) { + if (rt->rt_flags & RTF_WASCLONED) { + kget(rt->rt_parent, parent); + if (parent.rt_flags & RTF_PRCLONING) + return; + } + if (rt->rt_flags & RTF_LLINFO) return; } --Boundary-00=_ZwG/D13V8eFC7T4-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 22 07:06:05 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A5D616A422 for ; Wed, 22 Feb 2006 07:06:05 +0000 (GMT) (envelope-from rea@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (rea.mbslab.kiae.ru [144.206.177.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id B363743D46 for ; Wed, 22 Feb 2006 07:06:04 +0000 (GMT) (envelope-from rea@rea.mbslab.kiae.ru) Received: from rea.mbslab.kiae.ru (localhost [127.0.0.1]) by rea.mbslab.kiae.ru (Postfix) with ESMTP id CD518BDC1; Wed, 22 Feb 2006 10:06:02 +0300 (MSK) Received: by rea.mbslab.kiae.ru (Postfix, from userid 1000) id A535EB95D; Wed, 22 Feb 2006 10:06:02 +0300 (MSK) Date: Wed, 22 Feb 2006 10:06:02 +0300 From: "Eygene A. Ryabinkin" To: nielsen@memberwebs.com Message-ID: <20060222070602.GB44603@rea.mbslab.kiae.ru> References: <20060221165456.GZ44603@rea.mbslab.kiae.ru> <20060221192719.CD61EDCA992@mail.npubs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20060221192719.CD61EDCA992@mail.npubs.com> User-Agent: mutt-ng/devel-r581 (FreeBSD) X-AV-Checked: Yes! X-Mailman-Approved-At: Wed, 22 Feb 2006 17:39:47 +0000 Cc: hackers@freebsd.org, FreeLSD Subject: Re: FreeBSD-6 and em interface speed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 07:06:05 -0000 > Probably due to the test tool you're using. Does the tool serialize the > UDP stream (ie: wait for a response for each packet)? As far as I understand, not it doesn't. The tool is nepim, version 0.17. > > BTW, this should go on freebsd-net. OK, next time it will. Thanks! -- rea BOFH excuse #9: doppler effect From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 22 10:10:42 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0778016A420; Wed, 22 Feb 2006 10:10:42 +0000 (GMT) (envelope-from trond@ramstind.gtf.ol.no) Received: from ramstind.gtf.ol.no (ramstind.gtf.ol.no [128.39.174.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D62D43D45; Wed, 22 Feb 2006 10:10:40 +0000 (GMT) (envelope-from trond@ramstind.gtf.ol.no) Received: from ramstind.gtf.ol.no (Ximalas@localhost [127.0.0.1]) by ramstind.gtf.ol.no (8.12.9/8.12.9) with ESMTP id k1MAAcjA079567; Wed, 22 Feb 2006 11:10:39 +0100 (CET) (envelope-from trond@ramstind.gtf.ol.no) Received: from localhost (trond@localhost) by ramstind.gtf.ol.no (8.12.9/8.12.3/Submit) with ESMTP id k1MAAUgu079562; Wed, 22 Feb 2006 11:10:38 +0100 (CET) Date: Wed, 22 Feb 2006 11:10:29 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= To: Scott Long In-Reply-To: <43FA3A6D.4010903@samsco.org> Message-ID: <20060222103900.C4217@ramstind.gtf.ol.no> References: <43FA3A6D.4010903@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Mailman-Approved-At: Wed, 22 Feb 2006 17:40:03 +0000 Cc: stable@freebsd.org, hackers@freebsd.org, re@freebsd.org Subject: Re: FreeBSD 6.1-BETA2/FreeBSD 5.5-BETA2 Available X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 10:10:42 -0000 On Mon, 20 Feb 2006 14:53-0700, Scott Long wrote: > We encourage people to help with testing so any final bugs can be > identified and worked out. Although hardly related to the kernel, the libtool15 tagging problem in the ports collection is the biggest showstopper for all of us, I guess. Is this a problem local to each port, global to the entire ports infrastructure, or system wide, i.e. something we need to set in /etc/make.conf? -- ---------------------------------------------------------------------- Trond Endrestøl | trond@fagskolen.gjovik.no Patron of The Art of Computer Programming| FreeBSD 4.8-S & Pine 4.55 From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 22 18:59:44 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A475916A423 for ; Wed, 22 Feb 2006 18:59:44 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) Received: from mail.npubs.com (mail.zoneseven.net [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CB6E43D45 for ; Wed, 22 Feb 2006 18:59:44 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) From: Nate Nielsen User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary="------------040201030309000709050800" Message-Id: <20060222190919.C6B9FDCA99B@mail.npubs.com> X-Virus-Scanned: ClamAV using ClamSMTP Date: Wed, 22 Feb 2006 19:09:22 +0000 (GMT) Subject: devctl attach/detach notification for disks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nielsen@memberwebs.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 18:59:44 -0000 This is a multi-part message in MIME format. --------------040201030309000709050800 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm working on a bit of code to get devctl notifications for attaching and removing of disks. This would allow actions to be taken via devd when a disk is attached or removed from the system. Currently I have the attach and detach notifications hooked into disk_create() and disk_destroy() in geom_disk.c. See attached (rough) patch. However at these points the disks are not yet present in the /dev/ filesystem. Anyone have any clues or tips for a better place to hook these notifications into the system? Cheers, Nate --------------040201030309000709050800 Content-Type: text/x-patch; name="devctl-disk.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="devctl-disk.patch" Index: sys/geom/geom_disk.c =================================================================== RCS file: /home/ncvs/src/sys/geom/geom_disk.c,v retrieving revision 1.96.2.1 diff -U3 -r1.96.2.1 geom_disk.c --- sys/geom/geom_disk.c 26 Nov 2005 22:55:20 -0000 1.96.2.1 +++ sys/geom/geom_disk.c 22 Feb 2006 17:55:18 -0000 @@ -42,6 +42,7 @@ #include #include #include +#include #include #include #include @@ -340,6 +341,7 @@ struct g_geom *gp; struct g_provider *pp; struct disk *dp; + char *devctl; if (flag == EV_CANCEL) return; @@ -358,6 +360,16 @@ printf("GEOM: new disk %s\n", gp->name); dp->d_geom = gp; g_error_provider(pp, 0); + + /* Send a 'added' message to devctl */ + devctl = g_malloc(512, M_NOWAIT); + if (devctl != NULL) { + snprintf(devctl, 512, + "+%s%d media-type=\"disk\" sectorsize=0x%04x mediasize=0x%04llx sectors=0x%04x heads=0x%02x\n", + dp->d_name, dp->d_unit, dp->d_sectorsize, dp->d_mediasize, dp->d_fwsectors, dp->d_fwheads); + devctl_queue_data(devctl); + g_free(devctl); + } } static void @@ -365,6 +377,7 @@ { struct disk *dp; struct g_geom *gp; + char *devctl; g_topology_assert(); dp = ptr; @@ -373,6 +386,15 @@ gp->softc = NULL; g_wither_geom(gp, ENXIO); } + + /* Send a 'removed' message to devctl */ + devctl = g_malloc(128, M_NOWAIT); + if (devctl != NULL) { + snprintf(devctl, 128, "-%s%d media-type=\"disk\"", dp->d_name, dp->d_unit); + devctl_queue_data(devctl); + g_free(devctl); + } + g_free(dp); } Index: sys/sys/bus.h =================================================================== RCS file: /home/ncvs/src/sys/sys/bus.h,v retrieving revision 1.70 diff -U3 -r1.70 bus.h --- sys/sys/bus.h 12 Apr 2005 15:20:36 -0000 1.70 +++ sys/sys/bus.h 22 Feb 2006 17:55:19 -0000 @@ -83,7 +83,7 @@ */ void devctl_notify(const char *__system, const char *__subsystem, const char *__type, const char *__data); -void devctl_queue_data(char *__data); +void devctl_queue_data(const char *__data); /* * Forward declarations Index: sys/kern/subr_bus.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_bus.c,v retrieving revision 1.184.2.1 diff -U3 -r1.184.2.1 subr_bus.c --- sys/kern/subr_bus.c 6 Oct 2005 23:15:18 -0000 1.184.2.1 +++ sys/kern/subr_bus.c 22 Feb 2006 17:55:22 -0000 @@ -497,15 +497,8 @@ return (revents); } -/** - * @brief Queue data to be read from the devctl device - * - * Generic interface to queue data to the devctl device. It is - * assumed that @p data is properly formatted. It is further assumed - * that @p data is allocated using the M_BUS malloc type. - */ -void -devctl_queue_data(char *data) +static void +devqdata(char *data) { struct dev_event_info *n1 = NULL; struct proc *p; @@ -528,6 +521,26 @@ } /** + * @brief Queue data to be read from the devctl device + * + * Generic interface to queue data to the devctl device. It is + * assumed that @p data is properly formatted. + */ +void +devctl_queue_data(const char *data) +{ + int len; + char *msg; + + len = strlen(data) + 1; + msg = malloc(len, M_BUS, M_NOWAIT); + if (msg == NULL) + return; + strcpy(msg, data); + devqdata(msg); +} + +/** * @brief Send a 'notification' to userland, using standard ways */ void --------------040201030309000709050800-- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 23 00:36:11 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 026CA16A422 for ; Thu, 23 Feb 2006 00:36:10 +0000 (GMT) (envelope-from viktor.vasilev@stud.tu-darmstadt.de) Received: from lnx130.hrz.tu-darmstadt.de (lnx130.hrz.tu-darmstadt.de [130.83.174.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9D8843D45 for ; Thu, 23 Feb 2006 00:36:09 +0000 (GMT) (envelope-from viktor.vasilev@stud.tu-darmstadt.de) Received: from mailserver3.hrz.tu-darmstadt.de (lnx115.hrz.tu-darmstadt.de [130.83.174.27]) by lnx130.hrz.tu-darmstadt.de (8.12.10/8.12.10) with ESMTP id k1N0a84x028811 for ; Thu, 23 Feb 2006 01:36:08 +0100 Received: from [130.83.20.203] (helo=ABC216.ram1st.wh.tu-darmstadt.de) by mailserver3.hrz.tu-darmstadt.de with esmtpsa (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.50) id 1FC4Sl-00038K-Qs for hackers@freebsd.org; Thu, 23 Feb 2006 01:36:07 +0100 From: Viktor Vasilev To: hackers@freebsd.org Date: Thu, 23 Feb 2006 01:36:06 +0100 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_2NQ/DNCe++IlWBH" Message-Id: <200602230136.06689.viktor.vasilev@stud.tu-darmstadt.de> Cc: Subject: Looking for advice on chasing a kernel memory leak X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2006 00:36:11 -0000 --Boundary-00=_2NQ/DNCe++IlWBH Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I'm having trouble with a WARP (http://www.pcengines.ch/wrap.htm) board running m0n0wall v1.21 (stripped down FreeBSD 4.11-RELEASE-p13). It's serving as an internet gateway and the problem is, that after some time it starts blocking traffic and doesn't do NAT anymore. The box is handling very low traffic volume and is mostly idle. I've enabled logging to a remote machine and around the time the trouble happens, there are messages like these: Jan 15 04:02:25 gw /kernel: ipf_nattable_max reduced to -96 Jan 15 04:02:49 gw /kernel: ipf_nattable_max reduced to -94 Jan 15 04:02:49 gw /kernel: ipf_nattable_max reduced to -94 Jan 15 04:04:31 gw /kernel: ipf_nattable_max reduced to -92 An inspection of the ipfilter code shows that kmem_alloc is failing: http://fxr.watson.org/fxr/source/contrib/ipfilter/netinet/ip_nat.c?v=RELENG4#L1197 A reboot fixes the things until the same thing happens again in three or so weeks. Since that happened a couple of times, I've monitored RAM usage and see a constant growth of the wired memory. After reboot top reports: Mem: 4312K Active, 3684K Inact, 5960K Wired, 4848K Buf, 99M Free Now after two weeks: Mem: 5044K Active, 3824K Inact, 22M Wired, 5856K Buf, 82M Free vmstat -m output (attached) clearly shows that there's a huge amount of M_TEMP memory held and growing: temp 30370 15148K 15169K 19166K 16804822 0 0 16,32,64,128,256,512,1K,4K,8K,32K,256K,512K I don't know how to find out who actually allocates this memory. Any ideas? ps auxwww output, kernel config and dmesg are attached. Cheers, Viktor --Boundary-00=_2NQ/DNCe++IlWBH Content-Type: text/plain; charset="us-ascii"; name="wrap-dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="wrap-dmesg.txt" Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.11-RELEASE-p13 #0: Sat Nov 26 12:17:56 CET 2005 root@fb411.neon1.net:/usr/src/sys/compile/M0N0WALL_WRAP Timecounter "i8254" frequency 1193182 Hz CPU: NSC Geode (266.64-MHz 586-class CPU) Origin = "Geode by NSC" Id = 0x540 Stepping = 0 DIR=0x81b7 Features=0x808131 real memory = 134217728 (131072K bytes) avail memory = 116117504 (113396K bytes) Preloaded elf kernel "kernel" at 0xc0e03000. Preloaded mfs_root "/mfsroot" at 0xc0e030a8. md0: Preloaded image 11534336 bytes at 0xc0301df0 md1: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 sis0: port 0x1000-0x10ff mem 0x80000000-0x80000fff irq 10 at device 14.0 on pci0 sis0: Ethernet address: 00:0d:b9:02:c4:d0 miibus0: on sis0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis1: port 0x1400-0x14ff mem 0x80040000-0x80040fff irq 9 at device 15.0 on pci0 sis1: Ethernet address: 00:0d:b9:02:c4:d1 miibus1: on sis1 ukphy1: on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis2: port 0x1800-0x18ff mem 0x80080000-0x80080fff irq 11 at device 16.0 on pci0 sis2: Ethernet address: 00:0d:b9:02:c4:d2 miibus2: on sis2 ukphy2: on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: port 0xf600-0xf63f,0xf400-0xf43f at device 18.0 on pci0 isa0: on isab0 chip1: port 0xf000-0xf0ff at device 18.1 on pci0 atapci0: port 0xfc00-0xfc0f at device 18.2 on pci0 ata0: at 0x1f0 irq 14 on atapci0 pci0: (vendor=0x100b, dev=0x0503) at 18.3 chip2: port 0xf200-0xf23f at device 18.5 on pci0 orm0: