From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 17 00:38:57 2005 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 36F5816A420 for ; Sun, 17 Jul 2005 00:38:57 +0000 (GMT) (envelope-from ryan@britestream.com) Received: from gateway.layern.com (gateway.britestream.com [207.191.53.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB31F43D48 for ; Sun, 17 Jul 2005 00:38:56 +0000 (GMT) (envelope-from ryan@britestream.com) Received: from pineapple.layern.com (pineapple.layern.com [192.168.1.233]) by gateway.layern.com (8.12.11/8.12.11) with ESMTP id j6H0crSK003065 for ; Sat, 16 Jul 2005 19:38:53 -0500 Received: from ryan by pineapple.layern.com with local (Exim 4.50) id 1DtxBF-0000KD-B7 for freebsd-hackers@freebsd.org; Sat, 16 Jul 2005 19:38:53 -0500 Date: Sat, 16 Jul 2005 19:38:53 -0500 From: Ryan Nowakowski To: freebsd-hackers@freebsd.org Message-ID: <20050717003853.GK20287@pineapple.britestream.com> References: <20050715150500.GA19897@pineapple.britestream.com> <42D7D3ED.7030504@fs.ei.tum.de> <20050715161321.GA20287@pineapple.britestream.com> <319cceca05071509443dca4199@mail.gmail.com> <20050715203803.GD20287@pineapple.britestream.com> <42D82A7C.2010901@rfc2549.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42D82A7C.2010901@rfc2549.org> User-Agent: Mutt/1.5.9i X-Scanned-By: MIMEDefang 2.43 Subject: Re: Bootstrapping install from GRUB 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, 17 Jul 2005 00:38:57 -0000 On Fri, Jul 15, 2005 at 11:28:28PM +0200, Arne Schwabe wrote: > Ryan Nowakowski wrote: > > >FreeBSD loader doesn't load a kernel from ext2, fat16/32, or network so > >it's not usable in this case. > > > > > you can load the kernel from network via tftp at least with pxe loader > loads the kernel via tftp. > Yes, the pxe loader can load the kernel via tftp, however that requires PXE which doesn't meet my original requirements. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 16 16:54:28 2005 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 538CD16A41C for ; Sat, 16 Jul 2005 16:54:28 +0000 (GMT) (envelope-from dom@goodforbusiness.co.uk) Received: from mail.helenmarks.co.uk (mail.helenmarks.co.uk [82.68.196.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB95643D5E for ; Sat, 16 Jul 2005 16:54:27 +0000 (GMT) (envelope-from dom@goodforbusiness.co.uk) Received: from localhost (localhost [127.0.0.1]) by mail.helenmarks.co.uk (Postfix) with ESMTP id 8BB742710C02; Sat, 16 Jul 2005 17:54:26 +0100 (BST) Received: from mail.helenmarks.co.uk ([127.0.0.1]) by localhost (mail.helenmarks.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83350-08; Sat, 16 Jul 2005 17:54:22 +0100 (BST) Received: from egg (egg.helenmarks.co.uk [192.168.15.3]) by mail.helenmarks.co.uk (Postfix) with ESMTP id A14E42710C01; Sat, 16 Jul 2005 17:54:22 +0100 (BST) From: Dominic Marks To: freebsd-hackers@freebsd.org Date: Sat, 16 Jul 2005 17:56:57 +0100 User-Agent: KMail/1.8 References: <20050716194319.4375451a.vlady@sun-fish.com> In-Reply-To: <20050716194319.4375451a.vlady@sun-fish.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507161756.58334.dom@goodforbusiness.co.uk> X-Virus-Scanned: By ClamAV 0.85.1 X-Mailman-Approved-At: Sun, 17 Jul 2005 11:54:45 +0000 Cc: Subject: Re: Remove Heimdal Kerberos from my FreeBSD 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: Sat, 16 Jul 2005 16:54:28 -0000 On Saturday 16 July 2005 17:43, Vladimir Terziev wrote: > Hi, > > i've just installed a fresh FreeBSD 5.4 on my PC i saw i have > Heimdal Kerberos installed on it. I don't want Heimdal Kerberos on my > syetem! Could someone point me to a easy way to remove it and rebuild > all software (telnet, ssh, etc) which depends on it? In /etc/make.conf put NO_KERBEROS=yes Then build a new world. That should do the trick. I think freebsd-questions@freebsd.org would have been a more appropriate place to ask this question. > Thanks in advance! > > Vladimir > _______________________________________________ > 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" -- Dominic Marks From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 17 12:32:44 2005 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 BAFC416A41C for ; Sun, 17 Jul 2005 12:32:44 +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 DD41143D45 for ; Sun, 17 Jul 2005 12:32:41 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp246-29.lns2.adl2.internode.on.net [203.122.246.29]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j6HCWSsK044423 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 17 Jul 2005 22:02:34 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Sun, 17 Jul 2005 22:02:04 +0930 User-Agent: KMail/1.8.1 References: <20050716194319.4375451a.vlady@sun-fish.com> <200507161756.58334.dom@goodforbusiness.co.uk> In-Reply-To: <200507161756.58334.dom@goodforbusiness.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3169410.zETzdJiLS9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507172202.18757.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: Dominic Marks Subject: Re: Remove Heimdal Kerberos from my FreeBSD 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, 17 Jul 2005 12:32:44 -0000 --nextPart3169410.zETzdJiLS9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 17 July 2005 02:26, Dominic Marks wrote: > In /etc/make.conf put > > NO_KERBEROS=3Dyes > > Then build a new world. That should do the trick. This won't remove it, it will just not update it. You would have to delete it by hand. Telnet/ssh/etc don't have to depend on Kerberos and if you use the above=20 option they will be built without Kerb support. =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 --nextPart3169410.zETzdJiLS9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC2k/S5ZPcIHs/zowRAhogAJ9NoBRcqlyOk9ql4e4M+cxX+UpbwwCfYvT+ FX9BCVFopIVpKE51ZdO8eVQ= =Gr9T -----END PGP SIGNATURE----- --nextPart3169410.zETzdJiLS9-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 17 12:46:53 2005 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 A385616A41C for ; Sun, 17 Jul 2005 12:46:53 +0000 (GMT) (envelope-from vladimir.terziev@sun-fish.com) Received: from blah.sun-fish.com (blah.sun-fish.com [62.176.125.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC51043D45 for ; Sun, 17 Jul 2005 12:46:52 +0000 (GMT) (envelope-from vladimir.terziev@sun-fish.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id 2D9CB34164; Sun, 17 Jul 2005 14:46:50 +0200 (CEST) Received: from sun-fish.com (fs.cmotd.com [192.168.3.253]) by blah.sun-fish.com (Postfix) with ESMTP id ECBC834162; Sun, 17 Jul 2005 14:46:49 +0200 (CEST) Received: from sun-fish.com (localhost.cmotd.com [127.0.0.1]) by sun-fish.com (Postfix) with ESMTP id 716E238406; Sun, 17 Jul 2005 14:46:49 +0200 (CEST) Received: from daemon.cmotd.com (daemon.cmotd.com [192.168.3.104]) by sun-fish.com (Postfix) with SMTP id 3AD2C38404; Sun, 17 Jul 2005 14:46:49 +0200 (CEST) Date: Sun, 17 Jul 2005 15:46:49 +0300 From: Vladimir Terziev To: "Daniel O'Connor" Message-Id: <20050717154649.3d0a5520.vlady@sun-fish.com> In-Reply-To: <200507172202.18757.doconnor@gsoft.com.au> References: <20050716194319.4375451a.vlady@sun-fish.com> <200507161756.58334.dom@goodforbusiness.co.uk> <200507172202.18757.doconnor@gsoft.com.au> Organization: SunFish Ltd., Sofia X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.4.0; i386-unknown-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV X-AV-Checked: ClamAV SF1 Cc: freebsd-hackers@freebsd.org, dom@goodforbusiness.co.uk Subject: Re: Remove Heimdal Kerberos from my FreeBSD 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, 17 Jul 2005 12:46:53 -0000 Yes, i deleted it along with all libs related to it. This caused telnet/ssh/etc to stop working. So i rebuilt the world with NO_KERBEROS=yes and now all is like a charm -- no Heimdal Kerberos and no software depending on it. I think making the Heimdal Kerberos part of the base FreeBSD OS is bad idea, but linking base software (like telnet, ssh), which is part of the base FreeBSD OS, against it, is very very bad idea. Vladimir On Sun, 17 Jul 2005 22:02:04 +0930 "Daniel O'Connor" wrote: > On Sunday 17 July 2005 02:26, Dominic Marks wrote: > > In /etc/make.conf put > > > > NO_KERBEROS=yes > > > > Then build a new world. That should do the trick. > > This won't remove it, it will just not update it. > You would have to delete it by hand. > > Telnet/ssh/etc don't have to depend on Kerberos and if you use the above > option they will be built without Kerb support. > > -- > 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 > From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 17 21:16:31 2005 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 4E4F016A41C for ; Sun, 17 Jul 2005 21:16:31 +0000 (GMT) (envelope-from stsp@stsp.in-berlin.de) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id B47A443D49 for ; Sun, 17 Jul 2005 21:16:30 +0000 (GMT) (envelope-from stsp@stsp.in-berlin.de) X-Envelope-From: stsp@stsp.in-berlin.de X-Envelope-To: Received: from dice.seeling33.de (e178157109.adsl.alicedsl.de [85.178.157.109]) (authenticated bits=0) by einhorn.in-berlin.de (8.12.10/8.12.10/Debian-4) with ESMTP id j6HLGQAV024171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 17 Jul 2005 23:16:26 +0200 Received: by dice.seeling33.de (Postfix, from userid 1001) id C369833C25; Sun, 17 Jul 2005 23:16:25 +0200 (CEST) Date: Sun, 17 Jul 2005 23:16:25 +0200 From: Stefan Sperling To: freebsd-hackers@freebsd.org Message-ID: <20050717211625.GA7361@dice.seeling33.de> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Spam-Score: (-1.589) AWL,BAYES_00,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Subject: rfc: wake on lan patches for review 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, 17 Jul 2005 21:16:31 -0000 Hello Hackers, I have written a patch for the if_sis driver that enables wake on lan on the NatSemi DP8381[56] network chip. This did not work before because the driver needs to explicitely configure the card to enter wake on lan mode on system shutdown. I also added ioctls to make wake events configurable from userspace, and added an according 'wakeon ' command to ifconfig. The ioctls should be general enough to be used with other chips that require a similar configuration procedure for wake on lan. Before making efforts to get this committed I'd appreciate any comments and suggestions you may have. I'd especially appreciate people trying this at home if they have access to a network card with above mentioned chip. If you have a different card with wake on lan support that did not yet work as expected (i.e. your box does not wake up after shutting it down from FreeBSD), and have a datasheet available you might want to have a look at my code as an example on how to add wake on lan support to your card's driver. In my case, there wasn't much more to it than writing a couple of registers during the driver's shutdown procedure and implementing the new ioctls. You can find the patch at http://stsp.in-berlin.de/wol/ The patch applies cleanly to -current as of July 17th, and will probably apply to RELENG_6 just as well. regards, -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 17 23:30:31 2005 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 77FE216A41C for ; Sun, 17 Jul 2005 23:30:31 +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 9A47F43D45 for ; Sun, 17 Jul 2005 23:30:30 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.31]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j6HNUIb5064708 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 18 Jul 2005 09:00:25 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Vladimir Terziev Date: Mon, 18 Jul 2005 09:00:05 +0930 User-Agent: KMail/1.8.1 References: <20050716194319.4375451a.vlady@sun-fish.com> <200507172202.18757.doconnor@gsoft.com.au> <20050717154649.3d0a5520.vlady@sun-fish.com> In-Reply-To: <20050717154649.3d0a5520.vlady@sun-fish.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1349216.KIY4bF5HmA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507180900.15010.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: freebsd-hackers@freebsd.org, dom@goodforbusiness.co.uk Subject: Re: Remove Heimdal Kerberos from my FreeBSD 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, 17 Jul 2005 23:30:31 -0000 --nextPart1349216.KIY4bF5HmA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 17 July 2005 22:16, Vladimir Terziev wrote: > Yes, i deleted it along with all libs related to it. This caused > telnet/ssh/etc to stop working. So i rebuilt the world with NO_KERBEROS= =3Dyes > and now all is like a charm -- no Heimdal Kerberos and no software > depending on it. I think making the Heimdal Kerberos part of the base > FreeBSD OS is bad idea, but linking base software (like telnet, ssh), whi= ch > is part of the base FreeBSD OS, against it, is very very bad idea. Well you're entitled to your opinion but you might like to back it up with= =20 reasons.. =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 --nextPart1349216.KIY4bF5HmA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC2uoG5ZPcIHs/zowRAr//AJwJioLtZwckW/9Cx7DFc7YYudKM+gCfX5MM aTuuEQvyZoIDHcwGOjVQy+A= =Uaa7 -----END PGP SIGNATURE----- --nextPart1349216.KIY4bF5HmA-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 02:39:03 2005 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 DFA8E16A41C for ; Mon, 18 Jul 2005 02:39:03 +0000 (GMT) (envelope-from smartweb@leadhill.net) Received: from natco8.natcotech.com (natco8.natcotech.com [205.167.142.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6517C43D45 for ; Mon, 18 Jul 2005 02:39:03 +0000 (GMT) (envelope-from smartweb@leadhill.net) Received: from localhost (int9.natcotech.com [192.168.1.9]) by natco8.natcotech.com (Postfix) with ESMTP id 7606C29807F for ; Sun, 17 Jul 2005 21:39:02 -0500 (CDT) Received: from natco8.natcotech.com ([192.168.1.8]) by localhost (natco9 [192.168.1.9]) (amavisd-new, port 10024) with LMTP id 21595-01-20 for ; Sun, 17 Jul 2005 21:39:02 -0500 (CDT) Received: from ibm.nlcc.us (ldhl-ras1-dial-12-28-24-226.natcotech.com [12.28.24.226]) by natco8.natcotech.com (Postfix) with ESMTP id BE73329807C for ; Sun, 17 Jul 2005 21:39:01 -0500 (CDT) Received: (qmail 98918 invoked by uid 89); 18 Jul 2005 02:39:01 -0000 Received: from unknown (HELO ?192.168.0.2?) (192.168.0.2) by ibm.nlcc.us with SMTP; 18 Jul 2005 02:39:01 -0000 Message-ID: <42DB1642.4020801@leadhill.net> Date: Sun, 17 Jul 2005 21:38:58 -0500 From: Billy Newsom User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: stefan@aeschbacher.ch, hackers@freebsd.org References: <1121426237.42d79b3dcf954@horde.nts.ch> In-Reply-To: <1121426237.42d79b3dcf954@horde.nts.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at natco9.natcotech.com Cc: Subject: Re: rc.d ppp dependency 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, 18 Jul 2005 02:39:04 -0000 stefan@aeschbacher.ch wrote: > Hi > when using ppp together with pf there seems to exist a dependency problem. > I start ppp and pf with : ppp_enable="YES" and pf_enable="YES" in rc.conf. > > At startup when the pf rulefile is loaded, the tun0 (which I use in the pf > config) device does not yet exist and therefore the rules can not load. > > I noticed that in /etc/rc.d/ppp-user, ipfilter is resynced after ppp has > started. Shouldn't the same be done for pf? > > thanks > > Stefan > > P.S. a similar problem exists with sshd when a ListenAddress directive is > used with an address configured to tun0 Attn: I have been trying to get the same exact problem dealt with for ipnat and renaming interfaces. It appears that under FreeBSD 5-Stable, that although we are welcome to rename a network interface (like fxp0) to whatever we want (say out0), there seems to be a problem with the order in which things happen at boot. RENAMING happens after the ipnat has started, and so I feel that we need to re-sync ipnat after the renaming occurs. Otherwise, ipnat seems to have the old interface names, and ipnat will not work. Notice that in the rcorder of things, we see this (I skipped a bunch for brevity): ipfilter ... ipmon ... ipnat ipfs ... netif (interface renaming occurs; resync of ipfilter) isdnd ppp-user ipfw dhclient nsswitch ip6addrctl atm2 routing ip6fw network_ipv6 mroute6d route6d mrouted routed NETWORKING ... pflog pf pppoed ... localpkg natd What I see is that we need an IF-THEN-ELSE statement in the rcorder system someplace, that can notify pf if ppp is being used, and that will force ipnat to reload, etc. The ppp-user file, as you say, might need to reload pf if necessary. A simple patch could be thought up and attached here, huh? Can you post some of these comments as a bug (PR) to the FreeBSD system? I have one that could probably be fixed if my patch is used. See my related PR at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/81606 You might refer to PR 81606 as potentially being a similar issue with rcng. These thigns are slowly coming to light. rcng has got a lot of little tweaks it needs, especially if we start to let ports interact with the system rcng files. Billy From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 07:31:00 2005 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 EFBA316A41C for ; Mon, 18 Jul 2005 07:31:00 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42B2543D45 for ; Mon, 18 Jul 2005 07:30:57 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id j6I7Rsoe031478 for freebsd-hackers@freebsd.org.checked; Mon, 18 Jul 2005 11:27:54 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from [144.206.181.94] (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id j6I7RfFS031449; Mon, 18 Jul 2005 11:27:41 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <42DB59F9.80408@cronyx.ru> Date: Mon, 18 Jul 2005 11:27:53 +0400 From: Roman Kurakin User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladimir Terziev References: <20050716194319.4375451a.vlady@sun-fish.com> <200507161756.58334.dom@goodforbusiness.co.uk> <200507172202.18757.doconnor@gsoft.com.au> <20050717154649.3d0a5520.vlady@sun-fish.com> In-Reply-To: <20050717154649.3d0a5520.vlady@sun-fish.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dom@goodforbusiness.co.uk, freebsd-hackers@freebsd.org Subject: Re: Remove Heimdal Kerberos from my FreeBSD 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, 18 Jul 2005 07:31:01 -0000 Hi, Vladimir Terziev wrote: > Yes, i deleted it along with all libs related to it. This caused telnet/ssh/etc to stop working. So i rebuilt the world with NO_KERBEROS=yes and now all is like a charm -- no Heimdal Kerberos and no software depending on it. > I think making the Heimdal Kerberos part of the base FreeBSD OS is bad idea, but linking base software (like telnet, ssh), which is part of the base FreeBSD OS, against it, is very very bad idea. > > Why? Yes, all current OSs have a lot of useless things from some one point of view. For example, at work I do not need X while driver development, but at home I need it. At home I may not need almost all development tools. This is normal. If I want to setup a system fast and without additional efforts I'll setup a typical options. And I'll start use it as fast as it would be up. Most peoples do the same. It is better to have all thing in generic system that suits the majority. If you want to setup a custom system, you need to do it manually. rik > Vladimir > > >On Sun, 17 Jul 2005 22:02:04 +0930 >"Daniel O'Connor" wrote: > > > >>On Sunday 17 July 2005 02:26, Dominic Marks wrote: >> >> >>>In /etc/make.conf put >>> >>>NO_KERBEROS=yes >>> >>>Then build a new world. That should do the trick. >>> >>> >>This won't remove it, it will just not update it. >>You would have to delete it by hand. >> >>Telnet/ssh/etc don't have to depend on Kerberos and if you use the above >>option they will be built without Kerb support. >> >>-- >>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 >> >> >> >_______________________________________________ >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 Jul 18 08:33:38 2005 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 B268716A41C for ; Mon, 18 Jul 2005 08:33:38 +0000 (GMT) (envelope-from vladimir.terziev@sun-fish.com) Received: from blah.sun-fish.com (blah.sun-fish.com [62.176.125.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD44343D46 for ; Mon, 18 Jul 2005 08:33:37 +0000 (GMT) (envelope-from vladimir.terziev@sun-fish.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id B1F4C34196; Mon, 18 Jul 2005 10:33:34 +0200 (CEST) Received: from sun-fish.com (fs.cmotd.com [192.168.3.253]) by blah.sun-fish.com (Postfix) with ESMTP id 4B4D434193; Mon, 18 Jul 2005 10:33:34 +0200 (CEST) Received: from sun-fish.com (localhost.cmotd.com [127.0.0.1]) by sun-fish.com (Postfix) with ESMTP id B3E4B38406; Mon, 18 Jul 2005 10:33:33 +0200 (CEST) Received: from daemon.cmotd.com (daemon.cmotd.com [192.168.3.104]) by sun-fish.com (Postfix) with SMTP id 4CFB138404; Mon, 18 Jul 2005 10:33:33 +0200 (CEST) Date: Mon, 18 Jul 2005 11:33:33 +0300 From: Vladimir Terziev To: Roman Kurakin Message-Id: <20050718113333.4ab7ebb5.vlady@sun-fish.com> In-Reply-To: <42DB59F9.80408@cronyx.ru> References: <20050716194319.4375451a.vlady@sun-fish.com> <200507161756.58334.dom@goodforbusiness.co.uk> <200507172202.18757.doconnor@gsoft.com.au> <20050717154649.3d0a5520.vlady@sun-fish.com> <42DB59F9.80408@cronyx.ru> Organization: SunFish Ltd., Sofia X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.4.0; i386-unknown-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV X-AV-Checked: ClamAV SF1 Cc: dom@goodforbusiness.co.uk, freebsd-hackers@freebsd.org Subject: Re: Remove Heimdal Kerberos from my FreeBSD 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, 18 Jul 2005 08:33:38 -0000 Hi, your right about useless things, but making basic software to depend on these useless things is a very bad idea. I'm sure, telnet & ssh are the most used applications on any UNIX system, so they must not depend on any third party software by default. If you need kerberized ssh or telnet, then ok -- relink them to use kerberos, but why possible bugs in kerberos should affect ssh & telnet when kerberos is not mandantory for their functioning ? Vladimir On Mon, 18 Jul 2005 11:27:53 +0400 Roman Kurakin wrote: > Hi, > > Vladimir Terziev wrote: > > > Yes, i deleted it along with all libs related to it. This caused telnet/ssh/etc to stop working. So i rebuilt the world with NO_KERBEROS=yes and now all is like a charm -- no Heimdal Kerberos and no software depending on it. > > I think making the Heimdal Kerberos part of the base FreeBSD OS is bad idea, but linking base software (like telnet, ssh), which is part of the base FreeBSD OS, against it, is very very bad idea. > > > > > Why? Yes, all current OSs have a lot of useless things from some one > point of view. > For example, at work I do not need X while driver development, but at > home I need it. > At home I may not need almost all development tools. > This is normal. If I want to setup a system fast and without additional > efforts I'll setup > a typical options. And I'll start use it as fast as it would be up. Most > peoples do the > same. > > It is better to have all thing in generic system that suits the majority. > If you want to setup a custom system, you need to do it manually. > > rik > > > Vladimir > > > > > >On Sun, 17 Jul 2005 22:02:04 +0930 > >"Daniel O'Connor" wrote: > > > > > > > >>On Sunday 17 July 2005 02:26, Dominic Marks wrote: > >> > >> > >>>In /etc/make.conf put > >>> > >>>NO_KERBEROS=yes > >>> > >>>Then build a new world. That should do the trick. > >>> > >>> > >>This won't remove it, it will just not update it. > >>You would have to delete it by hand. > >> > >>Telnet/ssh/etc don't have to depend on Kerberos and if you use the above > >>option they will be built without Kerb support. > >> > >>-- > >>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 > >> > >> > >> > >_______________________________________________ > >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 Jul 18 09:15:55 2005 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 C627716A41C for ; Mon, 18 Jul 2005 09:15:55 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24C1443D53 for ; Mon, 18 Jul 2005 09:15:54 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id j6I9CsVR032475 for freebsd-hackers@freebsd.org.checked; Mon, 18 Jul 2005 13:12:54 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from [144.206.181.94] (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id j6I9BBTd032456; Mon, 18 Jul 2005 13:11:11 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <42DB723B.8060501@cronyx.ru> Date: Mon, 18 Jul 2005 13:11:23 +0400 From: Roman Kurakin User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladimir Terziev References: <20050716194319.4375451a.vlady@sun-fish.com> <200507161756.58334.dom@goodforbusiness.co.uk> <200507172202.18757.doconnor@gsoft.com.au> <20050717154649.3d0a5520.vlady@sun-fish.com> <42DB59F9.80408@cronyx.ru> <20050718113333.4ab7ebb5.vlady@sun-fish.com> In-Reply-To: <20050718113333.4ab7ebb5.vlady@sun-fish.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dom@goodforbusiness.co.uk, freebsd-hackers@freebsd.org Subject: Re: Remove Heimdal Kerberos from my FreeBSD 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, 18 Jul 2005 09:15:55 -0000 Vladimir Terziev wrote: > Hi, > > your right about useless things, but making basic software to depend on these useless things is a very bad idea. > I'm sure, telnet & ssh are the most used applications on any UNIX system, so they must not depend on any third party software by default. If you need kerberized ssh or telnet, then ok -- relink them to use kerberos, but why possible bugs in kerberos should affect ssh & telnet when kerberos is not mandantory for their functioning? > > It depends on what we chose as a basic functionality. One wouldn't use it, for other person it is necessary. Again, for generic system it is normal to have extra functionality. If we remove it, many persons would suffer from that. If you do not need it, just do not use it. And all one would be happy. It is not a problem to depend on kerberos till it isn't removed. The worse thing is indirect depend. Why I have to setup lib by dependence, that is needed by the unused functions from the lib I use? The same would be to ask to remove those functions from that lib since they add extra dependance. If smth is commonly used, even not by majority but by quite nomerous community it should be in generic system. No one is restricted to customize system for any particular case. If you have such ability there is no any problem. rik > Vladimir > > >On Mon, 18 Jul 2005 11:27:53 +0400 >Roman Kurakin wrote: > > > >>Hi, >> >>Vladimir Terziev wrote: >> >> >> >>> Yes, i deleted it along with all libs related to it. This caused telnet/ssh/etc to stop working. So i rebuilt the world with NO_KERBEROS=yes and now all is like a charm -- no Heimdal Kerberos and no software depending on it. >>> I think making the Heimdal Kerberos part of the base FreeBSD OS is bad idea, but linking base software (like telnet, ssh), which is part of the base FreeBSD OS, against it, is very very bad idea. >>> >>> >>> >>> >>Why? Yes, all current OSs have a lot of useless things from some one >>point of view. >>For example, at work I do not need X while driver development, but at >>home I need it. >>At home I may not need almost all development tools. >>This is normal. If I want to setup a system fast and without additional >>efforts I'll setup >>a typical options. And I'll start use it as fast as it would be up. Most >>peoples do the >>same. >> >>It is better to have all thing in generic system that suits the majority. >>If you want to setup a custom system, you need to do it manually. >> >>rik >> >> >> >>> Vladimir >>> >>> >>>On Sun, 17 Jul 2005 22:02:04 +0930 >>>"Daniel O'Connor" wrote: >>> >>> >>> >>> >>> >>>>On Sunday 17 July 2005 02:26, Dominic Marks wrote: >>>> >>>> >>>> >>>> >>>>>In /etc/make.conf put >>>>> >>>>>NO_KERBEROS=yes >>>>> >>>>>Then build a new world. That should do the trick. >>>>> >>>>> >>>>> >>>>> >>>>This won't remove it, it will just not update it. >>>>You would have to delete it by hand. >>>> >>>>Telnet/ssh/etc don't have to depend on Kerberos and if you use the above >>>>option they will be built without Kerb support. >>>> >>>>-- >>>>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 >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>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" >>> >>> >>> >>> >_______________________________________________ >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 Jul 18 09:24:10 2005 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 A203716A41C for ; Mon, 18 Jul 2005 09:24:10 +0000 (GMT) (envelope-from vladimir.terziev@sun-fish.com) Received: from blah.sun-fish.com (blah.sun-fish.com [62.176.125.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 942D143D4C for ; Mon, 18 Jul 2005 09:24:09 +0000 (GMT) (envelope-from vladimir.terziev@sun-fish.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id 0B76C3417A; Mon, 18 Jul 2005 11:24:08 +0200 (CEST) Received: from sun-fish.com (fs.cmotd.com [192.168.3.253]) by blah.sun-fish.com (Postfix) with ESMTP id C8DB834164; Mon, 18 Jul 2005 11:24:07 +0200 (CEST) Received: from sun-fish.com (localhost.cmotd.com [127.0.0.1]) by sun-fish.com (Postfix) with ESMTP id 4D8A23840A; Mon, 18 Jul 2005 11:24:07 +0200 (CEST) Received: from daemon.cmotd.com (daemon.cmotd.com [192.168.3.104]) by sun-fish.com (Postfix) with SMTP id 15DC538409; Mon, 18 Jul 2005 11:24:07 +0200 (CEST) Date: Mon, 18 Jul 2005 12:24:07 +0300 From: Vladimir Terziev To: Roman Kurakin Message-Id: <20050718122407.1c064644.vlady@sun-fish.com> In-Reply-To: <42DB723B.8060501@cronyx.ru> References: <20050716194319.4375451a.vlady@sun-fish.com> <200507161756.58334.dom@goodforbusiness.co.uk> <200507172202.18757.doconnor@gsoft.com.au> <20050717154649.3d0a5520.vlady@sun-fish.com> <42DB59F9.80408@cronyx.ru> <20050718113333.4ab7ebb5.vlady@sun-fish.com> <42DB723B.8060501@cronyx.ru> Organization: SunFish Ltd., Sofia X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.4.0; i386-unknown-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV X-AV-Checked: ClamAV SF1 Cc: dom@goodforbusiness.co.uk, freebsd-hackers@freebsd.org Subject: Re: Remove Heimdal Kerberos from my FreeBSD 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, 18 Jul 2005 09:24:10 -0000 Hi, i'm sure most of the FreeBSD users do not need kerberos for authnetication. Things should be kept simple, not generic -- this is one of the principles of UNIX. If someone needs telnet+kerberos, then ok, such meta port could be created and this person will just need to install it, but importing something in the base system which is NOT commonly used is not a good idea, as i've already said. Vladimir On Mon, 18 Jul 2005 13:11:23 +0400 Roman Kurakin wrote: > Vladimir Terziev wrote: > > > Hi, > > > > your right about useless things, but making basic software to depend on these useless things is a very bad idea. > > I'm sure, telnet & ssh are the most used applications on any UNIX system, so they must not depend on any third party software by default. If you need kerberized ssh or telnet, then ok -- relink them to use kerberos, but why possible bugs in kerberos should affect ssh & telnet when kerberos is not mandantory for their functioning? > > > > > It depends on what we chose as a basic functionality. One wouldn't use > it, for other > person it is necessary. Again, for generic system it is normal to have > extra functionality. > If we remove it, many persons would suffer from that. If you do not need > it, just do > not use it. And all one would be happy. > It is not a problem to depend on kerberos till it isn't removed. > > The worse thing is indirect depend. Why I have to setup lib by dependence, > that is needed by the unused functions from the lib I use? The same would be > to ask to remove those functions from that lib since they add extra > dependance. > > If smth is commonly used, even not by majority but by quite nomerous > community it should be in generic system. No one is restricted to customize > system for any particular case. If you have such ability there is no any > problem. > > rik > > > Vladimir > > > > > >On Mon, 18 Jul 2005 11:27:53 +0400 > >Roman Kurakin wrote: > > > > > > > >>Hi, > >> > >>Vladimir Terziev wrote: > >> > >> > >> > >>> Yes, i deleted it along with all libs related to it. This caused telnet/ssh/etc to stop working. So i rebuilt the world with NO_KERBEROS=yes and now all is like a charm -- no Heimdal Kerberos and no software depending on it. > >>> I think making the Heimdal Kerberos part of the base FreeBSD OS is bad idea, but linking base software (like telnet, ssh), which is part of the base FreeBSD OS, against it, is very very bad idea. > >>> > >>> > >>> > >>> > >>Why? Yes, all current OSs have a lot of useless things from some one > >>point of view. > >>For example, at work I do not need X while driver development, but at > >>home I need it. > >>At home I may not need almost all development tools. > >>This is normal. If I want to setup a system fast and without additional > >>efforts I'll setup > >>a typical options. And I'll start use it as fast as it would be up. Most > >>peoples do the > >>same. > >> > >>It is better to have all thing in generic system that suits the majority. > >>If you want to setup a custom system, you need to do it manually. > >> > >>rik > >> > >> > >> > >>> Vladimir > >>> > >>> > >>>On Sun, 17 Jul 2005 22:02:04 +0930 > >>>"Daniel O'Connor" wrote: > >>> > >>> > >>> > >>> > >>> > >>>>On Sunday 17 July 2005 02:26, Dominic Marks wrote: > >>>> > >>>> > >>>> > >>>> > >>>>>In /etc/make.conf put > >>>>> > >>>>>NO_KERBEROS=yes > >>>>> > >>>>>Then build a new world. That should do the trick. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>This won't remove it, it will just not update it. > >>>>You would have to delete it by hand. > >>>> > >>>>Telnet/ssh/etc don't have to depend on Kerberos and if you use the above > >>>>option they will be built without Kerb support. > >>>> > >>>>-- > >>>>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 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>_______________________________________________ > >>>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" > >>> > >>> > >>> > >>> > >_______________________________________________ > >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 Jul 18 10:51:18 2005 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 6EA9A16A41C for ; Mon, 18 Jul 2005 10:51:18 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from mallaury.nerim.net (smtp-101-monday.noc.nerim.net [62.4.17.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3AC643D46 for ; Mon, 18 Jul 2005 10:51:17 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoft.net1.nerim.net [62.212.107.51]) by mallaury.nerim.net (Postfix) with ESMTP id D79DB4F3B8; Mon, 18 Jul 2005 12:51:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by srvbsdnanssv.interne.kisoft-services.com (Postfix) with ESMTP id 4527FC592; Mon, 18 Jul 2005 12:51:26 +0200 (CEST) Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) by localhost (srvbsdnanssv.interne.kisoft-services.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89725-01; Mon, 18 Jul 2005 12:51:21 +0200 (CEST) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id AECC9C25B; Mon, 18 Jul 2005 12:51:21 +0200 (CEST) To: Vladimir Terziev From: Eric Masson In-Reply-To: <20050718122407.1c064644.vlady@sun-fish.com> (Vladimir Terziev's message of "Mon, 18 Jul 2005 12:24:07 +0300") References: <20050716194319.4375451a.vlady@sun-fish.com> <200507161756.58334.dom@goodforbusiness.co.uk> <200507172202.18757.doconnor@gsoft.com.au> <20050717154649.3d0a5520.vlady@sun-fish.com> <42DB59F9.80408@cronyx.ru> <20050718113333.4ab7ebb5.vlady@sun-fish.com> <42DB723B.8060501@cronyx.ru> <20050718122407.1c064644.vlady@sun-fish.com> X-Operating-System: FreeBSD 5.4-RELEASE-p2 i386 Date: Mon, 18 Jul 2005 12:51:21 +0200 Message-ID: <86br50v13q.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at interne.kisoft-services.com Cc: dom@goodforbusiness.co.uk, freebsd-hackers@freebsd.org, Roman Kurakin Subject: Re: Remove Heimdal Kerberos from my FreeBSD 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, 18 Jul 2005 10:51:18 -0000 Vladimir Terziev writes: Hi. > i'm sure most of the FreeBSD users do not need kerberos for > authnetication. Could you give me your fortune teller crystal ball brand ? > If someone needs telnet+kerberos, then ok, such meta port could be > created and this person will just need to install it, but importing > something in the base system which is NOT commonly used is not a good > idea, as i've already said. More and more shops have Active Directory domains and windows boxes, Kerberos support is something important in these shops. So tune your system for your own use and refrain telling others how they should work. Éric Masson -- AB : (...) et encore on semble échapper aux betas :-, LF : bah peut-être qu'ils en font plus ;-) GG : Ils auraient embauché des types de Microsoft ? -+- GG in Guide du Macounet Pervers : Bah oui, gros béta ! -+- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 11:26:30 2005 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 7151816A41C for ; Mon, 18 Jul 2005 11:26:30 +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 8E39C43D45 for ; Mon, 18 Jul 2005 11:26:29 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp246-29.lns2.adl2.internode.on.net [203.122.246.29]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j6IBQ42Z073945 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 18 Jul 2005 20:56:10 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Vladimir Terziev Date: Mon, 18 Jul 2005 20:55:57 +0930 User-Agent: KMail/1.8.1 References: <20050716194319.4375451a.vlady@sun-fish.com> <42DB59F9.80408@cronyx.ru> <20050718113333.4ab7ebb5.vlady@sun-fish.com> In-Reply-To: <20050718113333.4ab7ebb5.vlady@sun-fish.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart13680153.z8i0WlPmiy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507182055.57651.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: freebsd-hackers@freebsd.org, dom@goodforbusiness.co.uk, Roman Kurakin Subject: Re: Remove Heimdal Kerberos from my FreeBSD 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, 18 Jul 2005 11:26:30 -0000 --nextPart13680153.z8i0WlPmiy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 18 July 2005 18:03, Vladimir Terziev wrote: > your right about useless things, but making basic software to depend on > these useless things is a very bad idea. I'm sure, telnet & ssh are the > most used applications on any UNIX system, so they must not depend on any > third party software by default. If you need kerberized ssh or telnet, th= en > ok -- relink them to use kerberos, but why possible bugs in kerberos shou= ld > affect ssh & telnet when kerberos is not mandantory for their functioning= ? I think this is slightly disingenuous - what is the actual penalty for link= ing=20 to Kerberos? It is easy to not use Kerberos if you don't want to, but it's a major pain = in=20 the ass to recompile ssh/telnet/etc when you do. =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 --nextPart13680153.z8i0WlPmiy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC25HF5ZPcIHs/zowRAssGAJ9ZelXvyyTut2eFzSNw4xPDVrfyFgCgphHq iGOMdlZPwnWDfXyoG7yHhlw= =7not -----END PGP SIGNATURE----- --nextPart13680153.z8i0WlPmiy-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 11:44:24 2005 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 C029616A41C for ; Mon, 18 Jul 2005 11:44:24 +0000 (GMT) (envelope-from vladimir.terziev@sun-fish.com) Received: from blah.sun-fish.com (blah.sun-fish.com [62.176.125.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id B99D943D46 for ; Mon, 18 Jul 2005 11:44:23 +0000 (GMT) (envelope-from vladimir.terziev@sun-fish.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id 084813417A; Mon, 18 Jul 2005 13:44:22 +0200 (CEST) Received: from sun-fish.com (fs.cmotd.com [192.168.3.253]) by blah.sun-fish.com (Postfix) with ESMTP id C597F34169; Mon, 18 Jul 2005 13:44:21 +0200 (CEST) Received: from sun-fish.com (localhost.cmotd.com [127.0.0.1]) by sun-fish.com (Postfix) with ESMTP id 47D3338406; Mon, 18 Jul 2005 13:44:21 +0200 (CEST) Received: from daemon.cmotd.com (daemon.cmotd.com [192.168.3.104]) by sun-fish.com (Postfix) with SMTP id 0FB9038404; Mon, 18 Jul 2005 13:44:21 +0200 (CEST) Date: Mon, 18 Jul 2005 14:44:21 +0300 From: Vladimir Terziev To: "Daniel O'Connor" Message-Id: <20050718144421.68977452.vlady@sun-fish.com> In-Reply-To: <200507182055.57651.doconnor@gsoft.com.au> References: <20050716194319.4375451a.vlady@sun-fish.com> <42DB59F9.80408@cronyx.ru> <20050718113333.4ab7ebb5.vlady@sun-fish.com> <200507182055.57651.doconnor@gsoft.com.au> Organization: SunFish Ltd., Sofia X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.4.0; i386-unknown-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV X-AV-Checked: ClamAV SF1 Cc: freebsd-hackers@freebsd.org, dom@goodforbusiness.co.uk, rik@cronyx.ru Subject: Re: Remove Heimdal Kerberos from my FreeBSD 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, 18 Jul 2005 11:44:24 -0000 The problem is that third party software is a part of basic software, which functionality includes authentication and authorization for host access. A bug in this third party software could become a reason for a host compromise even the functionality of the third party software in not used (e.g. bug in the kerberos libs could involve sshd/telnetd compromise). When you really need a kerberos authentication then re-build the respective software in order to have it. But in that case, you'll be aware that your access-granting software depends on something other and you'll be aware to keep this something other up-to-date and bugless. Vladimir On Mon, 18 Jul 2005 20:55:57 +0930 "Daniel O'Connor" wrote: > On Monday 18 July 2005 18:03, Vladimir Terziev wrote: > > your right about useless things, but making basic software to depend on > > these useless things is a very bad idea. I'm sure, telnet & ssh are the > > most used applications on any UNIX system, so they must not depend on any > > third party software by default. If you need kerberized ssh or telnet, then > > ok -- relink them to use kerberos, but why possible bugs in kerberos should > > affect ssh & telnet when kerberos is not mandantory for their functioning ? > > I think this is slightly disingenuous - what is the actual penalty for linking > to Kerberos? > > It is easy to not use Kerberos if you don't want to, but it's a major pain in > the ass to recompile ssh/telnet/etc when you do. > > -- > 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 > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 12:15:31 2005 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 E3C4216A45D for ; Mon, 18 Jul 2005 12:15:30 +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 2EC5C43D48 for ; Mon, 18 Jul 2005 12:15:28 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp246-29.lns2.adl2.internode.on.net [203.122.246.29]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j6ICF2Qe074278 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 18 Jul 2005 21:45:11 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Vladimir Terziev Date: Mon, 18 Jul 2005 21:44:35 +0930 User-Agent: KMail/1.8.1 References: <20050716194319.4375451a.vlady@sun-fish.com> <200507182055.57651.doconnor@gsoft.com.au> <20050718144421.68977452.vlady@sun-fish.com> In-Reply-To: <20050718144421.68977452.vlady@sun-fish.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4331901.KkxNW5LqM0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507182144.49399.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: freebsd-hackers@freebsd.org, dom@goodforbusiness.co.uk, rik@cronyx.ru Subject: Re: Remove Heimdal Kerberos from my FreeBSD 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, 18 Jul 2005 12:15:31 -0000 --nextPart4331901.KkxNW5LqM0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 18 July 2005 21:14, Vladimir Terziev wrote: > The problem is that third party software is a part of basic software, > which functionality includes authentication and authorization for host > access. A bug in this third party software could become a reason for a ho= st > compromise even the functionality of the third party software in not used > (e.g. bug in the kerberos libs could involve sshd/telnetd compromise). I think you can extend this argument to just about any piece of software on= =20 the system.. > When you really need a kerberos authentication then re-build the > respective software in order to have it. But in that case, you'll be aware > that your access-granting software depends on something other and you'll = be > aware to keep this something other up-to-date and bugless. That is a pretty major inconvenience. It's like saying "Oh well if you want= to=20 use NSS you should rebuild things" - you can do it but it's very=20 inconvenient. There is always a trade off but it seems most people don't think Heimdal is= =20 insecure enough to disable by default. (Has it has any bugs that have been= =20 exploitable in an unused configuration recently? I don't believe so). Personally I'd be more worried about the PAM code. =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 --nextPart4331901.KkxNW5LqM0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC25055ZPcIHs/zowRAqsPAJwMON0Yc+QooK0Ltt3ESxiK/Qt8CwCeJvfa cWZm0Wc9lOoqvijXisDF1qg= =pzhX -----END PGP SIGNATURE----- --nextPart4331901.KkxNW5LqM0-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 15:09:14 2005 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 5528816A41C for ; Mon, 18 Jul 2005 15:09:14 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id F258D43D46 for ; Mon, 18 Jul 2005 15:09:11 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 1845846B9A; Mon, 18 Jul 2005 11:09:11 -0400 (EDT) Date: Mon, 18 Jul 2005 16:09:13 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Vladimir Terziev In-Reply-To: <20050718144421.68977452.vlady@sun-fish.com> Message-ID: <20050718160610.E9430@fledge.watson.org> References: <20050716194319.4375451a.vlady@sun-fish.com> <42DB59F9.80408@cronyx.ru> <20050718113333.4ab7ebb5.vlady@sun-fish.com> <200507182055.57651.doconnor@gsoft.com.au> <20050718144421.68977452.vlady@sun-fish.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: rik@cronyx.ru, dom@goodforbusiness.co.uk, freebsd-hackers@freebsd.org Subject: Re: Remove Heimdal Kerberos from my FreeBSD 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, 18 Jul 2005 15:09:14 -0000 On Mon, 18 Jul 2005, Vladimir Terziev wrote: > The problem is that third party software is a part of basic software, > which functionality includes authentication and authorization for host > access. A bug in this third party software could become a reason for a > host compromise even the functionality of the third party software in > not used (e.g. bug in the kerberos libs could involve sshd/telnetd > compromise). > > When you really need a kerberos authentication then re-build the > respective software in order to have it. But in that case, you'll be > aware that your access-granting software depends on something other and > you'll be aware to keep this something other up-to-date and bugless. Expectations have changed over the last few years -- support for integrating into directory services, such as Active Directory and/or Kerberos, is now considered a basic expectation for operating systems, and as such is a "built by default" feature. Any time you increase the quantity of code, especially security/network-sensitive code, you increase the opportunity for problems, but where one sits on the spectrum of "enabled by default" functionality has to be a response to user requirements. The direction we've been going in to minimize exposure has been to disable features at run-time, rather than compile-time. I.e., we no longer enable telnetd, ftpd, etc, by default -- they must be explicitly enabled. Robert N M Watson > > Vladimir > > > On Mon, 18 Jul 2005 20:55:57 +0930 > "Daniel O'Connor" wrote: > >> On Monday 18 July 2005 18:03, Vladimir Terziev wrote: >>> your right about useless things, but making basic software to depend on >>> these useless things is a very bad idea. I'm sure, telnet & ssh are the >>> most used applications on any UNIX system, so they must not depend on any >>> third party software by default. If you need kerberized ssh or telnet, then >>> ok -- relink them to use kerberos, but why possible bugs in kerberos should >>> affect ssh & telnet when kerberos is not mandantory for their functioning ? >> >> I think this is slightly disingenuous - what is the actual penalty for linking >> to Kerberos? >> >> It is easy to not use Kerberos if you don't want to, but it's a major pain in >> the ass to recompile ssh/telnet/etc when you do. >> >> -- >> 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 >> > _______________________________________________ > 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 Jul 18 15:23:50 2005 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 309C116A41C for ; Mon, 18 Jul 2005 15:23:50 +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 BCEA443D45 for ; Mon, 18 Jul 2005 15:23:49 +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 D478135717 for ; Mon, 18 Jul 2005 17:23:47 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id AC0F858FC; Mon, 18 Jul 2005 16:30:22 +0200 (CEST) Date: Mon, 18 Jul 2005 16:30:22 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20050718143022.GA1398@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20050716194319.4375451a.vlady@sun-fish.com> <200507182055.57651.doconnor@gsoft.com.au> <20050718144421.68977452.vlady@sun-fish.com> <200507182144.49399.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507182144.49399.doconnor@gsoft.com.au> User-Agent: Mutt/1.5.6i Subject: Re: Remove Heimdal Kerberos from my FreeBSD 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, 18 Jul 2005 15:23:50 -0000 On Mon, Jul 18, 2005 at 09:44:35PM +0930, Daniel O'Connor wrote: > There is always a trade off but it seems most people don't think Heimdal is > insecure enough to disable by default. (Has it has any bugs that have been > exploitable in an unused configuration recently? I don't believe so). In the last two years, there have been some nasty problems in Heimdal, not as bad as MIT krb5 though. This is from memory, I might be wrong. For the original poster, the default is a trade-off, it has both postive and negative sides. In DragonFly, we still default to OFF, mostly because we can't take advantage of it e.g. for smb anyway, since we don't have NSS. Beside the given example of Active Directory, NFS 4 uses GSSAPI and Kerberos 5 too. Those are two things a lot of people want to support of the box. Joerg From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 20:08:38 2005 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 D3C3816A41C for ; Mon, 18 Jul 2005 20:08:38 +0000 (GMT) (envelope-from gollum123@free.fr) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1017043D45 for ; Mon, 18 Jul 2005 20:08:37 +0000 (GMT) (envelope-from gollum123@free.fr) Received: from [192.168.0.140] (tui75-2-82-229-178-102.fbx.proxad.net [82.229.178.102]) by postfix3-1.free.fr (Postfix) with ESMTP id DBC141734A6; Mon, 18 Jul 2005 22:08:36 +0200 (CEST) Date: Mon, 18 Jul 2005 22:08:41 +0200 From: Mathieu CHATEAU X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <1197834201.20050718220841@free.fr> To: "J. Martin Petersen" In-Reply-To: <42D77323.7030903@alvorlig.dk> References: <42D77323.7030903@alvorlig.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Per CPU load statistics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mathieu CHATEAU List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 20:08:38 -0000 Hello, you can trough snmp & cacti for example. cheers, Friday, July 15, 2005, 10:26:11 AM, you wrote: JMP> Hi JMP> Is it possible to get per CPU (load) statistics? It seems cp_time is a JMP> sum for all the CPUs, so is there another way to get this information? I JMP> looked through the source, but I'm not quite sure what to look for. JMP> Cheers, Martin JMP> _______________________________________________ JMP> freebsd-hackers@freebsd.org mailing list JMP> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers JMP> To unsubscribe, send any mail to JMP> "freebsd-hackers-unsubscribe@freebsd.org" -- Best regards, Mathieu mailto:gollum123@free.fr From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 20:47:24 2005 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 B2E9E16A41C for ; Mon, 18 Jul 2005 20:47:24 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3241D43D45 for ; Mon, 18 Jul 2005 20:47:24 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: by wproxy.gmail.com with SMTP id 36so1095827wra for ; Mon, 18 Jul 2005 13:47:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=qRBpNyShLTtUSdzM5G9gLHnyJIFVEhUBI8exZuPURULC6mJCAhKSs7WchmBHh8h2lcA+m1T+lLT3WFytobif54i1qfQ0VU1VDeSCpR0TORGkClAQRu+vLEL6H7NgqYnkGALNMoMk/BBC/nIFdPH8vjweWap4yd5jxC2NKxEjfOM= Received: by 10.54.11.12 with SMTP id 12mr507793wrk; Mon, 18 Jul 2005 13:46:26 -0700 (PDT) Received: by 10.54.91.20 with HTTP; Mon, 18 Jul 2005 13:46:26 -0700 (PDT) Message-ID: <49402550507181346736e973f@mail.gmail.com> Date: Mon, 18 Jul 2005 23:46:26 +0300 From: victor cruceru To: Mathieu CHATEAU In-Reply-To: <1197834201.20050718220841@free.fr> Mime-Version: 1.0 References: <42D77323.7030903@alvorlig.dk> <1197834201.20050718220841@free.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "J. Martin Petersen" , freebsd-hackers@freebsd.org Subject: Re: Per CPU load statistics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soc-victor@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 20:47:24 -0000 Hi all, Could you please give more details?=20 Because the SNMP agent must query the O/S (FreeBSD in this case) for these= =20 stats.=20 Thanks, Victor Crcueru On 7/18/05, Mathieu CHATEAU wrote: >=20 > Hello, >=20 > you can trough snmp & cacti for example. >=20 > cheers, >=20 > Friday, July 15, 2005, 10:26:11 AM, you wrote: >=20 > JMP> Hi >=20 > JMP> Is it possible to get per CPU (load) statistics? It seems cp_time is= =20 > a > JMP> sum for all the CPUs, so is there another way to get this=20 > information? I > JMP> looked through the source, but I'm not quite sure what to look for. >=20 > JMP> Cheers, Martin > JMP> _______________________________________________ > JMP> freebsd-hackers@freebsd.org mailing list > JMP> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > JMP> To unsubscribe, send any mail to > JMP> "freebsd-hackers-unsubscribe@freebsd.org" >=20 >=20 >=20 > -- > Best regards, > Mathieu mailto:gollum123@free.fr >=20 > _______________________________________________ > 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 Jul 18 21:29:00 2005 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 1CC8016A41C; Mon, 18 Jul 2005 21:29:00 +0000 (GMT) (envelope-from gollum123@free.fr) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id B007843D49; Mon, 18 Jul 2005 21:28:59 +0000 (GMT) (envelope-from gollum123@free.fr) Received: from [192.168.0.140] (tui75-2-82-229-178-102.fbx.proxad.net [82.229.178.102]) by postfix3-1.free.fr (Postfix) with ESMTP id 7EEB91734C9; Mon, 18 Jul 2005 23:28:58 +0200 (CEST) Date: Mon, 18 Jul 2005 23:29:03 +0200 From: Mathieu CHATEAU X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <397406144.20050718232903@free.fr> To: victor cruceru In-Reply-To: <49402550507181346736e973f@mail.gmail.com> References: <42D77323.7030903@alvorlig.dk> <1197834201.20050718220841@free.fr> <49402550507181346736e973f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: soc-victor@freebsd.org, "J. Martin Petersen" , freebsd-hackers@freebsd.org Subject: Re[2]: Per CPU load statistics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mathieu CHATEAU List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 21:29:00 -0000 Hello victor, sorry i messed up my mind between graph. i have only one graph about cpu trough cacti :'( Monday, July 18, 2005, 10:46:26 PM, you wrote: vc> Hi all, vc> Could you please give more details? vc> Because the SNMP agent must query the O/S (FreeBSD in this case) for these  stats. vc> Thanks, vc> Victor Crcueru vc> On 7/18/05, Mathieu CHATEAU wrote: vc> Hello, vc> you can trough snmp & cacti for example. vc> cheers, vc> Friday, July 15, 2005, 10:26:11 AM, you wrote: JMP>> Hi JMP>> Is it possible to get per CPU (load) statistics? It seems cp_time is a JMP>> sum for all the CPUs, so is there another way to get this information? I JMP>> looked through the source, but I'm not quite sure what to look for. JMP>> Cheers, Martin JMP>> _______________________________________________ JMP>> freebsd-hackers@freebsd.org mailing list JMP>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers JMP>> To unsubscribe, send any mail to JMP>> "freebsd-hackers-unsubscribe@freebsd.org" vc> -- vc> Best regards, vc> Mathieu                            mailto:gollum123@free.fr vc> _______________________________________________ vc> freebsd-hackers@freebsd.org mailing list vc> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers vc> To unsubscribe, send any mail to " vc> freebsd-hackers-unsubscribe@freebsd.org" -- Best regards, Mathieu mailto:gollum123@free.fr From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 19 03:42:16 2005 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 4FA5116A41C for ; Tue, 19 Jul 2005 03:42:16 +0000 (GMT) (envelope-from edwin@verolan.com) Received: from ns11.webmasters.com (ns11.webmasters.com [66.118.156.2]) by mx1.FreeBSD.org (Postfix) with SMTP id E03B143D45 for ; Tue, 19 Jul 2005 03:42:15 +0000 (GMT) (envelope-from edwin@verolan.com) Received: (qmail 31320 invoked from network); 19 Jul 2005 03:39:07 -0000 Received: from unknown (HELO localhost.localdomain) (204.9.60.14) by ns11.webmasters.com with SMTP; 19 Jul 2005 03:39:07 -0000 Received: from localhost.localdomain (asx01 [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j6J3gFIQ020768; Mon, 18 Jul 2005 23:42:15 -0400 Received: (from edwin@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id j6J3gFXp020767; Mon, 18 Jul 2005 23:42:15 -0400 Date: Mon, 18 Jul 2005 23:42:15 -0400 From: Edwin To: freebsd-hackers@freebsd.org Message-ID: <20050719034215.GB20752@asx01.verolan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: Linux/(i686) Cc: edwin@verolan.com Subject: help w/panic under heavy load - 5.4 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, 19 Jul 2005 03:42:16 -0000 Hi, I have a recurring (re-producible) panic on the 5.3/5.4 kernels and I would like to ask for some help in tracking it down. :) - it could be some misconfig on my part - but i have tried several different configs of the kernel - ultimately w/ polling on/off, ipfw on/off, ipfastforwarding on/off - although with ipff off - the box still crashes but in a different location - it will even crash w/ GENERIC kernel under heavy load. I'm not quite sure where to look past the below (ie. what variables/etc to present to the list). Thanks! /edwin details are: - Soekris net4801 platform (SBC w/ Geode processor - i586 class). - similar crash was seen (as regularly) under 5.3 as well - just never got around to getting crashdump/etc. - crash is re-producible under heavy load here is the crash-info: fb54c# Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x8:0xc0647527 stack pointer = 0x10:0xc7692b78 frame pointer = 0x10:0xc7692b9c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 29 (swi1: net) trap number = 12 panic: page fault Uptime: 1m50s Dumping 128 MB 16 32 48 64 80 96 112 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort ** and the kgdb output ** mbsd05# uname -a FreeBSD mbsd05.maplecreek.org 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Fri Jul 15 01:34:05 EDT 2005 root@mbsd05.maplecreek.org:/usr/obj/usr/src/sys/SMP_OPT i386 mbsd05# kgdb ./kernel.debug /tmp/crash/vmcore.3 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". #0 doadump () at pcpu.h:159 159 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) (kgdb) l *0xc0647527 0xc0647527 is in m_copym (/usr/src/sys/kern/uipc_mbuf.c:386). 381 MBUF_CHECKSLEEP(wait); 382 if (off == 0 && m->m_flags & M_PKTHDR) 383 copyhdr = 1; 384 while (off > 0) { 385 KASSERT(m != NULL, ("m_copym, offset > size of mbuf chain")); 386 if (off < m->m_len) 387 break; 388 off -= m->m_len; 389 m = m->m_next; 390 } (kgdb) (kgdb) where #0 doadump () at pcpu.h:159 #1 0xc0615326 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410 #2 0xc06155bc in panic (fmt=0xc0819052 "%s") at /usr/src/sys/kern/kern_shutdown.c:566 #3 0xc07d141c in trap_fatal (frame=0xc7692b38, eva=12) at /usr/src/sys/i386/i386/trap.c:817 #4 0xc07d1187 in trap_pfault (frame=0xc7692b38, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:735 #5 0xc07d0dc9 in trap (frame= {tf_fs = -1057423336, tf_es = 16, tf_ds = -1057226736, tf_edi = -1056791980, tf_esi = 1432, tf_ebp = -949408868, tf_isp = -949408924, tf_ebx = -1056792064, tf_edx = 0, tf_ecx = -1055088626, tf_eax = 0, tf_trapno = 12, tf_err = -1066926080, tf_eip = -1067158233, tf_cs = 8, tf_eflags = 66050, tf_esp = 0, tf_ss = -1065850424}) at /usr/src/sys/i386/i386/trap.c:425 #6 0xc07c12ca in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #7 0xc0f90018 in ?? () #8 0x00000010 in ?? () #9 0xc0fc0010 in ?? () #10 0xc102a254 in ?? () #11 0x00000598 in ?? () #12 0xc7692b9c in ?? () #13 0xc7692b64 in ?? () #14 0xc102a200 in ?? () #15 0x00000000 in ?? () #16 0xc11ca00e in ?? () #17 0x00000000 in ?? () #18 0x0000000c in ?? () #19 0xc0680000 in pppdealloc (sc=0xc102a200) at /usr/src/sys/net/if_ppp.c:388 #20 0xc06ac168 in ip_fragment (ip=0xc11ca00e, m_frag=0xc7692c48, mtu=-1056791980, if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 #21 0xc06a39c8 in ip_fastforward (m=0xc11b8600) at /usr/src/sys/netinet/ip_fastfwd.c:572 #22 0xc067d65d in ether_demux (ifp=0xc0f91800, m=0xc11b8600) at /usr/src/sys/net/if_ethersubr.c:770 #23 0xc067d419 in ether_input (ifp=0xc0f91800, m=0xc11b8600) at /usr/src/sys/net/if_ethersubr.c:631 #24 0xc0729c2f in sis_rxeof (sc=0xc0f91800) at /usr/src/sys/pci/if_sis.c:1636 #25 0xc0729f6b in sis_poll (ifp=0xc0f91800, cmd=POLL_ONLY, count=0) at /usr/src/sys/pci/if_sis.c:1769 #26 0xc05f8398 in netisr_poll () at /usr/src/sys/kern/kern_poll.c:384 #27 0xc0684f7a in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:338 #28 0xc0601c39 in ithread_loop (arg=0xc0ec6480) at /usr/src/sys/kern/kern_intr.c:547 #29 0xc0600ecc in fork_exit (callout=0xc0601ae8 , arg=0xc0ec6480, frame=0xc7692d48) at /usr/src/sys/kern/kern_fork.c:791 #30 0xc07c132c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209 (kgdb) From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 19 18:00:01 2005 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 D574016A41F for ; Tue, 19 Jul 2005 18:00:01 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7451143D45 for ; Tue, 19 Jul 2005 18:00:01 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 19 Jul 2005 14:14:16 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 19 Jul 2005 11:20:36 -0400 User-Agent: KMail/1.8 References: <20050719034215.GB20752@asx01.verolan.com> In-Reply-To: <20050719034215.GB20752@asx01.verolan.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507191120.37526.jhb@FreeBSD.org> Cc: Edwin Subject: Re: help w/panic under heavy load - 5.4 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, 19 Jul 2005 18:00:01 -0000 On Monday 18 July 2005 11:42 pm, Edwin wrote: > Hi, > > I have a recurring (re-producible) panic on the 5.3/5.4 kernels and I would > like to ask for some help in tracking it down. :) - it could be some > misconfig on my part - but i have tried several different configs of the > kernel - ultimately w/ polling on/off, ipfw on/off, ipfastforwarding on/off > - although with ipff off - the box still crashes but in a different > location - it will even crash w/ GENERIC kernel under heavy load. > > I'm not quite sure where to look past the below (ie. what variables/etc to > present to the list). Try turning INVARIANTS and INVARIANT_SUPPORT on in your kernel and see if you can reproduce this. Also, try to get a traceback in ddb if possible as sometimes ddb gives more reliable stack traces. It looks like your m is NULL, in which case the KASSERT() on the previous line should fire if INVARIANTS is on. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 19 18:35:49 2005 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 DE4E716A420 for ; Tue, 19 Jul 2005 18:35:49 +0000 (GMT) (envelope-from igor@doom.homeunix.org) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B82B43D70 for ; Tue, 19 Jul 2005 18:35:44 +0000 (GMT) (envelope-from igor@doom.homeunix.org) Received: from dialup84114-183.ip.peterstar.net ([84.204.114.183] helo=doom.homeunix.org) by voodoo.oberon.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.51 (FreeBSD)) id 1Duwvo-000Nmv-JR for hackers@freebsd.org; Tue, 19 Jul 2005 20:35:07 +0200 Received: from doom.homeunix.org (localhost [127.0.0.1]) by doom.homeunix.org (8.13.3/8.13.3) with ESMTP id j6JIY4jD003808 for ; Tue, 19 Jul 2005 22:34:12 +0400 (MSD) (envelope-from igor@doom.homeunix.org) Received: (from igor@localhost) by doom.homeunix.org (8.13.3/8.13.3/Submit) id j6JIY0YH003807 for hackers@freebsd.org; Tue, 19 Jul 2005 22:34:00 +0400 (MSD) (envelope-from igor) Date: Tue, 19 Jul 2005 22:33:58 +0400 From: Igor Pokrovsky To: hackers@freebsd.org Message-ID: <20050719183358.GA3304@doom.homeunix.org> 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: no sound in SDL apps 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, 19 Jul 2005 18:35:50 -0000 Hi, Some time ago (unfortunatly I cannot say when) all sound had dissapeared from SDL apps. However soundcard itself is fine as xmms via /dev/dsp is working fine. I tried to recompile all sdl related stuff - no difference (even did portupgrade -R sdl). Is there anybody out there who is experiencing the same behaviour? Before digging into this I'd like to know if there is something obvious I'm missing. This is STABLE-4 with the latest SDL. Sound driver is OSS 3.99.1h. P.S. Excuse me if it's not the appropriate list for this. -ip -- Consumer assistance doesn't. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 19 20:46:49 2005 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 DE87216A420 for ; Tue, 19 Jul 2005 20:46:48 +0000 (GMT) (envelope-from edwin@verolan.com) Received: from ns11.webmasters.com (ns11.webmasters.com [66.118.156.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 1F86D43D48 for ; Tue, 19 Jul 2005 20:46:47 +0000 (GMT) (envelope-from edwin@verolan.com) Received: (qmail 20660 invoked from network); 19 Jul 2005 20:43:36 -0000 Received: from unknown (HELO localhost.localdomain) (204.9.60.14) by ns11.webmasters.com with SMTP; 19 Jul 2005 20:43:36 -0000 Received: from localhost.localdomain (asx01 [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j6JKkhYH023782; Tue, 19 Jul 2005 16:46:43 -0400 Received: (from edwin@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id j6JKkhen023781; Tue, 19 Jul 2005 16:46:43 -0400 Date: Tue, 19 Jul 2005 16:46:43 -0400 From: Edwin To: freebsd-hackers@freebsd.org Message-ID: <20050719204643.GA23752@asx01.verolan.com> References: <20050719034215.GB20752@asx01.verolan.com> <200507191120.37526.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507191120.37526.jhb@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Operating-System: Linux/(i686) Cc: Subject: Re: help w/panic under heavy load - 5.4 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, 19 Jul 2005 20:46:49 -0000 Hi John, Re-compiled with INVARIANTS/INVARIANT_SUPPORT included the gdb output below - same situation (put heavy load on the box - incidentally - small (68 byte UDP packets) - fwiw. my buildkernel kept failing on the options DDB (even tried GENERIC kernel) - so I'm sure I'm doing something wrong there - just didn't figure it out yet. I wanted to get back to you with the output for the above asap though - I'm happy to input/output whatever commands you would like if necc. Thanks! /Edwin mbsd05# kgdb kernel.debug /tmp/crash/vmcore.5 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". #0 doadump () at pcpu.h:159 159 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) where #0 doadump () at pcpu.h:159 #1 0xc060c474 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410 #2 0xc060c6f2 in panic (fmt=0xc081e5ad "m_copym, offset > size of mbuf chain") at /usr/src/sys/kern/kern_shutdown.c:566 #3 0xc063beb8 in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:385 #4 0xc06996b4 in ip_fragment (ip=0xc124400e, m_frag=0xc7692c38, mtu=-1056768768, if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 #5 0xc069132e in ip_fastforward (m=0xc120e700) at /usr/src/sys/netinet/ip_fastfwd.c:572 #6 0xc066cd99 in ether_demux (ifp=0xc0f90000, m=0xc120e700) at /usr/src/sys/net/if_ethersubr.c:770 #7 0xc066cb1d in ether_input (ifp=0xc0f90000, m=0xc120e700) at /usr/src/sys/net/if_ethersubr.c:631 #8 0xc0711597 in sis_rxeof (sc=0xc0f90000) at /usr/src/sys/pci/if_sis.c:1636 #9 0xc071185f in sis_poll (ifp=0xc0f90000, cmd=POLL_ONLY, count=0) at /usr/src/sys/pci/if_sis.c:1769 #10 0xc05f2f5c in netisr_poll () at /usr/src/sys/kern/kern_poll.c:384 #11 0xc0673cc5 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:338 #12 0xc05fb10c in ithread_loop (arg=0xc0ec6480) at /usr/src/sys/kern/kern_intr.c:547 #13 0xc05fa580 in fork_exit (callout=0xc05fafe8 , arg=0xc0ec6480, frame=0xc7692d48) at /usr/src/sys/kern/kern_fork.c:791 #14 0xc07a26cc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209 (kgdb) f 4 #4 0xc06996b4 in ip_fragment (ip=0xc124400e, m_frag=0xc7692c38, mtu=-1056768768, if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 967 m->m_next = m_copy(m0, off, len); (kgdb) f 3 #3 0xc063beb8 in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:385 385 KASSERT(m != NULL, ("m_copym, offset > size of mbuf chain")); (kgdb) quit mbsd05# John Baldwin (jhb@FreeBSD.org) wrote: > On Monday 18 July 2005 11:42 pm, Edwin wrote: > > Hi, > > > > I have a recurring (re-producible) panic on the 5.3/5.4 kernels and I would > > like to ask for some help in tracking it down. :) - it could be some > > misconfig on my part - but i have tried several different configs of the > > kernel - ultimately w/ polling on/off, ipfw on/off, ipfastforwarding on/off > > - although with ipff off - the box still crashes but in a different > > location - it will even crash w/ GENERIC kernel under heavy load. > > > > I'm not quite sure where to look past the below (ie. what variables/etc to > > present to the list). > > Try turning INVARIANTS and INVARIANT_SUPPORT on in your kernel and see if you > can reproduce this. Also, try to get a traceback in ddb if possible as > sometimes ddb gives more reliable stack traces. It looks like your m is > NULL, in which case the KASSERT() on the previous line should fire if > INVARIANTS is on. > > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 02:03:05 2005 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 73EDF16A422 for ; Wed, 20 Jul 2005 02:03:05 +0000 (GMT) (envelope-from edwin@verolan.com) Received: from ns11.webmasters.com (ns11.webmasters.com [66.118.156.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 4988A43D48 for ; Wed, 20 Jul 2005 02:03:04 +0000 (GMT) (envelope-from edwin@verolan.com) Received: (qmail 3478 invoked from network); 20 Jul 2005 01:59:55 -0000 Received: from unknown (HELO localhost.localdomain) (204.9.60.14) by ns11.webmasters.com with SMTP; 20 Jul 2005 01:59:55 -0000 Received: from localhost.localdomain (asx01 [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j6K232o0024496; Tue, 19 Jul 2005 22:03:03 -0400 Received: (from edwin@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id j6K232AJ024495; Tue, 19 Jul 2005 22:03:02 -0400 Date: Tue, 19 Jul 2005 22:03:02 -0400 From: Edwin To: freebsd-hackers@freebsd.org Message-ID: <20050720020302.GA24474@asx01.verolan.com> References: <20050719034215.GB20752@asx01.verolan.com> <200507191120.37526.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200507191120.37526.jhb@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Operating-System: Linux/(i686) Cc: edwin@verolan.com Subject: Re: help w/panic under heavy load - 5.4 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, 20 Jul 2005 02:03:05 -0000 Hi John, Updated the kernel, same crash under load, looks like m is null, you're right. Not quite sure where to go from here. I'm happy to do the footwork - just still real hazy on the BSD kernel part of things. Thanks for the help! /Edwin Results from KDB/DDB/INVARIANTS/INVARIANT_SUPPORT - same crash (ddb and kdb output) panic: m_copym, offset > size of mbuf chain KDB: enter: panic [thread pid 27 tid 100021 ] Stopped at kdb_enter+0x2b: nop db> where Tracing pid 27 tid 100021 td 0xc0ed0180 kdb_enter(c0821a6a) at kdb_enter+0x2b panic(c0826049,0,c076b79c,c102d600,100) at panic+0xbb m_copym(0,5dc,5c8,1,14) at m_copym+0x60 ip_fragment(c123180e,c76d1c38,5dc,0,1) at ip_fragment+0x214 ip_fastforward(c11fee00) at ip_fastforward+0x6ed ether_demux(c0f90000,c11fee00,52,c0f8aad0,1f) at ether_demux+0x259 ether_input(c0f90000,c11fee00,c0f902d0,0,c08336ab) at ether_input+0x25d sis_rxeof(c0f90000,1,5,c08e5500,c76d1ce0) at sis_rxeof+0x1ab sis_poll(c0f90000,0,5) at sis_poll+0x7f netisr_poll(0) at netisr_poll+0x188 swi_net(0) at swi_net+0x81 ithread_loop(c0ec6580,c76d1d48,c0ec6580,c060030c,0) at ithread_loop+0x124 fork_exit(c060030c,c0ec6580,c76d1d48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc76d1d7c, ebp = 0 --- db> call doadump Dumping 128 MB 16 32 48 64 80 96 112 Dump complete 0xf db> reset mbsd05# kgdb kernel.debug /tmp/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". #0 doadump () at pcpu.h:159 159 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) where #0 doadump () at pcpu.h:159 #1 0xc04611f6 in db_fncall (dummy1=0, dummy2=0, dummy3=43, dummy4=0xc76d19c0 "�\031m�") at /usr/src/sys/ddb/db_command.c:531 #2 0xc0461004 in db_command (last_cmdp=0xc08c9264, cmd_table=0x0, aux_cmd_tablep=0xc08483b8, aux_cmd_tablep_end=0xc08483d4) at /usr/src/sys/ddb/db_command.c:349 #3 0xc04610cc in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #4 0xc0462c51 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #5 0xc0627af2 in kdb_trap (type=3, code=0, tf=0xc76d1afc) at /usr/src/sys/kern/subr_kdb.c:468 #6 0xc07b6394 in trap (frame= {tf_fs = -949157864, tf_es = -1067319280, tf_ds = -1065222128, tf_edi = 1, tf_esi = - 1065197495, tf_ebp = -949150916, tf_isp = -949150936, tf_ebx = -949150872, tf_edx = 0, tf_e cx = -1060921344, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067288461, tf_cs = -1065222136, tf_eflags = 646, tf_esp = -949150884, tf_ss = -1067376657}) at /usr/src/sys/i386/i386/trap.c:584 #7 0xc07a69ca in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #8 0xc76d0018 in ?? () #9 0xc0620010 in schedcpu () at /usr/src/sys/kern/sched_4bsd.c:461 #10 0xc0611fef in panic (fmt=0xc0820008 "default") at /usr/src/sys/kern/kern_shutdown.c:550 #11 0xc0641a2c in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:385 #12 0xc069b694 in ip_fragment (ip=0xc123180e, m_frag=0xc76d1c38, mtu=-1056778752, if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 #13 0xc06933c1 in ip_fastforward (m=0xc11fee00) at /usr/src/sys/netinet/ip_fastfwd.c:572 #14 0xc0672a59 in ether_demux (ifp=0xc0f90000, m=0xc11fee00) at /usr/src/sys/net/if_ethersubr.c:770 #15 0xc06727f5 in ether_input (ifp=0xc0f90000, m=0xc11fee00) at /usr/src/sys/net/if_ethersubr.c:631 #16 0xc0713507 in sis_rxeof (sc=0xc0f90000) at /usr/src/sys/pci/if_sis.c:1636 #17 0xc07137cf in sis_poll (ifp=0xc0f90000, cmd=POLL_ONLY, count=0) at /usr/src/sys/pci/if_sis.c:1769 #18 0xc05f8280 in netisr_poll () at /usr/src/sys/kern/kern_poll.c:384 #19 0xc0679985 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:338 #20 0xc0600430 in ithread_loop (arg=0xc0ec6580) at /usr/src/sys/kern/kern_intr.c:547 #21 0xc05ff8a4 in fork_exit (callout=0xc060030c , arg=0xc0ec6580, frame=0xc76d1d48) at /usr/src/sys/kern/kern_fork.c:791 #22 0xc07a6a2c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209 (kgdb) f 12 #12 0xc069b694 in ip_fragment (ip=0xc123180e, m_frag=0xc76d1c38, mtu=-1056778752, if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 967 m->m_next = m_copy(m0, off, len); (kgdb) f 11 #11 0xc0641a2c in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:385 385 KASSERT(m != NULL, ("m_copym, offset > size of mbuf chain")); (kgdb) l 380 KASSERT(len >= 0, ("m_copym, negative len %d", len)); 381 MBUF_CHECKSLEEP(wait); 382 if (off == 0 && m->m_flags & M_PKTHDR) 383 copyhdr = 1; 384 while (off > 0) { 385 KASSERT(m != NULL, ("m_copym, offset > size of mbuf chain")); 386 if (off < m->m_len) 387 break; 388 off -= m->m_len; 389 m = m->m_next; (kgdb) i loc n = (struct mbuf *) 0xc102d600 np = (struct mbuf **) 0xc102d654 off = 1432 top = (struct mbuf *) 0x1 copyhdr = 0 (kgdb) p m $14 = (struct mbuf *) 0x0 (kgdb) (kgdb) f 12 #12 0xc069b694 in ip_fragment (ip=0xc123180e, m_frag=0xc76d1c38, mtu=-1056778752, if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 967 m->m_next = m_copy(m0, off, len); (kgdb) l 962 len = ip->ip_len - off; 963 m->m_flags |= M_LASTFRAG; 964 } else 965 mhip->ip_off |= IP_MF; 966 mhip->ip_len = htons((u_short)(len + mhlen)); 967 m->m_next = m_copy(m0, off, len); 968 if (m->m_next == NULL) { /* copy failed */ 969 m_free(m); 970 error = ENOBUFS; /* ??? */ 971 ipstat.ips_odropped++; (kgdb) i loc mhip = (struct ip *) 0xc102d640 m = (struct mbuf *) 0xc102d600 mhlen = 20 error = 0 hlen = 20 len = 1480 off = 1500 m0 = (struct mbuf *) 0xc11fee00 firstlen = 1480 mnext = (struct mbuf **) 0xc11fee04 nfrags = 1 (kgdb) p *m0 $13 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xc123180e "E", mh_len = 68, mh_flags = 3, mh_type = 1}, M_dat = {MH = {MH_pkthdr = {rcvif = 0xc0f90000, len = 68, header = 0x0, csum_flags = 769, csum_data = 0, tags = {slh_first = 0x0}}, MH_dat = {MH_ext = {ext_buf = 0xc1231800 "", ext_free = 0, ext_args = 0x0, ext_size = 2048, ref_cnt = 0x0, ext_type = 3}, MH_databuf = "\000\030#�\000\000\000\000\000\000\000\000\000\b\000\000\000\000\00 0\ \000\003", '\0' }}, M_databuf = "\000\000��D\000\000\000\000\000\000\000\001\003", '\0' , , "\030#�\000\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\003", '\0' }} (kgdb) John Baldwin (jhb@FreeBSD.org) wrote: > On Monday 18 July 2005 11:42 pm, Edwin wrote: > > Hi, > > > > I have a recurring (re-producible) panic on the 5.3/5.4 kernels and I would > > like to ask for some help in tracking it down. :) - it could be some > > misconfig on my part - but i have tried several different configs of the > > kernel - ultimately w/ polling on/off, ipfw on/off, ipfastforwarding on/off > > - although with ipff off - the box still crashes but in a different > > location - it will even crash w/ GENERIC kernel under heavy load. > > > > I'm not quite sure where to look past the below (ie. what variables/etc to > > present to the list). > > Try turning INVARIANTS and INVARIANT_SUPPORT on in your kernel and see if you > can reproduce this. Also, try to get a traceback in ddb if possible as > sometimes ddb gives more reliable stack traces. It looks like your m is > NULL, in which case the KASSERT() on the previous line should fire if > INVARIANTS is on. > > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 08:43:17 2005 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 E693C16A41F for ; Wed, 20 Jul 2005 08:43:17 +0000 (GMT) (envelope-from ozkan@mersin.edu.tr) Received: from mail.mersin.edu.tr (mail.mersin.edu.tr [193.255.128.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F61043D46 for ; Wed, 20 Jul 2005 08:43:17 +0000 (GMT) (envelope-from ozkan@mersin.edu.tr) Received: from localhost (localhost.mersin.edu.tr [127.0.0.1]) by mail.mersin.edu.tr (Postfix) with ESMTP id 164CC45398 for ; Wed, 20 Jul 2005 11:43:20 +0300 (EEST) Received: from mail.mersin.edu.tr ([127.0.0.1]) by localhost (mail.mersin.edu.tr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96469-33 for ; Wed, 20 Jul 2005 11:43:08 +0300 (EEST) Received: from [10.0.50.20] (unknown [81.213.166.209]) by mail.mersin.edu.tr (Postfix) with ESMTP id 73BEC45383 for ; Wed, 20 Jul 2005 11:43:08 +0300 (EEST) Message-ID: <42DE0E91.9000607@mersin.edu.tr> Date: Wed, 20 Jul 2005 11:42:57 +0300 From: =?ISO-8859-9?Q?=D6zkan_KIRIK?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mersin.edu.tr Subject: Real and Free Memory 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, 20 Jul 2005 08:43:18 -0000 Hi, i am trying to measure free memory and real memory. but values at dmesg.boot and sysctl are diffrent. # cat /var/run/dmesg.boot | grep real real memory = 268435456 (256 MB) # sysctl vm.vmtotal | grep Real Real Memory: (Total: 232792K Active 122448K) As above, values are not equal, so that, i cant trust the Free Memory value that sysctl gives. how can i get right values? with best regard, Ozkan KIRIK From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 08:57:01 2005 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 0399316A41F for ; Wed, 20 Jul 2005 08:57:01 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F3D143D46 for ; Wed, 20 Jul 2005 08:56:59 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id D24C8A2FDE; Wed, 20 Jul 2005 10:56:58 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id B30EE6462; Wed, 20 Jul 2005 10:56:58 +0200 (CEST) Date: Wed, 20 Jul 2005 10:56:58 +0200 From: Marc Olzheim To: =?iso-8859-1?Q?=D6zkan?= KIRIK Message-ID: <20050720085658.GA27390@stack.nl> References: <42DE0E91.9000607@mersin.edu.tr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <42DE0E91.9000607@mersin.edu.tr> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: Real and Free Memory 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, 20 Jul 2005 08:57:01 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2005 at 11:42:57AM +0300, zkan KIRIK wrote: > Hi, >=20 > i am trying to measure free memory and real memory. >=20 > but values at dmesg.boot and sysctl are diffrent. >=20 > # cat /var/run/dmesg.boot | grep real > real memory =3D 268435456 (256 MB) >=20 > # sysctl vm.vmtotal | grep Real > Real Memory: (Total: 232792K Active 122448K) >=20 > As above, values are not equal, > so that, i cant trust the Free Memory value that sysctl gives. >=20 > how can i get right values? sysctl hw.physmem Zlo --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3hHaezjnobFOgrERAtZZAJ9k6jwmAx9Ad+szMwlkGU+zSKR6bACbBIzB UNUUf9VFs8rQ04lgD1E/Sio= =cavg -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 09:01:41 2005 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 6ACA216A41F for ; Wed, 20 Jul 2005 09:01:41 +0000 (GMT) (envelope-from ozkan@mersin.edu.tr) Received: from mail.mersin.edu.tr (mail.mersin.edu.tr [193.255.128.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF79343D45 for ; Wed, 20 Jul 2005 09:01:40 +0000 (GMT) (envelope-from ozkan@mersin.edu.tr) Received: from localhost (localhost.mersin.edu.tr [127.0.0.1]) by mail.mersin.edu.tr (Postfix) with ESMTP id 7272E45383; Wed, 20 Jul 2005 12:01:43 +0300 (EEST) Received: from mail.mersin.edu.tr ([127.0.0.1]) by localhost (mail.mersin.edu.tr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99892-18; Wed, 20 Jul 2005 12:01:32 +0300 (EEST) Received: from [10.0.50.20] (unknown [81.213.166.209]) by mail.mersin.edu.tr (Postfix) with ESMTP id A313D45351; Wed, 20 Jul 2005 12:01:31 +0300 (EEST) Message-ID: <42DE12E1.3030808@mersin.edu.tr> Date: Wed, 20 Jul 2005 12:01:21 +0300 From: =?ISO-8859-9?Q?=D6zkan_KIRIK?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Olzheim , freebsd-hackers@freebsd.org References: <42DE0E91.9000607@mersin.edu.tr> <20050720085658.GA27390@stack.nl> In-Reply-To: <20050720085658.GA27390@stack.nl> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mersin.edu.tr Cc: Subject: Re: Real and Free Memory 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, 20 Jul 2005 09:01:41 -0000 Thanks for your fast reply. What about free memory? does vm.vmtotal give right value? Marc Olzheim wrote: >On Wed, Jul 20, 2005 at 11:42:57AM +0300, zkan KIRIK wrote: > > >>Hi, >> >>i am trying to measure free memory and real memory. >> >>but values at dmesg.boot and sysctl are diffrent. >> >># cat /var/run/dmesg.boot | grep real >>real memory = 268435456 (256 MB) >> >># sysctl vm.vmtotal | grep Real >>Real Memory: (Total: 232792K Active 122448K) >> >>As above, values are not equal, >>so that, i cant trust the Free Memory value that sysctl gives. >> >>how can i get right values? >> >> > >sysctl hw.physmem > >Zlo > > From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 09:17:27 2005 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 D692616A41F for ; Wed, 20 Jul 2005 09:17:27 +0000 (GMT) (envelope-from baldur@foo.is) Received: from gremlin.foo.is (gremlin.foo.is [194.105.250.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7380743D45 for ; Wed, 20 Jul 2005 09:17:25 +0000 (GMT) (envelope-from baldur@foo.is) Received: from 127.0.0.1 (localhost.foo.is [127.0.0.1]) by injector.foo.is (Postfix) with SMTP id 923983A249; Wed, 20 Jul 2005 09:17:23 +0000 (GMT) Received: by gremlin.foo.is (Postfix, from userid 1000) id 5A2CD3A1C7; Wed, 20 Jul 2005 09:17:21 +0000 (GMT) Date: Wed, 20 Jul 2005 09:17:21 +0000 From: Baldur Gislason To: =?iso-8859-1?Q?=D6zkan?= KIRIK Message-ID: <20050720091721.GB79958@gremlin.foo.is> References: <42DE0E91.9000607@mersin.edu.tr> <20050720085658.GA27390@stack.nl> <42DE12E1.3030808@mersin.edu.tr> In-Reply-To: <42DE12E1.3030808@mersin.edu.tr> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on gremlin.foo.is X-Spam-Level: X-Spam-Status: No, hits=-4.8 required=6.0 tests=AWL,BAYES_00 autolearn=ham version=2.61 X-Sanitizer: Foo MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Cc: Marc Olzheim , freebsd-hackers@freebsd.org Subject: Re: Real and Free Memory 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, 20 Jul 2005 09:17:28 -0000 You must understand that in FreeBSD there is not much "free" memory as free memory is wasted memory. However, most memory listed as buffers or cache will be given up by the kernel whenever requested. top has a good level of information about your memory usage. You can also fetch a program in ports called muse. Baldur On Wed, Jul 20, 2005 at 12:01:21PM +0300, Özkan KIRIK wrote: > Thanks for your fast reply. > > What about free memory? > does vm.vmtotal give right value? > > > Marc Olzheim wrote: > > >On Wed, Jul 20, 2005 at 11:42:57AM +0300, zkan KIRIK wrote: > > > > > >>Hi, > >> > >>i am trying to measure free memory and real memory. > >> > >>but values at dmesg.boot and sysctl are diffrent. > >> > >># cat /var/run/dmesg.boot | grep real > >>real memory = 268435456 (256 MB) > >> > >># sysctl vm.vmtotal | grep Real > >>Real Memory: (Total: 232792K Active 122448K) > >> > >>As above, values are not equal, > >>so that, i cant trust the Free Memory value that sysctl gives. > >> > >>how can i get right values? > >> > >> > > > >sysctl hw.physmem > > > >Zlo > > > > > _______________________________________________ > 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 Wed Jul 20 09:18:01 2005 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 EBF6D16A420 for ; Wed, 20 Jul 2005 09:18:01 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 859A843D46 for ; Wed, 20 Jul 2005 09:18:01 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 85E20A2FDE; Wed, 20 Jul 2005 11:18:00 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 657796462; Wed, 20 Jul 2005 11:18:00 +0200 (CEST) Date: Wed, 20 Jul 2005 11:18:00 +0200 From: Marc Olzheim To: =?iso-8859-1?Q?=D6zkan?= KIRIK Message-ID: <20050720091800.GB27390@stack.nl> References: <42DE0E91.9000607@mersin.edu.tr> <20050720085658.GA27390@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ftEhullJWpWg/VHq" Content-Disposition: inline In-Reply-To: <20050720085658.GA27390@stack.nl> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: Real and Free Memory 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, 20 Jul 2005 09:18:02 -0000 --ftEhullJWpWg/VHq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2005 at 10:56:58AM +0200, Marc Olzheim wrote: > On Wed, Jul 20, 2005 at 11:42:57AM +0300, zkan KIRIK wrote: > > Hi, > >=20 > > i am trying to measure free memory and real memory. > >=20 > > but values at dmesg.boot and sysctl are diffrent. > >=20 > > # cat /var/run/dmesg.boot | grep real > > real memory =3D 268435456 (256 MB) > >=20 > > # sysctl vm.vmtotal | grep Real > > Real Memory: (Total: 232792K Active 122448K) > >=20 > > As above, values are not equal, > > so that, i cant trust the Free Memory value that sysctl gives. > >=20 > > how can i get right values? >=20 > sysctl hw.physmem Let me be a bit more precise: sysctl vm.stats.vm will show you all the memory info you need in the vm system, as in: pageable memory. It's shown in number of pages (usually 4K: vm.stats.vm.v_page_size). Keep in mind that 'free' memory depends on the way you look at it. Pages that contain still caching synced-on-disk data (inactive pages) can be considered 'free' as well as any 'free' page. See http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html#TOP-MEMORY-= STATES Marc --ftEhullJWpWg/VHq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3hbIezjnobFOgrERApshAJ0U0GbuRYXPZri9HQk8Z/72toXrswCdHM3w JkpEgsueCeuUGPzJ7+T/flw= =Vh9H -----END PGP SIGNATURE----- --ftEhullJWpWg/VHq-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 10:06:27 2005 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 5723B16A420 for ; Wed, 20 Jul 2005 10:06:27 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2BA043D49 for ; Wed, 20 Jul 2005 10:06:26 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from beatrix.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by kane.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j6KA6OCT026239; Wed, 20 Jul 2005 13:06:24 +0300 Received: from beatrix.daedalusnetworks.priv (localhost [127.0.0.1]) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3) with ESMTP id j6KA6Nqk001518; Wed, 20 Jul 2005 13:06:23 +0300 (EEST) Received: (from keramida@localhost) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3/Submit) id j6KA6Nql001517; Wed, 20 Jul 2005 13:06:23 +0300 (EEST) Date: Wed, 20 Jul 2005 13:06:23 +0300 From: Giorgos Keramidas To: Edwin Message-ID: <20050720100623.GA1470@beatrix.daedalusnetworks.priv> References: <20050719034215.GB20752@asx01.verolan.com> <200507191120.37526.jhb@FreeBSD.org> <20050720020302.GA24474@asx01.verolan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050720020302.GA24474@asx01.verolan.com> Cc: freebsd-hackers@freebsd.org Subject: Re: help w/panic under heavy load - 5.4 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, 20 Jul 2005 10:06:27 -0000 On 2005-07-19 22:03, Edwin wrote: > Hi John, > > Updated the kernel, same crash under load, looks like m is null, you're right. > > Not quite sure where to go from here. I'm happy to do the footwork - just still real > hazy on the BSD kernel part of things. > > panic: m_copym, offset > size of mbuf chain > KDB: enter: panic > [thread pid 27 tid 100021 ] > Stopped at kdb_enter+0x2b: nop > db> where > Tracing pid 27 tid 100021 td 0xc0ed0180 > kdb_enter(c0821a6a) at kdb_enter+0x2b > panic(c0826049,0,c076b79c,c102d600,100) at panic+0xbb > m_copym(0,5dc,5c8,1,14) at m_copym+0x60 > ip_fragment(c123180e,c76d1c38,5dc,0,1) at ip_fragment+0x214 > ip_fastforward(c11fee00) at ip_fastforward+0x6ed > ether_demux(c0f90000,c11fee00,52,c0f8aad0,1f) at ether_demux+0x259 > ether_input(c0f90000,c11fee00,c0f902d0,0,c08336ab) at ether_input+0x25d > sis_rxeof(c0f90000,1,5,c08e5500,c76d1ce0) at sis_rxeof+0x1ab > sis_poll(c0f90000,0,5) at sis_poll+0x7f > netisr_poll(0) at netisr_poll+0x188 > swi_net(0) at swi_net+0x81 > ithread_loop(c0ec6580,c76d1d48,c0ec6580,c060030c,0) at ithread_loop+0x124 > fork_exit(c060030c,c0ec6580,c76d1d48) at fork_exit+0xa4 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xc76d1d7c, ebp = 0 --- Both tracebacks contain sis_poll() somewhere in the call stack? Are you using POLLING? If yes, can you try without POLLING and see if the crash can still be reproduced? - Giorgos From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 15:42:00 2005 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 4559016A420 for ; Wed, 20 Jul 2005 15:42:00 +0000 (GMT) (envelope-from edwin@verolan.com) Received: from ns11.webmasters.com (ns11.webmasters.com [66.118.156.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 232A343D48 for ; Wed, 20 Jul 2005 15:41:58 +0000 (GMT) (envelope-from edwin@verolan.com) Received: (qmail 15762 invoked from network); 20 Jul 2005 15:38:50 -0000 Received: from unknown (HELO localhost.localdomain) (204.9.60.14) by ns11.webmasters.com with SMTP; 20 Jul 2005 15:38:50 -0000 Received: from localhost.localdomain (asx01 [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j6KFfvKH026804; Wed, 20 Jul 2005 11:41:57 -0400 Received: (from edwin@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id j6KFfucR026803; Wed, 20 Jul 2005 11:41:56 -0400 Date: Wed, 20 Jul 2005 11:41:56 -0400 From: Edwin To: Giorgos Keramidas Message-ID: <20050720154156.GA26755@asx01.verolan.com> References: <20050719034215.GB20752@asx01.verolan.com> <200507191120.37526.jhb@FreeBSD.org> <20050720020302.GA24474@asx01.verolan.com> <20050720100623.GA1470@beatrix.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050720100623.GA1470@beatrix.daedalusnetworks.priv> User-Agent: Mutt/1.4.1i X-Operating-System: Linux/(i686) Cc: Edwin , freebsd-hackers@freebsd.org Subject: Re: help w/panic under heavy load - 5.4 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, 20 Jul 2005 15:42:00 -0000 Hi Giorgos, Yes - I'm using polling, but it still panics even w/ polling disabled or not compiled in. Still reproducible - same scenario (high load - actually, not even really high load - relative load,- small network packets). I did both (output included below): - disable polling via sysctl - re-compile new kernel w/o option It appears to be still the same error - traces the same w/ the exception of sis_poll versus sis_intr. I have tried various different options in my kernel before posting - w/ and/wo ipff, ipfw, polling, didn't seem to make a difference - but then again - I wasn't getting traces from DDB w/ INVARIANTS - so not for sure. I'm trying to understand the particulars about this - I get the null pointer part, but as to ip_fragment - it's fragmenting mbufs to handle ip packets during switching? and its failing trying to copy data past the end of the chain? Thanks! /edwin Giorgos Keramidas (keramida@freebsd.org) wrote: <....> > > ether_input(c0f90000,c11fee00,c0f902d0,0,c08336ab) at ether_input+0x25d > > sis_rxeof(c0f90000,1,5,c08e5500,c76d1ce0) at sis_rxeof+0x1ab > > sis_poll(c0f90000,0,5) at sis_poll+0x7f > > netisr_poll(0) at netisr_poll+0x188 > > swi_net(0) at swi_net+0x81 > > ithread_loop(c0ec6580,c76d1d48,c0ec6580,c060030c,0) at ithread_loop+0x124 > > fork_exit(c060030c,c0ec6580,c76d1d48) at fork_exit+0xa4 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0x1, eip = 0, esp = 0xc76d1d7c, ebp = 0 --- > > Both tracebacks contain sis_poll() somewhere in the call stack? Are you > using POLLING? If yes, can you try without POLLING and see if the crash > can still be reproduced? > > - Giorgos > DDB output from disabling polling via sysctl - trace fb54c# sysctl kern.polling.enable=0 kern.polling.enable: 1 -> 0 fb54c# panic: m_copym, offset > size of mbuf chain KDB: enter: panic [thread pid 21 tid 100015 ] Stopped at kdb_enter+0x2b: nop db> where Tracing pid 21 tid 100015 td 0xc0ecc780 kdb_enter(c0821a6a) at kdb_enter+0x2b panic(c0826049,0,c076b79c,c102b400,100) at panic+0xbb m_copym(0,5dc,5c8,1,14) at m_copym+0x60 ip_fragment(c11bd80e,c76bfc6c,5dc,0,1) at ip_fragment+0x214 ip_fastforward(c11ab100) at ip_fastforward+0x6ed ether_demux(c0f90000,c11ab100,52,c0f8abc0,29) at ether_demux+0x259 ether_input(c0f90000,c11ab100,c0f902d0,0,c08336ab) at ether_input+0x25d sis_rxeof(c0f90000) at sis_rxeof+0x1ab sis_intr(c0f90000) at sis_intr+0xf3 ithread_loop(c0ec6880,c76bfd48,c0ec6880,c060030c,0) at ithread_loop+0x124 fork_exit(c060030c,c0ec6880,c76bfd48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc76bfd7c, ebp = 0 --- db> call doadump Dumping 128 MB 16 32 48 64 80 96 112 Dump complete 0xf db> mbsd05# kgdb kernel.debug /tmp/crash/vmcore.3 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". #0 doadump () at pcpu.h:159 159 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) where #0 doadump () at pcpu.h:159 #1 0xc04611f6 in db_fncall (dummy1=0, dummy2=0, dummy3=-1, dummy4=0xc76bf9f4 "(�k�") at /usr/src/sys/ddb/db_command.c:531 #2 0xc0461004 in db_command (last_cmdp=0xc08c9264, cmd_table=0x0, aux_cmd_tablep=0xc08483b8, aux_cmd_tablep_end=0xc08483d4) at /usr/src/sys/ddb/db_command.c:349 #3 0xc04610cc in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #4 0xc0462c51 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #5 0xc0627af2 in kdb_trap (type=3, code=0, tf=0xc76bfb30) at /usr/src/sys/kern/subr_kdb.c:468 #6 0xc07b6394 in trap (frame= {tf_fs = -949288936, tf_es = -1067319280, tf_ds = -1065222128, tf_edi = 1, tf_esi = -1065 197495, tf_ebp = -949224592, tf_isp = -949224612, tf_ebx = -949224548, tf_edx = 0, tf_ecx = -10 60921344, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067288461, tf_cs = -1065222136, tf_eflags = 658, tf_esp = -949224560, tf_ss = -1067376657}) at /usr/src/sys/i386/i386/trap.c:584 #7 0xc07a69ca in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #8 0xc76b0018 in ?? () #9 0xc0620010 in schedcpu () at /usr/src/sys/kern/sched_4bsd.c:461 #10 0xc0611fef in panic (fmt=0xc0820008 "default") at /usr/src/sys/kern/kern_shutdown.c:550 #11 0xc0641a2c in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:385 #12 0xc069b694 in ip_fragment (ip=0xc11bd80e, m_frag=0xc76bfc6c, mtu=-1056787456, if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 6933c1 in ip_fastforward (m=0xc11ab100) at /usr/src/sys/netinet/ip_fastfwd.c:572 #14 0xc0672a59 in ether_demux (ifp=0xc0f90000, m=0xc11ab100) at /usr/src/sys/net/if_ethersubr.c:770 #15 0xc06727f5 in ether_input (ifp=0xc0f90000, m=0xc11ab100) at /usr/src/sys/net/if_ethersubr.c:631 #16 0xc0713507 in sis_rxeof (sc=0xc0f90000) at /usr/src/sys/pci/if_sis.c:1636 #17 0xc071398f in sis_intr (arg=0xc0f90000) at /usr/src/sys/pci/if_sis.c:1841 #18 0xc0600430 in ithread_loop (arg=0xc0ec6880) at /usr/src/sys/kern/kern_intr.c:547 #19 0xc05ff8a4 in fork_exit (callout=0xc060030c , arg=0xc0ec6880, frame=0xc76bfd48) at /usr/src/sys/kern/kern_fork.c:791 #20 0xc07a6a2c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209 (kgdb) f 12 #12 0xc069b694 in ip_fragment (ip=0xc11bd80e, m_frag=0xc76bfc6c, mtu=-1056787456, if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 967 m->m_next = m_copy(m0, off, len); (kgdb) l 962 len = ip->ip_len - off; 963 m->m_flags |= M_LASTFRAG; 964 } else 965 mhip->ip_off |= IP_MF; 966 mhip->ip_len = htons((u_short)(len + mhlen)); 967 m->m_next = m_copy(m0, off, len); 968 if (m->m_next == NULL) { /* copy failed */ 969 m_free(m); 970 error = ENOBUFS; /* ??? */ 971 ipstat.ips_odropped++; (kgdb) f 11 #11 0xc0641a2c in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:385 385 KASSERT(m != NULL, ("m_copym, offset > size of mbuf chain")); (kgdb) l 380 KASSERT(len >= 0, ("m_copym, negative len %d", len)); 381 MBUF_CHECKSLEEP(wait); 382 if (off == 0 && m->m_flags & M_PKTHDR) 383 copyhdr = 1; 384 while (off > 0) { 385 KASSERT(m != NULL, ("m_copym, offset > size of mbuf chain")); 386 if (off < m->m_lenek; 388 off -= m->m_len; 389 m = m->m_next; (kgdb) i loc n = (struct mbuf *) 0xc102b400 np = (struct mbuf **) 0xc102b454 off = 1432 top = (struct mbuf *) 0x1 copyhdr = 0 (kgdb) p m $1 = (struct mbuf *) 0x0 (kgdb) *** end of sysctl polling disabled *** *** begin of no POLLING option kernel *** fb54c# panic: m_copym, offset > size of mbuf chain KDB: enter: panic [thread pid 21 tid 100015 ] Stopped at kdb_enter+0x2b: nop db> where Tracing pid 21 tid 100015 td 0xc0ecc780 kdb_enter(c081f47b) at kdb_enter+0x2b panic(c0823a5a,0,c07694e0,c102bb00,100) at panic+0xbb m_copym(0,5dc,5c8,1,14) at m_copym+0x60 ip_fragment(c130100e,c76bfc6c,5dc,0,1) at ip_fragment+0x214 ip_fastforward(c12e5700) at ip_fastforward+0x6ed ether_demux(c0f90000,c12e5700,52,c0f8ab18,22) at ether_demux+0x259 ether_input(c0f90000,c12e5700,c0f902cc,0,c08310a3) at ether_input+0x25d sis_rxeof(c0f90000) at sis_rxeof+0x18b sis_intr(c0f90000) at sis_intr+0xa3 ithread_loop(c0ec6880,c76bfd48,c0ec6880,c05fedf0,0) at ithread_loop+0x124 fork_exit(c05fedf0,c0ec6880,c76bfd48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc76bfd7c, ebp = 0 --- db> call doadump Dumping 128 MB 16 32 48 64 80 96 112 Dump complete 0xf db> reset mbsd05# kgdb kernel.debug /tmp/crash/vmcore.5 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". #0 doadump () at pcpu.h:159 159 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) where #0 doadump () at pcpu.h:159 #1 0xc0461106 in db_fncall (dummy1=0, dummy2=0, dummy3=43, dummy4=0xc76bf9f4 "(�k�") at /usr/src/sys/ddb/db_command.c:531 #2 0xc0460f14 in db_command (last_cmdp=0xc08c6764, cmd_table=0x0, aux_cmd_tablep=0xc0845d60, aux_cmd_tablep_end=0xc0845d7c) at /usr/src/sys/ddb/db_command.c:349 #3 0xc0460fdc in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #4 0xc0462b61 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #5 0xc06265d6 in kdb_trap (type=3, code=0, tf=0xc76bfb30) at /usr/src/sys/kern/subr_kdb.c:468 #6 0xc07b40bc in trap (frame= {tf_fs = -949288936, tf_es = -1067319280, tf_ds = -1065222128, tf_edi = 1, tf_esi = -1065 207206, tf_ebp = -949224592, tf_isp = -949224612, tf_ebx = -949224548, tf_edx = 0, tf_ecx = -10 60921344, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067293865, tf_cs = -1065222136, tf_eflags = 658, tf_esp = -949224560, tf_ss = -1067382061}) at /usr/src/sys/i386/i386/trap.c:584 #7 0xc07a470a in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #8 0xc76b0018 in ?? () #9 0xc0620010 in blist_free (bl=0xc76bfb9c, blkno=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/kern/subr_blist.c:245 #10 0xc0610ad3 in panic (fmt=0xc0820008 "_scope_sys") at /usr/src/sys/kern/kern_shutdown.c:550 #11 0xc0640510 in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:385 #12 0xc069a170 in ip_fragment (ip=0xc130100e, m_frag=0xc76bfc6c, mtu=-1056785664, if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 #13 0xc0691e9d in ip_fastforward (m=0xc12e5700) at /usr/src/sys/netinet/ip_fastfwd.c:572 #14 0xc067153d in ether_demux (ifp=0xc0f90000, m=0xc12e5700) at /usr/src/sys/net/if_ethersubr.c:770 #15 0xc06712d9 in ether_input (ifp=0xc0f90000, m=0xc12e5700) at /usr/src/sys/net/if_ethersubr.c:631 #16 0xc0711963 in sis_rxeof (sc=0xc0f90000) at /usr/src/sys/pci/if_sis.c:1636 #17 0xc0711c53 in sis_intr (arg=0xc0f90000) at /usr/src/sys/pci/if_sis.c:1841 #18 0xc05fef14 in ithread_loop (arg=0xc0ec6880) at /usr/src/sys/kern/kern_intr.c:547 #19 0xc05fe388 in fork_exit (callout=0xc05fedf0 , arg=0xc0ec6880, frame=0xc76bfd48) at /usr/src/sys/kern/kern_fork.c:791 #20 0xc07a476c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209 (kgdb) f 11 #11 0xc0640510 in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:385 385 KASSERT(m != NULL, ("m_copym, offset > size of mbuf chain")); (kgdb) p m $1 = (struct mbuf *) 0x0 (kgdb) *** end of no POllING option kernel *** From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 17:30:16 2005 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 082BE16A41F for ; Wed, 20 Jul 2005 17:30:16 +0000 (GMT) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A74143D48 for ; Wed, 20 Jul 2005 17:30:15 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.3/8.13.3) with ESMTP id j6KHUSLv020157 for ; Wed, 20 Jul 2005 10:30:28 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.13.3/8.13.3) with ESMTP id j6KHUE2j001096 for ; Wed, 20 Jul 2005 10:30:14 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.13.3/8.12.9/Submit) id j6KHUCWh001095 for hackers@freebsd.org; Wed, 20 Jul 2005 10:30:12 -0700 (PDT) (envelope-from frank@exit.com) X-Authentication-Warning: realtime.exit.com: frank set sender to frank@exit.com using -f From: Frank Mayhar To: hackers@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Exit Consulting Date: Wed, 20 Jul 2005 10:30:11 -0700 Message-Id: <1121880611.929.12.camel@realtime.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-Virus-Scanned: ClamAV version 0.86.1, clamav-milter version 0.86 on tinker.exit.com X-Virus-Status: Clean Cc: Subject: UFS2 recovery tool? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: frank@exit.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 17:30:16 -0000 Due to a series of circumstances involving a RAID controller and an unclear user interface and an unfortunate use of "fsck -y", I managed to hammer a couple of very large file systems. (Fortunately I had a very recent copy of /home backed up elsewhere, or I wouldn't be sending this email.) While I could live without the data on those file systems if I absolutely had to, I know much of the data is recoverable with the right tools. In fact I found a whole intact subtree using fsdb. Unfortunately the root directory was wiped. While I can recover the inode with fsdb, it doesn't allow me to allocate a new (free) block for the directory contents. What I need is either a way to set up the root directory so I can link the subtrees that I find to it, or, alternatively, something like ffsrecov that will just pull the subtree off the dead filesystem directly, writing it to a _live_ filesystem. Unfortunately, ffsrecov hasn't yet been updated to support UFS2. If I have to, I'll write the code myself, but I'm hoping here that someone else has done so already. (At the moment it's hard for me to find the time for such relatively complex development that isn't directly work-related.) So, has anyone done this? If someone even has code lying around that understands UFS2 and can create directories and allocate blocks, even if it's not suitable for inclusion in ports, that would be wonderful. Drop me email with a pointer to said code. Alternatively, if you have (detailed, low-level) advice as to how to write the code, feel free to chime in. (Please, though, don't tell me to look at fsck_ffs, fsdb and sys/ffs/*; that I know already and it will be where I start if I end up writing this all myself.) So here's hoping... -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 17:45:56 2005 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 3916816A41F for ; Wed, 20 Jul 2005 17:45:56 +0000 (GMT) (envelope-from hackers@deadcafe.de) Received: from deadcafe.de (deadcafe.de [81.169.162.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9580F43D46 for ; Wed, 20 Jul 2005 17:45:55 +0000 (GMT) (envelope-from hackers@deadcafe.de) Received: from dialin.t-online.de (p54A5E3CC.dip.t-dialin.net [84.165.227.204]) by deadcafe.de (8.13.4/8.13.4/Rock) with ESMTP id j6KHje6P089301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jul 2005 19:45:49 +0200 (CEST) Received: from [172.23.7.254] (doom.rock.net [172.23.7.254]) by dialin.t-online.de (8.13.4/8.13.4/Rock) with ESMTP id j6KHjXcn073779; Wed, 20 Jul 2005 19:45:33 +0200 (CEST) Message-ID: <42DE8DBB.6080800@deadcafe.de> Date: Wed, 20 Jul 2005 19:45:31 +0200 From: Daniel Rock User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D6zkan_KIRIK?= References: <42DE0E91.9000607@mersin.edu.tr> In-Reply-To: <42DE0E91.9000607@mersin.edu.tr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.1 required=5.5 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on deadcafe.de Cc: freebsd-hackers@freebsd.org Subject: Re: Real and Free Memory 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, 20 Jul 2005 17:45:56 -0000 Özkan KIRIK schrieb: > # cat /var/run/dmesg.boot | grep real > real memory = 268435456 (256 MB) > > # sysctl vm.vmtotal | grep Real > Real Memory: (Total: 232792K Active 122448K) Real memory output from dmesg isn't the total amount of memory in the system, but only the highest address where memory was found. Memory holes below may reduce the available memory: real memory = 6442450944 (6144 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000090fff, 589824 bytes (144 pages) 0x0000000000985000 - 0x000000007ff1ffff, 2136584192 bytes (521627 pages) 0x0000000100000000 - 0x0000000174baffff, 1958412288 bytes (478128 pages) avail memory = 4085907456 (3896 MB) In above output you can see a very large memory hole of 2GB in total. The machine has 4GB RAM. Between 2GB-4GB has a memory hole to map in the PCI address space. Depending on the BIOS you will likely find a memory hole between 640kB-1/4/16MB in your system. Just boot into verbose mode and read the lines after "Physical memory chunk(s):" Daniel From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 20 23:22:44 2005 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 C6FDF16A41F for ; Wed, 20 Jul 2005 23:22:44 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECD3043D48 for ; Wed, 20 Jul 2005 23:22:42 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.101] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0) by crumpet.united-ware.com (8.12.8p2/8.12.8) with ESMTP id j6KNJMwj048573 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 20 Jul 2005 19:19:23 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: frank@exit.com Date: Wed, 20 Jul 2005 19:21:54 -0400 User-Agent: KMail/1.8 References: <1121880611.929.12.camel@realtime.exit.com> In-Reply-To: <1121880611.929.12.camel@realtime.exit.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1224922.qDkBpkRHDx"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507201922.01906.mistry.7@osu.edu> X-Spam-Status: No, hits=1.5 required=5.0 tests=BAYES_99 autolearn=no version=2.64 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on crumpet.united-ware.com Cc: freebsd-hackers@freebsd.org Subject: Re: UFS2 recovery tool? 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, 20 Jul 2005 23:22:44 -0000 --nextPart1224922.qDkBpkRHDx Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 20 July 2005 01:30 pm, Frank Mayhar wrote: > Due to a series of circumstances involving a RAID controller and an > unclear user interface and an unfortunate use of "fsck -y", I > managed to hammer a couple of very large file systems.=20 > (Fortunately I had a very recent copy of /home backed up elsewhere, > or I wouldn't be sending this email.) > > While I could live without the data on those file systems if I > absolutely had to, I know much of the data is recoverable with the > right tools. In fact I found a whole intact subtree using fsdb. > Unfortunately the root directory was wiped. While I can recover > the inode with fsdb, it doesn't allow me to allocate a new (free) > block for the directory contents. > > What I need is either a way to set up the root directory so I can > link the subtrees that I find to it, or, alternatively, something > like ffsrecov that will just pull the subtree off the dead > filesystem directly, writing it to a _live_ filesystem.=20 > Unfortunately, ffsrecov hasn't yet been updated to support UFS2. > > If I have to, I'll write the code myself, but I'm hoping here that > someone else has done so already. (At the moment it's hard for me > to find the time for such relatively complex development that isn't > directly work-related.) > > So, has anyone done this? If someone even has code lying around > that understands UFS2 and can create directories and allocate > blocks, even if it's not suitable for inclusion in ports, that > would be wonderful. Drop me email with a pointer to said code. > > Alternatively, if you have (detailed, low-level) advice as to how > to write the code, feel free to chime in. (Please, though, don't > tell me to look at fsck_ffs, fsdb and sys/ffs/*; that I know > already and it will be where I start if I end up writing this all > myself.) > > So here's hoping... scan_ffs and gpart have saved my butt more than a few times. =20 Depending on your situation they may or may not help. =2D-=20 Anish Mistry --nextPart1224922.qDkBpkRHDx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC3tyZxqA5ziudZT0RAgrEAKDCn/Lmy2IWh/5xzQMN2UUzEcdVMgCgtZjm 4wMY8S1tarFbFb6kDJ1fMGY= =GciF -----END PGP SIGNATURE----- --nextPart1224922.qDkBpkRHDx-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 01:00:49 2005 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 A62C116A425 for ; Thu, 21 Jul 2005 01:00:49 +0000 (GMT) (envelope-from edwin@verolan.com) Received: from ns11.webmasters.com (ns11.webmasters.com [66.118.156.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 2823A43D48 for ; Thu, 21 Jul 2005 01:00:46 +0000 (GMT) (envelope-from edwin@verolan.com) Received: (qmail 13623 invoked from network); 21 Jul 2005 00:57:38 -0000 Received: from unknown (HELO localhost.localdomain) (204.9.60.14) by ns11.webmasters.com with SMTP; 21 Jul 2005 00:57:38 -0000 Received: from localhost.localdomain (asx01 [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j6L10hBs005399; Wed, 20 Jul 2005 21:00:43 -0400 Received: (from edwin@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id j6L10dWt005398; Wed, 20 Jul 2005 21:00:39 -0400 Date: Wed, 20 Jul 2005 21:00:39 -0400 From: Edwin To: freebsd-hackers@freebsd.org Message-ID: <20050721010039.GA5310@asx01.verolan.com> References: <20050719034215.GB20752@asx01.verolan.com> <200507191120.37526.jhb@FreeBSD.org> <20050720020302.GA24474@asx01.verolan.com> <20050720100623.GA1470@beatrix.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050720100623.GA1470@beatrix.daedalusnetworks.priv> User-Agent: Mutt/1.4.1i X-Operating-System: Linux/(i686) Cc: Edwin Subject: Re: help w/panic under heavy load - 5.4 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, 21 Jul 2005 01:00:49 -0000 Giorgos/John/et.al :) I have compiled/tested/traced about 15 separate kernels for this, and am happy to provide crashdumps/etc to anyone interested :) I decided to start over - create a GENERIC kernel (w/ DDB/KDB/INVARIANTS/INVARIANT_SUPPORT) and see what I started to get if I could reproduce the problem more specifically. Just using the GENERIC w/ debug kernel - I did make it crash - although it took some handholding, lots of throwing packets at it and running processes on the box, about 5-10 minutes - didn't really try to reproduce it - since it really wasn't the fast panic that I was concerned about before. i've included the panic below here anyhow. What I did notice - was w/o any options - and turning on ip.fastforwarding via sysctl - the crash was reproducible consistently with the (pretty much) generic kernel, same kernel traces as before basically. I also received an 'interrupt storm' message on the console from the ip.fastforwarding trace - have seen that a few times in the past when polling was not enabled before it panic'd. I welcome all comments/thoughts/directions - happy to poke/prod/compile/debug - just really don't know where to go from here. Thanks for your help! /Edwin Kernel: DDB8-GENDBG (GENERIC + options DDB/KDB/INVARIANTS/INVARIANT_SUPPORT) sysctl: ip.fastforwarding=0 <--- turned off ospfd# panic: m_copym, offset > size of mbuf chain KDB: enter: panic [thread pid 27 tid 100021 ] Stopped at kdb_enter+0x2b: nop db> where Tracing pid 27 tid 100021 td 0xc0ed0180 kdb_enter(c0821a6a) at kdb_enter+0x2b panic(c0826049,0,c076b79c,c102bb00,100) at panic+0xbb m_copym(0,5dc,5c8,1,14) at m_copym+0x60 ip_fragment(c124100e,c76d1a04,5dc,0,1) at ip_fragment+0x214 ip_output(c1201200,0,c76d19d0,1,0,0) at ip_output+0x74c ip_forward(c1201200,0) at ip_forward+0x2d4 ip_input(c1201200) at ip_input+0x4a7 netisr_processqueue(c08ec138) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xc2 ithread_loop(c0ec6580,c76d1d48,c0ec6580,c060030c,0) at ithread_loop+0x124 fork_exit(c060030c,c0ec6580,c76d1d48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc76d1d7c, ebp = 0 --- db> call doadump Dumping 128 MB 16 32 48 64 80 96 112 Dump complete 0xf db> Kernel: DDB8-GENDBG (GENERIC + options DDB/KDB/INVARIANTS/INVARIANT_SUPPORT) Sysctl: ip.fastforwarding=1 fb54c# Interrupt storm detected on "irq10: sis0 sis1+"; throttling interrupt source fb54c# fb54c# fb54c# fb54c# panic: m_copym, offset > size of mbuf chain KDB: enter: panic [thread pid 21 tid 100015 ] Stopped at kdb_enter+0x2b: nop db> where Tracing pid 21 tid 100015 td 0xc0ecc780 kdb_enter(c08165b2) at kdb_enter+0x2b panic(c081ab91,0,c0760a0c,c1028800,100) at panic+0xbb m_copym(0,5dc,5c8,1,14) at m_copym+0x60 ip_fragment(c121880e,c76bfc6c,5dc,0,1) at ip_fragment+0x214 ip_fastforward(c11f2600) at ip_fastforward+0x6ed ether_demux(c0f90000,c11f2600,52,c0f8b8d8,a) at ether_demux+0x259 ether_input(c0f90000,c11f2600,c0f902cc,0,c0826fc6) at ether_input+0x25d sis_rxeof(c0f90000) at sis_rxeof+0x18b sis_intr(c0f90000) at sis_intr+0xa3 ithread_loop(c0ec6880,c76bfd48,c0ec6880,c05feb3c,0) at ithread_loop+0x124 fork_exit(c05feb3c,c0ec6880,c76bfd48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc76bfd7c, ebp = 0 --- db> doadump No such command db> call doadump Dumping 128 MB 16 32 48 64 80 96 112 Dump complete 0xf db> reset . Giorgos Keramidas (keramida@freebsd.org) wrote: > On 2005-07-19 22:03, Edwin wrote: > > Hi John, > > > > Updated the kernel, same crash under load, looks like m is null, you're right. > > > > Not quite sure where to go from here. I'm happy to do the footwork - just still real > > hazy on the BSD kernel part of things. > > > > panic: m_copym, offset > size of mbuf chain > > KDB: enter: panic > > [thread pid 27 tid 100021 ] > > Stopped at kdb_enter+0x2b: nop > > db> where > > Tracing pid 27 tid 100021 td 0xc0ed0180 > > kdb_enter(c0821a6a) at kdb_enter+0x2b > > panic(c0826049,0,c076b79c,c102d600,100) at panic+0xbb > > m_copym(0,5dc,5c8,1,14) at m_copym+0x60 > > ip_fragment(c123180e,c76d1c38,5dc,0,1) at ip_fragment+0x214 > > ip_fastforward(c11fee00) at ip_fastforward+0x6ed > > ether_demux(c0f90000,c11fee00,52,c0f8aad0,1f) at ether_demux+0x259 > > ether_input(c0f90000,c11fee00,c0f902d0,0,c08336ab) at ether_input+0x25d > > sis_rxeof(c0f90000,1,5,c08e5500,c76d1ce0) at sis_rxeof+0x1ab > > sis_poll(c0f90000,0,5) at sis_poll+0x7f > > netisr_poll(0) at netisr_poll+0x188 > > swi_net(0) at swi_net+0x81 > > ithread_loop(c0ec6580,c76d1d48,c0ec6580,c060030c,0) at ithread_loop+0x124 > > fork_exit(c060030c,c0ec6580,c76d1d48) at fork_exit+0xa4 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0x1, eip = 0, esp = 0xc76d1d7c, ebp = 0 --- > > Both tracebacks contain sis_poll() somewhere in the call stack? Are you > using POLLING? If yes, can you try without POLLING and see if the crash > can still be reproduced? > > - Giorgos > From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 03:04:55 2005 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 B2A5916A422 for ; Thu, 21 Jul 2005 03:04:55 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2906B43D58 for ; Thu, 21 Jul 2005 03:04:33 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so47110wri for ; Wed, 20 Jul 2005 20:04:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=n5UQnMbHHTEeaq8xmrnXqqjRAj8OhR1JpQB2eDQaJ7sZhGMRt+6vd3KcSPwTIc9RIZATbWM1m80aFkpSd5NeuaWTUstN8DajqZaICf05xYP4fZLIk458gbooxXDL8qXBBNZeGGnLvG2MgTGcbShlyfpApA6IYcYMLpCcPJCnAYM= Received: by 10.54.13.38 with SMTP id 38mr361742wrm; Wed, 20 Jul 2005 20:03:49 -0700 (PDT) Received: by 10.54.144.1 with HTTP; Wed, 20 Jul 2005 20:03:49 -0700 (PDT) Message-ID: Date: Wed, 20 Jul 2005 22:03:49 -0500 From: Sam Pierson To: FreeBSD Hackers Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Atheros, hardware access layer, collisions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sam Pierson List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 03:04:55 -0000 Hey all, I'm working on a project that requires creating a single packet collision between hosts, so I've been digging around in=20 /sys/contrib/dev/ath for awhile now. I successfully disabled the CTS and RTS control frames from being transmitted, which was the first step. I believe now the application is sending packets, creating a collision. I think there is still collision detection happening on the hardware=20 level. I think I have to disable the retransmission of frames=20 which are lost due to collisions. Here's my reasoning: In the lab, two hosts are sending packets to the middle guy at the same time. After examining the traffic on the middle guy, one packet will arrive before the other one (sometimes in different order) and the second packet comes 500-1200us after the first. From this, I think some retransmission is happening because of collision, since the results are seemingly random. Can anyone help me determine what I should zero out from the drivers? I'm not sure, but these look like the important ones: >From ah.h (/contrib/dev/ath/) #define=09CHANNEL_BUSY=090x0004=09/* Busy, occupied or overlap with adjoin = chan */ (earlier in the file...) typedef enum { =09TXQ_FLAG_TXOKINT_ENABLE=09 =3D 0x0001, /* enable TXOK interrupt */ =09TXQ_FLAG_TXERRINT_ENABLE =3D 0x0001, /* enable TXERR interrupt */ =09TXQ_FLAG_TXDESCINT_ENABLE =3D 0x0002, /* enable TXDESC interrupt */ =09TXQ_FLAG_TXEOLINT_ENABLE =3D 0x0004, /* enable TXEOL interrupt */ =09TXQ_FLAG_TXURNINT_ENABLE =3D 0x0008, /* enable TXURN interrupt */ =09TXQ_FLAG_BACKOFF_DISABLE =3D 0x0010, /* disable Post Backoff */ =09TXQ_FLAG_COMPRESSION_ENABLE =3D 0x0020, /* compression enabled */ =09TXQ_FLAG_RDYTIME_EXP_POLICY_ENABLE =3D 0x0040, /* enable ready time =09=09=09=09=09=09=09expiry policy */ =09TXQ_FLAG_FRAG_BURST_BACKOFF_ENABLE =3D 0x0080, /* enable backoff while =09=09=09=09=09=09=09sending fragment burst*/ } HAL_TX_QUEUE_FLAGS; Does zeroing out frag_burst_backoff_enable do anything for me? I'm still trying many configurations and recompiling this to my kernel is very time consuming. =20 Thanks, Sam From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 06:36:09 2005 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 34BD316A41F for ; Thu, 21 Jul 2005 06:36:09 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 63A0A43D45 for ; Thu, 21 Jul 2005 06:36:07 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 21 Jul 2005 07:36:06 +0100 (BST) Date: Thu, 21 Jul 2005 07:36:06 +0100 From: David Malone To: Sam Pierson Message-ID: <20050721063606.GA33233@walton.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: FreeBSD Hackers Subject: Re: Atheros, hardware access layer, collisions 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, 21 Jul 2005 06:36:09 -0000 On Wed, Jul 20, 2005 at 10:03:49PM -0500, Sam Pierson wrote: > I think there is still collision detection happening on the hardware > level. I think I have to disable the retransmission of frames > which are lost due to collisions. Here's my reasoning: In the lab, two > hosts are sending packets to the middle guy at the same time. > After examining the traffic on the middle guy, one packet will > arrive before the other one (sometimes in different order) and > the second packet comes 500-1200us after the first. From this, > I think some retransmission is happening because of collision, > since the results are seemingly random. Since introducing random delays before transmission and using carrier sensing are basic features of the 802.11 MAC, I'd be suprised if you can stop the hardware doing it. To reduce the effects as much as possible, you could try trying to reduce the number of retransmission attempts and changing the cwmin parameter to be small. Even if you do this, you'll still need to transmit the packets quite close to one another (probably within 20us) to avoid the carrier sense stuff kicking in. What effect are you trying to achieve? David. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 07:06:35 2005 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 85DDF16A41F for ; Thu, 21 Jul 2005 07:06:35 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from mail.rdu.kirov.ru (ns.rdu.kirov.ru [217.9.151.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id 803EF43D4C for ; Thu, 21 Jul 2005 07:06:32 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from kirov.so-cdu.ru (kirov [172.21.81.1]) by mail.rdu.kirov.ru (Postfix) with ESMTP id A2079FE67; Thu, 21 Jul 2005 11:06:30 +0400 (MSD) Received: from kirov.so-cdu.ru (localhost [127.0.0.1]) by rdu.kirov.ru (Postfix) with SMTP id 826B115C2D; Thu, 21 Jul 2005 11:06:30 +0400 (MSD) Received: by rdu.kirov.ru (Postfix, from userid 1014) id 0F45D15C2A; Thu, 21 Jul 2005 11:06:30 +0400 (MSD) Received: from [172.21.81.52] (elsukov.kirov.so-cdu.ru [172.21.81.52]) by rdu.kirov.ru (Postfix) with ESMTP id E059915357; Thu, 21 Jul 2005 11:06:29 +0400 (MSD) Message-ID: <42DF4975.2030406@yandex.ru> Date: Thu, 21 Jul 2005 11:06:29 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <27361.1120381532@phk.freebsd.dk> In-Reply-To: <27361.1120381532@phk.freebsd.dk> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Ancient FreeBSD releases online 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, 21 Jul 2005 07:06:35 -0000 Poul-Henning Kamp wrote: > ftp://phk.freebsd.dk > ./386BSD/cd1.iso Can you upload MD5 checksums too? -- WBR, Andrey V. Elsukov From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 07:34:49 2005 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 A400716A41F for ; Thu, 21 Jul 2005 07:34:49 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail25.syd.optusnet.com.au (mail25.syd.optusnet.com.au [211.29.133.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9EA743D4C for ; Thu, 21 Jul 2005 07:34:47 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail25.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j6L7Yf0b031796 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 21 Jul 2005 17:34:44 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j6L7YfTu004464; Thu, 21 Jul 2005 17:34:41 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j6L7Yeir004463; Thu, 21 Jul 2005 17:34:40 +1000 (EST) (envelope-from pjeremy) Date: Thu, 21 Jul 2005 17:34:40 +1000 From: Peter Jeremy To: "Eygene A. Ryabinkin" Message-ID: <20050721073440.GA324@cirb503493.alcatel.com.au> References: <20050714101442.GI16608@rea.mbslab.kiae.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050714101442.GI16608@rea.mbslab.kiae.ru> User-Agent: Mutt/1.4.2i Cc: hackers@freebsd.org Subject: Re: /etc/opiekeys permissions? 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, 21 Jul 2005 07:34:49 -0000 On Thu, 2005-Jul-14 14:14:42 +0400, Eygene A. Ryabinkin wrote: > Playing with OPIE I've noticed that the /etc/opiekeys have mode 644. ... > But now it seems to be vulnurable again. Are there any programs that are >run in non-root mode and they do want to use OPIE? If there is no such >programs, why the permissions are so strange? Since an OPIE password can only be used once, any program that uses OPIE needs to be able to read and write /etc/opiekeys. There is no valid reason for a program to just want to read the file. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 07:45:36 2005 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 E824A16A41F for ; Thu, 21 Jul 2005 07:45:36 +0000 (GMT) (envelope-from freebsd@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 82ABA43D46 for ; Thu, 21 Jul 2005 07:45:36 +0000 (GMT) (envelope-from freebsd@rea.mbslab.kiae.ru) Received: by rea.mbslab.kiae.ru (Postfix, from userid 1000) id 170FBBC70; Thu, 21 Jul 2005 11:45:35 +0400 (MSD) Date: Thu, 21 Jul 2005 11:45:35 +0400 From: "Eygene A. Ryabinkin" To: Peter Jeremy Message-ID: <20050721074535.GX57786@rea.mbslab.kiae.ru> References: <20050714101442.GI16608@rea.mbslab.kiae.ru> <20050721073440.GA324@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050721073440.GA324@cirb503493.alcatel.com.au> User-Agent: Mutt/1.5.9i Cc: hackers@freebsd.org Subject: Re: /etc/opiekeys permissions? 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, 21 Jul 2005 07:45:37 -0000 > Since an OPIE password can only be used once, any program that uses OPIE > needs to be able to read and write /etc/opiekeys. There is no valid reason > for a program to just want to read the file. Good point. I've missed it. Thanks. So, the arguments for permissions 0600 instead of 0644 are getting stronger. Probably I should make a PR? -- rea From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 11:57:44 2005 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 5137216A420 for ; Thu, 21 Jul 2005 11:57:44 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB2C343D60 for ; Thu, 21 Jul 2005 11:57:31 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from beatrix.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by aiolos.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j6LBvPoR019880; Thu, 21 Jul 2005 14:57:28 +0300 Received: from beatrix.daedalusnetworks.priv (localhost [127.0.0.1]) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3) with ESMTP id j6LBvLXr016799; Thu, 21 Jul 2005 14:57:21 +0300 (EEST) Received: (from keramida@localhost) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3/Submit) id j6LBvJwT016798; Thu, 21 Jul 2005 14:57:19 +0300 (EEST) Date: Thu, 21 Jul 2005 14:57:19 +0300 From: Giorgos Keramidas To: Edwin Message-ID: <20050721115719.GK16179@beatrix.daedalusnetworks.priv> References: <20050719034215.GB20752@asx01.verolan.com> <200507191120.37526.jhb@FreeBSD.org> <20050720020302.GA24474@asx01.verolan.com> <20050720100623.GA1470@beatrix.daedalusnetworks.priv> <20050720154156.GA26755@asx01.verolan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050720154156.GA26755@asx01.verolan.com> Cc: freebsd-hackers@freebsd.org Subject: Re: help w/panic under heavy load - 5.4 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, 21 Jul 2005 11:57:44 -0000 On 2005-07-20 11:41, Edwin wrote: > I'm trying to understand the particulars about this - I get the null pointer > part, but as to ip_fragment - it's fragmenting mbufs to handle ip packets > during switching? and its failing trying to copy data past the end of the > chain? ip_fastfwd() thinks that it should fragment the packet because it somehow calculates a bogus ``mtu'' value. See the mtu value in frame 12 of the stack trace below. > mbsd05# kgdb kernel.debug /tmp/crash/vmcore.3 > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". > #0 doadump () at pcpu.h:159 > 159 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) where > #0 doadump () at pcpu.h:159 > #1 0xc04611f6 in db_fncall (dummy1=0, dummy2=0, dummy3=-1, dummy4=0xc76bf9f4 "(�k�") > at /usr/src/sys/ddb/db_command.c:531 > #2 0xc0461004 in db_command (last_cmdp=0xc08c9264, cmd_table=0x0, aux_cmd_tablep=0xc08483b8, > aux_cmd_tablep_end=0xc08483d4) at /usr/src/sys/ddb/db_command.c:349 > #3 0xc04610cc in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 > #4 0xc0462c51 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 > #5 0xc0627af2 in kdb_trap (type=3, code=0, tf=0xc76bfb30) at /usr/src/sys/kern/subr_kdb.c:468 > #6 0xc07b6394 in trap (frame= > {tf_fs = -949288936, tf_es = -1067319280, tf_ds = -1065222128, tf_edi = 1, tf_esi = -1065 > 197495, tf_ebp = -949224592, tf_isp = -949224612, tf_ebx = -949224548, tf_edx = 0, tf_ecx = -10 > 60921344, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067288461, tf_cs = -1065222136, tf_eflags = 658, tf_esp = -949224560, tf_ss = -1067376657}) at /usr/src/sys/i386/i386/trap.c:584 > #7 0xc07a69ca in calltrap () at /usr/src/sys/i386/i386/exception.s:140 > #8 0xc76b0018 in ?? () > #9 0xc0620010 in schedcpu () at /usr/src/sys/kern/sched_4bsd.c:461 > #10 0xc0611fef in panic (fmt=0xc0820008 "default") at /usr/src/sys/kern/kern_shutdown.c:550 > #11 0xc0641a2c in m_copym (m=0x0, off0=1500, len=1480, wait=1) > at /usr/src/sys/kern/uipc_mbuf.c:385 > #12 0xc069b694 in ip_fragment (ip=0xc11bd80e, m_frag=0xc76bfc6c, mtu=-1056787456, > if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 The ``mtu'' is an extremely small integer value, which is definitely a problem here. Somehow, ip_fastforward() calculates a very wrong value for the ``mtu''. > 6933c1 in ip_fastforward (m=0xc11ab100) at /usr/src/sys/netinet/ip_fastfwd.c:572 If you have this particular crash dump, can you show me a dump of the ``ro.ro_rt->rt_rmx'' and the ``ifp'' structure that ip_fastforward() is using? One of these two seems to have an invalid mtu value. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 13:22:25 2005 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 4449116A420 for ; Thu, 21 Jul 2005 13:22:25 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id E335C43D5D for ; Thu, 21 Jul 2005 13:22:08 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so206950wri for ; Thu, 21 Jul 2005 06:22:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TetJ7qS/edNCM3SzdusCWTb3yumr8hbLYAGVasEO0HeQwlqUtMpH+vNqApSOM/K8WDlI4Yu63wOKyiSs4cjBoRXf6/IiNnoQk9gzeI2roTPKmTUFvNApK4i43KHfu6pya9cMHeSrzChdBdAZ5auCDODH9JrcayyOeSvTbJ0fVmg= Received: by 10.54.120.12 with SMTP id s12mr516466wrc; Thu, 21 Jul 2005 06:21:37 -0700 (PDT) Received: by 10.54.144.1 with HTTP; Thu, 21 Jul 2005 06:21:37 -0700 (PDT) Message-ID: Date: Thu, 21 Jul 2005 08:21:37 -0500 From: Sam Pierson To: David Malone In-Reply-To: <20050721063606.GA33233@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050721063606.GA33233@walton.maths.tcd.ie> Cc: FreeBSD Hackers Subject: Re: Atheros, hardware access layer, collisions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sam Pierson List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 13:22:25 -0000 On 7/21/05, David Malone wrote: > On Wed, Jul 20, 2005 at 10:03:49PM -0500, Sam Pierson wrote: > > I think there is still collision detection happening on the hardware > > level. I think I have to disable the retransmission of frames > > which are lost due to collisions. Here's my reasoning: In the lab, tw= o > > hosts are sending packets to the middle guy at the same time. > > After examining the traffic on the middle guy, one packet will > > arrive before the other one (sometimes in different order) and > > the second packet comes 500-1200us after the first. From this, > > I think some retransmission is happening because of collision, > > since the results are seemingly random. >=20 > Since introducing random delays before transmission and using carrier > sensing are basic features of the 802.11 MAC, I'd be suprised if > you can stop the hardware doing it. To reduce the effects as much > as possible, you could try trying to reduce the number of retransmission > attempts and changing the cwmin parameter to be small. Even if you > do this, you'll still need to transmit the packets quite close to > one another (probably within 20us) to avoid the carrier sense stuff > kicking in. >=20 > What effect are you trying to achieve? I've got two computers synchronized to send one packet each to this machine sitting between them. This machine responds with a packet to each that it receives (on the application level, not in the control fram= e space), so if there is a collision, I don't want the middle machine to respond and I don't want the senders to retransmit when they don't=20 receive an ACK control frame after they send their data packet (again, this packet is up on the transport layer, so more control frames might be sent). Normal operation (regular connectivity) is not needed on the two senders, so screwing up their retransmission scheme isn't a problem. -Sam From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 13:58:33 2005 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 3042516A430 for ; Thu, 21 Jul 2005 13:58:33 +0000 (GMT) (envelope-from parcn@yahoo.com) Received: from web41110.mail.yahoo.com (web41110.mail.yahoo.com [66.218.93.26]) by mx1.FreeBSD.org (Postfix) with SMTP id 8810243D8A for ; Thu, 21 Jul 2005 13:58:15 +0000 (GMT) (envelope-from parcn@yahoo.com) Received: (qmail 309 invoked by uid 60001); 21 Jul 2005 13:58:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2vQRmjZpnZJA6xsS7v/kDq2YIoREmIG2s5C2AQCUGKDSlLdjohhaQCcXCzX3UiPa4KVXQebO/AeVVrVMghXqr5hMfLb7iNC/fAfNx/1eEfZHyYLaVyCcfSgkuROjdd+zU3I7trO/We6W8t/Sp2EhBHxfuQRY+yr6cXASp3cN0OA= ; Message-ID: <20050721135815.307.qmail@web41110.mail.yahoo.com> Received: from [63.196.7.46] by web41110.mail.yahoo.com via HTTP; Thu, 21 Jul 2005 06:58:15 PDT Date: Thu, 21 Jul 2005 06:58:15 -0700 (PDT) From: "P.ArulChandran" To: freebsd-hackers@freebsd.org In-Reply-To: <20050721120037.6158716A427@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: IPv4 Link Local support in FreeBSD 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, 21 Jul 2005 13:58:33 -0000 Hi All, Does FreeBSD support IPv4 Link Local addresses as per RFC 3927 ? -Arul ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 14:47:14 2005 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 AEC3D16A421 for ; Thu, 21 Jul 2005 14:47:14 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25F5A43DA5 for ; Thu, 21 Jul 2005 14:46:47 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from beatrix.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by aiolos.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j6LEkirZ004219; Thu, 21 Jul 2005 17:46:45 +0300 Received: from beatrix.daedalusnetworks.priv (localhost [127.0.0.1]) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3) with ESMTP id j6LEki4x019391; Thu, 21 Jul 2005 17:46:44 +0300 (EEST) Received: (from keramida@localhost) by beatrix.daedalusnetworks.priv (8.13.3+Sun/8.13.3/Submit) id j6LEkiWS019390; Thu, 21 Jul 2005 17:46:44 +0300 (EEST) Date: Thu, 21 Jul 2005 17:46:44 +0300 From: Giorgos Keramidas To: Edwin Message-ID: <20050721144644.GA19340@beatrix.daedalusnetworks.priv> References: <20050719034215.GB20752@asx01.verolan.com> <200507191120.37526.jhb@FreeBSD.org> <20050720020302.GA24474@asx01.verolan.com> <20050720100623.GA1470@beatrix.daedalusnetworks.priv> <20050720154156.GA26755@asx01.verolan.com> <20050721115719.GK16179@beatrix.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050721115719.GK16179@beatrix.daedalusnetworks.priv> Cc: freebsd-hackers@freebsd.org Subject: Re: help w/panic under heavy load - 5.4 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, 21 Jul 2005 14:47:14 -0000 On 2005-07-21 14:57, Giorgos Keramidas wrote: > On 2005-07-20 11:41, Edwin wrote: > > I'm trying to understand the particulars about this - I get the null pointer > > part, but as to ip_fragment - it's fragmenting mbufs to handle ip packets > > during switching? and its failing trying to copy data past the end of the > > chain? > > ip_fastfwd() thinks that it should fragment the packet because it somehow > calculates a bogus ``mtu'' value. See the mtu value in frame 12 of the stack > trace below. > > > #10 0xc0611fef in panic (fmt=0xc0820008 "default") at /usr/src/sys/kern/kern_shutdown.c:550 > > #11 0xc0641a2c in m_copym (m=0x0, off0=1500, len=1480, wait=1) > > at /usr/src/sys/kern/uipc_mbuf.c:385 > > #12 0xc069b694 in ip_fragment (ip=0xc11bd80e, m_frag=0xc76bfc6c, mtu=-1056787456, > > if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 > > The ``mtu'' is an extremely small integer value, which is definitely a problem > here. Somehow, ip_fastforward() calculates a very wrong value for the ``mtu''. The check for finding the right MTU in ip_output.c is a bit different, as it includes a check for RTF_UP: 777: if (ip->ip_off & IP_DF) { 778: error = EMSGSIZE; 779: /* 780: * This case can happen if the user changed the MTU 781: * of an interface after enabling IP on it. Because 782: * most netifs don't keep track of routes pointing to 783: * them, there is no way for one to update all its 784: * routes when the MTU is changed. 785: */ 786: if ((ro->ro_rt->rt_flags & (RTF_UP | RTF_HOST)) && 787: (ro->ro_rt->rt_rmx.rmx_mtu > ifp->if_mtu)) { 788: ro->ro_rt->rt_rmx.rmx_mtu = ifp->if_mtu; 789: } 790: ipstat.ips_cantfrag++; 791: goto bad; 792: } The check for RTF_UP doesn't exist in ip_fastfwd.c, except perhaps through the ip_findroute() call. I'm probably confused, but it seems that ip_findroute() in ip_fastfwd.c may still return a route entry for a gateway that is not yet RTF_UP, since the check for the RTF_UP flag is not done for the dst.rt_gateway route entry too. This may be the cause of the invalid MTU value you're seeing. Can you try the following patch for ip_fastfwd.c? The diff is also available online at: http://people.freebsd.org/~keramida/diff/fastfwd-mtu.patch %%% Index: ip_fastfwd.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fastfwd.c,v retrieving revision 1.28 diff -u -r1.28 ip_fastfwd.c --- ip_fastfwd.c 4 May 2005 13:09:19 -0000 1.28 +++ ip_fastfwd.c 21 Jul 2005 14:38:35 -0000 @@ -537,12 +537,13 @@ } /* - * Check if packet fits MTU or if hardware will fragement for us + * Check if packet fits MTU or if hardware will fragment for us. + * If necessary, update the MTU of the route entry too. */ - if (ro.ro_rt->rt_rmx.rmx_mtu) - mtu = min(ro.ro_rt->rt_rmx.rmx_mtu, ifp->if_mtu); - else - mtu = ifp->if_mtu; + if ((ro.ro_rt.rt_flags & (RTF_UP | RTF_HOST)) && + ro.ro_rt->rt_rmx.rmx_mtu > ipf->if_mtu) + ro.ro_rt->rt_rmx.rmx_mtu = ipf->if_mtu; + mtu = ifp->if_mtu; if (ip->ip_len <= mtu || (ifp->if_hwassist & CSUM_FRAGMENT && (ip->ip_off & IP_DF) == 0)) { %%% From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 15:48:00 2005 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 0156A16A422 for ; Thu, 21 Jul 2005 15:48:00 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 9077C43D75 for ; Thu, 21 Jul 2005 15:47:48 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 21 Jul 2005 16:47:33 +0100 (BST) To: Sam Pierson In-reply-to: Your message of "Thu, 21 Jul 2005 08:21:37 CDT." X-Request-Do: Date: Thu, 21 Jul 2005 16:47:32 +0100 From: David Malone Message-ID: <200507211647.aa79456@salmon.maths.tcd.ie> Cc: FreeBSD Hackers Subject: Re: Atheros, hardware access layer, collisions 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, 21 Jul 2005 15:48:00 -0000 > I've got two computers synchronized to send one packet each to this > machine sitting between them. This machine responds with a packet > to each that it receives (on the application level, not in the control frame > space), so if there is a collision, I don't want the middle machine to > respond and I don't want the senders to retransmit when they don't > receive an ACK control frame after they send their data packet (again, > this packet is up on the transport layer, so more control frames might > be sent). Normal operation (regular connectivity) is not needed on the > two senders, so screwing up their retransmission scheme isn't a problem. OK - you can probably achieve that by setting the retry limit to be 1, setting CWmin to be very small. However, you'll need to make sure that both machines transmissions are synchronised to better than 20us (which is no mean feat), otherwise carrier sense will foil your plan! David. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 16:01:33 2005 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 28B5B16A41F for ; Thu, 21 Jul 2005 16:01:33 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC7EC43D45 for ; Thu, 21 Jul 2005 16:01:32 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so262989wri for ; Thu, 21 Jul 2005 09:01:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZVSJkVRYEeo5Bn/QJS8hrf9Pny/ZMcRr2UX2j3ZBDiJyqPcm0XnnqZt/gEkCRvewrXvSdNrq65hVCBadFnlEEYOz1P+BDiskCikJv7Bv+7crvKA+Ew71DoT7HxQL4pGGiiKd67T17+kxOcHX3V8P64zuaI/tUl16dWqGuec6F18= Received: by 10.54.13.67 with SMTP id 67mr574369wrm; Thu, 21 Jul 2005 09:01:07 -0700 (PDT) Received: by 10.54.144.1 with HTTP; Thu, 21 Jul 2005 09:01:06 -0700 (PDT) Message-ID: Date: Thu, 21 Jul 2005 11:01:07 -0500 From: Sam Pierson To: David Malone In-Reply-To: <200507211647.aa79456@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200507211647.aa79456@salmon.maths.tcd.ie> Cc: FreeBSD Hackers Subject: Re: Atheros, hardware access layer, collisions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sam Pierson List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 16:01:33 -0000 > OK - you can probably achieve that by setting the retry limit to > be 1, setting CWmin to be very small.=20 I was looking for this in the ah.h and the ah_desc.h files. Are they someplace else, or maybe this is a system call? I can't find anything about the retry limit (<-- CWmin =3D retry?) Thanks, Sam >However, you'll need to make > sure that both machines transmissions are synchronised to better > than 20us (which is no mean feat), otherwise carrier sense will > foil your plan! >=20 > David. > From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 16:18:54 2005 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 263FF16A423 for ; Thu, 21 Jul 2005 16:18:54 +0000 (GMT) (envelope-from patrick_dkt@yahoo.com.hk) Received: from web52101.mail.yahoo.com (web52101.mail.yahoo.com [206.190.48.104]) by mx1.FreeBSD.org (Postfix) with SMTP id CD39E43D60 for ; Thu, 21 Jul 2005 16:18:31 +0000 (GMT) (envelope-from patrick_dkt@yahoo.com.hk) Received: (qmail 63617 invoked by uid 60001); 21 Jul 2005 16:18:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.hk; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Axmx3rgOwmOq792RZutoMe4hM5YEW3L/jYF8a+RFiXeQxgU/L3xEhr6zaqTPXzqJlIRSBcXI7ufnxzHgtMIvHkalA8UUbtJbZnBMnTDeWL8trIwP3MXTnk0PmL0pcbo+7UqLrNJorM5hE+sYLt7GC6/8vHbP3k+IBbwvMq6WSN4= ; Message-ID: <20050721161831.63615.qmail@web52101.mail.yahoo.com> Received: from [61.10.7.85] by web52101.mail.yahoo.com via HTTP; Thu, 21 Jul 2005 09:18:31 PDT Date: Thu, 21 Jul 2005 09:18:31 -0700 (PDT) From: Patrick Dung To: freebsd hackers MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: sendmail and clamav milter 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: Thu, 21 Jul 2005 16:18:54 -0000 Hi I have a clamd server(antivirus server), opening TCP connection instead of the unix domain socket. Next, I have another separate sendmail server. Now I want to do virus scanning. So, should the clamav-milter daemon be on the sendmail server or the antivirus server? I have this configuration and this works: Sendmail SRV <-local domain socket-> clamav-milter <- tcp -> clamd server (server A) (server A) (server b) Or this is the correct one: Sendmail SRV <-tcp-> clamav-milter <- tcp/domain socket -> clamd server (server A) (server b) (server b) Regards Patrick ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 16:43:22 2005 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 4CEEA16A43E for ; Thu, 21 Jul 2005 16:43:22 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C49E43D69 for ; Thu, 21 Jul 2005 16:43:18 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j6LGhH6P042783; Thu, 21 Jul 2005 11:43:17 -0500 (CDT) (envelope-from dan) Date: Thu, 21 Jul 2005 11:43:17 -0500 From: Dan Nelson To: Patrick Dung Message-ID: <20050721164317.GA10043@dan.emsphone.com> References: <20050721161831.63615.qmail@web52101.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050721161831.63615.qmail@web52101.mail.yahoo.com> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i Cc: freebsd hackers Subject: Re: sendmail and clamav milter 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: Thu, 21 Jul 2005 16:43:22 -0000 In the last episode (Jul 21), Patrick Dung said: > I have a clamd server(antivirus server), opening TCP connection > instead of the unix domain socket. > > Next, I have another separate sendmail server. Now I want to do virus > scanning. > > So, should the clamav-milter daemon be on the sendmail server or the > antivirus server? > > I have this configuration and this works: > > Sendmail SRV <-local domain socket-> clamav-milter <- tcp -> clamd > server (server A) (server A) (server b) This is probably slightly faster than the one below, since the sendmail-milter connection is more chatty (you may get a callback for each header, etc). > Or this is the correct one: > Sendmail SRV <-tcp-> clamav-milter <- tcp/domain socket -> clamd server > (server A) (server b) (server b) -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 17:06:22 2005 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 A994416A41F for ; Thu, 21 Jul 2005 17:06:22 +0000 (GMT) (envelope-from freebsd.macgregor@blueyonder.co.uk) Received: from the-macgregors.org (82-46-96-19.cable.ubr06.stav.blueyonder.co.uk [82.46.96.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1146543D45 for ; Thu, 21 Jul 2005 17:06:21 +0000 (GMT) (envelope-from freebsd.macgregor@blueyonder.co.uk) X-Urban-Legend: Mail headers contain urban legends Received: from fire (rob@fire.macgregor [192.168.32.100]) (user=freebsd mech=LOGIN bits=0) by the-macgregors.org (8.13.4/8.13.4) with ESMTP id j6LH6JKp004409 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 21 Jul 2005 17:06:20 GMT Message-Id: <200507211706.j6LH6JKp004409@the-macgregors.org> From: "Rob MacGregor" To: "'freebsd hackers'" Date: Thu, 21 Jul 2005 18:06:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050721161831.63615.qmail@web52101.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWOECRTw+Up0rJ4QOOFOwY5TF84oQABk1Zg X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) Subject: RE: sendmail and clamav milter 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: Thu, 21 Jul 2005 17:06:22 -0000 On Thursday, July 21, 2005 5:19 PM, Patrick Dung <> unleashed the infinite monkeys and produced: > So, should the clamav-milter daemon be on the sendmail server or the > antivirus server? You may get more relevant information on the clamav list, or even comp.mail.sendmail (since the question isn't FreeBSD specific). Actually, I'm fairly certain it's been discussed before, though not necessarily for clamav, on comp.mail.sendmail. > I have this configuration and this works: > > Sendmail SRV <-local domain socket-> clamav-milter <- tcp -> clamd > server > (server A) (server A) (server b) > > Or this is the correct one: > Sendmail SRV <-tcp-> clamav-milter <- tcp/domain socket -> clamd server > (server A) (server b) (server b) To some degree the answer is: either. It'll depend on the relative hardware specs, the network speed and the sizes of the emails. Try both and see what's faster, on average, for you. -- Rob | Oh my God! They killed init! You bastards! From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 17:49:35 2005 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 4DA4716A420 for ; Thu, 21 Jul 2005 17:49:35 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id A5C9943D82 for ; Thu, 21 Jul 2005 17:49:09 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 21 Jul 2005 18:49:08 +0100 (BST) To: Sam Pierson In-reply-to: Your message of "Thu, 21 Jul 2005 11:01:07 CDT." X-Request-Do: Date: Thu, 21 Jul 2005 18:49:08 +0100 From: David Malone Message-ID: <200507211849.aa11934@salmon.maths.tcd.ie> Cc: FreeBSD Hackers Subject: Re: Atheros, hardware access layer, collisions 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, 21 Jul 2005 17:49:35 -0000 > I was looking for this in the ah.h and the ah_desc.h files. Are they > someplace else, or maybe this is a system call? I can't find anything > about the retry limit (<-- CWmin = retry?) Thanks, CWmin is a setting that controls the random delay before packets are transmitted. Search for tqi_cwmin in the driver. The retry limit says how many times the MAC should retry if it gets a collision while trying to transmit - I think it is controled by the tqi_shretry and tqi_lgretry values. In the driver in 6.X you can (in principle) set these values at the time the transmit queues are configured. David. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 21 19:26:05 2005 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 B058D16A41F; Thu, 21 Jul 2005 19:26:05 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A1B343D6A; Thu, 21 Jul 2005 19:26:05 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.9p2/8.12.9) with ESMTP id j6LJQ5Yk071116; Thu, 21 Jul 2005 12:26:05 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j6LJQ55D071115; Thu, 21 Jul 2005 12:26:05 -0700 (PDT) (envelope-from dillon) Date: Thu, 21 Jul 2005 12:26:05 -0700 (PDT) From: Matthew Dillon Message-Id: <200507211926.j6LJQ55D071115@apollo.backplane.com> To: Igor Shmukler References: <6533c1c9050721121030016b7d@mail.gmail.com> Cc: hackers@freebsd.org, fs@freebsd.org Subject: Re: per file lock list 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, 21 Jul 2005 19:26:05 -0000 :Hi, : :We have a question: how to get all POSIX locks for a given file? :.. : :As far as I know, existing API does not allow to retrieve all file :locks. Therefore, we need to use kernel internal structures to get all :... :So the question: is there an elegant way to get the lock list for a given file? : :Thank you in advance. You can use F_GETLK to iterate through all posix locks held on a file. From man fcntl: F_GETLK Get the first lock that blocks the lock description pointed to by the third argument, arg, taken as a pointer to a struct flock (see above). The information retrieved overwrites the information passed to fcntl() in the flock structure. If no lock is found that would prevent this lock from being created, the structure is left unchanged by this function call except for the lock type which is set to F_UNLCK. So what you do is you specify a lock description that covers the whole file and call F_GETLK. You then use the results to modify the lock description to a range that starts just past the returned lock for the next call. You continue iterating until F_GETLK tells you that there are no more locks. -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 22 00:25:58 2005 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 1744416A420 for ; Fri, 22 Jul 2005 00:25:58 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BFED43D48 for ; Fri, 22 Jul 2005 00:25:57 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j6M0Ptms039262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 17:25:56 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42E03E5B.80905@errno.com> Date: Thu, 21 Jul 2005 17:31:23 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Malone References: <200507211849.aa11934@salmon.maths.tcd.ie> In-Reply-To: <200507211849.aa11934@salmon.maths.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sam Pierson , FreeBSD Hackers Subject: Re: Atheros, hardware access layer, collisions 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: Fri, 22 Jul 2005 00:25:58 -0000 David Malone wrote: >>I was looking for this in the ah.h and the ah_desc.h files. Are they >>someplace else, or maybe this is a system call? I can't find anything >>about the retry limit (<-- CWmin = retry?) Thanks, > > > CWmin is a setting that controls the random delay before packets > are transmitted. Search for tqi_cwmin in the driver. The retry limit > says how many times the MAC should retry if it gets a collision > while trying to transmit - I think it is controled by the tqi_shretry > and tqi_lgretry values. In the driver in 6.X you can (in principle) > set these values at the time the transmit queues are configured. You need to set cwmin on the tx q as David describes. Be sure to set the parameters you set into the hardware; check the wme update code for the correct logic. For the other thing just set the tx descriptor to do 1 try. Sam From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 22 06:38:39 2005 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 1450116A421 for ; Fri, 22 Jul 2005 06:38:39 +0000 (GMT) (envelope-from yuka.muromachi@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id A601C43D82 for ; Fri, 22 Jul 2005 06:38:34 +0000 (GMT) (envelope-from yuka.muromachi@gmail.com) Received: by zproxy.gmail.com with SMTP id c3so126441nze for ; Thu, 21 Jul 2005 23:38:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Vnsman4x4SGUw6bX8x/kWBZ+bb93F5A3HiJEGbNiix6Hs0dJ3xypmzroCB4kurd0GwGF3ARxX0Opxq7vQG5sbkYN75Zpj8Edb/dRT+wGLsbko7AhDfUXOlIV/TD6pi/0KhvRd+r+9XPHfQXFxe+gpJJDUKYuttz1pB+o9wlm3+U= Received: by 10.36.115.4 with SMTP id n4mr1302480nzc; Thu, 21 Jul 2005 23:38:32 -0700 (PDT) Received: by 10.36.221.16 with HTTP; Thu, 21 Jul 2005 23:38:32 -0700 (PDT) Message-ID: Date: Fri, 22 Jul 2005 14:38:32 +0800 From: =?ISO-2022-JP?B?GyRCPDxELk0lOWEbKEI=?= To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Bus Driver probe and attach device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-2022-JP?B?GyRCPDxELk0lOWEbKEI=?= List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 06:38:39 -0000 Hi: I'm trying to written Azalia (HD Audio) driver for freebsd now. The HDA controller is a standard controller, which can take max=20 15 codecs. I'm planning made it be a bus driver (azalia bus). I tried to read the PCI, USB and Firewire driver code be sample. It looks: 1. Detect codec which already connected to azalia controller. 2. call device_add_child(azbus_dev, NULL, -1); to create a child device, which attach to azalia bus driver. 3. allocate memory to put codec info (e.g. device id, vendor id,=20 revision..etc), and call device_set_ivars(codec_dev, codec_info); save the codec_info ptr into device's ivars. 4. Continue 1 ~ 3, untin all available codecs be added. After all codecs be added, I call the device_probe_and_attach(azbus_dev);,= =20 but there is no thing happend.=20 Then I try to call bus_generic_attach(azbus_dev);, the codecs driver probe function be called. Is this correct (use bus_generic_attach()), and I'm interested the detail. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 22 07:11:27 2005 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 91D9D16A424 for ; Fri, 22 Jul 2005 07:11:27 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14CE343D95 for ; Fri, 22 Jul 2005 07:11:14 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-1.free.fr (Postfix) with ESMTP id 319861734DF; Fri, 22 Jul 2005 09:11:12 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 1555A407E; Fri, 22 Jul 2005 09:11:01 +0200 (CEST) Date: Fri, 22 Jul 2005 09:11:01 +0200 From: Jeremie Le Hen To: "P.ArulChandran" Message-ID: <20050722071101.GL39292@obiwan.tataz.chchile.org> References: <20050721120037.6158716A427@hub.freebsd.org> <20050721135815.307.qmail@web41110.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050721135815.307.qmail@web41110.mail.yahoo.com> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org Subject: Re: IPv4 Link Local support in FreeBSD 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: Fri, 22 Jul 2005 07:11:27 -0000 Hi Arul, > Does FreeBSD support IPv4 Link Local addresses as per RFC 3927 ? I think it's being worked on. IIRC, this is called zeroconf. You can check the archive for this word if you want to know more. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 22 07:13:20 2005 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 9D24D16A436 for ; Fri, 22 Jul 2005 07:13:20 +0000 (GMT) (envelope-from lists@partylemon.com) Received: from yorktown.networkredux.net (yorktown.networkredux.net [64.128.80.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 953BF43D49 for ; Fri, 22 Jul 2005 07:12:25 +0000 (GMT) (envelope-from lists@partylemon.com) Received: from 203-96-145-231.adsl.paradise.net.nz ([203.96.145.231] helo=[192.168.10.16]) by yorktown.networkredux.net with esmtpa (Exim 4.52) id 1Dvri1-0000Ir-P4 for freebsd-hackers@freebsd.org; Fri, 22 Jul 2005 00:12:38 -0700 Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-hackers@freebsd.org From: Phil Date: Fri, 22 Jul 2005 19:13:14 +1200 X-Mailer: Apple Mail (2.733) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - yorktown.networkredux.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - partylemon.com X-Source: X-Source-Args: X-Source-Dir: Subject: Help debugging mysterious freezing (5.4) 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: Fri, 22 Jul 2005 07:13:21 -0000 I'm trying to debug a strange freezing issue on my file-server, but I'm not quite sure how to go about it. My hardware setup is: -Rather old P3 -5 HDDs (All Seagate, around 1 year old) --4 of those drives (all apart from the system drive) are connected to a Promise Ultra100 TX2 PCI controller card -vr network card My software setup is: -FreeBSD 5.4 -Custom kernel: --Workaround from i386/73706 applied --No APIC (Required for my vr network card to work) --Device hints disabling ACPI and APIC -The bare essentials running for a NFS/SMB server What happens, is that the machine will freeze (no HDD activity, doesn't respond to keyboard, doesn't respond to network, etc.), usually when there's a lot of HDD activity. I don't get any console error messages, helpful log messages, or anything - the machine just halts and I have to give it a hard reboot. It's been working fine for almost a week (sharing drives over NFS/ SMB), when this started happening (I didn't start anything special, in fact, I wasn't even using it). The last couple of times this has happened, has been during a fsck (during phase 1) of the drives after I'd noticed it had frozen. The next time I ran fsck, it completed fine, no errors. It doesn't seem to freeze on one particular drive - SMART status for the drives is fine, and I've run a few tests - all pass. The IDE cables are all 80-pin, nice, stiff, new ones as well. If this is a hardware problem (which it looks to be), I'd at least like to know where. Thanks, -Phil From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 22 07:44:40 2005 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 BF32716A41F for ; Fri, 22 Jul 2005 07:44:40 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53E0F43D93 for ; Fri, 22 Jul 2005 07:44:35 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 1000) id DE1AD1F; Fri, 22 Jul 2005 09:44:34 +0200 (CEST) Date: Fri, 22 Jul 2005 09:44:34 +0200 From: Andrea Campi To: Jeremie Le Hen Message-ID: <20050722074434.GD34685@webcom.it> References: <20050721120037.6158716A427@hub.freebsd.org> <20050721135815.307.qmail@web41110.mail.yahoo.com> <20050722071101.GL39292@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050722071101.GL39292@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org, "P.ArulChandran" Subject: Re: IPv4 Link Local support in FreeBSD 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: Fri, 22 Jul 2005 07:44:40 -0000 On Fri, Jul 22, 2005 at 09:11:01AM +0200, Jeremie Le Hen wrote: > Hi Arul, > > > Does FreeBSD support IPv4 Link Local addresses as per RFC 3927 ? > > I think it's being worked on. IIRC, this is called zeroconf. You can > check the archive for this word if you want to know more. Better yet, check freebsd-net's archives, as that is where networking discussions happen... You can also search for howl, as that's the name of the package that is being used to provide that functionality. That said, I worked on getting the drive behave better; I offered to work with people to integrate the functionality in the rcNG framework, and to work with upstream maintainers to integrate any patches back into howl's distribution. Nobody showed any interest whatsoever in seeing this happen, so I had to quit working on this. Bye, Andrea -- Press every key to continue. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 22 07:48:20 2005 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 6C61216A447 for ; Fri, 22 Jul 2005 07:48:20 +0000 (GMT) (envelope-from takawata@axe-inc.co.jp) Received: from axe-inc.co.jp (axegw.axe-inc.co.jp [61.199.217.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A5DA43D9F for ; Fri, 22 Jul 2005 07:48:08 +0000 (GMT) (envelope-from takawata@axe-inc.co.jp) Received: from localhost (localhost [127.0.0.1]) by axe-inc.co.jp (8.9.3+3.2W/3.7W) with SMTP id QAA02213 for ; Fri, 22 Jul 2005 16:48:07 +0900 (JST) Message-Id: <200507220748.QAA02213@axe-inc.co.jp> X-Authentication-Warning: axegw.axe-inc.co.jp: localhost [127.0.0.1] didn't use HELO protocol To: freebsd-hackers@freebsd.org From: takawata@jp.freebsd.org In-reply-to: Your message of "Fri, 22 Jul 2005 14:38:32 +0800." Date: Fri, 22 Jul 2005 16:48:07 +0900 Sender: takawata@axe-inc.co.jp Subject: Re: Bus Driver probe and attach device 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: Fri, 22 Jul 2005 07:48:20 -0000 In message , $B<Hi: > >I'm trying to written Azalia (HD Audio) driver for freebsd now. > >The HDA controller is a standard controller, which can take max= >15 codecs. I'm planning made it be a bus driver (azalia bus). > >I tried to read the PCI, USB and Firewire driver code be sample. >It looks: > >1. Detect codec which already connected to azalia controller. >2. call device_add_child(azbus_dev, NULL, -1); to create a child > device, which attach to azalia bus driver. >3. allocate memory to put codec info (e.g. device id, vendor id,=20 > revision..etc), and call device_set_ivars(codec_dev, codec_info); > save the codec_info ptr into device's ivars. >4. Continue 1 ~ 3, untin all available codecs be added. > >After all codecs be added, I call the device_probe_and_attach(azbus_dev);, >but there is no thing happend.=20 Because it trys to attach azbus driver itself, not try to attach its child. >Then I try to call bus_generic_attach(azbus_dev);, the codecs driver probe >function be called. >Is this correct (use bus_generic_attach()), and I'm interested the detail. Correct. It calls device_probe_and_attach() for all child you already add. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 22 08:06:47 2005 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 69F9616A482 for ; Fri, 22 Jul 2005 08:06:47 +0000 (GMT) (envelope-from yuka.muromachi@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3F9F43DA9 for ; Fri, 22 Jul 2005 08:06:16 +0000 (GMT) (envelope-from yuka.muromachi@gmail.com) Received: by zproxy.gmail.com with SMTP id j2so138230nzf for ; Fri, 22 Jul 2005 01:06:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S4GyAeC9k/OBQQvkDL92q7OHLttyr3Duc/HlJaXZPRicyhhraDC3CAZJmgk+58LCX0C0gfKWiBu3OUOAdCzAjxjXF5lA8/QtuXzurto7Fh0hGOphUF7LFgMBsRkJQAQTM6HTFTLQ6RbM9JLBCc6HK1HTFl48nkUXLiJNo5By7sg= Received: by 10.36.129.16 with SMTP id b16mr1281797nzd; Fri, 22 Jul 2005 00:59:04 -0700 (PDT) Received: by 10.36.221.16 with HTTP; Fri, 22 Jul 2005 00:59:04 -0700 (PDT) Message-ID: Date: Fri, 22 Jul 2005 15:59:04 +0800 From: Yuka Muromachi To: freebsd-hackers@freebsd.org In-Reply-To: <200507220748.QAA02213@axe-inc.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200507220748.QAA02213@axe-inc.co.jp> Subject: Re: Bus Driver probe and attach device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yuka Muromachi List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 08:06:47 -0000 It mean I have 2 way to do it? (please view the code below) CodecPresent = az_rw(sc, AZX_REG_STATESTS); for (idx=0; idx> idx) & 0x0001) { // alloc codec info // fill codec info device_t codec_dev = device_add_child(azbus_dev, NULL, -1); device_set_ivars(codec_dev, codec); // I can probe and attach new device self here. device_probe_and_attach(codec_dev); } } // Or, I can probe and attach all new child here bus_generic_attach(azbus_dev); 05/07/22 $B$K(B takawata@jp.freebsd.org $B$5$s$O=q$-$^$7$?(B: > In message , $B< >Hi: > > > >I'm trying to written Azalia (HD Audio) driver for freebsd now. > > > >The HDA controller is a standard controller, which can take max= > >15 codecs. I'm planning made it be a bus driver (azalia bus). > > > >I tried to read the PCI, USB and Firewire driver code be sample. > >It looks: > > > >1. Detect codec which already connected to azalia controller. > >2. call device_add_child(azbus_dev, NULL, -1); to create a child > > device, which attach to azalia bus driver. > >3. allocate memory to put codec info (e.g. device id, vendor id,=20 > > revision..etc), and call device_set_ivars(codec_dev, codec_info); > > save the codec_info ptr into device's ivars. > >4. Continue 1 ~ 3, untin all available codecs be added. > > > >After all codecs be added, I call the device_probe_and_attach(azbus_dev);, > >but there is no thing happend.=20 > > Because it trys to attach azbus driver itself, not try to attach its child. > > >Then I try to call bus_generic_attach(azbus_dev);, the codecs driver probe > >function be called. > > >Is this correct (use bus_generic_attach()), and I'm interested the detail. > > Correct. It calls device_probe_and_attach() for all child you already > add. > > _______________________________________________ > 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 Fri Jul 22 12:44:34 2005 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 417A116A41F for ; Fri, 22 Jul 2005 12:44:34 +0000 (GMT) (envelope-from arundel@h3c.de) Received: from enterprise4.noxa.de (enterprise.noxa.de [212.60.197.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FD0443D72 for ; Fri, 22 Jul 2005 12:44:01 +0000 (GMT) (envelope-from arundel@h3c.de) Received: (qmail 12708 invoked from network); 22 Jul 2005 14:43:58 +0200 Received: from p508feed6.dip.t-dialin.net (HELO localhost.skatecity) (80.143.238.214) by enterprise.noxa.de with AES256-SHA encrypted SMTP; 22 Jul 2005 14:43:58 +0200 Received: from localhost.skatecity (nobody@localhost.skatecity [127.0.0.1]) by localhost.skatecity (8.13.4/8.13.4) with ESMTP id j6MChqfs033158 for ; Fri, 22 Jul 2005 14:43:52 +0200 (CEST) (envelope-from arundel@localhost.skatecity) Received: (from arundel@localhost) by localhost.skatecity (8.13.4/8.13.4/Submit) id j6MChqlA033157 for freebsd-hackers@freebsd.org; Fri, 22 Jul 2005 14:43:52 +0200 (CEST) (envelope-from arundel) From: alexander Date: Fri, 22 Jul 2005 14:43:51 +0200 To: freebsd-hackers@freebsd.org Message-ID: <20050722124351.GA33129@skatecity> Mail-Followup-To: freebsd-hackers@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: Help debugging mysterious freezing (5.4) 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: Fri, 22 Jul 2005 12:44:34 -0000 I had the very same problem under 5.4-STABLE. I tried a lot to get rid of the problem (switch RAM, recompile ports && world, change nvidia driver settings, etc.). What solved the problem for me was to remove a hardrive witch I used as swap partition: ad5: 810MB at ata2-slave WDMA2 Now I'm using a different swap partition. It shares a harddrive with my root (/) partition. After that I haven't experienced any lookups anymore. I asume the hardrive which I was using as a swap aprtition was either broken, had wrong sectors or the FBSD driver for it was buggy. Hope that helps you a bit. Cheers. On Fri Jul 22 05, Phil wrote: > I'm trying to debug a strange freezing issue on my file-server, but > I'm not quite sure how to go about it. > > My hardware setup is: > -Rather old P3 > -5 HDDs (All Seagate, around 1 year old) > --4 of those drives (all apart from the system drive) are connected > to a Promise Ultra100 TX2 PCI controller card > -vr network card > > My software setup is: > -FreeBSD 5.4 > -Custom kernel: > --Workaround from i386/73706 applied > --No APIC > (Required for my vr network card to work) > --Device hints disabling ACPI and APIC > -The bare essentials running for a NFS/SMB server > > What happens, is that the machine will freeze (no HDD activity, > doesn't respond to keyboard, doesn't respond to network, etc.), > usually when there's a lot of HDD activity. > > I don't get any console error messages, helpful log messages, or > anything - the machine just halts and I have to give it a hard reboot. > > It's been working fine for almost a week (sharing drives over NFS/ > SMB), when this started happening (I didn't start anything special, > in fact, I wasn't even using it). > > The last couple of times this has happened, has been during a fsck > (during phase 1) of the drives after I'd noticed it had frozen. The > next time I ran fsck, it completed fine, no errors. > It doesn't seem to freeze on one particular drive - SMART status for > the drives is fine, and I've run a few tests - all pass. The IDE > cables are all 80-pin, nice, stiff, new ones as well. > > If this is a hardware problem (which it looks to be), I'd at least > like to know where. > > Thanks, > > -Phil > > _______________________________________________ > 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 Thu Jul 21 19:10:45 2005 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 5F1DB16A41F for ; Thu, 21 Jul 2005 19:10:45 +0000 (GMT) (envelope-from igor.shmukler@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB6DD43D75 for ; Thu, 21 Jul 2005 19:10:33 +0000 (GMT) (envelope-from igor.shmukler@gmail.com) Received: by zproxy.gmail.com with SMTP id o1so36706nzf for ; Thu, 21 Jul 2005 12:10:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=q10kAIOoB6TwJY4GAkJr8JZoP+J3yc3jJhvVzLMocW4Iv53buKmTDRFgU011N9HrKmyjMS/auwTz5bVomvAAphHCpFT+VnJM/ZEqkUdZzKYOnfv/+EBetyRiYeJfr1Qs8cj6A6EVudB4/AeV1SUXjn5CUnSh7TIfPQahtfId5Yo= Received: by 10.36.129.16 with SMTP id b16mr1235566nzd; Thu, 21 Jul 2005 12:10:30 -0700 (PDT) Received: by 10.36.119.12 with HTTP; Thu, 21 Jul 2005 12:10:30 -0700 (PDT) Message-ID: <6533c1c9050721121030016b7d@mail.gmail.com> Date: Thu, 21 Jul 2005 15:10:30 -0400 From: Igor Shmukler To: fs@freebsd.org, hackers@freebsd.org, dillon@apollo.backplane.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailman-Approved-At: Fri, 22 Jul 2005 13:24:23 +0000 Cc: Subject: per file lock list X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Igor Shmukler List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 19:10:45 -0000 Hi, We have a question: how to get all POSIX locks for a given file? As far as I know, existing API does not allow to retrieve all file locks. Therefore, we need to use kernel internal structures to get all applied locks. Unfortunately, a head of list with file locks is attached to inode rather then vnode. As result, it is much harder to get the lock list head due to the need to know exact inode type that is hidden behind the vnode. Of course, the problem could be resolved in a hackish way: we may get the address of VOP_ADVLOCK() method and compare it with all known FS methods, that handles this VOP operation: (ufs_advlock, etc.) and therefore apply a proper type cast to vnode->v_data to get valid inode. However, this would be a last resort. So the question: is there an elegant way to get the lock list for a given f= ile? Thank you in advance. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 22 13:35:03 2005 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 5618A16A45A for ; Fri, 22 Jul 2005 13:35:03 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AC0143D88 for ; Fri, 22 Jul 2005 13:34:53 +0000 (GMT) (envelope-from samuel.pierson@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so347884wri for ; Fri, 22 Jul 2005 06:34:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KnS+u61kTdUsb4BpIgLNqScEjEegx44XRVmTMzeMbNw48uNx21DbHcGoi+DauUu30pItkm7UsZmaqv3c33xn8qm/43Eyl2uGICbDRW15y9bmQDVvnkVjdiCGupiepRdv6f2f3S9PIrdqwKVRQUcQJrVhfI0+VBXmv7iiRJKBWOs= Received: by 10.54.68.4 with SMTP id q4mr1184954wra; Fri, 22 Jul 2005 06:34:52 -0700 (PDT) Received: by 10.54.144.1 with HTTP; Fri, 22 Jul 2005 06:34:52 -0700 (PDT) Message-ID: Date: Fri, 22 Jul 2005 08:34:52 -0500 From: Sam Pierson To: Sam Leffler In-Reply-To: <42E03E5B.80905@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200507211849.aa11934@salmon.maths.tcd.ie> <42E03E5B.80905@errno.com> Cc: David Malone , FreeBSD Hackers Subject: Re: Atheros, hardware access layer, collisions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sam Pierson List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 13:35:03 -0000 > You need to set cwmin on the tx q as David describes. Be sure to set > the parameters you set into the hardware; check the wme update code for > the correct logic. For the other thing just set the tx descriptor to do > 1 try. >=20 > Sam Thanks guys. I'm still playing with these files so I'll let you know how it goes, your answers have been very helpful. Is there a way to sniff control frames and/or detect collisions? This would help me out a lot and eliminate the guesswork that I've been doing. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 22 18:09:47 2005 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 1FA5916A438; Fri, 22 Jul 2005 18:09:41 +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 10F9E44E90; Fri, 22 Jul 2005 18:05:35 +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.3/8.13.3) with ESMTP id j6MIFTGv047129; Fri, 22 Jul 2005 12:15:29 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42E13578.2090202@samsco.org> Date: Fri, 22 Jul 2005 12:05:44 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED,DOMAIN_4U2 autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Content-Type: text/plain; name="report.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="report.txt" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: FreeBSD Status Report Second Quarter 2005 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: Fri, 22 Jul 2005 18:09:47 -0000 March-June 2005 Status Report Introduction The second quarter of 2005 has again been very exciting. The BSDCan and MeetBSD conferences were both very interesting and and the sources of very good times. I highly recommend attending them again next year. The Google Summer of Code project has also generated quite a bit of excitement. FreeBSD has been granted 18 funded mentorship spots, the fourth most of all of participating organizations. Projects being worked on range from UFS Journalling to porting the new BSDInstaller to redesigning the venerable www.FreeBSD.org website. We are quite pleased to be working with so many talented students, and eagerly await the results of their work. More information and status can be found at the Wiki site at http://wikitest.freebsd.org/moin.cgi/SummerOfCode2005. The FreeBSD 6.0 release cycle is also starting up. The purpose of quickly jumping from 5.x to 6.0 is to reduce the amount of transition pain that most users and developers felt when switching from 4-STABLE to 5.x. 6.0 will feature improved performance and stability over 5.x, experimental PowerPC support, and many new WiFi/802.11 features. The 5.x series will continue for at least one more release this fall, and will then be supported by the security team for at least 2 years after that. We encourage everyone to give the 6.0-BETA snapshots a try and help us make it ready for production. We hope to release FreeBSD 6.0 by the end of August. Thanks again to everyone who submitted reports, and thanks to Max Laier for running the show and putting the reports together. Enjoy reading! _________________________________________________________________ Google summer of code * FreeBSD Summer of Code * FreeBSD website improvements * FreeSBIE toolkit integration * gjournal * gvinum 'move', 'rename' * Improve libalias * Integrate the BSD Installer into FreeBSD * launchd(8) for FreeBSD * Network Interface API Cleanup * Nsswitch / Caching daemon * SEBSD * UFSJ -- Journaling for UFS Projects * Fundraising - TCP & IP Routing Optimization * GEOM Gate rewrite * TODO list for volunteers * VFS SMP Documentation * The FreeBSD Dutch Documentation Project Kernel * Autotuning of the page queue coloring algorithm * CPU Cache Prefetching * libmemstat(3), UMA(9) and malloc(9) statistics * Low-overhead performance monitoring for FreeBSD * Removable interface improvements * SMP Network Stack * Transparent support for superpages in the FreeBSD Kernel * TrustedBSD Audit Network infrastructure * Dingo * if_bridge * IPv6 Support for IPFW * Move ARP out of routing table * TCP Reassembly Rewrite and Optimization * TTCPv2: Transactional TCP version 2 * Wireless Networking Support Userland programs * OpenBSD dhclient import. * Removing of old basesystem files and directories Architectures * PowerPC Port Ports * FreshPorts * Porting v9 of Intels C/C++ Compiler * Update of the Linux userland infrastructure Vendor / 3rd Party Software * OpenBSD packet filter - pf Miscellaneous * BSDCan * EuroBSDCon 2005 - Basel * FreeBSD Security Officer and Security Team * TrustedBSD SEBSD _________________________________________________________________ Autotuning of the page queue coloring algorithm URL: http://www.Leidinger.net/FreeBSD/current-patches/pq.diff Contact: Alexander Leidinger The VM subsystem has code to reduce the amount of cache collisions of VM pages. Currently this code needs to be tuned with a kernel option. I have a patch which changes this to auto-tuning at boot time. The auto-tuning is MI, the cache size detection is MD. Cache size detection is currently available for x86/amd64 (on other systems it uses default values). Open tasks: 1. Add cache-detection code for other arches too (Marius told me how to do this for sparc64). 2. Analyze why the cache detection on Athlons doesn't work (no problems on a P4, but it uses a different code-path). _________________________________________________________________ BSDCan URL: http://www.bsdcan.org/2005/ Contact: Dan Langille The second annual BSDCan conference was well presented, well attended, and everyone went away with good stories to tell. If you know anything that attended, get them to tell you what they did, who they met with, and talks they listened to. We had 197 people from 15 different countries. That's a strong turnout by any definition. We'll be adding more people to the program committee for BSDCan 2006. This job involves prodding and poking people from your respective projects. You get them to submit papers. There are a lot of very interesting projects out there and not all of them submit a paper. If you know someone doing interesting work, please let me know and urge them to start thinking about BSDCan 2006. _________________________________________________________________ CPU Cache Prefetching URL: http://people.freebsd.org/~andre/tcpoptimization.html URL: http://www.nrg4u.com/freebsd/tcp_reass+prefetch-20041216.patch Contact: Andre Oppermann Modern CPU's can only perform to their maximum if their working code is in fast L1-3 cache memory instead of the bulk main memory. All of today's CPU's support certain L1-3 cache prefetching instructions which cause data to be retrieved from main memory to the cache ahead of the time that it is already in place when it is eventually accessed by the CPU. CPU Cache Prefetching however is not a silver bullet and has to be used with extreme care and only in very specific places to be beneficial. Incorrect usage can lead to massive cache pollution and a drop in effective performance. Correct and very carefully usage on the other can lead to drastic performance increases in common operations. In the linked patch CPU cache prefetching has been used to prefetch the packet header (OSI layer 2 to 4) into the CPU caches right after entering into the network stack. This avoids a complete CPU stall on the first access to the packet header because packets get DMA'd into main memory and thus never are already pre-cache in the CPU caches. A second use in the patch is in the TCP input code to prefetch the entire struct tcpcb which is very large and used with a very high probability. Use in both of these places show a very significant performance gain but not yet fully quantified. The final patch will include documentation and a guide to evaluate and assess the use of CPU cache prefetch instructions in the kernel. Open tasks: 1. Need funding, see "Fundraising - TCP & IP Routing Optimization". _________________________________________________________________ Dingo URL: http://www.freebsd.org/projects/dingo/ Contact: Several <> Currently trying to restart bits of the project. Cleaning up the p4 branch. Recently more people have volunteered to help as well. Brooks Davis has completed removing the ifnet from the softc. Open tasks: 1. See the web page. _________________________________________________________________ EuroBSDCon 2005 - Basel URL: http://www.eurobsdcon.org/ URL: http://www.eurobsdcon.org/cfp.php Contact: Information The fourth European BSD conference in Basel, Switzerland is a great opportunity to present new ideas to the community and to meet some of the developers behind the different BSDs. The two day conference program (Nov 26 and 27) will be complemented by a tutorial day preceeding the conference (Nov 25). The program committee is looking for tutorial and paper submissions. For details, please see: The call for papers online. _________________________________________________________________ FreeBSD Security Officer and Security Team URL: http://www.freebsd.org/security/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/st= aff-listing.html#STAFF-SECTEAM URL: http://vuxml.freebsd.org/ Contact: Security Officer Contact: Security Team In May 2005, Remko Lodder joined the FreeBSD Security Team, followed by Christian S.J. Peron in July 2005. In the same time period, Gregory Shapiro and Josef El-Rayes resigned from the team in order to devote their time to other projects. The current Security Team membership is published on the web site. In the time since the last FreeBSD status report, twelve security advisories have been issued concerning problems in the base system of FreeBSD; of these, six problems were in "contributed" code, while five problems were in code maintained within FreeBSD. The Vulnerabilities and Exposures Markup Language (VuXML) document has continued to be updated by the Security Team and the Ports Committers documenting new vulnerabilities in the FreeBSD Ports Collection; since the last status report, 97 new entries have been added, bringing the total up to 519. The following FreeBSD releases are supported by the FreeBSD Security Team: FreeBSD 4.10, FreeBSD 4.11, FreeBSD 5.3, and FreeBSD 5.4. Their respective End of Life dates are listed on the web site. _________________________________________________________________ FreeBSD Summer of Code URL: http://wikitest.freebsd.org/moin.cgi/SummerOfCode2005 Contact: Summer of Code Mentors Google has generously funded 18 students to spend the summer working on FreeBSD related projects. Each student is working with one or more mentors to learn about how open source software development is done with FreeBSD. This development work is happening in the Perforce repository as //depot/projects/soc2005. This tree will soon be exported via CVSup -- check the Wiki for more information. _________________________________________________________________ FreeBSD website improvements Contact: Emily Boyd As part of the Google Summer of Code, I'm working on improvements to the FreeBSD website (including a proposed website redesign). My mentor for this project is Murray Stokely. _________________________________________________________________ FreeSBIE toolkit integration URL: http://www.freesbie.org URL: http://wikitest.freebsd.org/moin.cgi/DarioFreni Contact: Dario Freni My Summer of Code project is reengineering and rewrite of FreeSBIE toolkit, in order to include it in the source tree. Let's call it FreeSBIE 2 Before being accepted, I worked hard on the FreeSBIE 1 toolkit to make it more flexible. It now supports amd64 and powerpc architecture. The built filesystem can now boot from almost every media, from dvd to compact flash or hard disk. Also on i386 is possible to include the BSD Installer on the livefs. We've received reports that our toolkit is successfully used for install cd of pfSense and PC-BSD projects. My future goals are to make the toolkit even more flexible, capable to build embedded images (like nanoBSD) or big Live-DVD systems, depending on user's choice, to support all the architectures supported by FreeBSD and to write a set of tools for making a netboot server with a FreeSBIE image. _________________________________________________________________ FreshPorts URL: http://www.freshports.org/ Contact: Dan Langille The following new features have been added to FreshPorts: * Deprecated Ports * Expired Ports * Ports Set To Expire * Display relevent entries from ports/UPDATING on your watch list Open tasks: 1. I've noticed that FreshPorts is incorrectly reporting vulnerabilities under a ver y specific situation . The fix is sitting in BETA, waiting to be moved to production. 2. I've been working on added Last-Modified to the headers. At present, there are none. Most of the pages on the BETA website have been completed. I need to move this to production soon. 3. Customized news feeds are in the works. You'll be able to create a news feed for each of your watch lists This work is contingent upon finishing the Last-Modified headers. _________________________________________________________________ Fundraising - TCP & IP Routing Optimization URL: http://people.freebsd.org/~andre/tcpoptimization.html Contact: Andre Oppermann The TCP code in FreeBSD has evolved significantly since the fork from 4.4BSD-Lite2 in 1994 primarily due to new features and refinements of the TCP specifications. The TCP code now needs a general overhaul, streamlining and cleanup to make it easily comprehensible, maintainable and extensible again. In addition there are many little optimizations that can be done during such an operation, propelling FreeBSD back at the top of the best performing TCP/IP stacks again, a position it has held for the longest time in the 90's. This overhaul is a very involved and delicate matter and needs extensive formal and actual testing to ensure no regressions compared to the current code. The effort needed for this work is about three man-month of fully focused and dedicated time. To get it done I need funding to take time off my day job and to dedicate me to FreeBSD work much the way PHK did with his buffer cache and vnode rework projects. I've got the opportunity to work up to three man-month exclusively full-time on FreeBSD during the second half of 2005. That means up to 720 hours of full-steam coding (at 60 hours/week)! I will work as much time as the fundraise provides. I need to raise enough money for each month from donations from the FreeBSD community to cover my fixed cost of living, office and associated overhead. These fixed cost amount to US$6,300/month (EUR5,200 or CHF8,000). Yes, Switzerland is not the cheapest place to live. :) A detailed description of the tasks involved and the code I will write is on my FreeBSD website; Follow the link above. Open tasks: 1. Raise enough money to get all the almost finished TCP and IP code into the tree. _________________________________________________________________ GEOM Gate rewrite URL: http://cvsweb.freebsd.org/src/sys/geom/gate/ URL: http://cvsweb.freebsd.org/src/sbin/ggate/ Contact: Pawel Jakub Dawidek GGATE is a machinism for exporting storage devices over the network. It was reimplemented to be much faster and to handle network failures better. The ggatec uses two threads now: sendtd, which takes I/O request from the kernel and sends it to ggated; recvtd, which receives finished requests and forwards them to the kernel. The ggated uses three threads: recvtd, which receives I/O requests from ggatec; disktd, which executes I/O requests (reads or writes data); sendtd, which sends finished requests to ggatec. The new ggate has been committed to 6.x. The work was sponsored by Wheel Sp. z o.o. _________________________________________________________________ gjournal URL: http://wikitest.freebsd.org/moin.cgi/gjournal Contact: Ivan Voras The schedule (as stated on the wiki page) is honoured, which means that the development has started, but there's not enough code for testing. Many details have been thought-out and the development is ongoing. _________________________________________________________________ gvinum 'move', 'rename' URL: http://wikitest.freebsd.org/moin.cgi/GvinumMoveRename Contact: Chris Jones With the releases of FreeBSD 5.3 and 5.4, FreeBSD has been moving away from "old-style" vinum towards GEOM-enabled gvinum for logical volume management. While gvinum is a mostly feature-complete replacement for vinum, it does not implement the 'move' or 'rename' verbs which are rather useful when reorganizing one's volume layout, the alternative being a tedious process of deleting and recreating subdisks, plexes, or volumes. Additionally, gvinum is nearly completely undocumented, which contributes to the perception of gvinum as an unfinished project. I'm working on implementing 'move' (being able to move a subdisk from one drive to another) and 'rename' (being able to rename an subdisk, plex, volume, or drive), as well as on documentation for gvinum. So far, I've come up with a plan of attack with le@ and phk@, and implemented the bulk of the userland code for gvinum 'move' and 'rename'. Still to come are the kernel-side code and documentation. Open tasks: 1. 'move' and 'rename' userland implementation 2. 'move' and 'rename' kernel-side implementation 3. Outline new handbook section and man page 4. Implement new handbook section and man page _________________________________________________________________ if_bridge Contact: Andrew Thompson This was committed to current on 5 Jun 2005 and will first appear in the 6.0 release, thanks to everyone who tested. Recent improvements include: * IPFW layer2 filtering * DUMMYNET support * IP header alignment checking There is ongoing work to bring in some of the advanced features from OpenBSD such as IPSec bridging. People are encouraged to use if_bridge and report any problems to the mailing lists. _________________________________________________________________ Improve libalias URL: http://wikitest.freebsd.org/moin.cgi/PaoloPisati Contact: Paolo Pisati My SoC project is about improving libalias and integrating it with ipfw2, adding nat support into the firewall. Till now i ported libalias (as a kld) and ng_nat to 4.x and 5.x branches, and i've already a first working patchset that adds 'nat' action into ipfw. Next step will be to add a complete syntax to ipfw that will let us manipulate libalias operations, much like we already do with queue and pipes for dummynet. In the end the entire work will compile and work out of the box for 4.x, 5.x and 6.x. More details about the project and its status are available on wiki page. _________________________________________________________________ Integrate the BSD Installer into FreeBSD URL: http://www.bsdinstaller.org URL: http://wikitest.freebsd.org/moin.cgi/BSDInstaller URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects /soc2005/bsdinstaller Contact: Andrew Turner Progress towards integrating the BSD Installer for Google's Summer of Code is coming along nicely. The installation CD will boot to multi-user mode and run both the front and back ends. It can then partition a hard drive, install the base distribution and make the disk bootable. Open tasks: 1. Test in non-i386 2. Investigate installing from other media 3. Many more tasks _________________________________________________________________ IPv6 Support for IPFW Contact: Max Laier Contact: Brooks Davis At the developer summit before BSDCan it was decided to remove IP6FW from the tree as it has a couple of problems. The most pressing one is the lack of synchronization and thus the need for debug.mpsafenet=0. As a replacement Brooks Davis has imported patches to teach the existing and well-locked IPFW2 code about IPv6. Since the initial import I have added some features required to manage IPv4 and IPv6 in a single ruleset. I have also extended existing opcodes to work with IPv6. There are, however, still some opcodes that do not work with IPv6 and most of the more exotic ones haven't been tested. As long as IPFW2+v6 does not provide enough functionality and stability to work as a drop-in replacement for IP6FW, we won't remove IP6FW. In order to get the new code to that point we really need more testers with real world IPv6 deployment and interest in IPFW+v6. The lack thereof (I haven't received a single answer on my requests to various FreeBSD mailing lists) has made it hard to progress. Open tasks: 1. Properly implement O_REJECT for IPv6 2. Maybe implement O_LOG 3. Test new(er) IPFW2 opcodes with IPv6 4. Test 5. Test 6. Test _________________________________________________________________ launchd(8) for FreeBSD URL: http://wikitest.freebsd.org/moin.cgi/launchd URL: http://developer.apple.com/documentation/Darwin/Reference/ManPages/man 8/launchd.8.html Contact: R. Tyler Ballance So far progress has been slow, the autoconf build system has been removed from all of the launchd(8) code, and launchctl(1) is building and semi-functional on FreeBSD-CURRENT (i.e. CoreFoundation hooks have been removed) I'm currently working on porting "liblaunch" which is the core backend to both launchd(8) (the actual daemon) and launchctl(1), there are some mach/xnu specific hooks and calls that need to be remove and either reimplemented or worked around. We're also waiting on a response from Apple on a possible BSD-licensed version of the code (it's currently under the APSL) Progress is slow, but steady. _________________________________________________________________ libmemstat(3), UMA(9) and malloc(9) statistics URL: http://www.watson.org/~robert/freebsd/libmemstat/ Contact: Robert Watson libmemstat(3) provides a user space library API to monitor kernel memory allocators, currently uma(9) and malloc(9), with the following benefits: * ABI-robust interface making use of accessor functions, in order to divorce monitoring applications from kernel/user ABI changes. * Allocator-independent interfaces, allowing monitoring of multiple allocators using the same interface. * CPU-cache awareness, allowing tracking of memory use across multiple CPUs for allocators aware of caches. Unlike previous interfaces, libmemstat(3) coalesces per-CPU stats in user space rather than kernel, and exposes per-CPU stats to interested applications. * Ability to track memory types over multiple queries, and update existing structures, allowing easy tracking of statistics over time. libmemstat(3) and the the appropriate allocator changes for uma(9) and malloc(9) are currently in HEAD (7-CURRENT), and MFC has been approved to RELENG_6 for inclusion in 6.0-RELEASE. These changes may also be backported to 5.x. Sample applications include memstat(8), an allocator-independent statistics viewing tool, memtop(8), which provides a top(1)-like interface for monitoring kernel memory use and active memory types. None of these are "pretty". netstat -mb has also been updated to use libmemstat(3) to track network memory use using uma(9), rather than the less reliable mbuf allocator statistics interface. As a result, the statistics are now more reliable on SMP systems (this corrects the bug in which mbuf statistics sometimes "leaked", even though memory didn't), and more informative (cache information is now displayed, as well as mbuf tag information). Open tasks: 1. Teach libmemstat(3) to speak libkvm(3) in order to allow tools linked -lmemstat to interogate kernel core dumps. 2. Teach libmemstat(3) to interface with user space malloc and track malloc allocations for user space applications. 3. Update vmstat(8) -m and -z implementations to use libmemstat(3) instead of the old monitoring interfaces. Code to do this exists in the sample libmemstat(3) applications. 4. Identify how to make streams or the library endian-aware so that streams dumped from a kernel of alternative endian could be processed using libmemstat(3) on another system. 5. Identify any remaining caching allocators in the kernel, such as the sfbuf allocator, and teach libmemstat(3) how to interface with them. _________________________________________________________________ Low-overhead performance monitoring for FreeBSD URL: http://people.freebsd.org/~jkoshy/projects/perf-measurement Contact: Joseph Koshy Modern CPUs have on-chip performance monitoring counters (PMCs) that may be used to count low-level hardware events like instruction retirals, branch mispredictions, and cache misses. PMC architectures and capabilities vary between CPU vendors and between CPU generations from the same vendor, making the creation of portable applications difficult. This project implements a cross-platform PMC management API for applications, and implements the infrastructure to "virtualize" and manage these PMCs. The creation of performance analysis tools that use this infrastructure is also part of the project's goals. Work since the last status report: * Sampling mode support for P4 and AMD64 PMCs has been implemented. * A pmclog(3) API for parsing hwpmc(4) log files has been added. * A number of bugs in libpmc(3), hwpmc(4) and pmcstat(8) have been fixed. Future work: * Creating user documentation showing a few real-world uses of the currently available tools. * Testing, improving the stability of the code, and characterizing its overheads. * Implementing P5 PMC support. _________________________________________________________________ Move ARP out of routing table URL: http://people.freebsd.org/~qingli/ Contact: Qing Li I've sent the patch to jinmei@isl.rdc.toshiba.co.jp @KAME for review. I'm still waiting for feedback from Andre. There hasn't been any major change since the last report. I've kept the code in sync with CURRENT. Gleb has created a separate P4 branch and has been helping out on the locking side. Gleb is also helping out on the testing front. Open tasks: 1. I'm waiting for review feedback from my mentor Andre on the overall design and code. I'm waiting for feedback from Andre on Gleb's suggested modification. _________________________________________________________________ Network Interface API Cleanup URL: http://wikitest.freebsd.org/moin.cgi/CleanupOfNetworkIterfaceApis Contact: Anders Persson The goal of this project is to review the network interface API and try to remove references to kernel-only data structures by removing the use of libkvm and instead rely on other interfaces to provide information. If there are no adequate interfaces, they would be created. Currently netstat is being reviewed and parts of it have been modified to use sysctl rather than libkvm to provide the information. A big thank you to Brooks Davis for mentoring :-) _________________________________________________________________ Nsswitch / Caching daemon URL: http://wikitest.freebsd.org/moin.cgi/NsswitchAndCachingTechnicalDetail s URL: http://wikitest.freebsd.org/moin.cgi/MichaelBushkov Contact: Michael Bushkov The nsswitch / caching daemon project is being developed within the Google's Summer Of Code program. The first goal of this project is to implement a set of patches to extend the use of nsswitch subsystem. The second goal is the development of the caching library and daemon to add the caching ability to the nsswitch. Currently services, protocols, rpc and openssh patches are finished. Support for services, services_compat, rpc, protocols, and ssh_host_keys databases is added with 'files', 'nis' and 'compat' (for services) sources possible. The nsswitch-friendly openssh port is amlost completed. Open tasks: 1. Implement set of patches to make nsswitch support globus grid security files , MAC and audit related configuration files databases. 2. Implement the caching library and the caching daemon and patch nsdispatch function to support caching. _________________________________________________________________ OpenBSD dhclient import. Contact: Brooks Davis Contact: Sam Leffler The OpenBSD rewrite of dhclient has been imported, replacing the ISC dhclient. The OpenBSD client provides better support for roaming on wireless networks and a simpler model of operation. Instead of a single dhclient process per system, there is on per network interface. This instance automatically goes away in the even of link loss and is restarted via devd when link is reacquired. To support this change, many aspects of the network interface configuration process were overhauled. The current code works well in most circumstances, but more testing and polishing is needed. _________________________________________________________________ OpenBSD packet filter - pf Contact: Max Laier We will have pf as of OpenBSD 3.7 for RELENG_6. Import has been completed in early May and FreeBSD release 6.0 will ship with it. A few serious issues with pfsync on SMP have been discovered since CARP is around and more and more people use it on big iron. Everything that has been discovered is fixed in HEAD and (if applicable) MFCed back to RELENG_5. Some functional changes are undergoing testing right now and will be MFCed in the coming days. With the import of if_bridge from Net/OpenBSD we finally have a bridge implementation that allows for stateful filtering as well as IPv6 filtering. Please see the respective report. Open tasks: 1. Shared lock implementation? _________________________________________________________________ Porting v9 of Intels C/C++ Compiler Contact: Alexander Leidinger Intel released version 9 of its C/C++ compiler. Work to port the x86 version to FreeBSD is in progress as time permits. Porting the EM64T (amd64) version is on the TODO list too, but is subject to enough free time and access to appropriate hardware. _________________________________________________________________ PowerPC Port URL: http://www.freebsd.org/platforms/ppc.html Contact: Peter Grehan Florent Thoumie has updated the massively out-of-date platform page. Work continues to creating a 6.0 release of the PowerPC port. _________________________________________________________________ Removable interface improvements URL: http://people.freebsd.org/~brooks/pubs/eurobsdcon2004/ URL: http://www.freebsd.org/projects/dingo/ Contact: Brooks Davis This project is an attempt to clean up handling of network interfaces in order to allow interfaces to be removed reliably. Current problems include panics if Dummynet is delaying packets to an interface when it is removed. I have removed struct ifnet's and layer two common structures from device driver structures. This will eventually allow them to be managed properly upon device removal. This code has been committed and will appear in 6.0. Popular drivers have generally been fixed, but more testing is needed. _________________________________________________________________ Removing of old basesystem files and directories URL: http://www.Leidinger.net/FreeBSD/current-patches/obsolete_removal.diff Contact: Alexander Leidinger FreeBSD lacks a way to remove old/outdated files and directories in the basesystem. I have a patch which removes obsolete files in a safe way (interactively, since only the administrator really knows if there's a need to keed an old file or not; there's a switch for batch-processing). This feature may or may not be available for 6.0-RELEASE, depending on the decission from the Release Engineering team. Open tasks: 1. Respect the NO_* switches and remove those files too. This is easy to do with the current implementation, but isn't needed to commit the removal of obsolete files feature. _________________________________________________________________ SEBSD URL: http://wikitest.freebsd.org/moin.cgi/YanjunWu Contact: Yanjun Wu 1. Setup a local P4 workspace of sebsd source and Setup lxr for TrustedBSD source for studying source code. 2. Test a simple policy configuration for vsftpd. 3. Writing a HOWTO document Getting Started with SEBSD HOWTO by deriving the existing Getting Started with SELinux HOWTO . Thanks Robert Watson and Scott Long for their kind help. Open tasks: 1. When writing the document, try to figure out the sebsd userland utils that need to be ported. 2. Test and edit more policies for BSD environment. _________________________________________________________________ SMP Network Stack URL: http://www.FreeBSD.org/projects/netperf/ Contact: Robert Watson Significant work has occurred over the last few months relating to the SMP network stack work. A few of the highlights are covered here at a high level: * The UMA(9) per-CPU caches have been modified to use critical sections instead of mutexes. Recent critical section optimizations make this a performance win for both UP and SMP systems. This results in a several percent improvement in a number of user space benchmarks, and larger improvement for kernel-only network forwarding and processing benchmarks. * The malloc(9) allocator has been modified to store statistics per-CPU instead of using a cross-CPU statistics pool, with each per-CPU pool now using critical sections to synchronize access. This results in a measurable performance win, especially on SMP systems * The netnatm ATM code is now MPSAFE. * netipx MPSAFEty has been merged to RELENG_5. * The netperf cluster has now been expanded to include two additional quad-CPU systems (one dual dual-core AMD system, one quad-CPU PIII system). * libmemsetat(3) (see separate report) now corrects SMP-related races in the measuring of mbuf allocator statistics, as well as substantially improving kernel memory monitoring capabilities and tools. * A range of locking bug fixes, and general network stack bug fixes. * Significant updates to the SMPng web page (still more to do!). * Identification of all non-MPSAFE network device drivers, with ultimatum issued, on freebsd-arch. Quite a bit of new driver locking work as a result (if_ed, if_de, ...). * Lots of other stuff. In most cases, these changes will appear in FreeBSD 6.0-RELEASE; some have been, or will be, merged to FreeBSD 5.x. On-going tasks include: * Review and improvement of ifnet locking, such as address lists and flags. * Optimization of interface start hand-off. * Prototyping of queue-oriented packet hand-off in the stack. * Performance measurement and analysis. * Prototype rewrite and simplification of socket locking. _________________________________________________________________ TCP Reassembly Rewrite and Optimization URL: http://people.freebsd.org/~andre/tcpoptimization.html URL: http://www.nrg4u.com/freebsd/tcp_reass-20041213.patch URL: http://lists.freebsd.org/pipermail/freebsd-net/2004-December/005918.ht ml Contact: Andre Oppermann Currently TCP segment reassembly is implemented as a linked list of segments. With today's high bandwidth links and large bandwidth*delay products this doesn't scale and perform well. The rewrite optimizes a large number of operational aspects of the segments reassembly process. For example it is very likely that the just arrived segment attaches to the end of the reassembly queue, so we check that first. Second we check if it is the missing segment or alternatively attaches to the start of the reassembly queue. Third consecutive segments are merged together (logically) and are skipped over in one jump for linear searches instead of each segment at a time. Further optimizations prototyped merge consecutive segments on the mbuf level instead of only logically. This is expected to give another significant performance gain. The new reassembly queue is tracking all holes in the queue and it may be beneficial to integrate this with the scratch pad of SACK in the future. Andrew Gallatin was able to get 3.7Gb/sec TCP performance on dual-2Gbit Myrinet cards with severe packet reordering (due to a firmware bug) with the new TCP reassembly code. See second link. Open tasks: 1. Need funding, see "Fundraising - TCP & IP Routing Optimization". _________________________________________________________________ The FreeBSD Dutch Documentation Project URL: http://www.freebsd.org/doc/nl/books/handbook URL: http://www.evilcoder.org/content/section/6/39/ URL: http://www.evilcoder.org/freebsd_html/ URL: http://www.evilcoder.org/freebsd/flyer.pdf Contact: Remko Lodder Contact: Siebrand Mazeland Contact: Rene Ladan The FreeBSD Dutch Documentation Project is a ongoing project in translating the english documentation to the Dutch language. Currently we are almost done with the FreeBSD Handbook. Finishing the Handbook is our first priority, and we could use your help. Please contact Siebrand or myself if you want to helpout. After the handbook we will focus on other documents as well, so feel free to help us there as well Open tasks: 1. FreeBSD Handbook translation. Finish the translation from English to Dutch 2. FreeBSD Handbook review. Finish the review of the translated documents 3. FreeBSD Articles. Start translating the articles from English to the Dutch Language 4. FreeBSD www. Start translating the website from English to the Dutch Language 5. The rest of the FreeBSD Documents. Start translating them from English to the Dutch Language. _________________________________________________________________ TODO list for volunteers Contact: Alexander Leidinger Since Google's "Summer of Code" resulted in a lot of interest in open projects, I'm in the process of compiling a list of nice projects for volunteers. Unlike Google's SoC those projects aren't backed with money (but this doesn't means nobody is allowed to sponsor one of those projects), so we can only guarantee the social aspects (some "Thank you!" and "That's great!" messages). So far the list has several entries where the difficulty ranges from "someone just has to sit down and spend some time on it" up to "we need a guru for this". Open tasks: 1. Merging untaken entries from the SoC list as soon as the official participants/tasks in the SoC are announced. 2. Sending the document to some doc people for review. 3. Commit the list. _________________________________________________________________ Transparent support for superpages in the FreeBSD Kernel Contact: Alan L. Cox Contact: Olivier Crameri We are currently working on an updated implementation of Juan Navarro's transparent support for superpages in FreeBSD The idea is to take advantage of the architectural support for big memory pages (superpages) by using a reservation mechanism allowing us to transparently promote groups of base pages into superpages and demote superpages into several smaller superpages or base pages. The advantage of using superpages vs. base pages is to significantly improve the TLB coverage of the physical memory, thus improving the peformance by reducing the number of TLB misses. The modification of the FreeBSD kernel that we are working on involves the replacement of the current list based page allocation mechanism with a system using a buddy allocator to reserve groups of pages for a memory object. The promotion and demotion of the pages occur directly within the pmap module. The former implementation was supporting the alpha and IA64 architectures. We are adding the support for amd64. We currently have an almost complete implementation. Once completed we will make a performance study with a particular emphasis on TLB and cache misses. _________________________________________________________________ TrustedBSD Audit URL: http://www.trustedbsd.org/components.html#audit Contact: Robert Watson Contact: Wayne Salamon Contact: In the past few months, significant work has been done relating to the TrustedBSD audit implementation, including preparatory work to merge audit into the FreeBSD CVS repository for FreeBSD 6.x. In particular: * The user space components, such as libbsm, include files, and command line utilities have been broken out into an OpenBSM distribution in Perforce. Improvements in OpenBSM will be made available separately for use by projects such as Darwin, and imported into the contrib area of FreeBSD. * The system call table format has been updated to include an audit event identifier for each system call across all hardware platforms and ABIs (merged), and all system calls have been assigned event identifiers (not yet merged). * The audit management daemon has been rewritten to run on FreeBSD (originally derived from Darwin) using /dev/audit to track kernel events. * Many system calls now properly audit their arguments. * The TrustedBSD audit3 branch has been updated to a recent 6.x-CURRENT. * Significant work has gone into synchronizing the audit event tables between FreeBSD, Darwin, and OpenSolaris to make sure file formats and events are portable. * OpenBSM has been adapted to consume and generate endian-independent event streams. * OpenBSM documentation has been created. The hope is still to provide audit as "experimental" in 6.0; the primary blocking factor is our awaiting relicensing of the last remaining audit files from Apple's APSL license to BSDL so that they can be included in the FreeBSD kernel. This is anticipated to complete in the near future. Once this is done, the changes can be merged to CVS, and then MFC'd to RELENG_6. If this is not complete by 6.0-RELEASE, the work will be merged shortly after the release, as all ABI-sensitive data structures have been updated as needed. _________________________________________________________________ TrustedBSD SEBSD URL: http://www.TrustedBSD.org/sebsd.html Contact: Robert Watson The TrustedBSD Project has released a new snapshot of "SEBSD", a port of NSA's SELinux FLASK and Type Enforcement implementation to FreeBSD based on a late 2005 FreeBSD 6.x snapshot. The SEBSD distribution has now been updated in Perforce to a recent 6.x snapshot, and a new distribution will be made available in the near future. Work has been performed to merge additional dependencies for SEBSD back into the base FreeBSD tree, including most recently, changes to devfs, and System V and POSIX IPC. Open tasks: 1. Update to new NSA FLASK implementation, which has improved MLS support. 2. Merge remaining kernel changes to support SEBSD back to the base FreeBSD CVS repository, including file descriptor labeling and access control (in contrast to file labeling and access control), and categorization of kernel privileges. _________________________________________________________________ TTCPv2: Transactional TCP version 2 URL: http://people.freebsd.org/~andre/tcpoptimization.html URL: http://lists.freebsd.org/pipermail/cvs-all/2004-November/089939.html Contact: Andre Oppermann The old TTCP according to RFC1644 was insecure, intrusive, complicated and has been removed from FreeBSD >= 5.3. Although the idea and semantics behind it are still sound and valid. The rewrite uses a much easier and more secure system with 24bit long client and server cookies which are transported in the TCP options. Client cookies protect against various kinds of blind injection attacks and can be used as well to generally secure TCP sessions (for BGP for example). Server cookies are only exchanged during the SYN-SYN/ACK phase and allow a server to ensure that it has communicated with this particular client before. The first connection is always performing a 3WHS and assigning a server cookie to a client. Subsequent connections can send the cookie back to the server and short-cut the 3WHS to SYN->OPEN on the server. TTCPv2 is fully configurable per-socket via the setsockopt() system call. Clients and server not capable of TTCPv2 remain fully compatible and just continue using the normal 3WHS without any delay or other complications. Work on implementing TTCPv2 is done to 90% and expected to be available by early February 2005. Writing the implementation specification (RFC Draft) has just started. Open tasks: 1. Need funding, see "Fundraising - TCP & IP Routing Optimization". _________________________________________________________________ UFSJ -- Journaling for UFS Contact: Brian Wilson Contact: Scott Long filesystem. Journaling helps ensure the filesystem's integrity should the system crash. Journaling eliminates the need for fsck'ing a filesystem, as the filesystem is never in an inconsistent state (barring hardware failure). This implementation is inspired by Darwin's HFS+ filesystem and the SGI XFS filesystem. This is a Summer of Code project, with Scott Long as the mentor and Brian Wilson as the developer/mentee. Currently this project is still in the early stages, but will be in a usable state by September 1 (the Google Summer of Code completion date). Open tasks: 1. Finish making the file system log metadata updates. 2. Add facilities to replay the log on dirty file systems. 3. Make snapshots work with journaling. _________________________________________________________________ Update of the Linux userland infrastructure Contact: Alexander Leidinger Contact: Emulation Mailinglist The cleanup/streamlining and the possibility of overriding the default Linux base as reported in the last report happened without major problems. Work on the open tasks hasn't started yet, but is scheduled to start "soon". If a volunteer wants to spend some hours on one of the open tasks, he should tell it on the emulation mailinglist. Open tasks: 1. Refactoring the common RPM code in x11-toolkits/linux-gtk/Makefile into bsd.rpm.mk. 2. Determining which up-to-date Linux distribution to use as the next default Linux base. Important criteria: + RPM based (to be able to use the existing infrastructure) + good track record regarding availability of security fixes + packages available from several mirror sites + available for several hardware architectures (e.g. i386, amd64, sparc64; Note: not all architectures have a working linuxolator for their native bit with, but as long as there are no userland bits available, no motivation regarding writing the kernel bits will arise) 3. Moving the linuxolator userland to an up-to-date version (see above). _________________________________________________________________ VFS SMP Contact: Jeff Roberson FreeBSD's VFS layer has been fine grain locked along with the FFS filesystem for the FreeBSD 6.0 release. The locking has been underway for several years, with the project really picking up over the last 6 months thanks largely to sponsorship provided by Isilon Systems, Inc. a leading vendor of clustered storage systems. The project has entered a stabilization phase, with a few bugs being reported in extreme circumstances while the majority of users have seen no problems. Tests on a 8 and 16 way machines yield reasonable parallelization, however, it will be beneficial to do lock contention analysis once things are fully stable. For those interested in technical details, there have been a few relatively significant changes with vnode life-cycle management. Vnode reference counting and recycling is now no longer an ad-hoc process involving a variety of flags, a use count and the hold count. A single hold count is used to track all vnode references and a destroyed vnode is freed in the context of the caller when the last ref is lost. The old system would never reclaim memory used by vnodes and also had pathlogical behavior with unreferenced vnode caching under pressure. The new system is much simpler than the old one, however, callers are now required to vhold a vnode that they lock directly without going through vget to prevent it from being recycled while they are waiting on a lock. Relying on 'location stable storage', which is a more strict version of 'type stable storage' is no longer a valid approach. Some other side effects include a much simpler and faster nullfs implementation, an improved buf daemon flushing algorithm which eliminated high latency that caused audio skipping, and a lots of minor cleanups and debugging aids. _________________________________________________________________ Wireless Networking Support Contact: Sam Leffler A lot of bugs were fixed in preparation for the 6.0 release. 6.0 will be the first release to include full WPA support (both supplicant and authenticator). A presentation on the forthcoming multi-bss support was given at BSDCan 2005. The slides from the talk are available at http://www.freebsd.org/~sam/BSDCan2005.pdf . The plan is to commit this work to HEAD after 6.0 is released which means the first release that will have it is 7.0. Open tasks: 1. hostapd needs work to support the IAPP and 802.11i preauthentication protocols (these are simple conversions of existing Linux code). _________________________________________________________________ From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 22 18:11:11 2005 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 41A2516A46A; Fri, 22 Jul 2005 18:10:49 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA8C6440DF; Fri, 22 Jul 2005 16:54:46 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.9p2/8.12.9) with ESMTP id j6MGskYk076200; Fri, 22 Jul 2005 09:54:46 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j6MGskBD076199; Fri, 22 Jul 2005 09:54:46 -0700 (PDT) (envelope-from dillon) Date: Fri, 22 Jul 2005 09:54:46 -0700 (PDT) From: Matthew Dillon Message-Id: <200507221654.j6MGskBD076199@apollo.backplane.com> To: Robert Watson References: <200507212344.j6LNi9HU000683@ferens.net> <20050722004940.P16902@fledge.watson.org> Cc: freebsd-hackers@freebsd.org Subject: Enhanced KTR logging (was RE: Quality of FreeBSD) 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: Fri, 22 Jul 2005 18:11:11 -0000 :... :have an extensive instrumentation system named KTR(9). If you're :interested in giving it a try, you can find out more here: : : http://www.watson.org/~robert/freebsd/netperf/ktr/ : :This page is primarily targetted at tracing locks, memory allocation, and :context switching, but you can also trace I/O, bus operations, VFS :operations, and a range of other things. While my web page doesn't talk :about it, as it's generally focused on micro-tracing of kernel events, you :can also queue the event stream to disk using alq(9). The man pages have :more information. There are some neat tools, such as Jeff Roberson's :schedgraph, for managing and rendering trace results. :... :Robert N M Watson Speaking of KTR, I would recommend that you look at our implementation of it (modeled after the one in FreeBSD but somewhat more generic at the cost of being slightly more expensive). In particular, I added some trivial code which traces back two stack frames and provides the instruction pointer of the caller of the procedure that did the KTR log, and the caller of the caller of the procedure that did the KTR log. I then rewrote the ktrdump program to extract the kernel's namelist and provide actual symbolic names. The result was a *HUGE* improvement in the usefullness of KTR. Like night and day, in fact. The heart of the two-caller-traceback is the cpu_ktr_caller() function in /usr/src/sys/i386/i386/ktr.c. I recommend that you add the traceback facility to your own KTR implementation. http://www.dragonflybsd.org/cgi-bin/cvsweb.cgi/src/sys/i386/i386/ktr.c?rev=1.1&content-type=text/x-cvsweb-markup&only_with_tag=HEAD Here is an example of ktrdump -a output: index cpu timestamp caller2 caller1 ID file and line trace 0 0 78286413138797 pmap_remove_pages+455 zfree+33 tokens_get /usr/src/sys/kern/lwkt_token.c:426 REF=0xd71f2a54 TOK=0xc043e500 TD=0xcc2b7200 1 0 78286413139038 pmap_remove_pages+455 zfree+83 tokens_release /usr/src/sys/kern/lwkt_token.c:466 REF=0xd71f2a54 TOK=0xc043e500 TD=0xcc2b7200 2 0 78286413140030 pmap_remove_pages+455 zfree+33 tokens_get /usr/src/sys/kern/lwkt_token.c:426 REF=0xd71f2a54 TOK=0xc043e500 TD=0xcc2b7200 3 0 78286413140279 pmap_remove_pages+455 zfree+83 tokens_release /usr/src/sys/kern/lwkt_token.c:466 REF=0xd71f2a54 TOK=0xc043e500 TD=0xcc2b7200 -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 22 21:54:09 2005 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 6BA2416A41F for ; Fri, 22 Jul 2005 21:54:09 +0000 (GMT) (envelope-from edwin@verolan.com) Received: from ns11.webmasters.com (ns11.webmasters.com [66.118.156.2]) by mx1.FreeBSD.org (Postfix) with SMTP id BBE7843D5E for ; Fri, 22 Jul 2005 21:54:06 +0000 (GMT) (envelope-from edwin@verolan.com) Received: (qmail 2269 invoked from network); 22 Jul 2005 21:50:57 -0000 Received: from unknown (HELO localhost.localdomain) (204.9.60.14) by ns11.webmasters.com with SMTP; 22 Jul 2005 21:50:57 -0000 Received: from localhost.localdomain (asx01 [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j6MLr4Ii011178; Fri, 22 Jul 2005 17:53:04 -0400 Received: (from edwin@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id j6MLr3Vk011177; Fri, 22 Jul 2005 17:53:03 -0400 Date: Fri, 22 Jul 2005 17:53:03 -0400 From: Edwin To: Giorgos Keramidas Message-ID: <20050722215303.GA11141@asx01.verolan.com> References: <20050719034215.GB20752@asx01.verolan.com> <200507191120.37526.jhb@FreeBSD.org> <20050720020302.GA24474@asx01.verolan.com> <20050720100623.GA1470@beatrix.daedalusnetworks.priv> <20050720154156.GA26755@asx01.verolan.com> <20050721115719.GK16179@beatrix.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050721115719.GK16179@beatrix.daedalusnetworks.priv> User-Agent: Mutt/1.4.1i X-Operating-System: Linux/(i686) Cc: Edwin , freebsd-hackers@freebsd.org Subject: Re: help w/panic under heavy load - 5.4 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: Fri, 22 Jul 2005 21:54:09 -0000 Hi Giorgos, I'm sorry - I have so many kernels I was trying - I belive I overwrote that particular kernel/kernel.debug set - so I created a new kernel as a baseline with the same options per my notes - and included the output from the crash below. It does crash in the same fashion, and the KGDB output shows an MTU of the same type value (-1056788992 v. (-1056787456). I also patched ip_fastforward.c w/ your patch - still a crash - still same type bogus mtu value - a few lines from kgdb included @ end of message. Thanks again, -Edwin the variables you were asking about from this crash. (kgdb) f 13 #13 0xc06933c1 in ip_fastforward (m=0xc12e6c00) at /usr/src/sys/netinet/ip_fastfwd.c:572 572 if (ip_fragment(ip, &m, mtu, ifp->if_hwassist, (kgdb) p ro.ro_rt->rt_rmx $1 = {rmx_mtu = 1500, rmx_expire = 333905919, rmx_pksent = 3868} (kgdb) p ifp $2 = (struct ifnet *) 0xc0f91800 (kgdb) p *ifp $3 = {if_softc = 0xc0f91800, if_link = {tqe_next = 0xc0f90000, tqe_prev = 0xc08ebe84}, if_xname = "sis0", '\0' , if_dname = 0xc0f2ec2c "sis", if_dunit = 0, if_addrhead = {tqh_first = 0xc0ec0000, tqh_last = 0xc1040460}, if_klist = { kl_lock = 0xc08e5a40, kl_list = {slh_first = 0x0}}, if_pcount = 0, if_carp = 0x0, if_bpf = 0x0, if_index = 1, if_timer = 5, if_nvlans = 0, if_flags = 34883, if_capabilities = 72, if_capenable = 72, if_linkmib = 0x0, if_linkmiblen = 0, if_data = {ifi_type = 6 '\006', ifi_physical = 0 '\0', ifi_addrlen = 6 '\006', ifi_hdrlen = 18 '\022', ifi_link_state = 2 '\002', ifi_recvquota = 0 '\0', ifi_xmitquota = 0 '\0', ifi_datalen = 80 'P', ifi_mtu = 1500, ifi_metric = 0, ifi_baudrate = 10000000, ifi_ipackets = 50, ifi_ierrors = 0, ifi_opackets = 3914, ifi_oerrors = 0, ifi_collisions = 0, ifi_ibytes = 6146, ifi_obytes = 213356, ifi_imcasts = 40, ifi_omcasts = 29, ifi_iqdrops = 0, ifi_noproto = 0, ifi_hwassist = 0, ifi_epoch = 0, ifi_lastchange = {tv_sec = 0, tv_usec = 0}}, if_multiaddrs = {tqh_first = 0xc0fab3e0, tqh_last = 0xc0fabcc0}, if_amcount = 0, if_output = 0xc0671e04 , if_input = 0xc0672598 , if_start = 0xc0713c10 , if_ioctl = 0xc071497c , if_watchdog = 0xc0714b04 , if_init = 0xc0713f60 , if_resolvemulti = 0xc0672e48 , if_spare1 = 0x0, if_spare2 = 0x0, if_spare3 = 0x0, if_spare_flags1 = 0, if_spare_flags2 = 0, if_snd = {ifq_head = 0x0, ifq_tail = 0x0, ifq_len = 0, ifq_maxlen = 127, ifq_drops = 0, ifq_mtx = { mtx_object = {lo_class = 0xc0880b3c, lo_name = 0xc0f9180c "sis0", lo_type = 0xc0829304 "if send queue", lo_flags = 196608, lo_list = { tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0}, ifq_drv_head = 0x0, ifq_drv_tail = 0x0, ifq_drv_len = 0, ifq_drv_maxlen = 127, altq_type = 0, altq_flags = 1, altq_disc = 0x0, altq_ifp = 0xc0f91800, altq_enqueue = 0, altq_dequeue = 0, altq_request = 0, altq_clfier = 0x0, altq_classify = 0, altq_tbr = 0x0, altq_cdnr = 0x0}, if_broadcastaddr = 0xc07db600 "������", lltables = 0x0, if_label = 0x0, if_prefixhead = {tqh_first = 0x0, tqh_last = 0xc0f91968}, if_afdata = { 0x0 , 0xc0faaab0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, if_afdata_initialized = 1, if_afdata_mtx = {mtx_object = {lo_class = 0xc0880b3c, lo_name = 0xc08292f4 "if_afdata", lo_type = 0xc08292f4 "if_afdata", lo_flags = 196608, lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0}, if_starttask = {ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0xc06711c0 , ta_context = 0xc0f91800}} (kgdb) for reference going forward - this kernel was named D1-0722, and I'm making cross correlations to save the kernels/debugs/cores. new kernel crash - all options compiled, sysctl ipff=1, polling not enabled fb54c# panic: m_copym, offset > size of mbuf chain KDB: enter: panic [thread pid 21 tid 100015 ] Stopped at kdb_enter+0x2b: nop db> where Tracing pid 21 tid 100015 td 0xc0ecc780 kdb_enter(c0821a6a) at kdb_enter+0x2b panic(c0826049,0,c076b79c,c102ae00,100) at panic+0xbb m_copym(0,5dc,5c8,1,14) at m_copym+0x60 ip_fragment(c12f700e,c76bfc6c,5dc,0,1) at ip_fragment+0x214 ip_fastforward(c12e6c00) at ip_fastforward+0x6ed ether_demux(c0f90000,c12e6c00,3c,c0f8a8d8,a) at ether_demux+0x259 ether_input(c0f90000,c12e6c00,c0f902d0,0,c08336ab) at ether_input+0x25d sis_rxeof(c0f90000) at sis_rxeof+0x1ab sis_intr(c0f90000) at sis_intr+0xf3 ithread_loop(c0ec6880,c76bfd48,c0ec6880,c060030c,0) at ithread_loop+0x124 fork_exit(c060030c,c0ec6880,c76bfd48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc76bfd7c, ebp = 0 --- db> (kgdb) where #0 doadump () at pcpu.h:159 #1 0xc04611f6 in db_fncall (dummy1=0, dummy2=0, dummy3=43, dummy4=0xc76bf9f4 "(�k�") at /usr/src/sys/ddb/db_command.c:531 #2 0xc0461004 in db_command (last_cmdp=0xc08c9264, cmd_table=0x0, aux_cmd_tablep=0xc08483b8, aux_cmd_tablep_end=0xc08483d4) at /usr/src/sys/ddb/db_command.c:349 #3 0xc04610cc in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #4 0xc0462c51 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #5 0xc0627af2 in kdb_trap (type=3, code=0, tf=0xc76bfb30) at /usr/src/sys/kern/subr_kdb.c:468 #6 0xc07b6394 in trap (frame= {tf_fs = -949288936, tf_es = -1067319280, tf_ds = -1065222128, tf_edi = 1, tf_esi = - 1065197495, tf_ebp = -949224592, tf_isp = -949224612, tf_ebx = -949224548, tf_edx = 0, tf_e cx = -1060921344, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067288461, tf_cs = -1065222136, tf_eflags = 658, tf_esp = -949224560, tf_ss = -1067376657}) at /usr/src/sys/i386/i386/trap.c:584 #7 0xc07a69ca in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #8 0xc76b0018 in ?? () #9 0xc0620010 in schedcpu () at /usr/src/sys/kern/sched_4bsd.c:461 #10 0xc0611fef in panic (fmt=0xc0820008 "default") at /usr/src/sys/kern/kern_shutdown.c:550 #11 0xc0641a2c in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:385 #12 0xc069b694 in ip_fragment (ip=0xc12f700e, m_frag=0xc76bfc6c, mtu=-1056788992, if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 #13 0xc06933c1 in ip_fastforward (m=0xc12e6c00) at /usr/src/sys/netinet/ip_fastfwd.c:572 #14 0xc0672a59 in ether_demux (ifp=0xc0f90000, m=0xc12e6c00) at /usr/src/sys/net/if_ethersubr.c:770 #15 0xc06727f5 in ether_input (ifp=0xc0f90000, m=0xc12e6c00) at /usr/src/sys/net/if_ethersubr.c:631 #16 0xc0713507 in sis_rxeof (sc=0xc0f90000) at /usr/src/sys/pci/if_sis.c:1636 #17 0xc071398f in sis_intr (arg=0xc0f90000) at /usr/src/sys/pci/if_sis.c:1841 #18 0xc0600430 in ithread_loop (arg=0xc0ec6880) at /usr/src/sys/kern/kern_intr.c:547 #19 0xc05ff8a4 in fork_exit (callout=0xc060030c , arg=0xc0ec6880, frame=0xc76bfd48) at /usr/src/sys/kern/kern_fork.c:791 #20 0xc07a6a2c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209 (kgdb) [**** your patch applied ***] #12 0xc069b690 in ip_fragment (ip=0xc11d580e, m_frag=0xc76bfc6c, mtu=-1056791808, if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 #13 0xc06933bf in ip_fastforward (m=0xc11ae300) at /usr/src/sys/netinet/ip_fastfwd.c:586 #14 0xc0672a59 in ether_demux (ifp=0xc0f90000, m=0xc11ae300) at /usr/src/sys/net/if_ethersubr.c:770 #15 0xc06727f5 in ether_input (ifp=0xc0f90000, m=0xc11ae300) at /usr/src/sys/net/if_ethersubr.c:631 Giorgos Keramidas (keramida@freebsd.org) wrote: > On 2005-07-20 11:41, Edwin wrote: > > I'm trying to understand the particulars about this - I get the null pointer > > part, but as to ip_fragment - it's fragmenting mbufs to handle ip packets > > during switching? and its failing trying to copy data past the end of the > > chain? > > ip_fastfwd() thinks that it should fragment the packet because it somehow > calculates a bogus ``mtu'' value. See the mtu value in frame 12 of the stack > trace below. > > > mbsd05# kgdb kernel.debug /tmp/crash/vmcore.3 > > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are [... deleted ...] > > #11 0xc0641a2c in m_copym (m=0x0, off0=1500, len=1480, wait=1) > > at /usr/src/sys/kern/uipc_mbuf.c:385 > > #12 0xc069b694 in ip_fragment (ip=0xc11bd80e, m_frag=0xc76bfc6c, mtu=-1056787456, > > if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 > > The ``mtu'' is an extremely small integer value, which is definitely a problem > here. Somehow, ip_fastforward() calculates a very wrong value for the ``mtu''. > > > 6933c1 in ip_fastforward (m=0xc11ab100) at /usr/src/sys/netinet/ip_fastfwd.c:572 > > If you have this particular crash dump, can you show me a dump of the > ``ro.ro_rt->rt_rmx'' and the ``ifp'' structure that ip_fastforward() is using? > > One of these two seems to have an invalid mtu value. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 23 00:21:19 2005 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 077E116A41F for ; Sat, 23 Jul 2005 00:21:19 +0000 (GMT) (envelope-from iwan@staff.usd.ac.id) Received: from staff.usd.ac.id (staff.usd.ac.id [202.152.7.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3AB943D48 for ; Sat, 23 Jul 2005 00:21:17 +0000 (GMT) (envelope-from iwan@staff.usd.ac.id) Received: from webmail.usd.ac.id (webmail.usd.ac.id [202.152.7.139]) by staff.usd.ac.id (8.11.0/8.11.0) with ESMTP id j6N0R1510417 for ; Sat, 23 Jul 2005 07:27:01 +0700 Received: from 202.65.114.229 (proxying for 172.21.200.55) (SquirrelMail authenticated user iwan) by webmail.usd.ac.id with HTTP; Sat, 23 Jul 2005 07:30:57 -0000 (UTC) Message-ID: <63769.202.65.114.229.1122103857.squirrel@webmail.usd.ac.id> Date: Sat, 23 Jul 2005 07:30:57 -0000 (UTC) From: iwan@staff.usd.ac.id To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: howto: linuxthreads+mysql ? 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: Sat, 23 Jul 2005 00:21:19 -0000 Hi, I'm sorry because my English is not good. I have trouble in my box FreeBSD 5.1/5.3 (RELEASE) + mysql 4.0.21. Its often hanging if so much connection to mysql. My friend told me that there is no linuxthread in my box. Please help me to solve this problem. How to activate linuxthread in my box ? I tried installing linuxthread library, but it could not work. -- Iwan Binanto Divisi Support-BAPSI Universitas Sanata Dharma Yogyakarta From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 23 01:14:06 2005 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 A1CE416A41F for ; Sat, 23 Jul 2005 01:14:06 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3F8843D46 for ; Sat, 23 Jul 2005 01:14:05 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from gothmog.gr (patr530-b186.otenet.gr [212.205.244.194]) by rosebud.otenet.gr (8.13.4/8.13.4/Debian-1) with ESMTP id j6N1E1qq029821; Sat, 23 Jul 2005 04:14:02 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.4/8.13.4) with ESMTP id j6N1DuBO001076; Sat, 23 Jul 2005 04:13:56 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.4/8.13.4/Submit) id j6N1Duid001071; Sat, 23 Jul 2005 04:13:56 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sat, 23 Jul 2005 04:13:48 +0300 From: Giorgos Keramidas To: Edwin Message-ID: <20050723011348.GA973@gothmog.gr> References: <20050719034215.GB20752@asx01.verolan.com> <200507191120.37526.jhb@FreeBSD.org> <20050720020302.GA24474@asx01.verolan.com> <20050720100623.GA1470@beatrix.daedalusnetworks.priv> <20050720154156.GA26755@asx01.verolan.com> <20050721115719.GK16179@beatrix.daedalusnetworks.priv> <20050722215303.GA11141@asx01.verolan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050722215303.GA11141@asx01.verolan.com> Cc: freebsd-hackers@freebsd.org Subject: Re: help w/panic under heavy load - 5.4 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: Sat, 23 Jul 2005 01:14:06 -0000 On 2005-07-22 17:53, Edwin wrote: > > I also patched ip_fastforward.c w/ your patch - still a crash - still > same type bogus mtu value - a few lines from kgdb included @ end of > message. > (kgdb) f 13 > #13 0xc06933c1 in ip_fastforward (m=0xc12e6c00) at /usr/src/sys/netinet/ip_fastfwd.c:572 > 572 if (ip_fragment(ip, &m, mtu, ifp->if_hwassist, > (kgdb) p ro.ro_rt->rt_rmx > $1 = {rmx_mtu = 1500, rmx_expire = 333905919, rmx_pksent = 3868} The route entry has mtu = 1500. > (kgdb) p *ifp > $3 = {if_softc = 0xc0f91800, if_link = {tqe_next = 0xc0f90000, tqe_prev = 0xc08ebe84}, > if_xname = "sis0", '\0' , if_dname = 0xc0f2ec2c "sis", if_dunit = 0, > if_addrhead = {tqh_first = 0xc0ec0000, tqh_last = 0xc1040460}, if_klist = { > kl_lock = 0xc08e5a40, kl_list = {slh_first = 0x0}}, if_pcount = 0, if_carp = 0x0, > if_bpf = 0x0, if_index = 1, if_timer = 5, if_nvlans = 0, if_flags = 34883, > if_capabilities = 72, if_capenable = 72, if_linkmib = 0x0, if_linkmiblen = 0, > if_data = {ifi_type = 6 '\006', ifi_physical = 0 '\0', ifi_addrlen = 6 '\006', > ifi_hdrlen = 18 '\022', ifi_link_state = 2 '\002', ifi_recvquota = 0 '\0', > ifi_xmitquota = 0 '\0', ifi_datalen = 80 'P', ifi_mtu = 1500, ifi_metric = 0, The interface also has an mtu of 1500 (ifi_mtu in the last line above). > #10 0xc0611fef in panic (fmt=0xc0820008 "default") > at /usr/src/sys/kern/kern_shutdown.c:550 > #11 0xc0641a2c in m_copym (m=0x0, off0=1500, len=1480, wait=1) > at /usr/src/sys/kern/uipc_mbuf.c:385 > #12 0xc069b694 in ip_fragment (ip=0xc12f700e, m_frag=0xc76bfc6c, mtu=-1056788992, > if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 > #13 0xc06933c1 in ip_fastforward (m=0xc12e6c00) at /usr/src/sys/netinet/ip_fastfwd.c:572 This looks rather strange. ip_fastforward() should pass an mtu of 1500 but somehow the negative strange value gets passed. It would be interesting to see the value of ``mtu'' in frame 13 too, if you still have this crash dump stored somewhere. You are not running a kernel with optimization and/or architecture- dependent optimization flags, right? From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 23 03:13:04 2005 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 47F1616A425 for ; Sat, 23 Jul 2005 03:13:04 +0000 (GMT) (envelope-from jas_arlerr@yahoo.com.cn) Received: from web15006.mail.cnb.yahoo.com (web15006.mail.cnb.yahoo.com [202.165.103.63]) by mx1.FreeBSD.org (Postfix) with SMTP id 19CCC43D6B for ; Sat, 23 Jul 2005 03:12:30 +0000 (GMT) (envelope-from jas_arlerr@yahoo.com.cn) Received: (qmail 31408 invoked by uid 60001); 23 Jul 2005 03:12:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dLUhyJTViyE/SBwS2rQ1OmKz8mgBLlXwi5pVZoOOrJAiCgSSjhoFG8uhsoV9GgZ2QMndU9S6hrndXOu1GQBFnw+bbRlh0OI4P8hOH9mb4KCQ3+HIe/dyCZq99qkiwio1vlhAD3c9LN1jSRTlPoUQ67h/APjpwkgi2Ubn/y9o8BU= ; Message-ID: <20050723031226.31406.qmail@web15006.mail.cnb.yahoo.com> Received: from [61.187.54.9] by web15006.mail.cnb.yahoo.com via HTTP; Sat, 23 Jul 2005 11:12:26 CST Date: Sat, 23 Jul 2005 11:12:26 +0800 (CST) From: Jone Jas To: freebsd hackers MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: networking jail 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: Sat, 23 Jul 2005 03:13:04 -0000 Hi hackers As far as I know, the FreeBSD jail facility has not the ablitiy to cooperate on network (Am I wrong?). But the Solaris Zones (part of the N1 Grid Container) dose have. The N1 Grid Container treat N nodes on network as 1. It can manage resources across network. We have to admit that Solaris Zones is more powerful than jail. Does jail has such ToDo plan? If so, we have a long way to go :-) Regards ----- Jas --------------------------------- DO YOU YAHOO!? ÑÅ»¢Ãâ·ÑGÓÊÏ䣭ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 23 03:23:38 2005 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 C2F9C16A41F for ; Sat, 23 Jul 2005 03:23:38 +0000 (GMT) (envelope-from julian@elischer.org) Received: from postoffice.vicor-nb.com (postoffice.vicor.com [69.26.56.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 695E143D46 for ; Sat, 23 Jul 2005 03:23:38 +0000 (GMT) (envelope-from julian@elischer.org) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 195424CE8FB; Fri, 22 Jul 2005 20:23:38 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95506-10; Fri, 22 Jul 2005 20:23:37 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 87C3B4CE7F3; Fri, 22 Jul 2005 20:23:37 -0700 (PDT) Message-ID: <42E1B839.2030201@elischer.org> Date: Fri, 22 Jul 2005 20:23:37 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050629 X-Accept-Language: en, hu MIME-Version: 1.0 To: Jone Jas References: <20050723031226.31406.qmail@web15006.mail.cnb.yahoo.com> In-Reply-To: <20050723031226.31406.qmail@web15006.mail.cnb.yahoo.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com Cc: freebsd hackers Subject: Re: networking jail 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: Sat, 23 Jul 2005 03:23:38 -0000 Jone Jas wrote: >Hi hackers > As far as I know, the FreeBSD jail facility has not the ablitiy to >cooperate on network (Am I wrong?). But the Solaris Zones (part >of the N1 Grid Container) dose have. The N1 Grid Container treat >N nodes on network as 1. It can manage resources across network. > We have to admit that Solaris Zones is more powerful than jail. >Does jail has such ToDo plan? If so, we have a long way to go :-) > > marco zec has a set of patches for freebsd 4.x that implements something like this however it would be hard to port it to 5.x virtualisation is however something that continues to be studied. > >Regards >----- >Jas > > >--------------------------------- >DO YOU YAHOO!? > ÑÅ»¢Ãâ·ÑGÓÊÏ䣭ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä >_______________________________________________ >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 Sat Jul 23 13:53:24 2005 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 5213216A53F for ; Sat, 23 Jul 2005 13:53:24 +0000 (GMT) (envelope-from edwin@verolan.com) Received: from ns11.webmasters.com (ns11.webmasters.com [66.118.156.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 351E343D53 for ; Sat, 23 Jul 2005 13:53:23 +0000 (GMT) (envelope-from edwin@verolan.com) Received: (qmail 32718 invoked from network); 23 Jul 2005 13:50:15 -0000 Received: from unknown (HELO localhost.localdomain) (204.9.60.14) by ns11.webmasters.com with SMTP; 23 Jul 2005 13:50:15 -0000 Received: from localhost.localdomain (asx01 [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j6NDrL0h013662; Sat, 23 Jul 2005 09:53:21 -0400 Received: (from edwin@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id j6NDrLXs013661; Sat, 23 Jul 2005 09:53:21 -0400 Date: Sat, 23 Jul 2005 09:53:21 -0400 From: Edwin To: Giorgos Keramidas Message-ID: <20050723135321.GA13607@asx01.verolan.com> References: <20050719034215.GB20752@asx01.verolan.com> <200507191120.37526.jhb@FreeBSD.org> <20050720020302.GA24474@asx01.verolan.com> <20050720100623.GA1470@beatrix.daedalusnetworks.priv> <20050720154156.GA26755@asx01.verolan.com> <20050721115719.GK16179@beatrix.daedalusnetworks.priv> <20050722215303.GA11141@asx01.verolan.com> <20050723011348.GA973@gothmog.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050723011348.GA973@gothmog.gr> User-Agent: Mutt/1.4.1i X-Operating-System: Linux/(i686) Cc: Edwin , freebsd-hackers@freebsd.org Subject: Re: help w/panic under heavy load - 5.4 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: Sat, 23 Jul 2005 13:53:24 -0000 comments in-line. Giorgos Keramidas (keramida@freebsd.org) wrote: > > This looks rather strange. ip_fastforward() should pass an mtu of 1500 > but somehow the negative strange value gets passed. It would be > interesting to see the value of ``mtu'' in frame 13 too, if you still > have this crash dump stored somewhere. included right below - i have a few other questions while i'm looking @ these - the value of hlen (looks from the code that it should be ip->ip_hl << 2 (5*4=20 right?) not some large -value - plus the value of hlen is sortof close to crazy mtu value - ip->ip_len = 10240 ??? not sure why this would be either - i think mtu should have a value of 1500 here - both the ifp struct and ro struct have values of 1500, but even if it did have a value of 1500 - since ip->ip_len = 10240 - it's still going to drop through to else of line 542 (ie. ip->ip_len <= mtu) which leaves either can't frag/drop or frag (where we are i think) - unless I'm missing something (kgdb) f 13 #13 0xc06933c1 in ip_fastforward (m=0xc12e6c00) at /usr/src/sys/netinet/ip_fastfwd.c:572 warning: Source file is more recent than executable. 572 if (ip_fragment(ip, &m, mtu, ifp->if_hwassist, (kgdb) i loc ip = (struct ip *) 0xc12f700e m0 = (struct mbuf *) 0xc12f700e ro = {ro_rt = 0xc11f8420, ro_dst = {sa_len = 16 '\020', sa_family = 2 '\002', sa_data = "\000\000�\002\005\000\000\000\000\000\000\000"}} dst = (struct sockaddr_in *) 0xc76bfc3c ia = (struct in_ifaddr *) 0x0 ifa = (struct ifaddr *) 0x0 ifp = (struct ifnet *) 0xc0f91800 odest = {s_addr = 84060352} dest = {s_addr = 84060352} sum = 0 ip_len = 0 error = 84060352 hlen = -1057417216 mtu = 0 __func__ = "ip_fastforward" (kgdb) p *ip $1 = {ip_hl = 5, ip_v = 4, ip_tos = 0 '\0', ip_len = 10240, ip_id = 61249, ip_off = 0, ip_ttl = 63 '?', ip_p = 17 '\021', ip_sum = 31921, ip_src = {s_addr = 67479744}, ip_dst = {s_addr = 84060352}} (kgdb) > > You are not running a kernel with optimization and/or architecture- > dependent optimization flags, right? > ntiko - i have added CPU_GEODE/CPU_SOEKRIS to my config - but same crash on the generic config as well..this is a soekris net4801 box (w/ geode proc - i586). generic 'make buildkernel KERNCONF=D1-0722' command line (ie no other make/compiler options). mbsd05# diff /root/kernels/D1-0722 /root/kernels/GENERIC 21,22d20 < makeoptions DEBUG=-g < 24c22 < #cpu I486_CPU --- > cpu I486_CPU 26,27c24,25 < #cpu I686_CPU < ident D1-0722 --- > cpu I686_CPU > ident GENERIC 31,48d28 < < options KDB < options DDB < options INVARIANTS < options INVARIANT_SUPPORT < < options CPU_SOEKRIS < options CPU_GEODE < < options HZ=1000 < options DEVICE_POLLING < < options IPFIREWALL < options IPFIREWALL_VERBOSE < options IPFIREWALL_VERBOSE_LIMIT < options IPFIREWALL_DEFAULT_TO_ACCEPT < options DUMMYNET < options IPDIVERT mbsd05# From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 23 14:23:21 2005 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 31FA516A420; Sat, 23 Jul 2005 14:23:21 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74DD143D4C; Sat, 23 Jul 2005 14:23:20 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3D810.dip.t-dialin.net [84.163.216.16] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML21M-1DwKuM2o7M-0000Ns; Sat, 23 Jul 2005 16:23:18 +0200 From: Max Laier To: freebsd-hackers@freebsd.org Date: Sat, 23 Jul 2005 16:23:09 +0200 User-Agent: KMail/1.8 References: <20050719034215.GB20752@asx01.verolan.com> <20050723011348.GA973@gothmog.gr> <20050723135321.GA13607@asx01.verolan.com> In-Reply-To: <20050723135321.GA13607@asx01.verolan.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1693224.H6tQgjfbOi"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507231623.16183.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Edwin , Giorgos Keramidas Subject: Re: help w/panic under heavy load - 5.4 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: Sat, 23 Jul 2005 14:23:21 -0000 --nextPart1693224.H6tQgjfbOi Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 23 July 2005 15:53, Edwin wrote: Can we see one complete picture, please. This includes: A trace local vars in ip_fastforward including unfolded ip, m, ro.ro_rt and ifp. local vars in ip_fragment(). Thanks. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1693224.H6tQgjfbOi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC4lLUXyyEoT62BG0RAuakAJoCoi6rGIx6fp6xildyjcOmdOoTJACggULT pFHGz1SV09+cbJ53WA/tjs8= =5BDZ -----END PGP SIGNATURE----- --nextPart1693224.H6tQgjfbOi-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 23 18:41:13 2005 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 98AD416A41F for ; Sat, 23 Jul 2005 18:41:13 +0000 (GMT) (envelope-from edwin@verolan.com) Received: from ns11.webmasters.com (ns11.webmasters.com [66.118.156.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 96B8E43D48 for ; Sat, 23 Jul 2005 18:41:12 +0000 (GMT) (envelope-from edwin@verolan.com) Received: (qmail 9679 invoked from network); 23 Jul 2005 18:38:04 -0000 Received: from unknown (HELO localhost.localdomain) (204.9.60.14) by ns11.webmasters.com with SMTP; 23 Jul 2005 18:38:04 -0000 Received: from localhost.localdomain (asx01 [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j6NIf9su014151; Sat, 23 Jul 2005 14:41:09 -0400 Received: (from edwin@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id j6NIf8hi014150; Sat, 23 Jul 2005 14:41:08 -0400 Date: Sat, 23 Jul 2005 14:41:08 -0400 From: Edwin To: Max Laier Message-ID: <20050723184108.GA14076@asx01.verolan.com> References: <20050719034215.GB20752@asx01.verolan.com> <20050723011348.GA973@gothmog.gr> <20050723135321.GA13607@asx01.verolan.com> <200507231623.16183.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200507231623.16183.max@love2party.net> User-Agent: Mutt/1.4.1i X-Operating-System: Linux/(i686) Cc: Edwin , freebsd-hackers@freebsd.org, Giorgos Keramidas Subject: Re: help w/panic under heavy load - 5.4 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: Sat, 23 Jul 2005 18:41:13 -0000 Max Laier (max@love2party.net) wrote: > On Saturday 23 July 2005 15:53, Edwin wrote: > > Can we see one complete picture, please. This includes: > > A trace > local vars in ip_fastforward including unfolded ip, m, ro.ro_rt and ifp. > local vars in ip_fragment(). > > Thanks. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News Absolutely ;) - Thanks for taking the time! cheers. /edwin Kernel name: D1-0722 (for reference) mbsd05# kgdb kernel.debug /usr/local/STORAGE/crash/vmcore.5 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". #0 doadump () at pcpu.h:159 159 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) where #0 doadump () at pcpu.h:159 #1 0xc04611f6 in db_fncall (dummy1=0, dummy2=0, dummy3=43, dummy4=0xc76bf9f4 "(úkÇ") at /usr/src/sys/ddb/db_command.c:531 #2 0xc0461004 in db_command (last_cmdp=0xc08c9264, cmd_table=0x0, aux_cmd_tablep=0xc08483b8, aux_cmd_tablep_end=0xc08483d4) at /usr/src/sys/ddb/db_command.c:349 #3 0xc04610cc in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #4 0xc0462c51 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #5 0xc0627af2 in kdb_trap (type=3, code=0, tf=0xc76bfb30) at /usr/src/sys/kern/subr_kdb.c:468 #6 0xc07b6394 in trap (frame= {tf_fs = -949288936, tf_es = -1067319280, tf_ds = -1065222128, tf_edi = 1, tf_esi = -1065197495, tf_ebp = -949224592, tf_isp = -949224612, tf_ebx = -949224548, tf_edx = 0, tf_ecx = -1060921344, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067288461, tf_cs = -1065222136, tf_eflags = 658, tf_esp = -949224560, tf_ss = -1067376657}) at /usr/src/sys/i386/i386/trap.c:584 #7 0xc07a69ca in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #8 0xc76b0018 in ?? () #9 0xc0620010 in schedcpu () at /usr/src/sys/kern/sched_4bsd.c:461 #10 0xc0611fef in panic (fmt=0xc0820008 "default") at /usr/src/sys/kern/kern_shutdown.c:550 #11 0xc0641a2c in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:385 #12 0xc069b694 in ip_fragment (ip=0xc12f700e, m_frag=0xc76bfc6c, mtu=-1056788992, if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 #13 0xc06933c1 in ip_fastforward (m=0xc12e6c00) at /usr/src/sys/netinet/ip_fastfwd.c:572 #14 0xc0672a59 in ether_demux (ifp=0xc0f90000, m=0xc12e6c00) at /usr/src/sys/net/if_ethersubr.c:770 #15 0xc06727f5 in ether_input (ifp=0xc0f90000, m=0xc12e6c00) at /usr/src/sys/net/if_ethersubr.c:631 #16 0xc0713507 in sis_rxeof (sc=0xc0f90000) at /usr/src/sys/pci/if_sis.c:1636 #17 0xc071398f in sis_intr (arg=0xc0f90000) at /usr/src/sys/pci/if_sis.c:1841 #18 0xc0600430 in ithread_loop (arg=0xc0ec6880) at /usr/src/sys/kern/kern_intr.c:547 #19 0xc05ff8a4 in fork_exit (callout=0xc060030c , arg=0xc0ec6880, frame=0xc76bfd48) at /usr/src/sys/kern/kern_fork.c:791 #20 0xc07a6a2c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209 (kgdb) f 13 #13 0xc06933c1 in ip_fastforward (m=0xc12e6c00) at /usr/src/sys/netinet/ip_fastfwd.c:572 warning: Source file is more recent than executable. 572 if (ip_fragment(ip, &m, mtu, ifp->if_hwassist, (kgdb) l 567 m->m_pkthdr.csum_flags |= CSUM_IP; 568 /* 569 * ip_fragment expects ip_len and ip_off in host byte 570 * order but returns all packets in network byte order 571 */ 572 if (ip_fragment(ip, &m, mtu, ifp->if_hwassist, 573 (~ifp->if_hwassist & CSUM_DELAY_IP))) { 574 goto drop; 575 } 576 KASSERT(m != NULL, ("null mbuf and no error")); (kgdb) i loc ip = (struct ip *) 0xc12f700e m0 = (struct mbuf *) 0xc12f700e ro = {ro_rt = 0xc11f8420, ro_dst = {sa_len = 16 '\020', sa_family = 2 '\002', sa_data = "\000\000À¨\002\005\000\000\000\000\000\000\000"}} dst = (struct sockaddr_in *) 0xc76bfc3c ia = (struct in_ifaddr *) 0x0 ifa = (struct ifaddr *) 0x0 ifp = (struct ifnet *) 0xc0f91800 odest = {s_addr = 84060352} dest = {s_addr = 84060352} sum = 0 ip_len = 0 error = 84060352 hlen = -1057417216 mtu = 0 __func__ = "ip_fastforward" (kgdb) p *ip $1 = {ip_hl = 5, ip_v = 4, ip_tos = 0 '\0', ip_len = 10240, ip_id = 61249, ip_off = 0, ip_ttl = 63 '?', ip_p = 17 '\021', ip_sum = 31921, ip_src = {s_addr = 67479744}, ip_dst = {s_addr = 84060352}} (kgdb) p *m $2 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xc12f700e "E", mh_len = 40, mh_flags = 3, mh_type = 1}, M_dat = {MH = {MH_pkthdr = {rcvif = 0xc0f90000, len = 40, header = 0x0, csum_flags = 769, csum_data = 0, tags = {slh_first = 0x0}}, MH_dat = {MH_ext = {ext_buf = 0xc12f7000 "", ext_free = 0, ext_args = 0x0, ext_size = 2048, ref_cnt = 0x0, ext_type = 3}, MH_databuf = "\000p/Á\000\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\003", '\0' }}, M_databuf = "\000\000ùÀ(\000\000\000\000\000\000\000\001\003", '\0' , "p/Á\000\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\003", '\0' }} (kgdb) p *ro.ro_rt $3 = {rt_nodes = {{rn_mklist = 0x0, rn_parent = 0xc11f8438, rn_bit = -1, rn_bmask = 0 '\0', rn_flags = 4 '\004', rn_u = {rn_leaf = {rn_Key = 0xc1058680 "\020\002", rn_Mask = 0x0, rn_Dupedkey = 0x0}, rn_node = { rn_Off = -1056602496, rn_L = 0x0, rn_R = 0x0}}}, {rn_mklist = 0x0, rn_parent = 0xc11f8120, rn_bit = 61, rn_bmask = 4 '\004', rn_flags = 4 '\004', rn_u = {rn_leaf = {rn_Key = 0x7
, rn_Mask = 0xc11f9000 "\020¨úÀ8\204\037ÁÇÿ", rn_Dupedkey = 0xc11f8420}, rn_node = {rn_Off = 7, rn_L = 0xc11f9000, rn_R = 0xc11f8420}}}}, rt_gateway = 0xc1058690, rt_flags = 132101, rt_ifp = 0xc0f91800, rt_ifa = 0xc1054d00, rt_rmx = {rmx_mtu = 1500, rmx_expire = 333905919, rmx_pksent = 3868}, rt_refcnt = 1, rt_genmask = 0x0, rt_llinfo = 0xc0fab320 "à»úÀàµúÀ \204\037Á", rt_gwroute = 0x0, rt_parent = 0xc11f9000, rt_mtx = {mtx_object = {lo_class = 0xc0880b3c, lo_name = 0xc082a169 "rtentry", lo_type = 0xc082a169 "rtentry", lo_flags = 4390912, lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0}} (kgdb) p *ifp $4 = {if_softc = 0xc0f91800, if_link = {tqe_next = 0xc0f90000, tqe_prev = 0xc08ebe84}, if_xname = "sis0", '\0' , if_dname = 0xc0f2ec2c "sis", if_dunit = 0, if_addrhead = { tqh_first = 0xc0ec0000, tqh_last = 0xc1040460}, if_klist = {kl_lock = 0xc08e5a40, kl_list = { slh_first = 0x0}}, if_pcount = 0, if_carp = 0x0, if_bpf = 0x0, if_index = 1, if_timer = 5, if_nvlans = 0, if_flags = 34883, if_capabilities = 72, if_capenable = 72, if_linkmib = 0x0, if_linkmiblen = 0, if_data = { ifi_type = 6 '\006', ifi_physical = 0 '\0', ifi_addrlen = 6 '\006', ifi_hdrlen = 18 '\022', ifi_link_state = 2 '\002', ifi_recvquota = 0 '\0', ifi_xmitquota = 0 '\0', ifi_datalen = 80 'P', ifi_mtu = 1500, ifi_metric = 0, ifi_baudrate = 10000000, ifi_ipackets = 50, ifi_ierrors = 0, ifi_opackets = 3914, ifi_oerrors = 0, ifi_collisions = 0, ifi_ibytes = 6146, ifi_obytes = 213356, ifi_imcasts = 40, ifi_omcasts = 29, ifi_iqdrops = 0, ifi_noproto = 0, ifi_hwassist = 0, ifi_epoch = 0, ifi_lastchange = {tv_sec = 0, tv_usec = 0}}, if_multiaddrs = {tqh_first = 0xc0fab3e0, tqh_last = 0xc0fabcc0}, if_amcount = 0, if_output = 0xc0671e04 , if_input = 0xc0672598 , if_start = 0xc0713c10 , if_ioctl = 0xc071497c , if_watchdog = 0xc0714b04 , if_init = 0xc0713f60 , if_resolvemulti = 0xc0672e48 , if_spare1 = 0x0, if_spare2 = 0x0, if_spare3 = 0x0, if_spare_flags1 = 0, if_spare_flags2 = 0, if_snd = {ifq_head = 0x0, ifq_tail = 0x0, ifq_len = 0, ifq_maxlen = 127, ifq_drops = 0, ifq_mtx = {mtx_object = {lo_class = 0xc0880b3c, lo_name = 0xc0f9180c "sis0", lo_type = 0xc0829304 "if send queue", lo_flags = 196608, lo_list = { tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0}, ifq_drv_head = 0x0, ifq_drv_tail = 0x0, ifq_drv_len = 0, ifq_drv_maxlen = 127, altq_type = 0, altq_flags = 1, altq_disc = 0x0, altq_ifp = 0xc0f91800, altq_enqueue = 0, altq_dequeue = 0, altq_request = 0, altq_clfier = 0x0, altq_classify = 0, altq_tbr = 0x0, altq_cdnr = 0x0}, if_broadcastaddr = 0xc07db600 "ÿÿÿÿÿÿ", lltables = 0x0, if_label = 0x0, if_prefixhead = {tqh_first = 0x0, tqh_last = 0xc0f91968}, if_afdata = {0x0 , 0xc0faaab0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, if_afdata_initialized = 1, if_afdata_mtx = { mtx_object = {lo_class = 0xc0880b3c, lo_name = 0xc08292f4 "if_afdata", lo_type = 0xc08292f4 "if_afdata", lo_flags = 196608, lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0}, if_starttask = {ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0xc06711c0 , ta_context = 0xc0f91800}} (kgdb) f 12 #12 0xc069b694 in ip_fragment (ip=0xc12f700e, m_frag=0xc76bfc6c, mtu=-1056788992, if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:967 967 m->m_next = m_copy(m0, off, len); (kgdb) l 962 len = ip->ip_len - off; 963 m->m_flags |= M_LASTFRAG; 964 } else 965 mhip->ip_off |= IP_MF; 966 mhip->ip_len = htons((u_short)(len + mhlen)); 967 m->m_next = m_copy(m0, off, len); 968 if (m->m_next == NULL) { /* copy failed */ 969 m_free(m); 970 error = ENOBUFS; /* ??? */ 971 ipstat.ips_odropped++; (kgdb) i loc mhip = (struct ip *) 0xc102ae40 m = (struct mbuf *) 0xc102ae00 mhlen = 20 error = 0 hlen = 20 len = 1480 off = 1500 m0 = (struct mbuf *) 0xc12e6c00 firstlen = 1480 mnext = (struct mbuf **) 0xc12e6c04 nfrags = 1 (kgdb) quit mbsd05# From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 23 22:27:59 2005 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 A4E1D16A41F; Sat, 23 Jul 2005 22:27:59 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0959B43D46; Sat, 23 Jul 2005 22:27:58 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3C0F3.dip.t-dialin.net [84.163.192.243] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML21M-1DwSTM3cWt-0000YG; Sun, 24 Jul 2005 00:27:56 +0200 From: Max Laier To: Edwin Date: Sun, 24 Jul 2005 00:27:38 +0200 User-Agent: KMail/1.8 References: <20050719034215.GB20752@asx01.verolan.com> <200507231623.16183.max@love2party.net> <20050723184108.GA14076@asx01.verolan.com> In-Reply-To: <20050723184108.GA14076@asx01.verolan.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1700961.AHckfZInam"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507240027.54127.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-hackers@freebsd.org, Giorgos Keramidas Subject: Re: help w/panic under heavy load - 5.4 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: Sat, 23 Jul 2005 22:27:59 -0000 --nextPart1700961.AHckfZInam Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 23 July 2005 20:41, Edwin wrote: > Kernel name: D1-0722 (for reference) > > mbsd05# kgdb kernel.debug /usr/local/STORAGE/crash/vmcore.5 > #13 0xc06933c1 in ip_fastforward (m=3D0xc12e6c00) at > /usr/src/sys/netinet/ip_fastfwd.c:572 warning: Source file is more recent > than executable. Let's hope that's still correct ... > 572 if (ip_fragment(ip, &m, mtu, ifp->if_hwassist, > (kgdb) l > 567 m->m_pkthdr.csum_flags |=3D CSUM_IP; > 568 /* > 569 * ip_fragment expects ip_len and ip_off in host byte > 570 * order but returns all packets in network byte order > 571 */ > 572 if (ip_fragment(ip, &m, mtu, ifp->if_hwassist, > 573 (~ifp->if_hwassist & CSUM_DELAY_IP))) { > 574 goto drop; > 575 } > 576 KASSERT(m !=3D NULL, ("null mbuf and no error")); > (kgdb) i loc > ip =3D (struct ip *) 0xc12f700e > m0 =3D (struct mbuf *) 0xc12f700e > ro =3D {ro_rt =3D 0xc11f8420, ro_dst =3D {sa_len =3D 16 '\020', sa_family= =3D 2 > '\002', sa_data =3D "\000\000=C0=A8\002\005\000\000\000\000\000\000\000"}} > dst =3D (struct sockaddr_in *) 0xc76bfc3c > ia =3D (struct in_ifaddr *) 0x0 > ifa =3D (struct ifaddr *) 0x0 > ifp =3D (struct ifnet *) 0xc0f91800 > odest =3D {s_addr =3D 84060352} > dest =3D {s_addr =3D 84060352} > sum =3D 0 > ip_len =3D 0 This should not happen. ip_len is initialize from ntohs(ip->ip_len) and nev= er=20 touched again. Anyway, let's look some more ... > error =3D 84060352 > hlen =3D -1057417216 > mtu =3D 0 > __func__ =3D "ip_fastforward" > (kgdb) p *ip > $1 =3D {ip_hl =3D 5, ip_v =3D 4, ip_tos =3D 0 '\0', ip_len =3D 10240, ip_= id =3D 61249, ip_len should be 40 as ip_len is supposed to be in HOST BYTE ORDER at this= =20 point. Feeding 10240 to ntohs() give the correct value, so something=20 obviously went wrong. Let's see how we got here: 355 does the byteorder flip to host byte order 366 pfil OUT 451 pfil IN 527 first check ip_len < if_mtu etc ... Obviously, the only thing that might mess with the byte order (unless I mis= sed=20 something along the way) is one of the pfil consumers. *** *** What firewall(s) are you running with? *** > ip_off =3D 0, ip_ttl =3D 63 '?', ip_p =3D 17 '\021', ip_sum =3D 31921, ip= _src =3D > {s_addr =3D 67479744}, ip_dst =3D {s_addr =3D 84060352}} (kgdb) p *m > $2 =3D {m_hdr =3D {mh_next =3D 0x0, mh_nextpkt =3D 0x0, mh_data =3D 0xc12= f700e "E", > mh_len =3D 40, mh_flags =3D 3, mh_type =3D 1}, M_dat =3D {MH =3D {MH_pkth= dr =3D {rcvif > =3D 0xc0f90000, len =3D 40, header =3D 0x0, csum_flags =3D 769, csum_data= =3D 0, tags 40, there you have it - no need to fragment at all! > /usr/src/sys/netinet/ip_output.c:967 > 967 m->m_next =3D m_copy(m0, off, len); > (kgdb) l > 962 len =3D ip->ip_len - off; > 963 m->m_flags |=3D M_LASTFRAG; > 964 } else > 965 mhip->ip_off |=3D IP_MF; > 966 mhip->ip_len =3D htons((u_short)(len + mhlen)); > 967 m->m_next =3D m_copy(m0, off, len); > 968 if (m->m_next =3D=3D NULL) { /* copy failed */ > 969 m_free(m); > 970 error =3D ENOBUFS; /* ??? */ > 971 ipstat.ips_odropped++; Just to make sure, we didn't touch the original packet at this point so the= =20 above values are still the ones we based the (wrong) decision on. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1700961.AHckfZInam Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC4sRqXyyEoT62BG0RAh+KAJ94YzIMUpdJ4uevZzhCaKBTwp+zswCfblzk issKUmM+7rkv7Ir28mgPI5E= =HYJP -----END PGP SIGNATURE----- --nextPart1700961.AHckfZInam--