From owner-freebsd-stable@FreeBSD.ORG Sun Jan 1 00:13:21 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 768EF16A41F; Sun, 1 Jan 2006 00:13:21 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id EABC843D48; Sun, 1 Jan 2006 00:13:20 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id k010DFo7001277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Dec 2005 16:13:17 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <43B71EF7.2010803@errno.com> Date: Sat, 31 Dec 2005 16:14:47 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051227) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Paul References: <20051231212858.9F9D116A420@hub.freebsd.org> In-Reply-To: <20051231212858.9F9D116A420@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ondra Holecek , freebsd-acpi@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: problems with wifi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2006 00:13:21 -0000 Bill Paul wrote: >>yes, i can load if_ath, wireless card is found and i can set it up as >>ath0, but i still have no signal (and there are many ap's - i can see >>with different pcmcia card) > > > Note that if this in fact a problem with ACPI not supporting the > wireless enable switch on your laptop correctly, it won't work > with the NDISulator any better than it will with the ath(4) driver. > I think the wireless enable switch controls the connection to the > antenna(s), and is a separate device from the NIC itself that varies > in implementation depending on the laptop. The NDIS driver only knows > how to manipulate the NIC hardware: the NIC manufacturer can't really > customize the driver for each laptop out there (and the laptop > manufacturers usually don't customize the drivers either, beyond > sticking their logo on them). <...ndis related stuff deleted...> Handling this in the ath driver is actually very simple; I've just never done it 'cuz none of my laptops have the this setup to test with. When you hit the switch the driver gets an interrupt from the ath card and can then toggle the state of the rfkill pin. If you run the latest code out for testing there is also a sysctl that you can use to control this manually. Sam From owner-freebsd-stable@FreeBSD.ORG Sun Jan 1 02:31:48 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06C1D16A41F; Sun, 1 Jan 2006 02:31:48 +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 7309543D5A; Sun, 1 Jan 2006 02:31:43 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp232-237.lns2.adl4.internode.on.net [203.122.232.237]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k012VZwY040983 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 1 Jan 2006 13:01:37 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Ondra Holecek Date: Sun, 1 Jan 2006 13:01:19 +1030 User-Agent: KMail/1.8.3 References: <43B5274C.5010206@deprese.net> <200512311422.13184.doconnor@gsoft.com.au> <43B65249.1030104@deprese.net> In-Reply-To: <43B65249.1030104@deprese.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2631632.gJjh6IHy4W"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601011301.29541.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: problems with wifi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2006 02:31:48 -0000 --nextPart2631632.gJjh6IHy4W Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, 31 Dec 2005 20:11, Ondra Holecek wrote: > yes, i can load if_ath, wireless card is found and i can set it up as > ath0, but i still have no signal (and there are many ap's - i can see > with different pcmcia card) > > therefore, i think i have to somehow turn it on (the special "wireless" > key on keyboard of course doesn't work) Hmm, in my experience the key actually works, but there is no response apar= t=20 from the radio magically working. > > Why don't you just load if_ath.ko? It should support that chipset. > i know, i did it. loaded generated kernel module, but no ndis0 Then I'd say you didn't do it correctly :) PS cross posting to 3 lists is a bad idea. I seriously doubt this thread is= =20 appropriate to all 3 (especially -acpi). =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 --nextPart2631632.gJjh6IHy4W Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDtz8B5ZPcIHs/zowRAj8sAKCa1AuD7VqZ7xe6NrvHAg8JfEjMTQCdEweh vmv7sfjT58Tn4E7PsNjH8j4= =NJ7w -----END PGP SIGNATURE----- --nextPart2631632.gJjh6IHy4W-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 1 02:32:00 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF2C216A41F for ; Sun, 1 Jan 2006 02:32:00 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from omta05ps.mx.bigpond.com (omta05ps.mx.bigpond.com [144.140.83.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE13F43D58 for ; Sun, 1 Jan 2006 02:31:52 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from areilly.bpc-users.org ([141.168.4.160]) by omta05ps.mx.bigpond.com with ESMTP id <20060101023150.DRMV14751.omta05ps.mx.bigpond.com@areilly.bpc-users.org> for ; Sun, 1 Jan 2006 02:31:50 +0000 Received: (qmail 34812 invoked by uid 501); 1 Jan 2006 13:31:49 +1100 Date: Sun, 1 Jan 2006 13:31:48 +1100 From: Andrew Reilly To: Torfinn Ingolfsen Message-ID: <20060101023148.GA34753@gurney.reilly.home> References: <20051231035757.GA24100@gurney.reilly.home> <20051231124022.62da4895.torfinn.ingolfsen@broadpark.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051231124022.62da4895.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: 5-port (NEC) USB-2.0 PCI card support? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2006 02:32:01 -0000 On Sat, Dec 31, 2005 at 12:40:22PM +0100, Torfinn Ingolfsen wrote: > On Sat, 31 Dec 2005 14:57:57 +1100 > Andrew Reilly wrote: > > > And even the BIOS doesn't mention it in the pre-boot PCI > > interrupt assignment scan (which doesn't bode well, I suspect). > > > > Thoughts, suggestions? > > Does 'pciconf -lv' report anything for this card? Hmm. No, nothing at all. (And it also clearly shows that the piece of dmesg.boot that I posted (none@pci0:7:3) was part of the Intel PIIX4 chipset.) > Second, have you tried FreeBSD 6.0 (you could boot an installation CD) > to see if it is detected there? I'll give that a go, but if the BIOS doesn't see it first, I suspect that the card's just a dud. I'll try to take it back. Thanks, -- Andrew From owner-freebsd-stable@FreeBSD.ORG Sun Jan 1 16:30:35 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AB0216A41F for ; Sun, 1 Jan 2006 16:30:35 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D106543D7F for ; Sun, 1 Jan 2006 16:30:28 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Et669-0005xy-CG for freebsd-stable@freebsd.org; Sun, 01 Jan 2006 17:30:21 +0100 Received: from r4v24.chello.upc.cz ([84.42.149.24]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Jan 2006 17:30:21 +0100 Received: from v.haisman by r4v24.chello.upc.cz with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Jan 2006 17:30:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= Date: Sun, 01 Jan 2006 17:29:47 +0100 Lines: 30 Message-ID: References: <20051230215108.GA99536@Xarfai.MHoerich.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAF1AE419AD8A99273CF35E1B" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: r4v24.chello.upc.cz User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en In-Reply-To: <20051230215108.GA99536@Xarfai.MHoerich.de> X-Enigmail-Version: 0.93.0.0 OpenPGP: id=63B6B297 Sender: news Subject: Re: FBSD 6 and pthread_testcancel() X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2006 16:30:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAF1AE419AD8A99273CF35E1B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I have similar problems with Evolution on after some portupgrades. Though I use 5.4, not 6.0. VH --------------enigAF1AE419AD8A99273CF35E1B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQ7gDhG56zbtzMDG0AQINYgf/WUHNS8WQLN6AhNBYnBJ0U27ns1jqB/Xo RoUTwkX+CPhJWtG26LnsViJAAfmqvKX9xZqrg6/aiGt/JjG9SKeLnlkomNUBdi8N MnEghJYczZaI+5aS7e0R/Ojt8mq5AJJqA9bT8W2v+aO/FkI/573g+qe5wICSFzHc E83i4RoF4PuoU6RNZrzABEouxLncQhO/zHbYRIaLh+hleXgw+Cfe4RgUMgxnme9B L74yoIRxo59M+vM5K2sqQj6d2hQSBpAJJLoi1PdNNoAG27ZQ7E4YU++HPOTbSp+z vD0tV090tqXFUQ0I7wbcMcwhliGghn8cbHgaO4phT2hrzmvte6OJ9A== =dtfk -----END PGP SIGNATURE----- --------------enigAF1AE419AD8A99273CF35E1B-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 1 17:27:50 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 085D216A41F for ; Sun, 1 Jan 2006 17:27:50 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EEE143D46 for ; Sun, 1 Jan 2006 17:27:49 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id 9D551AD; Sun, 1 Jan 2006 11:27:48 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id B015361C2B; Sun, 1 Jan 2006 11:27:47 -0600 (CST) Date: Sun, 1 Jan 2006 11:27:47 -0600 From: "Matthew D. Fuller" To: Andrew Reilly Message-ID: <20060101172747.GF63497@over-yonder.net> References: <20051231035757.GA24100@gurney.reilly.home> <20051231124022.62da4895.torfinn.ingolfsen@broadpark.no> <20060101023148.GA34753@gurney.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060101023148.GA34753@gurney.reilly.home> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.2 Cc: Torfinn Ingolfsen , freebsd-stable@freebsd.org Subject: Re: 5-port (NEC) USB-2.0 PCI card support? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2006 17:27:50 -0000 On Sun, Jan 01, 2006 at 01:31:48PM +1100 I heard the voice of Andrew Reilly, and lo! it spake thus: > > Hmm. No, nothing at all. (And it also clearly shows that the piece > of dmesg.boot that I posted (none@pci0:7:3) was part of the Intel > PIIX4 chipset.) FWIW, I've got an Adaptec 4-port USB2 card that similar doesn't show up at all in pciconf or a -v dmesg. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 00:16:06 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4F7916A41F for ; Mon, 2 Jan 2006 00:16:05 +0000 (GMT) (envelope-from mitch@bitblock.com) Received: from bigass1.bitblock.com (ns1.bitblock.com [66.199.170.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B04143D4C for ; Mon, 2 Jan 2006 00:16:05 +0000 (GMT) (envelope-from mitch@bitblock.com) Received: from dc1 ([66.199.170.122]) (AUTH: LOGIN mitch@bitblock.com) by bigass1.bitblock.com with esmtp; Mon, 02 Jan 2006 00:15:57 +0000 X-Abuse-Reports: Visit http://www.bitblock.com/abuse.php X-Abuse-Reports: and submit a copy of the message headers X-Abuse-Reports: or review our policies and procedures X-Abuse-Reports: ID= 43B870BD.00015E67.bigass1.bitblock.com,dns; dc1 ([66.199.170.122]),AUTH: LOGIN mitch@bitblock.com From: "Mitch \(Bitblock\)" To: freebsd-stable@freebsd.org Date: Sun, 1 Jan 2006 16:15:57 -0800 Organization: Bitblock Systems Inc. Message-ID: <026001c60f31$b42cb200$0600010a@hts.bitblock.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 thread-index: AcYPMbPPeYRSCeqbRdmGsuD0rLiw+Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: OK - I'm stumped - where IS stable? Sorry if it seems like a dumb question but I looked in the handbook... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 00:16:06 -0000 The handbook (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.ht ml#STABLE) references ftp://snapshots.jp.FreeBSD.org/pub/FreeBSD/snapshots/ - which doesn't seem to contain any 6.0 files newer than 2004? The main FTP site doesn't contain a "branches" folder for anything past 4.0-stable. Are formal "stable releases" not available for 6.0 yet? Just the current daily snapshots? Or am I missing something? Thanks! m/ From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 00:28:42 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF63F16A420 for ; Mon, 2 Jan 2006 00:28:42 +0000 (GMT) (envelope-from dsyphers@u.washington.edu) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49A8843D45 for ; Mon, 2 Jan 2006 00:28:42 +0000 (GMT) (envelope-from dsyphers@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k020SYQt032309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 1 Jan 2006 16:28:34 -0800 X-Auth-Received: from yggdrasil.seektruth.org (c-67-171-38-33.hsd1.wa.comcast.net [67.171.38.33]) (authenticated authid=dsyphers) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k020SYZP028142 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 1 Jan 2006 16:28:34 -0800 From: David Syphers To: freebsd-stable@freebsd.org Date: Sun, 1 Jan 2006 16:28:33 -0800 User-Agent: KMail/1.8.3 References: <026001c60f31$b42cb200$0600010a@hts.bitblock.net> In-Reply-To: <026001c60f31$b42cb200$0600010a@hts.bitblock.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601011628.33690.dsyphers@u.washington.edu> X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CD 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: "Mitch \(Bitblock\)" Subject: Re: OK - I'm stumped - where IS stable? Sorry if it seems like a dumb question but I looked in the handbook... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 00:28:42 -0000 On Sunday 01 January 2006 04:15 pm, Mitch (Bitblock) wrote: > The handbook > (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.h >t ml#STABLE) references > ftp://snapshots.jp.FreeBSD.org/pub/FreeBSD/snapshots/ - which doesn't seem > to contain any 6.0 files newer than 2004? Monthly snapshots are at ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ > Or am I missing something? Most people track stable via source updates and building world (in the handbook). When I install on a new machine I usually install the last release, and then immediately do a source upgrade. That said, the jp daily snapshots are a good resource, as are the monthly snapshots. The only formal releases are, well, releases - 6.0-R, etc. -David -- "...which will go down in history as the funniest parody of a Seattle Department of Transportation Urban Forestry publication EVER." -The Stranger From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 05:42:08 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 439C616A41F for ; Mon, 2 Jan 2006 05:42:08 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 727EA43D62 for ; Mon, 2 Jan 2006 05:42:05 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Sun, 01 Jan 2006 21:42:01 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 3A5905D07; Sun, 1 Jan 2006 21:42:02 -0800 (PST) To: "Mitch \(Bitblock\)" In-reply-to: Your message of "Sun, 01 Jan 2006 16:15:57 PST." <026001c60f31$b42cb200$0600010a@hts.bitblock.net> Date: Sun, 01 Jan 2006 21:42:02 -0800 From: "Kevin Oberman" Message-Id: <20060102054202.3A5905D07@ptavv.es.net> Cc: freebsd-stable@freebsd.org Subject: Re: OK - I'm stumped - where IS stable? Sorry if it seems like a dumb question but I looked in the handbook... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 05:42:08 -0000 > From: "Mitch \(Bitblock\)" > Date: Sun, 1 Jan 2006 16:15:57 -0800 > Sender: owner-freebsd-stable@freebsd.org > > The handbook > (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.ht > ml#STABLE) references ftp://snapshots.jp.FreeBSD.org/pub/FreeBSD/snapshots/ > - which doesn't seem to contain any 6.0 files newer than 2004? > > The main FTP site doesn't contain a "branches" folder for anything past > 4.0-stable. > > Are formal "stable releases" not available for 6.0 yet? Just the current > daily snapshots? Formal "stable releases" are called releases. Stable is the development branch of a given version. At this time there are "stable" branches of at least versions 3, 4, 5, and 6. But these are branches and normally the most recent point on any branch is referred to as "stable". Releases are (more or less) marked points along the stable development that get a great deal of extra work to make them as clean as possible and then the tree is tagged with the release and ISO images are generated for the various platforms. If you want a "stable release", you want just that, a release. As of this time there has been only a single release on the version 6 branch, 6.0. If you want 6, install 6.0-Release. From there you can update your system to 6-Stable, if you wish. (The same is true for prior version, except that V3 is pretty much dead these days and 4 gets little attention other than security issues. V5 is moving in that direction, but is still getting some updates. Snapshots are built, but not on the normal distribution systems. They are on ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/, but they are not "formal" in any way. They are development snapshots and nothing more. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 08:20:08 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A506816A41F; Mon, 2 Jan 2006 08:20:08 +0000 (GMT) (envelope-from jack@jarasoft.net) Received: from orac.jarasoft.net (raats.xs4all.nl [80.126.151.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 697D643D45; Mon, 2 Jan 2006 08:20:06 +0000 (GMT) (envelope-from jack@jarasoft.net) Received: from orac.jarasoft.net (localhost.jarasoft.net [127.0.0.1]) by orac.jarasoft.net (Postfix) with ESMTP id EC05E1169A; Mon, 2 Jan 2006 09:20:03 +0100 (CET) Received: from jara3 (unknown [10.0.0.151]) by orac.jarasoft.net (Postfix) with ESMTP id 72DCF116AA; Mon, 2 Jan 2006 09:20:03 +0100 (CET) Message-ID: <001801c60f75$585a21d0$9700000a@jarasoft.net> From: "Jack Raats" To: "FreeBSD Current" , "FreeBSD Stable" Date: Mon, 2 Jan 2006 09:20:08 +0100 MIME-Version: 1.0 X-Priority: 1 X-Virus-Scanned: ClamAV using ClamSMTP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Errors after upgrading to new portupgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jack Raats List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 08:20:08 -0000 Hi, Running the new portupgrade 2.0.0,1 gives the following errors: orac# portupgrade -Na [Updating the portsdb in /usr/ports ... - 13945 port = entries found = .........1000.........2000.........3000.........4000.........5000........= .6000.........7000.........8000.........9000.........10000.........11000.= ........12000.........13000......... ..... done] ** Package origin of 'bison' has been changed: 'devel/bison' -> = 'devel/bison2' ** No need to upgrade 'bison-1.75_2,1' (>=3D bison-2.1_1). (specify -f = to force) /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:89:in `<<': failed to = allocate memory (NoMemoryError) from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:89:in `trace' from /usr/local/sbin/portupgrade:723:in `do_upgrade' from /usr/local/sbin/portupgrade:696:in `main' from /usr/local/sbin/portupgrade:693:in `each' from /usr/local/sbin/portupgrade:693:in `main' from /usr/local/sbin/portupgrade:208:in `initialize' from /usr/local/sbin/portupgrade:208:in `new' from /usr/local/sbin/portupgrade:208:in `main' from /usr/local/sbin/portupgrade:1893 Anyone know how to cure this error? Jack From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 08:25:25 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32DCF16A41F; Mon, 2 Jan 2006 08:25:25 +0000 (GMT) (envelope-from jack@jarasoft.net) Received: from orac.jarasoft.net (raats.xs4all.nl [80.126.151.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id B549A43D77; Mon, 2 Jan 2006 08:25:21 +0000 (GMT) (envelope-from jack@jarasoft.net) Received: from orac.jarasoft.net (localhost.jarasoft.net [127.0.0.1]) by orac.jarasoft.net (Postfix) with ESMTP id D3B97116A0; Mon, 2 Jan 2006 09:25:18 +0100 (CET) Received: from jara3 (unknown [10.0.0.151]) by orac.jarasoft.net (Postfix) with ESMTP id B3C541169A; Mon, 2 Jan 2006 09:25:18 +0100 (CET) Message-ID: <003d01c60f76$144631e0$9700000a@jarasoft.net> From: "Jack Raats" To: , Date: Mon, 2 Jan 2006 09:25:24 +0100 MIME-Version: 1.0 X-Priority: 1 X-Virus-Scanned: ClamAV using ClamSMTP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Errors after upgrading portupgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jack Raats List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 08:25:25 -0000 Hi, Running the new portupgrade 2.0.0,1 gives the following errors: orac# portupgrade -Na [Updating the portsdb in /usr/ports ... - 13945 port = entries found = .........1000.........2000.........3000.........4000.........5000........= .6000.........7000.........8000.........9000.........10000.........11000.= ........12000.........13000......... ..... done] ** Package origin of 'bison' has been changed: 'devel/bison' -> = 'devel/bison2' ** No need to upgrade 'bison-1.75_2,1' (>=3D bison-2.1_1). (specify -f = to force) /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:89:in `<<': failed to = allocate memory (NoMemoryError) from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:89:in `trace' from /usr/local/sbin/portupgrade:723:in `do_upgrade' from /usr/local/sbin/portupgrade:696:in `main' from /usr/local/sbin/portupgrade:693:in `each' from /usr/local/sbin/portupgrade:693:in `main' from /usr/local/sbin/portupgrade:208:in `initialize' from /usr/local/sbin/portupgrade:208:in `new' from /usr/local/sbin/portupgrade:208:in `main' from /usr/local/sbin/portupgrade:1893 Anyone know how to cure this error? Jack From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 09:35:40 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C220F16A41F for ; Mon, 2 Jan 2006 09:35:40 +0000 (GMT) (envelope-from mitch@bitblock.com) Received: from bigass1.bitblock.com (ns1.bitblock.com [66.199.170.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DEA543D53 for ; Mon, 2 Jan 2006 09:35:37 +0000 (GMT) (envelope-from mitch@bitblock.com) Received: from dc1 ([66.199.170.122]) (AUTH: LOGIN mitch@bitblock.com) by bigass1.bitblock.com with esmtp; Mon, 02 Jan 2006 09:35:31 +0000 X-Abuse-Reports: Visit http://www.bitblock.com/abuse.php X-Abuse-Reports: and submit a copy of the message headers X-Abuse-Reports: or review our policies and procedures X-Abuse-Reports: ID= 43B8F3E3.0000701D.bigass1.bitblock.com,dns; dc1 ([66.199.170.122]),AUTH: LOGIN mitch@bitblock.com From: "Mitch \(Bitblock\)" To: "'Kevin Oberman'" , "'David Syphers'" Date: Mon, 2 Jan 2006 01:35:32 -0800 Organization: Bitblock Systems Inc. Message-ID: <002401c60f7f$e020d870$0600010a@hts.bitblock.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 In-Reply-To: <20060102054202.3A5905D07@ptavv.es.net> Thread-Index: AcYPX0ReRT27hte1S7irJVKnKgyTPgAH5z4g Cc: freebsd-stable@freebsd.org Subject: RE: OK - I'm stumped - where IS stable? Sorry if it seems like a dumb question but I looked in the handbook... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 09:35:40 -0000 > > From: "Mitch \(Bitblock\)" > > Date: Sun, 1 Jan 2006 16:15:57 -0800 > > Sender: owner-freebsd-stable@freebsd.org > > > > The handbook > > (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current- > stable.ht > > ml#STABLE) references > ftp://snapshots.jp.FreeBSD.org/pub/FreeBSD/snapshots/ > > - which doesn't seem to contain any 6.0 files newer than 2004? > > > > The main FTP site doesn't contain a "branches" folder for anything past > > 4.0-stable. > > > > Are formal "stable releases" not available for 6.0 yet? Just the current > > daily snapshots? > [Mitch says:] Thanks to both of you for your reply - so basically, it seems that what was once documented... (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.ht ml) is no longer maintained? Should I point this out to someone on a doc list or something? Where CURRENT could be buggy and was not yet reviewed / fully tested, and STABLE was given an extra level of QA has at some point been abandoned then? Or are the CVS branches still in existence, but there is just no longer an ftp'able repository? My reason for looking at this is that I have some hardware which worked in 5.4, but does not in 6.0 RELEASE 0, so I thought I'd try to test bootable STABLE snapshots periodically to see if the problem gets fixed. The handbook seems to specifically state that STABLE branch should be able to be downloaded and installed like any normal RELEASE, but what you are saying is that I have to patch a 6.0 RELEASE now - does the "stable" code branch exist? Or am I likely to find unworkable snapshots? Thanks for your patience. The more I learn the more I realize I need to learn ;-) m/ From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 11:14:51 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84C8B16A41F for ; Mon, 2 Jan 2006 11:14:51 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 302B243D49 for ; Mon, 2 Jan 2006 11:14:50 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id k02BEgOQ004377; Mon, 2 Jan 2006 03:14:46 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200601021114.k02BEgOQ004377@gw.catspoiler.org> Date: Mon, 2 Jan 2006 03:14:42 -0800 (PST) From: Don Lewis To: spamrefuse@yahoo.com In-Reply-To: <20051125032845.73799.qmail@web36208.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: PeterJeremy@optushome.com.au, freebsd-stable@FreeBSD.org Subject: Re: Swapfile problem in 6? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 11:14:51 -0000 Attempting to catch up with my backlog of unread email, only 12K unread messages to go ... On 24 Nov, Rob wrote: > I have cvsup'ed the sources to STABLE as of Nov. 23rd > 2005. > After recompiling/installing world and debug-kernel, > I again get a kernel deadlock when using swapfile: > http://surfion.snu.ac.kr/~lahaye/swapfile2.txt > > Previous deadlocks are still documented here > http://surfion.snu.ac.kr/~lahaye/swapfile.txt > > I hope this is of use for fixing this bug in 6. > If further investigation is needed, then please let me > know. This is a deadlock caused by memory exhaustion. The pagedaemon only has a limited number of bufs that it uses for writing dirty pages to swap to prevent it from saturating the I/O subsystem with large numbers of writes. In this case, pagedaemon is trying to free up memory by writing dirty pages, and it has used up all of its bufs and is waiting for the write requests to complete and the bufs the bufs to be returned to it. This isn't happening because md0 is stuck waiting for memory. This is a little bit suprising to me because it looks like writes to vnode backed devices are done synchronously by default. If you have a chance to test this again, a stack trace of md0 in the deadlock state would be interesting. I'd like to know where md0 is getting stuck. I wonder if pagedaemon should scan ahead and more agressively discard clean pages when it has run out of bufs to write dirty pages, especially in low memory situations. Preventing the creation of more dirty pages would be nice, but I don't know how to do that ... From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 11:16:39 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4802C16A41F for ; Mon, 2 Jan 2006 11:16:39 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91CA443D79 for ; Mon, 2 Jan 2006 11:16:34 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id k02BGPKJ004388; Mon, 2 Jan 2006 03:16:29 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200601021116.k02BGPKJ004388@gw.catspoiler.org> Date: Mon, 2 Jan 2006 03:16:25 -0800 (PST) From: Don Lewis To: kris@obsecurity.org In-Reply-To: <20051118010106.GB47900@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: spamrefuse@yahoo.com, freebsd-stable@FreeBSD.org Subject: Re: Swapfile problem in 6? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 11:16:39 -0000 On 17 Nov, Kris Kennaway wrote: > On Thu, Nov 17, 2005 at 04:33:50PM -0800, Rob wrote: >> --- Kris Kennaway wrote: >> > >> > I commented on it elsewhere in this thread. >> >> Do you mean your comment on the swap_pager error: >> >> Quote: >> "AFAICT that is just a trigger-happy timer..it's >> supposed to detect when a swap operation took too >> long to complete, but it also triggers on swapfiles >> since they're so much less efficient (i.e. slower) >> than swapping onto a bare device." >> EndQuote. > > Right: "harmless warning" not "error". This isn't totally harmless because the pagedaemon is only allowed a handful of outstanding writes. It gets stuck when it runs out. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 12:14:08 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 362B316A422 for ; Mon, 2 Jan 2006 12:14:08 +0000 (GMT) (envelope-from zanchey@ucc.gu.uwa.edu.au) Received: from asclepius.uwa.edu.au (asclepius3.uwa.edu.au [130.95.128.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id D92A043D49 for ; Mon, 2 Jan 2006 12:14:04 +0000 (GMT) (envelope-from zanchey@ucc.gu.uwa.edu.au) Received: from asclepius.kas (localhost.localdomain [127.0.0.1]) by asclepius.uwa.edu.au (Postfix) with SMTP id 71A7A184CC7 for ; Mon, 2 Jan 2006 20:13:57 +0800 (WST) Received: from asclepius (localhost.localdomain [127.0.0.1]) by asclepius.prekas (Postfix) with SMTP id 33611186F0F for ; Mon, 2 Jan 2006 20:13:57 +0800 (WST) X-UWA-Client-IP: 130.95.13.9 (UWA) Received: from mooneye.ucc.gu.uwa.edu.au (mooneye.ucc.gu.uwa.edu.au [130.95.13.9]) by asclepius.extinput (Postfix) with ESMTP id ED7AA185F22 for ; Mon, 2 Jan 2006 20:13:56 +0800 (WST) Received: by mooneye.ucc.gu.uwa.edu.au (Postfix, from userid 801) id 8A06518ADA; Mon, 2 Jan 2006 20:13:53 +0800 (WST) Received: from mussel.ucc.gu.uwa.edu.au (mussel.ucc.gu.uwa.edu.au [130.95.13.18]) by mooneye.ucc.gu.uwa.edu.au (Postfix) with ESMTP id C4501183F6; Mon, 2 Jan 2006 20:13:52 +0800 (WST) Received: from zanchey (helo=localhost) by mussel.ucc.gu.uwa.edu.au with local-esmtp (Exim 3.36 #1 (Debian)) id 1EtOZU-0007bq-00; Mon, 02 Jan 2006 20:13:52 +0800 Date: Mon, 2 Jan 2006 20:13:52 +0800 (WST) From: David Adam To: "Mitch (Bitblock)" In-Reply-To: <002401c60f7f$e020d870$0600010a@hts.bitblock.net> Message-ID: References: <002401c60f7f$e020d870$0600010a@hts.bitblock.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SpamTest-Info: Profile: Formal (309/051227) X-SpamTest-Info: Profile: Detect Hard [UCS 290904] X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (UCS) [02-08-04] X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release Cc: 'David Syphers' , freebsd-stable@freebsd.org Subject: RE: OK - I'm stumped - where IS stable? Sorry if it seems like a dumb question but I looked in the handbook... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zanchey@ucc.gu.uwa.edu.au List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 12:14:08 -0000 Mitch, On Mon, 2 Jan 2006, Mitch (Bitblock) wrote: > > > From: "Mitch \(Bitblock\)" > > > Date: Sun, 1 Jan 2006 16:15:57 -0800 > > > Sender: owner-freebsd-stable@freebsd.org > > > > > > The handbook > > > (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current- > > stable.ht > > > ml#STABLE) references > > ftp://snapshots.jp.FreeBSD.org/pub/FreeBSD/snapshots/ > > > - which doesn't seem to contain any 6.0 files newer than 2004? > > > > > > The main FTP site doesn't contain a "branches" folder for anything past > > > 4.0-stable. > > > > > > Are formal "stable releases" not available for 6.0 yet? Just the current > > > daily snapshots? > > > [Mitch says:] Thanks to both of you for your reply - so basically, it seems > that what was once documented... > (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.ht > ml) is no longer maintained? Should I point this out to someone on a doc > list or something? Where CURRENT could be buggy and was not yet reviewed / > fully tested, and STABLE was given an extra level of QA has at some point > been abandoned then? > > Or are the CVS branches still in existence, but there is just no longer an > ftp'able repository? > > My reason for looking at this is that I have some hardware which worked in > 5.4, but does not in 6.0 RELEASE 0, so I thought I'd try to test bootable > STABLE snapshots periodically to see if the problem gets fixed. > > The handbook seems to specifically state that STABLE branch should be able > to be downloaded and installed like any normal RELEASE, but what you are > saying is that I have to patch a 6.0 RELEASE now - does the "stable" code > branch exist? Or am I likely to find unworkable snapshots? The handbook document should point to ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ instead (I think there's a problem report with a patch under review). Yes, the -STABLE branch exists. That's how you would patch a 6.0-RELEASE system: using cvsup(1) to follow the STABLE branch changes. You'll probably want ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/Dec_2005/6.0-STABLE-SNAP010-i386-disc1.iso or ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/Dec_2005/6.0-STABLE-SNAP010-i386-bootonly.iso (long URLs, may wrap). Generally speaking, the snapshots will work. Yes, you should be able to just download and install them. However, because they're taken from a continually-moving branch, and aren't subject to a code freeze and rigorous review, they might have minor issues. It's unlikely, but if a snapshot explodes your computer, steals your children and wipes your credit cards, You Have Been Warned. I hope you have some luck with the snapshots - what hardware specifically isn't working? This list or freebsd-questions@freebsd.org may be able to help you. Cheers, David Adam zanchey@ucc.gu.uwa.edu.au (FreeBSD paradise.ucc.gu.uwa.edu.au 6.0-STABLE FreeBSD 6.0-STABLE #5) From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 14:36:51 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46D8D16A41F for ; Mon, 2 Jan 2006 14:36:51 +0000 (GMT) (envelope-from sty@blosphere.net) Received: from vanessa.ncm.brain.riken.jp (vanessa.ncm.brain.riken.jp [134.160.174.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B43FC43D6A for ; Mon, 2 Jan 2006 14:36:45 +0000 (GMT) (envelope-from sty@blosphere.net) Received: from [192.168.0.4] (d245.HtokyoFL24.vectant.ne.jp [210.131.223.245]) by vanessa.ncm.brain.riken.jp (Postfix) with ESMTP id 88F416168 for ; Mon, 2 Jan 2006 23:36:42 +0900 (JST) Message-ID: <43B93A77.5070502@blosphere.net> Date: Mon, 02 Jan 2006 23:36:39 +0900 From: =?ISO-8859-1?Q?Tommi_L=E4tti?= User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: graid3 lost disk - array still fails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 14:36:51 -0000 A few hours ago, my customers graid3 array crashed due one hard-drive loss and it's unable to recover. The data is easily replaceable so no loss of sleep for that but I'd really like to hear some ideas what happened, if possible. Since this was 'do-it-cheaply', we got 3x160G seagates, all old pata type and put the in as primary master, secondary master and slave. Not the best possible combo I know but it worked. Now the secondary master died a bit earlier, and the array started rebuilding, and then somebody rebooted the machine while it was rebuilding ad3... ad2: FAILURE - READ_DMA status=51 error=40 LBA=286404016 GEOM_RAID3: Request failed. ad2[READ(offset=146638856192, length=8192)] GEOM_RAID3: Request failed. raid3/gr0[READ(offset=293277712384, length=16384)] GEOM_RAID3: Device gr0: provider ad2 disconnected. GEOM_RAID3: Device gr0: provider raid3/gr0 destroyed. GEOM_RAID3: Device gr0: rebuilding provider ad3 stopped. GEOM_RAID3: Synchronization request failed (error=6). ad3[WRITE(offset=973602816, length= 65536)] GEOM_RAID3: Device gr0: provider ad3 disconnected. GEOM_RAID3: Device gr0 destroyed. So now that the ad2 is removed, graid3 still reports that ad3 is broken (GEOM_RAID3: Component ad3 (device gr0) broken, skipping.) and then proceeds to remove the array since that was the second disk already and there are not enough disks left... Now, the question would be that is there any way I could lie to the graid3 that the ad3 is okay? I'm pretty sure that there were no writes to the array during the time the ad2 crashed so maybe some data would still be recoverable? -- br, Tommi From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 17:06:13 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B599A16A41F for ; Mon, 2 Jan 2006 17:06:13 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal4.es.net (postal4.es.net [198.124.252.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A92E43D49 for ; Mon, 2 Jan 2006 17:06:13 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id IBA74465 for ; Mon, 02 Jan 2006 09:06:12 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 8B4AA5D07 for ; Mon, 2 Jan 2006 09:06:09 -0800 (PST) To: stable@freebsd.org Date: Mon, 02 Jan 2006 09:06:07 -0800 From: "Kevin Oberman" Message-Id: <20060102170610.8B4AA5D07@ptavv.es.net> Cc: Subject: Where ahve all the sockets gone? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 17:06:13 -0000 6.0-Stable as of 12/11. % netstat -anf inet % netstat -anf inet6 % I have connections to several systems and a few daemons listening, both INET and INET6. Since my last upgrade, I can't see them with netstat. Has anyone else seen this? (For the record, I DO see lots of UNIX sockets if I don't specify -f.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 18:08:49 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FB7B16A41F for ; Mon, 2 Jan 2006 18:08:49 +0000 (GMT) (envelope-from mitch@bitblock.com) Received: from bigass1.bitblock.com (ns1.bitblock.com [66.199.170.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 819A343D66 for ; Mon, 2 Jan 2006 18:08:39 +0000 (GMT) (envelope-from mitch@bitblock.com) Received: from dc1 ([66.199.170.122]) (AUTH: LOGIN mitch@bitblock.com) by bigass1.bitblock.com with esmtp; Mon, 02 Jan 2006 18:08:34 +0000 X-Abuse-Reports: Visit http://www.bitblock.com/abuse.php X-Abuse-Reports: and submit a copy of the message headers X-Abuse-Reports: or review our policies and procedures X-Abuse-Reports: ID= 43B96C22.00003BA1.bigass1.bitblock.com,dns; dc1 ([66.199.170.122]),AUTH: LOGIN mitch@bitblock.com From: "Mitch \(Bitblock\)" To: zanchey@ucc.gu.uwa.edu.au Date: Mon, 2 Jan 2006 10:08:34 -0800 Organization: Bitblock Systems Inc. Message-ID: <004b01c60fc7$8bb102e0$0600010a@hts.bitblock.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 In-Reply-To: Thread-Index: AcYPlgdhZyxfRR7QTbqRBNdrOaGhVQAMI+Cw Cc: 'David Syphers' , freebsd-stable@freebsd.org Subject: RE: OK - I'm stumped - where IS stable? Sorry if it seems like a dumb question but I looked in the handbook... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 18:08:49 -0000 Hey David! [Mitch says:] > The handbook document should point to > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ instead (I think there's a > problem report with a patch under review). > > Yes, the -STABLE branch exists. That's how you would patch a 6.0-RELEASE > system: using cvsup(1) to follow the STABLE branch changes. You'll > probably want > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/Dec_2005/6.0-STABLE-SNAP010- > i386-disc1.iso > > or > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/Dec_2005/6.0-STABLE-SNAP010- > i386-bootonly.iso [Mitch says:] Awesome! That's exactly what I wanted - I figure with those I can keep on top of things and see if my hardware starts working with 6.0 at some point... > Generally speaking, the snapshots will work. Yes, you should be able to > just download and install them. However, because they're taken from a > continually-moving branch, and aren't subject to a code freeze and > rigorous review, they might have minor issues. It's unlikely, but if a > snapshot explodes your computer, steals your children and wipes your > credit cards, You Have Been Warned. [Mitch says:] I understand that - am willing to take the risk - not production really - just want to see if my hardware will function in the future - I filed a PR about the regression, but I've heard that they can be difficult to track down - particularly as there's not much chance the dev team have the same hardware combination... > I hope you have some luck with the snapshots - what hardware specifically > isn't working? This list or freebsd-questions@freebsd.org may be able to > help you. > There was a thread a while back, and I posted a PR too (though some said prematurely, it was the best I could do at the time...) - Mark Linimon flagged it as a regression... RE: (i386/88610) Problem with booting FreeBSD 6.0 bootonly.iso -5.4works fine Basically the system works with 5.4, but crashes during boot with 6.0 - ONLY if I use a multiport (any brand) PCI network card in it - a single NIC is ok... how's that for an odd ball eh? Thanks for the help - downloading now! m/ From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 18:49:52 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75B9C16A41F; Mon, 2 Jan 2006 18:49:52 +0000 (GMT) (envelope-from wtd@pobox.com) Received: from as2.dm.egate.net (shell1.dm.egate.net [216.235.15.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5073243D5D; Mon, 2 Jan 2006 18:49:50 +0000 (GMT) (envelope-from wtd@pobox.com) Received: by as2.dm.egate.net (Postfix, from userid 5562) id 66A924AED; Mon, 2 Jan 2006 13:49:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by as2.dm.egate.net (Postfix) with ESMTP id 5C8504AEB; Mon, 2 Jan 2006 13:49:49 -0500 (EST) Date: Mon, 2 Jan 2006 13:49:49 -0500 (EST) From: William Denton X-X-Sender: buff@as2.dm.egate.net To: Jack Raats In-Reply-To: <001801c60f75$585a21d0$9700000a@jarasoft.net> Message-ID: References: <001801c60f75$585a21d0$9700000a@jarasoft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , FreeBSD Stable Subject: Re: Errors after upgrading to new portupgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 18:49:52 -0000 On 2 January 2006, Jack Raats wrote: > /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:89:in `<<': failed to allocate memory (NoMemoryError) > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:89:in `trace' > from /usr/local/sbin/portupgrade:723:in `do_upgrade' > from /usr/local/sbin/portupgrade:696:in `main' > from /usr/local/sbin/portupgrade:693:in `each' > from /usr/local/sbin/portupgrade:693:in `main' > from /usr/local/sbin/portupgrade:208:in `initialize' > from /usr/local/sbin/portupgrade:208:in `new' > from /usr/local/sbin/portupgrade:208:in `main' > from /usr/local/sbin/portupgrade:1893 > > Anyone know how to cure this error? I had this too, on 6.0-STABLE (to which I upgraded from 5 on Saturday without any trouble). I recompiled all my ruby ports (which took a long time because because it kept saying the pkgdb was in the wrong format and would rebuild it every time I added or removed something, I guess because of the ruby-bdb1 and ruby-bdb4 ports going and coming), then reinstalled portupgrade, and that did it. My /var/db/ports/portupgrade/options now looks like: # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for portupgrade-2.0.0_1,1 _OPTIONS_READ=portupgrade-2.0.0_1,1 WITH_BDB4=true This is just me stumbling around without a clue, but it worked. Bill -- William Denton : Toronto, Canada : www.miskatonic.org : www.frbr.org From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 19:43:40 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F62B16A41F for ; Mon, 2 Jan 2006 19:43:40 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6205343D45 for ; Mon, 2 Jan 2006 19:43:39 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id k02JhI1d005076; Mon, 2 Jan 2006 11:43:23 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200601021943.k02JhI1d005076@gw.catspoiler.org> Date: Mon, 2 Jan 2006 11:43:18 -0800 (PST) From: Don Lewis To: Tor.Egge@cvsup.no.freebsd.org In-Reply-To: <20051126.000406.74717773.Tor.Egge@cvsup.no.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: gcr+freebsd-stable@tharned.org, freebsd-stable@FreeBSD.org, kris@obsecurity.org Subject: Re: Recurring problem: processes block accessing UFS file system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 19:43:40 -0000 On 26 Nov, Tor Egge wrote: > >> Thanks Kris, these are exactly the clues I needed. Since the deadlock >> during a snapshot is fairly easy to reproduce, I did so and collected this >> information below. "alltrace" didn't work as I expected (didn't produce a >> trace), so I traced each pid associated with a locked vnode separately. > > The vnode syncing loop in ffs_sync() has some problems: > > 1. Softupdate processing performed after the loop has started might > trigger the need for retrying the loop. Processing of dirrem work > items can cause IN_CHANGE to be set on some inodes, causing > deadlock in ufs_inactive() later on while the file system is > suspended). I also don't like how this loop interacts with the vnode list churn done by vnlru_free(). Maybe vnode recycling for a file system should be skipped while a file system is being suspended or unmounted. > 2. nvp might no longer be associated with the same mount point after > MNT_IUNLOCK(mp) has been called in the loop. This can cause the > vnode list traversal to be incomplete, with stale information in > the snapshot. Further damage can occur when background fsck uses > that stale information. It looks like this is handled in __mnt_vnode_next() by starting over. Skipping vnode recycling should avoid this problem in the snapshot case. This loop should be bypassed in normal operation and the individual vnode syncing should be done by the syncer. The only reason this loop isn't skipped during normal operation is that that timestamp updates aren't sufficient to add vnodes to the syncer worklist. > Just a few lines down from that loop is a new problem: > > 3. softdep_flushworklist() might not have processed all dirrem work > items associated with the file system even if both error and count > are zero. This can cause both background fsck and softupdate > processing (after file system has been resumed) to decrement the > link count of an inode, causing file system corruption or a panic. Are you sure this is still true after the changes that were committed to both HEAD and RELENG_6 before 6.0-RELEASE? All the pending items that hang around various lists make me nervous, though. I really thing the number of each flavor should be tracked per mount point and softupdates should complain if the counts are non-zero at the end of the suspend and unmount tasks. > Processing of these work items while the file system is suspended > causes a panic. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 19:57:35 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D68E716A41F for ; Mon, 2 Jan 2006 19:57:35 +0000 (GMT) (envelope-from lars+lister.freebsd@adventuras.no) Received: from mail.adventuras.no (mail.adventuras.no [194.63.250.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D84643D6B for ; Mon, 2 Jan 2006 19:57:31 +0000 (GMT) (envelope-from lars+lister.freebsd@adventuras.no) Received: from mail.adventuras.no (seven [127.0.0.1]) by mail.adventuras.no (8.12.10/8.12.10) with ESMTP id k02JvCjt013725 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 2 Jan 2006 20:57:12 +0100 Received: (from apache@localhost) by mail.adventuras.no (8.12.10/8.12.10/Submit) id k02JvCxP013722; Mon, 2 Jan 2006 20:57:12 +0100 Received: from 80.111.250.79 (SquirrelMail authenticated user lars) by mail.adventuras.no with HTTP; Mon, 2 Jan 2006 20:57:12 +0100 (CET) Message-ID: <50410.80.111.250.79.1136231832.squirrel@mail.adventuras.no> In-Reply-To: <200601021114.k02BEgOQ004377@gw.catspoiler.org> References: <20051125032845.73799.qmail@web36208.mail.mud.yahoo.com> <200601021114.k02BEgOQ004377@gw.catspoiler.org> Date: Mon, 2 Jan 2006 20:57:12 +0100 (CET) From: "Lars Kristiansen" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.4-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Adventuras-MailScanner-Information: Please contact the ISP for more information X-Adventuras: du kan filtrere etter AdvSpamScore over 5-10 X-Adventuras-SpamCheck: not spam, SpamAssassin (score=-4.399, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-MailScanner-From: lars+lister.freebsd@adventuras.no Subject: Re: Swapfile problem in 6? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 19:57:36 -0000 > Attempting to catch up with my backlog of unread email, only 12K unread > messages to go ... > > On 24 Nov, Rob wrote: > >> I have cvsup'ed the sources to STABLE as of Nov. 23rd >> 2005. >> After recompiling/installing world and debug-kernel, >> I again get a kernel deadlock when using swapfile: >> http://surfion.snu.ac.kr/~lahaye/swapfile2.txt >> >> Previous deadlocks are still documented here >> http://surfion.snu.ac.kr/~lahaye/swapfile.txt >> >> I hope this is of use for fixing this bug in 6. >> If further investigation is needed, then please let me >> know. > > This is a deadlock caused by memory exhaustion. The pagedaemon only has > a limited number of bufs that it uses for writing dirty pages to swap to > prevent it from saturating the I/O subsystem with large numbers of > writes. In this case, pagedaemon is trying to free up memory by writing > dirty pages, and it has used up all of its bufs and is waiting for the > write requests to complete and the bufs the bufs to be returned to it. > This isn't happening because md0 is stuck waiting for memory. This is a > little bit suprising to me because it looks like writes to vnode backed > devices are done synchronously by default. > > If you have a chance to test this again, a stack trace of md0 in the > deadlock state would be interesting. I'd like to know where md0 is > getting stuck. > > I wonder if pagedaemon should scan ahead and more agressively discard > clean pages when it has run out of bufs to write dirty pages, especially > in low memory situations. Preventing the creation of more dirty pages > would be nice, but I don't know how to do that ... Just in case it can help. Do not have this machine available for testing at the moment but this is the last debuginfo I did get from it. Here is a trace from a situation when a possible idle system got stuck during the night and db showed only one locked vnode: db> show lockedvnods Locked vnodes 0xc1309330: tag ufs, type VREG usecount 1, writecount 1, refcount 154 mountedhere 0 flags () v_object 0xc12cb39c ref 0 pages 606 lock type ufs: EXCL (count 1) by thread 0xc126b900 (pid 178) ino 8155, on dev ad0s1f db> trace 178 Tracing pid 178 tid 100058 td 0xc126b900 sched_switch(c126b900,0,1) at 0xc066a4db = sched_switch+0x17b mi_switch(1,0) at 0xc065f49e = mi_switch+0x27e sleepq_switch(c09b2a98,c484bacc,c065f0e3,c09b2a98,0) at 0xc0677f00 = sleepq_switch+0xe0 sleepq_wait(c09b2a98,0,0,c08ad92d,37b) at 0xc0678100 = sleepq_wait+0x30 msleep(c09b2a98,c09b2d00,244,c08adb6a,0) at 0xc065f0e3 = msleep+0x333 vm_wait(c12cb39c,0,c08990f3,ad7,c06512a4) at 0xc07c6a71 = vm_wait+0x91 allocbuf(c28fa9d8,4000,354000,0,354000) at 0xc06a2f89 = allocbuf+0x4e9 getblk(c1309330,d5,0,4000,0) at 0xc06a29cb = getblk+0x4eb cluster_read(c1309330,10000000,0,d5,0) at 0xc06a5d65 = cluster_read+0xe5 ffs_read(c484bc9c) at 0xc07a631f = ffs_read+0x28f VOP_READ_APV(c09309a0,c484bc9c) at 0xc0838aab = VOP_READ_APV+0x7b mdstart_vnode(c1310800,c1634294,c1310820,1,c0566e10) at 0xc056688c = mdstart_vnode+0xec md_kthread(c1310800,c484bd38,c1310800,c0566e10,0) at 0xc0566f7f = md_kthread+0x16f fork_exit(c0566e10,c1310800,c484bd38) at 0xc0645618 = fork_exit+0xa8 fork_trampoline() at 0xc0816f3c = fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc484bd6c, ebp = 0 --- -- Lars From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 21:32:46 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5617616A41F for ; Mon, 2 Jan 2006 21:32:46 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C1A343D75 for ; Mon, 2 Jan 2006 21:32:43 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id k02LVnLI005261; Mon, 2 Jan 2006 13:31:53 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200601022131.k02LVnLI005261@gw.catspoiler.org> Date: Mon, 2 Jan 2006 13:31:49 -0800 (PST) From: Don Lewis To: Tor.Egge@cvsup.no.freebsd.org In-Reply-To: <20051126.000406.74717773.Tor.Egge@cvsup.no.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: gcr+freebsd-stable@tharned.org, freebsd-stable@FreeBSD.org, kris@obsecurity.org Subject: Re: Recurring problem: processes block accessing UFS file system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 21:32:46 -0000 On 26 Nov, Tor Egge wrote: > >> Thanks Kris, these are exactly the clues I needed. Since the deadlock >> during a snapshot is fairly easy to reproduce, I did so and collected this >> information below. "alltrace" didn't work as I expected (didn't produce a >> trace), so I traced each pid associated with a locked vnode separately. > > The vnode syncing loop in ffs_sync() has some problems: There is also a MNT_VNODE_FOREACH() loop in ffs_snapshot(). From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 22:48:22 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 531D916A41F for ; Mon, 2 Jan 2006 22:48:22 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9950C43D55 for ; Mon, 2 Jan 2006 22:48:21 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id k02MmAPe005402; Mon, 2 Jan 2006 14:48:15 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200601022248.k02MmAPe005402@gw.catspoiler.org> Date: Mon, 2 Jan 2006 14:48:10 -0800 (PST) From: Don Lewis To: gcr+freebsd-stable@tharned.org In-Reply-To: <20051122211507.P32523@nc8000.tharned.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd@McKusick.COM, freebsd-stable@FreeBSD.org, kris@obsecurity.org Subject: Re: Recurring problem: processes block accessing UFS file system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 22:48:22 -0000 On 22 Nov, Greg Rivers wrote: > On Mon, 21 Nov 2005, Kris Kennaway wrote: > >> It may not be the same problem. You should also try to obtain a trace >> when snapshots are not implicated. >> > > Agreed. I'll do so at the first opportunity. > > >> 'show lockedvnods' is very important for diagnosing filesystem >> deadlocks, and 'alltrace' is the easiest way to obtain stack traces for >> the resulting processes that are holding locks. You'll want to 'set >> $lines=0' and capture the output from the serial console to a file. >> > > Thanks Kris, these are exactly the clues I needed. Since the deadlock > during a snapshot is fairly easy to reproduce, I did so and collected this > information below. "alltrace" didn't work as I expected (didn't produce a > trace), so I traced each pid associated with a locked vnode separately. There appears to be a lock order reversal between a vnode lock and the hand-rolled suspend lock. Basically, it is not permissible to wait for the suspend lock while holding a vnode lock. In cases where a thread holds a vnode lock and then wants to start a file system write, it has to make a non-blocking attempt to grab the suspend lock and then release the vnode lock if the suspend lock can't be obtained. For example, in vn_open_cred(): if (vn_start_write(ndp->ni_dvp, &mp, V_NOWAIT) != 0) { NDFREE(ndp, NDF_ONLY_PNBUF); vput(ndp->ni_dvp); VFS_UNLOCK_GIANT(vfslocked); if ((error = vn_start_write(NULL, &mp, V_XSLEEP | PCATCH)) != 0) return (error); goto restart; } The problem is taht vput() may call vinactive(), which calls ufs_inactive(), which may attempt to do a file system write and block on the snapshot lock. db> trace 99361 Tracing pid 99361 tid 100437 td 0xce67cd80 sched_switch(ce67cd80,0,1,3d4e53a2,95c40548) at sched_switch+0x158 mi_switch(1,0,c04d7b33,c86d706c,ebb00908) at mi_switch+0x1d5 sleepq_switch(c86d706c,ebb0093c,c04bb9ce,c86d706c,9f) at sleepq_switch+0x16f sleepq_wait(c86d706c,9f,c061a026,0,c0647200) at sleepq_wait+0x11 msleep(c86d706c,c86d7044,29f,c061a026,0,c0653720,c8dc1aa0,ebb00978,ce67cd80) at msleep+0x3d7 vn_write_suspend_wait(c8dc1aa0,c86d7000,1,0,ca07f817) at vn_write_suspend_wait+0 x181 ufs_inactive(ebb009c8,ebb009dc,c051b330,c0646cc0,ebb009c8) at ufs_inactive+0x1b4 VOP_INACTIVE_APV(c0646cc0,ebb009c8,a03,ebb009d0,c051054f) at VOP_INACTIVE_APV+0x 3a vinactive(c8dc1aa0,ce67cd80,ffffffdf,ebb00a24,c0513592) at vinactive+0x82 vput(c8dc1aa0,ffffffdf,2,ebb00a50,0) at vput+0x187 vn_open_cred(ebb00bc0,ebb00cc0,180,c9430580,5) at vn_open_cred+0xfb vn_open(ebb00bc0,ebb00cc0,180,5,4b5fcfad) at vn_open+0x33 kern_open(ce67cd80,81414e0,0,a03,180) at kern_open+0xca open(ce67cd80,ebb00d04,c,ce67cd80,8155000) at open+0x36 syscall(3b,3b,3b,0,a02) at syscall+0x324 99361 ce682624 100 673 673 0000100 [SLPQ suspfs 0xc86d706c][SLP] sendmail If a thread gets stuck waiting for the suspend lock while holding a vnode lock, then it is possible for the thread that is creating the snapshot to get stuck when it attempts to lock that same vnode. 98639 c8e91418 11008 98637 97958 0004102 [SLPQ ufs 0xc8991d18][SLP] mksnap_ffs db> trace 98639 Tracing pid 98639 tid 100282 td 0xc8e8e300 sched_switch(c8e8e300,0,1,cc167362,733b6597) at sched_switch+0x158 mi_switch(1,0,c04d7b33,c8991d18,eb80c544) at mi_switch+0x1d5 sleepq_switch(c8991d18,eb80c578,c04bb9ce,c8991d18,50) at sleepq_switch+0x16f sleepq_wait(c8991d18,50,c06186b3,0,c065ae80) at sleepq_wait+0x11 msleep(c8991d18,c065888c,50,c06186b3,0) at msleep+0x3d7 acquire(eb80c5e0,40,60000,c8e8e300,0) at acquire+0x89 lockmgr(c8991d18,2002,c8991d3c,c8e8e300,eb80c608) at lockmgr+0x45f vop_stdlock(eb80c660,0,c0646cc0,eb80c660,eb80c618) at vop_stdlock+0x2f VOP_LOCK_APV(c0647200,eb80c660,eb80c630,c05f9f43,eb80c660) at VOP_LOCK_APV+0x44 ffs_lock(eb80c660,0,2002,c8991cc0,eb80c67c) at ffs_lock+0x19 VOP_LOCK_APV(c0646cc0,eb80c660,c06402e0,eb80c7d0,0) at VOP_LOCK_APV+0x44 vn_lock(c8991cc0,2002,c8e8e300,4000,c851f300) at vn_lock+0x132 ffs_snapshot(c86d7000,cc978e00,eb80c9a4,6c,eb80c964) at ffs_snapshot+0x152b ffs_mount(c86d7000,c8e8e300,0,c8e8e300,c9f71bb0) at ffs_mount+0x9af vfs_domount(c8e8e300,c88a8760,c88a8870,11211000,c9a77510) at vfs_domount+0x728 vfs_donmount(c8e8e300,11211000,eb80cbec,c9314580,e) at vfs_donmount+0x12e kernel_mount(c8737b80,11211000,eb80cc30,6c,bfbfe8c8) at kernel_mount+0x46 ffs_cmount(c8737b80,bfbfe110,11211000,c8e8e300,0) at ffs_cmount+0x85 mount(c8e8e300,eb80cd04,10,c8e8e300,8052000) at mount+0x21b syscall(3b,3b,3b,8814819c,bfbfe0b0) at syscall+0x324 Xint0x80_syscall() at Xint0x80_syscall+0x1f This block of code in ufs_inactive() is triggering the problem: if (ip->i_flag & (IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) { if ((ip->i_flag & (IN_CHANGE | IN_UPDATE | IN_MODIFIED)) == 0 && vn_write_suspend_wait(vp, NULL, V_NOWAIT)) { ip->i_flag &= ~IN_ACCESS; } else { (void) vn_write_suspend_wait(vp, NULL, V_WAIT); UFS_UPDATE(vp, 0); } } I think the intent is to defer access time updates while writes are suspended, but wait for writes to be allowed before syncing the other timestamps. Hmn, I wonder why any of IN_CHANGE, IN_UPDATE, or IN_MODIFIED are set at this point. They should have been cleared when the file system was synced before MNTK_SUSPENDED was set. I suspect it is all the handle_workitem_foo() calls done by softdep_flushworklist() that set IN_CHANGE. I don't see anything that flushes those changes to disk other maybe the syncer thread ... Ugh! Another bug that I just noticed is that ffs_snapshot() clears MNTK_SUSPENDED before entering its MNT_VNODE_FOREACH() loop, which might re-enable access time updates by other threads. Probably some other flag should be set to allow this thread to bypass the writes forbidden while MNTK_SUSPENDED is set sanity check. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 3 03:10:39 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFF5816A41F for ; Tue, 3 Jan 2006 03:10:39 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3309443D5C for ; Tue, 3 Jan 2006 03:10:38 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id k033AUij005775; Mon, 2 Jan 2006 19:10:34 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200601030310.k033AUij005775@gw.catspoiler.org> Date: Mon, 2 Jan 2006 19:10:30 -0800 (PST) From: Don Lewis To: dan@syz.com In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD unstable on Dell 1750 using SMP? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 03:10:39 -0000 On 30 Nov, Dan Charrois wrote: > This is encouraging - it's the first I've heard of someone who has > found a way to trigger the problem "on demand". The problems I was > experiencing were on a dual Xeon with HTT enabled as well. Perhaps > someone out there who knows much more about the inner workings of > FreeBSD may have an idea of why running top in "aggressive mode" like > this might trigger the random rebooting. In particular, it would be > nice to *know* that someone out there specifically fixed whatever is > wrong in 5.4 when bringing it to 6.0. It's encouraging that you > haven't had any problems since upgrading to 6.0, but I have to wonder > if the bug's actually fixed, or the specific trigger of running top > doesn't trigger the problem but the problem is still lurking in the > background waiting to strike with the right combination of events. > > In any case, I'm anxious to try it out myself on our server to see if > "top -s0" brings it down "on command" with HTT enabled, and not with > HTT disabled. But I'm going to have to wait until some time over the > Christmas holidays to do that sort of experimentation at a time when > it isn't affecting the end users of the machine. I may also upgrade > to 6.0 at that time, since by then it will have been out for a couple > of months, so most of the worst quirks should be worked out by then. > > In the meantime, disabling HTT as I've done seems like a reasonable > precaution to improve the stability.. > > Thanks for your help! > > Dan Try this patch, which I posted to stable@ on October 15. I had hoped to commit it to RELENG_5 in November, but my day job intervened. ------ Forwarded message ------ From: Don Lewis Subject: testers wanted for 5.4-STABLE sysctl kern.proc patch Date: Sat, 15 Oct 2005 14:51:37 -0700 (PDT) To: stable@freebsd.org Cc: The patch below is the 5.4-STABLE version of a patch that was recently committed to HEAD and 6.0-BETA5 to fix locking problems in the kern.proc sysctl handler that could cause panics or deadlocks. It has already been tested by myself and one other person in 5.4-STABLE, but I think it deserves wider testing before I commit it. Testing on SMP systems, while running threaded applications, and on systems that have experienced panics in the existing code is of the most interest. Also be on the lookout for any regressions, such as incorrect data being returned. Index: sys/kern/kern_proc.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_proc.c,v retrieving revision 1.215.2.6 diff -u -r1.215.2.6 kern_proc.c --- sys/kern/kern_proc.c 22 Mar 2005 13:40:23 -0000 1.215.2.6 +++ sys/kern/kern_proc.c 12 Oct 2005 19:13:14 -0000 @@ -72,6 +72,8 @@ static void doenterpgrp(struct proc *, struct pgrp *); static void orphanpg(struct pgrp *pg); +static void fill_kinfo_proc_only(struct proc *p, struct kinfo_proc *kp); +static void fill_kinfo_thread(struct thread *td, struct kinfo_proc *kp); static void pgadjustjobc(struct pgrp *pgrp, int entering); static void pgdelete(struct pgrp *); static int proc_ctor(void *mem, int size, void *arg, int flags); @@ -601,33 +603,22 @@ } } #endif /* DDB */ -void -fill_kinfo_thread(struct thread *td, struct kinfo_proc *kp); /* - * Fill in a kinfo_proc structure for the specified process. + * Clear kinfo_proc and fill in any information that is common + * to all threads in the process. * Must be called with the target process locked. */ -void -fill_kinfo_proc(struct proc *p, struct kinfo_proc *kp) -{ - fill_kinfo_thread(FIRST_THREAD_IN_PROC(p), kp); -} - -void -fill_kinfo_thread(struct thread *td, struct kinfo_proc *kp) +static void +fill_kinfo_proc_only(struct proc *p, struct kinfo_proc *kp) { - struct proc *p; struct thread *td0; - struct ksegrp *kg; struct tty *tp; struct session *sp; struct timeval tv; struct ucred *cred; struct sigacts *ps; - p = td->td_proc; - bzero(kp, sizeof(*kp)); kp->ki_structsize = sizeof(*kp); @@ -685,7 +676,8 @@ kp->ki_tsize = vm->vm_tsize; kp->ki_dsize = vm->vm_dsize; kp->ki_ssize = vm->vm_ssize; - } + } else if (p->p_state == PRS_ZOMBIE) + kp->ki_stat = SZOMB; if ((p->p_sflag & PS_INMEM) && p->p_stats) { kp->ki_start = p->p_stats->p_start; timevaladd(&kp->ki_start, &boottime); @@ -704,71 +696,6 @@ kp->ki_nice = p->p_nice; bintime2timeval(&p->p_runtime, &tv); kp->ki_runtime = tv.tv_sec * (u_int64_t)1000000 + tv.tv_usec; - if (p->p_state != PRS_ZOMBIE) { -#if 0 - if (td == NULL) { - /* XXXKSE: This should never happen. */ - printf("fill_kinfo_proc(): pid %d has no threads!\n", - p->p_pid); - mtx_unlock_spin(&sched_lock); - return; - } -#endif - if (td->td_wmesg != NULL) { - strlcpy(kp->ki_wmesg, td->td_wmesg, - sizeof(kp->ki_wmesg)); - } - if (TD_ON_LOCK(td)) { - kp->ki_kiflag |= KI_LOCKBLOCK; - strlcpy(kp->ki_lockname, td->td_lockname, - sizeof(kp->ki_lockname)); - } - - if (p->p_state == PRS_NORMAL) { /* XXXKSE very approximate */ - if (TD_ON_RUNQ(td) || - TD_CAN_RUN(td) || - TD_IS_RUNNING(td)) { - kp->ki_stat = SRUN; - } else if (P_SHOULDSTOP(p)) { - kp->ki_stat = SSTOP; - } else if (TD_IS_SLEEPING(td)) { - kp->ki_stat = SSLEEP; - } else if (TD_ON_LOCK(td)) { - kp->ki_stat = SLOCK; - } else { - kp->ki_stat = SWAIT; - } - } else { - kp->ki_stat = SIDL; - } - - kg = td->td_ksegrp; - - /* things in the KSE GROUP */ - kp->ki_estcpu = kg->kg_estcpu; - kp->ki_slptime = kg->kg_slptime; - kp->ki_pri.pri_user = kg->kg_user_pri; - kp->ki_pri.pri_class = kg->kg_pri_class; - - /* Things in the thread */ - kp->ki_wchan = td->td_wchan; - kp->ki_pri.pri_level = td->td_priority; - kp->ki_pri.pri_native = td->td_base_pri; - kp->ki_lastcpu = td->td_lastcpu; - kp->ki_oncpu = td->td_oncpu; - kp->ki_tdflags = td->td_flags; - kp->ki_tid = td->td_tid; - kp->ki_numthreads = p->p_numthreads; - kp->ki_pcb = td->td_pcb; - kp->ki_kstack = (void *)td->td_kstack; - kp->ki_pctcpu = sched_pctcpu(td); - - /* We can't get this anymore but ps etc never used it anyway. */ - kp->ki_rqindex = 0; - - } else { - kp->ki_stat = SZOMB; - } mtx_unlock_spin(&sched_lock); tp = NULL; if (p->p_pgrp) { @@ -804,8 +731,6 @@ p->p_sysent->sv_name[0] != '\0') strlcpy(kp->ki_emul, p->p_sysent->sv_name, sizeof(kp->ki_emul)); kp->ki_siglist = p->p_siglist; - SIGSETOR(kp->ki_siglist, td->td_siglist); - kp->ki_sigmask = td->td_sigmask; kp->ki_xstat = p->p_xstat; kp->ki_acflag = p->p_acflag; kp->ki_lock = p->p_lock; @@ -813,6 +738,92 @@ kp->ki_ppid = p->p_pptr->p_pid; } +/* + * Fill in information that is thread specific. + * Must be called with sched_lock locked. + */ +static void +fill_kinfo_thread(struct thread *td, struct kinfo_proc *kp) +{ + struct ksegrp *kg; + struct proc *p; + + p = td->td_proc; + + if (td->td_wmesg != NULL) + strlcpy(kp->ki_wmesg, td->td_wmesg, sizeof(kp->ki_wmesg)); + else + bzero(kp->ki_wmesg, sizeof(kp->ki_wmesg)); + if (TD_ON_LOCK(td)) { + kp->ki_kiflag |= KI_LOCKBLOCK; + strlcpy(kp->ki_lockname, td->td_lockname, + sizeof(kp->ki_lockname)); + } else { + kp->ki_kiflag &= ~KI_LOCKBLOCK; + bzero(kp->ki_lockname, sizeof(kp->ki_lockname)); + } + + if (p->p_state == PRS_NORMAL) { /* XXXKSE very approximate */ + if (TD_ON_RUNQ(td) || + TD_CAN_RUN(td) || + TD_IS_RUNNING(td)) { + kp->ki_stat = SRUN; + } else if (P_SHOULDSTOP(p)) { + kp->ki_stat = SSTOP; + } else if (TD_IS_SLEEPING(td)) { + kp->ki_stat = SSLEEP; + } else if (TD_ON_LOCK(td)) { + kp->ki_stat = SLOCK; + } else { + kp->ki_stat = SWAIT; + } + } else { + kp->ki_stat = SIDL; + } + + kg = td->td_ksegrp; + + /* things in the KSE GROUP */ + kp->ki_estcpu = kg->kg_estcpu; + kp->ki_slptime = kg->kg_slptime; + kp->ki_pri.pri_user = kg->kg_user_pri; + kp->ki_pri.pri_class = kg->kg_pri_class; + + /* Things in the thread */ + kp->ki_wchan = td->td_wchan; + kp->ki_pri.pri_level = td->td_priority; + kp->ki_pri.pri_native = td->td_base_pri; + kp->ki_lastcpu = td->td_lastcpu; + kp->ki_oncpu = td->td_oncpu; + kp->ki_tdflags = td->td_flags; + kp->ki_tid = td->td_tid; + kp->ki_numthreads = p->p_numthreads; + kp->ki_pcb = td->td_pcb; + kp->ki_kstack = (void *)td->td_kstack; + kp->ki_pctcpu = sched_pctcpu(td); + + /* We can't get this anymore but ps etc never used it anyway. */ + kp->ki_rqindex = 0; + + SIGSETOR(kp->ki_siglist, td->td_siglist); + kp->ki_sigmask = td->td_sigmask; +} + +/* + * Fill in a kinfo_proc structure for the specified process. + * Must be called with the target process locked. + */ +void +fill_kinfo_proc(struct proc *p, struct kinfo_proc *kp) +{ + + fill_kinfo_proc_only(p, kp); + mtx_lock_spin(&sched_lock); + if (FIRST_THREAD_IN_PROC(p) != NULL) + fill_kinfo_thread(FIRST_THREAD_IN_PROC(p), kp); + mtx_unlock_spin(&sched_lock); +} + struct pstats * pstats_alloc(void) { @@ -875,24 +886,28 @@ PROC_LOCK_ASSERT(p, MA_OWNED); + fill_kinfo_proc_only(p, &kinfo_proc); if (flags & KERN_PROC_NOTHREADS) { - fill_kinfo_proc(p, &kinfo_proc); - PROC_UNLOCK(p); + mtx_lock_spin(&sched_lock); + if (FIRST_THREAD_IN_PROC(p) != NULL) + fill_kinfo_thread(FIRST_THREAD_IN_PROC(p), &kinfo_proc); + mtx_unlock_spin(&sched_lock); error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc, sizeof(kinfo_proc)); - PROC_LOCK(p); } else { - _PHOLD(p); - FOREACH_THREAD_IN_PROC(p, td) { - fill_kinfo_thread(td, &kinfo_proc); - PROC_UNLOCK(p); + mtx_lock_spin(&sched_lock); + if (FIRST_THREAD_IN_PROC(p) != NULL) + FOREACH_THREAD_IN_PROC(p, td) { + fill_kinfo_thread(td, &kinfo_proc); + error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc, + sizeof(kinfo_proc)); + if (error) + break; + } + else error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc, sizeof(kinfo_proc)); - PROC_LOCK(p); - if (error) - break; - } - _PRELE(p); + mtx_unlock_spin(&sched_lock); } PROC_UNLOCK(p); if (error) @@ -934,6 +949,9 @@ if (oid_number == KERN_PROC_PID) { if (namelen != 1) return (EINVAL); + error = sysctl_wire_old_buffer(req, 0); + if (error) + return (error); p = pfind((pid_t)name[0]); if (!p) return (ESRCH); _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Jan 3 04:34:08 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F1E716A41F for ; Tue, 3 Jan 2006 04:34:08 +0000 (GMT) (envelope-from dikshie@ppk.itb.ac.id) Received: from mx1.itb.ac.id (mx1.itb.ac.id [167.205.23.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F8E243D60 for ; Tue, 3 Jan 2006 04:33:59 +0000 (GMT) (envelope-from dikshie@ppk.itb.ac.id) Received: from localhost (antivirus.ITB.ac.id [167.205.108.137]) by mx1.itb.ac.id (Postfix) with ESMTP id DD607E8ED6 for ; Tue, 3 Jan 2006 11:33:47 +0700 (WIT) Received: from mx1.itb.ac.id ([167.205.23.6]) by localhost (antivirus.itb.ac.id [167.205.108.137]) (amavisd-new, port 10001) with ESMTP id 07420-01 for ; Tue, 3 Jan 2006 11:34:20 +0000 (UTC) Received: from ipv6.ppk.itb.ac.id (ipv6.ppk.itb.ac.id [167.205.30.228]) by mx1.itb.ac.id (Postfix) with ESMTP id 9460CEFFBF for ; Tue, 3 Jan 2006 11:30:48 +0700 (WIT) Received: by ipv6.ppk.itb.ac.id (Postfix, from userid 1001) id 5248011526; Tue, 3 Jan 2006 11:30:51 +0700 (WIT) Date: Tue, 3 Jan 2006 11:30:51 +0700 From: Dikshie To: freebsd-stable@freebsd.org Message-ID: <20060103043051.GA174@ppk.itb.ac.id> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: (FreeBSD 7.0-CURRENT i386) X-Uptime: 11:27AM up 18:06, 1 user, load averages: 2.05, 1.85, 1.20 X-Organization: Pusat Penelitian Kelautan (PPK) X-Location: Labtek VI Building, Institute of Technology, Bandung, Indonesia X-Web-Site: http://ipv6.ppk.itb.ac.id/~dikshie X-Yahoo-ID: dikshie X-GnuPG-Key: http://ipv6.ppk.itb.ac.id/gpg/ X-FingerPrint: 19AC 2592 1394 6C96 BABB 9060 50B8 D244 88E3 B55D X-Virus-Scanned: amavisd-new at itb.ac.id Subject: 6.0-STABLE Panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 04:34:08 -0000 Dear All, my 6.0-STABLE always panic when "make buildworld" heres the dump: lapi# kgdb kernel.debug vmcore.0 [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". Unread portion of the kernel message buffer: panic: trying to sleep while sleeping is prohibited KDB: stack backtrace: kdb_backtrace(100,c32f4480,c06f8c28,c32f4480,c06f3970) at 0xc0510929 = kdb_backtrace+0x29 panic(c06988c7,c32f4480,0,c06f3970,d5629a7c) at 0xc04f9318 = panic+0xa8 sleepq_add(c06f3970,c06f4a2c,c06917eb,1,c06f4a2c,0,c0691b7d,7d) at 0xc0515e68 = sleepq_add+0x8c cv_wait(c06f3970,c06f4a2c,0,16,d5629cb4) at 0xc04d3b5e = cv_wait+0x132 _sx_xlock(c06f3940,c06918e2,180) at 0xc04fe334 = _sx_xlock+0x5c acctwatch(0) at 0xc04d1cf8 = acctwatch+0x20 softclock(0) at 0xc05043d9 = softclock+0x211 ithread_loop(c32ab500,d5629d38,c32ab500,c04e5d74,0) at 0xc04e5eb8 = ithread_loop+0x144 fork_exit(c04e5d74,c32ab500,d5629d38) at 0xc04e5328 = fork_exit+0xa0 fork_trampoline() at 0xc065169c = fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd5629d6c, ebp = 0 --- Uptime: 41m7s Dumping 510 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 511MB (130608 pages) 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc04f90d0 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xc04f937b in panic (fmt=0xc06988c7 "trying to sleep while sleeping is prohibited") at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xc0515e68 in sleepq_add (wchan=0xc06f3970, lock=0xc06f4a2c, wmesg=0x0, flags=1) at /usr/src/sys/kern/subr_sleepqueue.c:273 #4 0xc04d3b5e in cv_wait (cvp=0xc06f3970, mp=0xc06f4a2c) at /usr/src/sys/kern/kern_condvar.c:127 #5 0xc04fe334 in _sx_xlock (sx=0xc06f3940, file=0xc06918e2 "/usr/src/sys/kern/kern_acct.c", line=384) at /usr/src/sys/kern/kern_sx.c:188 #6 0xc04d1cf8 in acctwatch (a=0x0) at /usr/src/sys/kern/kern_acct.c:384 #7 0xc05043d9 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:290 #8 0xc04e5eb8 in ithread_loop (arg=0xc32ab500) at /usr/src/sys/kern/kern_intr.c:547 #9 0xc04e5328 in fork_exit (callout=0xc04e5d74 , arg=0xc32ab500, frame=0xd5629d38) at /usr/src/sys/kern/kern_fork.c:789 #10 0xc065169c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 (kgdb) it is: lapi# uname -a FreeBSD lapi.itb.ac.id 6.0-STABLE FreeBSD 6.0-STABLE #0: Tue Jan 3 10:22:22 WIT 2006 dikshie@lapi.itb.ac.id:/usr/obj/usr/src/sys/LAPI i386 regards, -dikshie- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 3 12:41:43 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1603A16A41F; Tue, 3 Jan 2006 12:41:42 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from imap1u.univie.ac.at (murder.univie.ac.at [131.130.1.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 229E343D58; Tue, 3 Jan 2006 12:41:41 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from pcle2.cc.univie.ac.at (pcle2.cc.univie.ac.at [131.130.2.177]) by imap1u.univie.ac.at (8.12.10/8.12.10) with ESMTP id k03CfLTr068625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 13:41:21 +0100 (CET) Date: Tue, 3 Jan 2006 13:41:21 +0100 (CET) From: Lukas Ertl To: Ludo Koren In-Reply-To: <200512221207.jBMC7WfC007322@lk.tempest.sk> Message-ID: <20060103133952.U45962@pcle2.cc.univie.ac.at> References: <8764pi7778.fsf@lk.tempest.sk> <87u0d25fw1.fsf@lk.tempest.sk> <200512221207.jBMC7WfC007322@lk.tempest.sk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: gvinum: adding plex and subdisks to existing volume panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 12:41:43 -0000 On Thu, 22 Dec 2005, Ludo Koren wrote: > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x40 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc07339c9 > stack pointer = 0x10:0xe5f9e840 > frame pointer = 0x10:0xe5f9e848 > 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 = 2 (g_event) > trap number = 12 > panic: page fault > Uptime: 2m32s > Dumping 1022 MB > 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 > > #0 doadump () at pcpu.h:160 > 160 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) add-symbol-file /usr/src/sys/modules/geom/geom_vinum/geom_vinum.ko 0xc072 a9b8 > add symbol table from file "/usr/src/sys/modules/geom/geom_vinum/geom_vinum.ko" at > .text_addr = 0xc072a9b8 > (y or n) y > Reading symbols from /usr/src/sys/modules/geom/geom_vinum/geom_vinum.ko...done. > (kgdb) bt > #0 doadump () at pcpu.h:160 > #1 0xc04eaf44 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:412 > #2 0xc04eb1d8 in panic (fmt=0xc060fcbc "%s") > at /usr/src/sys/kern/kern_shutdown.c:568 > #3 0xc05ec2f0 in trap_fatal (frame=0xe5f9e800, eva=64) > at /usr/src/sys/i386/i386/trap.c:822 > #4 0xc05ec057 in trap_pfault (frame=0xe5f9e800, usermode=0, eva=64) > at /usr/src/sys/i386/i386/trap.c:737 > #5 0xc05ebcb9 in trap (frame= > {tf_fs = -1040646120, tf_es = -1037893616, tf_ds = -1038024688, tf_edi = -1038012416, tf_esi = 0, tf_ebp = -436606904, tf_isp = -436606932, tf_ebx = -1038077952, tf_edx = 1, tf_ecx = -1066995504, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1066190391, tf_cs = 8, tf_eflags = 66182, tf_esp = -1038077952, tf_ss = -1038516864}) at /usr/src/sys/i386/i386/trap.c:427 > #6 0xc05dc52a in calltrap () at /usr/src/sys/i386/i386/exception.s:140 > #7 0xc1f90018 in ?? () > #8 0xc2230010 in ?? () > #9 0xc2210010 in ?? () I'm afraid that doesn't help me, either, as you can see there's no debugging information in there (the "??" question marks should be function calls actually). Apparently there's a NULL pointer deref somewhere, I'll try to track it down on my own. Thanks, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ le@FreeBSD.org http://people.freebsd.org/~le/ From owner-freebsd-stable@FreeBSD.ORG Tue Jan 3 15:28:12 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F15316A41F for ; Tue, 3 Jan 2006 15:28:12 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id B471343D76 for ; Tue, 3 Jan 2006 15:28:09 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eto51-000JYC-LZ; Tue, 03 Jan 2006 15:28:08 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eto50-0002n9-8z; Tue, 03 Jan 2006 05:28:06 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17338.38917.752522.305498@roam.psg.com> Date: Tue, 3 Jan 2006 05:28:05 -1000 To: "Kevin Oberman" References: <20060102170610.8B4AA5D07@ptavv.es.net> Cc: stable@freebsd.org Subject: Re: Where ahve all the sockets gone? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 15:28:12 -0000 > I have connections to several systems and a few daemons listening, both > INET and INET6. Since my last upgrade, I can't see them with netstat. > > Has anyone else seen this? i have had known listeners not showing in 6 and 7 randy From owner-freebsd-stable@FreeBSD.ORG Tue Jan 3 15:54:01 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B52016A428 for ; Tue, 3 Jan 2006 15:54:01 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2000143D97 for ; Tue, 3 Jan 2006 15:53:40 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.1.6] (unknown [192.168.1.6]) by yertle.kcilink.com (Postfix) with ESMTP id 707B4B810 for ; Tue, 3 Jan 2006 10:53:39 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43B71A9B.8040607@jim-liesl.org> References: <43B70858.6060500@forrie.com> <000901c60e5c$0ef2efa0$0100a8c0@macgregor> <20051231231527.GJ810@gir.gshapiro.net> <43B71A9B.8040607@jim-liesl.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Tue, 3 Jan 2006 10:53:38 -0500 To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.746.2) Subject: Re: sendmail_enable="NO" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 15:54:01 -0000 On Dec 31, 2005, at 6:56 PM, security wrote: > And the rc.sendmail(8) under 5.4 stable says that "NONE" is > deprecated and will be removed in a future release. According to > the man page, It says that in 6.0 also, so it will probably be at least until 7.0 that it continues to work. Personally, I think having to set a bazillion variables to turn off sendmail in rc.conf and periodic.conf is just a pain (and probably a wrong design as it totally violates POLA), but at least it is just a cut/paste everytime I set up a new server. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 3 16:47:32 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DE2916A41F; Tue, 3 Jan 2006 16:47:32 +0000 (GMT) (envelope-from lk@tempest.sk) Received: from mailgw.dgrp.sk (mailgw.dgrp.sk [195.28.127.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5071743D45; Tue, 3 Jan 2006 16:47:25 +0000 (GMT) (envelope-from lk@tempest.sk) Received: by mailgw.dgrp.sk (Postfix, from userid 1003) id EEA1934A5A3; Tue, 3 Jan 2006 17:47:20 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mailgw.dgrp.sk X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from webmail.tempest.sk (domino1.tempest.sk [195.28.100.38]) by mailgw.dgrp.sk (Postfix) with ESMTP id E2B0934A5A2; Tue, 3 Jan 2006 17:47:18 +0100 (CET) Received: from lk.tempest.sk ([195.28.109.47]) by webmail.tempest.sk (Lotus Domino Release 6.5.4) with ESMTP id 2006010317471781-11030 ; Tue, 3 Jan 2006 17:47:17 +0100 Received: from lk.tempest.sk (localhost [127.0.0.1]) by lk.tempest.sk (8.13.3/8.12.9) with ESMTP id k03GlCNc070066; Tue, 3 Jan 2006 17:47:12 +0100 (CET) (envelope-from lk@lk.tempest.sk) Received: (from koren@localhost) by lk.tempest.sk (8.13.3/8.13.1/Submit) id k03GlBOR070063; Tue, 3 Jan 2006 17:47:12 +0100 (CET) (envelope-from lk) X-Authentication-Warning: lk.tempest.sk: koren set sender to lk using -f Sender: lk@tempest.sk To: Lukas Ertl References: <8764pi7778.fsf@lk.tempest.sk> <87u0d25fw1.fsf@lk.tempest.sk> <200512221207.jBMC7WfC007322@lk.tempest.sk> <20060103133952.U45962@pcle2.cc.univie.ac.at> From: Ludo Koren Date: 03 Jan 2006 17:47:11 +0100 In-Reply-To: <20060103133952.U45962@pcle2.cc.univie.ac.at> Message-ID: <873bk5p8c0.fsf@lk.tempest.sk> Lines: 16 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on Domino1/DGRP(Release 6.5.4|March 27, 2005) at 03.01.2006 17:47:18, Serialize by Router on Domino1/DGRP(Release 6.5.4|March 27, 2005) at 03.01.2006 17:47:18, Serialize complete at 03.01.2006 17:47:18 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: Re: gvinum: adding plex and subdisks to existing volume panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 16:47:32 -0000 >>>>> Lukas Ertl writes: .... > I'm afraid that doesn't help me, either, as you can see there's > no debugging information in there (the "??" question marks > should be function calls actually). > Apparently there's a NULL pointer deref somewhere, I'll try to > track it down on my own. Is there a way how can I help you (probably the question marks - source is from another module ) or something else ? lk From owner-freebsd-stable@FreeBSD.ORG Tue Jan 3 16:55:54 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6885C16A420 for ; Tue, 3 Jan 2006 16:55:54 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0731543D5A for ; Tue, 3 Jan 2006 16:55:42 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 2E61D20AB; Tue, 3 Jan 2006 17:55:03 +0100 (CET) X-Spam-Tests: AWL,BAYES_00,FORGED_RCVD_HELO X-Spam-Learn: ham X-Spam-Score: -3.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id A6BE320AA; Tue, 3 Jan 2006 17:55:02 +0100 (CET) Received: by xps.des.no (Postfix, from userid 1001) id 88D7033C3E; Tue, 3 Jan 2006 17:55:02 +0100 (CET) To: "Kevin Oberman" References: <20060102170610.8B4AA5D07@ptavv.es.net> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 03 Jan 2006 17:55:02 +0100 In-Reply-To: <20060102170610.8B4AA5D07@ptavv.es.net> (Kevin Oberman's message of "Mon, 02 Jan 2006 09:06:07 -0800") Message-ID: <86u0cli74p.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org Subject: Re: Where ahve all the sockets gone? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 16:55:54 -0000 "Kevin Oberman" writes: > I have connections to several systems and a few daemons listening, both > INET and INET6. Since my last upgrade, I can't see them with netstat. Are you sure your kernel and userland are in synch? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Tue Jan 3 17:24:22 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2392816A420 for ; Tue, 3 Jan 2006 17:24:22 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id B84A143D99 for ; Tue, 3 Jan 2006 17:24:09 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Tue, 03 Jan 2006 09:24:06 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 4B2DC5D09; Tue, 3 Jan 2006 09:24:06 -0800 (PST) To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: Your message of "Tue, 03 Jan 2006 17:55:02 +0100." <86u0cli74p.fsf@xps.des.no> Date: Tue, 03 Jan 2006 09:24:06 -0800 From: "Kevin Oberman" Message-Id: <20060103172406.4B2DC5D09@ptavv.es.net> Cc: stable@freebsd.org Subject: Re: Where ahve all the sockets gone? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 17:24:22 -0000 > From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) > Date: Tue, 03 Jan 2006 17:55:02 +0100 > > "Kevin Oberman" writes: > > I have connections to several systems and a few daemons listening, both > > INET and INET6. Since my last upgrade, I can't see them with netstat. > > Are you sure your kernel and userland are in synch? I would have sworn that my kernel was built from the exact same source tree as my userland, but I just rebuilt the userland and my sockets are back. Is my system CVSup'ing behind my back? ;-) In any case, thanks. It's all better. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 18:37:02 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D73516A41F for ; Mon, 2 Jan 2006 18:37:02 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0B3443D5D for ; Mon, 2 Jan 2006 18:37:00 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Mon, 02 Jan 2006 10:36:54 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 40E225D07; Mon, 2 Jan 2006 10:36:55 -0800 (PST) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: Kris Kennaway In-reply-to: Your message of "Wed, 14 Dec 2005 19:52:03 EST." <20051215005203.GA89670@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_1136226929_197500" Date: Mon, 02 Jan 2006 10:36:55 -0800 From: "Kevin Oberman" Message-Id: <20060102183655.40E225D07@ptavv.es.net> X-Mailman-Approved-At: Tue, 03 Jan 2006 18:13:32 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org Subject: Re: Odd performance problems after upgrade from 4.11 to 6.0-Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 18:37:02 -0000 This is a multipart MIME message. --==_Exmh_1136226929_197500 Content-Type: text/plain; charset=us-ascii > Date: Wed, 14 Dec 2005 19:52:03 -0500 > From: Kris Kennaway > > > --45Z9DzgjV8m4Oswq > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Wed, Dec 14, 2005 at 04:45:47PM -0800, Kevin Oberman wrote: > > > Date: Wed, 14 Dec 2005 19:34:04 -0500 > > > From: Kris Kennaway > > >=20 > > > On Wed, Dec 14, 2005 at 04:26:18PM -0800, Kevin Oberman wrote: > > >=20 > > > > I am attaching a dmesg. I do have a few of drivers (uhci, pcm, psm, > > > > atkbd0 and ichsmb) that are still marked as GIANT-LOCKED, but I'm not > > > > using the USB very often. And I'm not using pcm or ichsmb during the > > > > dump, either. I think everyone has the mouse and keyboard under GIANT, > > > > but I can't really see those as a problem, either. > > >=20 > > > A bunch of things are sharing interrupts with USB..disable it and see > > > if that helps. Also check vmstat -i to see if some device is > > > storming. If not, turn on MUTEX_PROFILING(9) in your kernel and run > > > the dump (or something faster that also exhibits the problem), then > > > look for what is contending with Giant. > >=20 > > Yes, it may be time for MUTEX_PROFILING. I had already looked at > > interrupts. My kernel is sans APIC so I didn't really think that > > interrupts were a problems and I see: > > interrupt total rate > > irq0: clk 207037779 1000 > > irq1: atkbd0 50208 0 > > irq6: fdc0 9 0 > > irq8: rtc 26498038 128 > > irq10: pcm0 ichsmb0 2 0 > > irq11: xl0 uhci0 18076067 87 > > irq12: psm0 869500 4 > > irq13: npx0 1 0 > > irq14: ata0 10423468 50 > > irq15: ata1 112 0 > > Total 262955184 1270 > > > > Clearly no storms and nothing looks obviously broken. USB and the > > network card share an IRQ, but the USB is not connected to anything and > > I would not think that it is generating many interrupts. The network > > IS being used and I'm not seeing all that many interrupts on IRQ11. > > Whenever there is an interrupt on irq11 from the NIC, *both* drivers > will wake up to process it. uhci0 will need to acquire Giant. If > something else is also trying to acquire Giant (bufdaemon), then they > will serialize, degrading performance. This may not be the cause > since there are only a few interrupts, but MUTEX_PROFILING will tell > you. Well, with the holidays and such, this has taken a while, but here is an update. I have removed USB support. I hardly ever use it on this system, so that was an obvious step. No improvement at all. # vmstat -i interrupt total rate irq0: clk 319818027 1000 irq1: atkbd0 15443 0 irq6: fdc0 11 0 irq8: rtc 40932392 128 irq10: pcm0 ichsmb0 125545 0 irq11: xl0 3616426 11 irq12: psm0 281380 0 irq13: npx0 1 0 irq14: ata0 8756176 27 irq15: ata1 144 0 Total 373545545 1168 Only one shared interrupt and both IRQ 10 devices should have been totally quiescent during my test run. The test was building a glimpse index of my inbox. CPU at about 20%. System interactive response was terrible. Took about two minutes just to log in. Starting Gnome takes roughly forever (about 10 minutes). I collected mutex stats for just about 3 minutes and found nothing surprising, but I may not know what to look for. Nothing shows a total time of over 3.1 seconds. The total time for all of them is 28 seconds. The sum of all Giant lock times was only 4.65 seconds and the largest of these was in kern_sysctl.c, so I expect it was the profiling that ate 3.1 of those 4.65 seconds. I am attaching a spreadsheet with the profile data in case anyone wants to look at it. (Probably the mail system will strip it, so let me know if I should post it.) Still totally baffled and still feeling the pain. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 --==_Exmh_1136226929_197500-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 3 19:21:23 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FEEC16A41F for ; Tue, 3 Jan 2006 19:21:23 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E49E743D5D for ; Tue, 3 Jan 2006 19:21:22 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id k03JLLdh001587; Tue, 3 Jan 2006 14:21:21 -0500 (EST) Date: Tue, 3 Jan 2006 14:21:21 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Vivek Khera In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-stable@freebsd.org Subject: Re: sendmail_enable="NO" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 19:21:23 -0000 On Tue, 3 Jan 2006, Vivek Khera wrote: > > On Dec 31, 2005, at 6:56 PM, security wrote: > > > And the rc.sendmail(8) under 5.4 stable says that "NONE" is > > deprecated and will be removed in a future release. According to > > the man page, > > It says that in 6.0 also, so it will probably be at least until 7.0 > that it continues to work. > > Personally, I think having to set a bazillion variables to turn off > sendmail in rc.conf and periodic.conf is just a pain (and probably a Strongly seconded. There should be one knob to disable the entire thing. SENDMAIL_ENABLE=NO should disable *everything* without touching any other knobs. > wrong design as it totally violates POLA), but at least it is just a > cut/paste everytime I set up a new server. -- DE From owner-freebsd-stable@FreeBSD.ORG Tue Jan 3 19:42:39 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C056B16A41F for ; Tue, 3 Jan 2006 19:42:39 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 53BF043D53 for ; Tue, 3 Jan 2006 19:42:38 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 44826 invoked by uid 399); 3 Jan 2006 19:42:37 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 3 Jan 2006 19:42:37 -0000 Message-ID: <43BAD3AB.302@FreeBSD.org> Date: Tue, 03 Jan 2006 11:42:35 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20051206) MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Vivek Khera , freebsd-stable@freebsd.org Subject: Re: sendmail_enable="NO" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 19:42:39 -0000 Daniel Eischen wrote: > On Tue, 3 Jan 2006, Vivek Khera wrote: > >> On Dec 31, 2005, at 6:56 PM, security wrote: >> >>> And the rc.sendmail(8) under 5.4 stable says that "NONE" is >>> deprecated and will be removed in a future release. According to >>> the man page, >> It says that in 6.0 also, so it will probably be at least until 7.0 >> that it continues to work. >> >> Personally, I think having to set a bazillion variables to turn off >> sendmail in rc.conf and periodic.conf is just a pain (and probably a > > Strongly seconded. There should be one knob to disable the > entire thing. SENDMAIL_ENABLE=NO should disable *everything* > without touching any other knobs. First, rc.conf and periodic.conf are totally separate, so having just one knob for both isn't practical now, but might be an interesting project down the road. Second, IIRC the first implementation of sendmail_enable=no did actually disable all of sendmail, but since people could not send mail locally that turned out to be a POLA violation itself, so the current two-stage system was developed. It's impossible to make everyone happy here, so I think the current system is a reasonable compromise. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Tue Jan 3 19:46:32 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E74116A41F; Tue, 3 Jan 2006 19:46:32 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3632D43D64; Tue, 3 Jan 2006 19:46:30 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id k03JkUKi003034; Tue, 3 Jan 2006 14:46:30 -0500 (EST) Date: Tue, 3 Jan 2006 14:46:29 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Doug Barton In-Reply-To: <43BAD3AB.302@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Vivek Khera , freebsd-stable@freebsd.org Subject: Re: sendmail_enable="NO" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 19:46:32 -0000 On Tue, 3 Jan 2006, Doug Barton wrote: > First, rc.conf and periodic.conf are totally separate, so having just one > knob for both isn't practical now, but might be an interesting project down > the road. Second, IIRC the first implementation of sendmail_enable=no did > actually disable all of sendmail, but since people could not send mail > locally that turned out to be a POLA violation itself, so the current > two-stage system was developed. It's impossible to make everyone happy here, > so I think the current system is a reasonable compromise. No, you can still have *one* overriding knob to turn off everything. If folks want to enable/disable different parts of sendmail, they can do that with the other knobs. POLA says the one overriding sendmail knob should be sendmail_enable. -- DE From owner-freebsd-stable@FreeBSD.ORG Tue Jan 3 19:54:13 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07CE516A41F for ; Tue, 3 Jan 2006 19:54:13 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 1487543D4C for ; Tue, 3 Jan 2006 19:54:11 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 54248 invoked by uid 399); 3 Jan 2006 19:54:11 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 3 Jan 2006 19:54:11 -0000 Message-ID: <43BAD660.5050900@FreeBSD.org> Date: Tue, 03 Jan 2006 11:54:08 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20051206) MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Vivek Khera , freebsd-stable@freebsd.org Subject: Re: sendmail_enable="NO" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 19:54:13 -0000 Daniel Eischen wrote: > On Tue, 3 Jan 2006, Doug Barton wrote: > >> First, rc.conf and periodic.conf are totally separate, so having just one >> knob for both isn't practical now, but might be an interesting project down >> the road. Second, IIRC the first implementation of sendmail_enable=no did >> actually disable all of sendmail, but since people could not send mail >> locally that turned out to be a POLA violation itself, so the current >> two-stage system was developed. It's impossible to make everyone happy here, >> so I think the current system is a reasonable compromise. > > No, you can still have *one* overriding knob to turn off > everything. If folks want to enable/disable different > parts of sendmail, they can do that with the other knobs. > POLA says the one overriding sendmail knob should be > sendmail_enable. Well, I certainly understand your perspective, although I'm not sure I agree. Feel free to create a patch that does what you want it to do, and send it to freebsd-rc@ and gshapiro@ for review, and we'll see what others have to say about it. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Tue Jan 3 20:03:42 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E954216A426; Tue, 3 Jan 2006 20:03:42 +0000 (GMT) (envelope-from gcr+freebsd-stable@tharned.org) Received: from nc8000.tharned.org (rrcs-24-56-87-26.ma.biz.rr.com [24.56.87.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14FD343D77; Tue, 3 Jan 2006 20:03:30 +0000 (GMT) (envelope-from gcr+freebsd-stable@tharned.org) Received: from nc8000.tharned.org (gcr@localhost [127.0.0.1]) by nc8000.tharned.org (8.13.4/8.13.4) with ESMTP id k03K3Gqs024376; Tue, 3 Jan 2006 14:03:16 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) Received: from localhost (gcr@localhost) by nc8000.tharned.org (8.13.4/8.13.4/Submit) with ESMTP id k03K36PU024373; Tue, 3 Jan 2006 14:03:06 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) Date: Tue, 3 Jan 2006 14:03:06 -0600 (CST) From: Greg Rivers Sender: gcr@tharned.org To: freebsd-stable@freebsd.org In-Reply-To: <20051122211507.P32523@nc8000.tharned.org> Message-ID: <20060103135624.A798@nc8000.tharned.org> References: <20051121164139.T48994@w10.sac.fedex.com> <20051122021224.GA12402@xor.obsecurity.org> <20051121205535.W32523@nc8000.tharned.org> <20051122043952.GA14168@xor.obsecurity.org> <20051122211507.P32523@nc8000.tharned.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Don Lewis , Kirk McKusick , Kris Kennaway Subject: Re: Recurring problem: processes block accessing UFS file system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 20:03:43 -0000 On Tue, 22 Nov 2005, I wrote: > On Mon, 21 Nov 2005, Kris Kennaway wrote: > >> It may not be the same problem. You should also try to obtain a trace when >> snapshots are not implicated. >> > > Agreed. I'll do so at the first opportunity. > First, my thanks to all of you for looking into this. It's taken more than a month, but the problem has recurred without snapshots ever having been run. I've got a good trace of the machine in this state (ftp://ftp.fedex.com/incoming/no-snapshots.bz2). My apologies for the size of the debug output, but the processes had really stacked up this time before I noticed it. I have enough capacity that I can afford to have this machine out of production for a while, so I've left it suspended in kdb for the time being in case additional information is needed. Please let me know if there's anything else I can do to facilitate troubleshooting this. Thanks! -- Greg From owner-freebsd-stable@FreeBSD.ORG Tue Jan 3 20:15:19 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FB4C16A41F for ; Tue, 3 Jan 2006 20:15:19 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DE0743D55 for ; Tue, 3 Jan 2006 20:15:15 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EtsYW-0007u1-JR for freebsd-stable@freebsd.org; Tue, 03 Jan 2006 21:14:54 +0100 Received: from efficio.wh29.tu-dresden.de ([141.30.207.25]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Jan 2006 21:14:52 +0100 Received: from der_julian by efficio.wh29.tu-dresden.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Jan 2006 21:14:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Julian Stecklina Date: Tue, 03 Jan 2006 21:14:28 +0100 Lines: 28 Message-ID: <86hd8l3w7v.fsf@dellbeast.localnet> References: <86acenia3h.fsf@dellbeast.localnet> <200512272222.18357.patfbsds@davenulle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: efficio.wh29.tu-dresden.de User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.5-b24 (dandelion, berkeley-unix) Cancel-Lock: sha1:h/Bvv6c5O5UwQsE9nTEXjjnWdAA= Sender: news Subject: Re: Problem with new DRI/DRM support for Intel 855GM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 20:15:19 -0000 Patrick Lamaizière writes: > Le Mardi 27 Décembre 2005 02:48, Julian Stecklina a écrit : > > Hello, > >> I just discovered that the DRM drivers have been updated and my 855GM >> is now supported by i915.ko. >> >> If I load the module, the driver attaches: > ... >> The problem is easily spotted, as there is only /dev/dri/card1. If I >> try to symlink card1 to card0, the kernel says: >> error: [drm:pid890:drm_unlock] *ERROR* Process 890 using kernel context 0 > > Look this thread : > http://lists.freebsd.org/pipermail/freebsd-stable/2005-December/020815.html It seems the PR is unrelated to my problem. Or do I miss something? At least no DRM/DRI problems are reported. I'll try -CURRENT one day or the other. Regards, -- Julian Stecklina When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop. - Alan Perlis From owner-freebsd-stable@FreeBSD.ORG Tue Jan 3 21:28:27 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39BFB16A41F for ; Tue, 3 Jan 2006 21:28:27 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D082D43D68 for ; Tue, 3 Jan 2006 21:28:25 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id k03LS2Il007744; Tue, 3 Jan 2006 13:28:06 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200601032128.k03LS2Il007744@gw.catspoiler.org> Date: Tue, 3 Jan 2006 13:28:02 -0800 (PST) From: Don Lewis To: gcr+freebsd-stable@tharned.org In-Reply-To: <20060103120454.O798@nc8000.tharned.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd@McKusick.COM, freebsd-stable@FreeBSD.org, kris@obsecurity.org Subject: Re: Recurring problem: processes block accessing UFS file system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 21:28:27 -0000 On 3 Jan, Greg Rivers wrote: > On Tue, 22 Nov 2005, I wrote: > >> On Mon, 21 Nov 2005, Kris Kennaway wrote: >> >>> It may not be the same problem. You should also try to obtain a trace when >>> snapshots are not implicated. >>> >> >> Agreed. I'll do so at the first opportunity. >> > > First, my thanks to all of you for looking into this. > > It's taken more than a month, but the problem has recurred without > snapshots ever having been run. I've got a good trace of the machine in > this state (attached). My apologies for the size of the debug output, but > the processes had really stacked up this time before I noticed it. > > I have enough capacity that I can afford to have this machine out of > production for a while, so I've left it suspended in kdb for the time > being in case additional information is needed. Please let me know if > there's anything else I can do to facilitate troubleshooting this. > Thanks! There are large number of sendmail processes waiting on vnode locks which are held by other sendmail processes that are waiting on other vnode locks, etc. until we get to sendmail pid 87150 which is holding a vnode lock and waiting to lock a buf. Tracing command sendmail pid 87150 tid 100994 td 0xcf1c5480 sched_switch(cf1c5480,0,1,b2c5195e,a480a2bc) at sched_switch+0x158 mi_switch(1,0,c04d7b33,dc713fb0,ec26a6ac) at mi_switch+0x1d5 sleepq_switch(dc713fb0,ec26a6e0,c04bb9ce,dc713fb0,50) at sleepq_switch+0x16f sleepq_wait(dc713fb0,50,c0618ef5,0,202122) at sleepq_wait+0x11 msleep(dc713fb0,c0658430,50,c0618ef5,0) at msleep+0x3d7 acquire(ec26a748,120,60000,15c2e6e0,0) at acquire+0x89 lockmgr(dc713fb0,202122,c89855cc,cf1c5480,dc76fe30) at lockmgr+0x45f getblk(c8985550,15c2e6e0,0,4000,0) at getblk+0x211 breadn(c8985550,15c2e6e0,0,4000,0) at breadn+0x52 bread(c8985550,15c2e6e0,0,4000,0) at bread+0x4c ffs_vget(c8870000,ae58b3,2,ec26a8d4,8180) at ffs_vget+0x383 ffs_valloc(c8d41660,8180,c92e8d00,ec26a8d4,c05f9302) at ffs_valloc+0x154 ufs_makeinode(8180,c8d41660,ec26abd4,ec26abe8,ec26aa24) at ufs_makeinode+0x61 ufs_create(ec26aa50,ec26aa24,ec26ad04,ec26abc0,ec26ab0c) at ufs_create+0x36 VOP_CREATE_APV(c0646cc0,ec26aa50,2,ec26aa50,0) at VOP_CREATE_APV+0x3c vn_open_cred(ec26abc0,ec26acc0,180,c92e8d00,6) at vn_open_cred+0x1fe vn_open(ec26abc0,ec26acc0,180,6,c679eacb) at vn_open+0x33 kern_open(cf1c5480,81416c0,0,a03,180) at kern_open+0xca open(cf1c5480,ec26ad04,c,cf1c5480,8169000) at open+0x36 syscall(3b,bfbf003b,bfbf003b,0,a02) at syscall+0x324 Xint0x80_syscall() at Xint0x80_syscall+0x1f This doesn't appear to be a buf/memory exhausting problem because syncer, bufdaemon, and pagedaemon all appear to be idle. What does "show lockedbufs" say? From owner-freebsd-stable@FreeBSD.ORG Tue Jan 3 23:41:57 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C9C316A420 for ; Tue, 3 Jan 2006 23:41:57 +0000 (GMT) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0907C43D53 for ; Tue, 3 Jan 2006 23:41:56 +0000 (GMT) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0ISJ00F6JJE3AGE0@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 04 Jan 2006 00:46:51 +0100 (CET) Received: from kg-work.kg4.no ([80.203.92.30]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0ISJ00JOKJAAE530@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 04 Jan 2006 00:44:34 +0100 (CET) Date: Wed, 04 Jan 2006 00:41:55 +0100 From: Torfinn Ingolfsen X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH In-reply-to: <200512081301.37861.joao@matik.com.br> To: freebsd-stable@freebsd.org Message-id: <20060104004155.1509e915.torfinn.ingolfsen@broadpark.no> MIME-version: 1.0 X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <120720050703.13264.43968936000DCA87000033D0220076106404040A9C9C9A9D9902080106@comcast.net> <20051207092948.GB9312@kierun.org> <20051207222230.6691634e.torfinn.ingolfsen@broadpark.no> <200512081301.37861.joao@matik.com.br> Subject: Re: some more on Re: Adventurous fix for wheel mouse not working in FreeBSD 6.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2006 23:41:57 -0000 On Thu, 08 Dec 2005 13:01:36 -0200 JoaoBR wrote: > I found out this for releng_6 and appearently is the same on former > versions since all call the same problem: Interesting enough, today I stubled over a much easier solution than those discussed earlier in this thread. I simply removed 'moused_flags="-z4"' from /etc/rc.conf, and restarted moused and Xorg. Now (wheel) scroll works again! Details: root@kg-quiet# uname -a FreeBSD kg-quiet.kg4.no 6.0-STABLE FreeBSD 6.0-STABLE #1: Thu Dec 22 06:29:24 CET 2005 root@kg-quiet.kg4.no:/usr/obj/usr/src/sys/QUIET amd64 root@kg-quiet# ps ax | grep moused 10104 ?? Is 0:00.04 /usr/sbin/moused -p /dev/psm0 -t auto root@kg-quiet# portversion -v | grep xorg-server xorg-server-6.8.99.903 = up-to-date with port I will have to test this on my laptop (6.0-stable / i386) sometime soon. -- Regards, Torfinn Ingolfsen, Norway From owner-freebsd-stable@FreeBSD.ORG Wed Jan 4 00:36:36 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3920516A41F; Wed, 4 Jan 2006 00:36:36 +0000 (GMT) (envelope-from gcr+freebsd-stable@tharned.org) Received: from nc8000.tharned.org (rrcs-24-56-87-26.ma.biz.rr.com [24.56.87.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA0D243D49; Wed, 4 Jan 2006 00:36:34 +0000 (GMT) (envelope-from gcr+freebsd-stable@tharned.org) Received: from nc8000.tharned.org (gcr@localhost [127.0.0.1]) by nc8000.tharned.org (8.13.4/8.13.4) with ESMTP id k040aU1B025066; Tue, 3 Jan 2006 18:36:30 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) Received: from localhost (gcr@localhost) by nc8000.tharned.org (8.13.4/8.13.4/Submit) with ESMTP id k040aTuu025063; Tue, 3 Jan 2006 18:36:29 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) Date: Tue, 3 Jan 2006 18:36:29 -0600 (CST) From: Greg Rivers Sender: gcr@tharned.org To: Don Lewis In-Reply-To: <200601032128.k03LS2Il007744@gw.catspoiler.org> Message-ID: <20060103182349.X798@nc8000.tharned.org> References: <200601032128.k03LS2Il007744@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@FreeBSD.org, Kirk McKusick , Kris Kennaway Subject: Re: Recurring problem: processes block accessing UFS file system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2006 00:36:36 -0000 On Tue, 3 Jan 2006, Don Lewis wrote: > There are large number of sendmail processes waiting on vnode locks > which are held by other sendmail processes that are waiting on other > vnode locks, etc. until we get to sendmail pid 87150 which is holding a > vnode lock and waiting to lock a buf. > > Tracing command sendmail pid 87150 tid 100994 td 0xcf1c5480 > sched_switch(cf1c5480,0,1,b2c5195e,a480a2bc) at sched_switch+0x158 > mi_switch(1,0,c04d7b33,dc713fb0,ec26a6ac) at mi_switch+0x1d5 > sleepq_switch(dc713fb0,ec26a6e0,c04bb9ce,dc713fb0,50) at sleepq_switch+0x16f > sleepq_wait(dc713fb0,50,c0618ef5,0,202122) at sleepq_wait+0x11 > msleep(dc713fb0,c0658430,50,c0618ef5,0) at msleep+0x3d7 > acquire(ec26a748,120,60000,15c2e6e0,0) at acquire+0x89 > lockmgr(dc713fb0,202122,c89855cc,cf1c5480,dc76fe30) at lockmgr+0x45f > getblk(c8985550,15c2e6e0,0,4000,0) at getblk+0x211 > breadn(c8985550,15c2e6e0,0,4000,0) at breadn+0x52 > bread(c8985550,15c2e6e0,0,4000,0) at bread+0x4c > ffs_vget(c8870000,ae58b3,2,ec26a8d4,8180) at ffs_vget+0x383 > ffs_valloc(c8d41660,8180,c92e8d00,ec26a8d4,c05f9302) at ffs_valloc+0x154 > ufs_makeinode(8180,c8d41660,ec26abd4,ec26abe8,ec26aa24) at ufs_makeinode+0x61 > ufs_create(ec26aa50,ec26aa24,ec26ad04,ec26abc0,ec26ab0c) at ufs_create+0x36 > VOP_CREATE_APV(c0646cc0,ec26aa50,2,ec26aa50,0) at VOP_CREATE_APV+0x3c > vn_open_cred(ec26abc0,ec26acc0,180,c92e8d00,6) at vn_open_cred+0x1fe > vn_open(ec26abc0,ec26acc0,180,6,c679eacb) at vn_open+0x33 > kern_open(cf1c5480,81416c0,0,a03,180) at kern_open+0xca > open(cf1c5480,ec26ad04,c,cf1c5480,8169000) at open+0x36 > syscall(3b,bfbf003b,bfbf003b,0,a02) at syscall+0x324 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > This doesn't appear to be a buf/memory exhausting problem because > syncer, bufdaemon, and pagedaemon all appear to be idle. > > What does "show lockedbufs" say? > db> show lockedbufs buf at 0xdc625678 b_flags = 0x20000000 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc8985610), b_data = 0xddcef000, b_blkno = 365233216 lockstatus = 2, excl count = 1, excl owner 0xfffffffe b_npages = 4, pages(OBJ, IDX, PA): (0xc8984108, 0x2b8a088, 0x53175000),(0xc8984108, 0x2b8a089, 0x7ae56000),(0xc8984108, 0x2b8a08a, 0xd3f57000),(0xc8984108, 0x2b8a08b, 0xd7d58000) buf at 0xdc6b8ab0 b_flags = 0x20000000 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc8985610), b_data = 0xdf9ab000, b_blkno = 365257760 lockstatus = 2, excl count = 1, excl owner 0xfffffffe b_npages = 4, pages(OBJ, IDX, PA): (0xc8984108, 0x2b8ac84, 0x60b1000),(0xc8984108, 0x2b8ac85, 0x454d2000),(0xc8984108, 0x2b8ac86, 0x1b273000),(0xc8984108, 0x2b8ac87, 0x47b74000) buf at 0xdc6c3cc8 b_flags = 0x20000000 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc8985610), b_data = 0xdfbd7000, b_blkno = 365265888 lockstatus = 2, excl count = 1, excl owner 0xfffffffe b_npages = 4, pages(OBJ, IDX, PA): (0xc8984108, 0x2b8b07c, 0xba549000),(0xc8984108, 0x2b8b07d, 0x92eaa000),(0xc8984108, 0x2b8b07e, 0xbdf4b000),(0xc8984108, 0x2b8b07f, 0x2090c000) buf at 0xdc6d9e68 b_flags = 0x20000000 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc8985610), b_data = 0xe0027000, b_blkno = 365240832 lockstatus = 2, excl count = 1, excl owner 0xfffffffe b_npages = 4, pages(OBJ, IDX, PA): (0xc8984108, 0x2b8a440, 0x61b8d000),(0xc8984108, 0x2b8a441, 0xb0f4e000),(0xc8984108, 0x2b8a442, 0x5f98f000),(0xc8984108, 0x2b8a443, 0x5c210000) buf at 0xdc6e5458 b_flags = 0x20000000 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc8985610), b_data = 0xe025f000, b_blkno = 364617056 lockstatus = 2, excl count = 1, excl owner 0xfffffffe b_npages = 4, pages(OBJ, IDX, PA): (0xc8984108, 0x2b773ac, 0x4e539000),(0xc8984108, 0x2b773ad, 0x6e13a000),(0xc8984108, 0x2b773ae, 0xc653b000),(0xc8984108, 0x2b773af, 0x14e3c000) buf at 0xdc6fd4b8 b_flags = 0x20000000 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc8985610), b_data = 0xe070f000, b_blkno = 365224960 lockstatus = 2, excl count = 1, excl owner 0xfffffffe b_npages = 4, pages(OBJ, IDX, PA): (0xc8984108, 0x2b89c80, 0x37c6d000),(0xc8984108, 0x2b89c81, 0x2e40e000),(0xc8984108, 0x2b89c82, 0xa39af000),(0xc8984108, 0x2b89c83, 0x27ff0000) buf at 0xdc713f50 b_flags = 0xa00200a0 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc8985610), b_data = 0xe0b7b000, b_blkno = 365094624 lockstatus = 2, excl count = 1, excl owner 0xcfeb5d80 b_npages = 4, pages(OBJ, IDX, PA): (0xc8984108, 0x2b85cdc, 0xa89e9000),(0xc8984108, 0x2b85cdd, 0xa852a000),(0xc8984108, 0x2b85cde, 0xa850b000),(0xc8984108, 0x2b85cdf, 0xa836c000) buf at 0xdc765f50 b_flags = 0xa00200a0 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc9c68b60), b_data = 0xe1b7b000, b_blkno = 364555424 lockstatus = 2, excl count = 1, excl owner 0xce9d4c00 b_npages = 4, pages(OBJ, IDX, PA): (0xcff70000, 0xffffffd0, 0xafa36000),(0xcff70000, 0xffffffd1, 0x6bcd7000),(0xcff70000, 0xffffffd2, 0x970d8000),(0xcff70000, 0xffffffd3, 0x89959000) buf at 0xdc7ae590 b_flags = 0x20000000 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc8985610), b_data = 0xe299b000, b_blkno = 364555424 lockstatus = 2, excl count = 1, excl owner 0xfffffffe b_npages = 4, pages(OBJ, IDX, PA): (0xc8984108, 0x2b75594, 0xd5081000),(0xc8984108, 0x2b75595, 0xa6722000),(0xc8984108, 0x2b75596, 0x402e3000),(0xc8984108, 0x2b75597, 0xb1d04000) buf at 0xdc7d7590 b_flags = 0x20000000 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc8985610), b_data = 0xe319b000, b_blkno = 364607808 lockstatus = 2, excl count = 1, excl owner 0xfffffffe b_npages = 4, pages(OBJ, IDX, PA): (0xc8984108, 0x2b76f28, 0x387d5000),(0xc8984108, 0x2b76f29, 0x28896000),(0xc8984108, 0x2b76f2a, 0x40d17000),(0xc8984108, 0x2b76f2b, 0x27d98000) db> From owner-freebsd-stable@FreeBSD.ORG Wed Jan 4 01:56:23 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DC0A16A420 for ; Wed, 4 Jan 2006 01:56:23 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FC8743D5E for ; Wed, 4 Jan 2006 01:56:22 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id k041u5Z9008271; Tue, 3 Jan 2006 17:56:09 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200601040156.k041u5Z9008271@gw.catspoiler.org> Date: Tue, 3 Jan 2006 17:56:05 -0800 (PST) From: Don Lewis To: gcr+freebsd-stable@tharned.org In-Reply-To: <20060103182349.X798@nc8000.tharned.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org, freebsd@McKusick.COM, kris@obsecurity.org Subject: Re: Recurring problem: processes block accessing UFS file system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2006 01:56:23 -0000 On 3 Jan, Greg Rivers wrote: > On Tue, 3 Jan 2006, Don Lewis wrote: > >> There are large number of sendmail processes waiting on vnode locks >> which are held by other sendmail processes that are waiting on other >> vnode locks, etc. until we get to sendmail pid 87150 which is holding a >> vnode lock and waiting to lock a buf. >> >> Tracing command sendmail pid 87150 tid 100994 td 0xcf1c5480 >> sched_switch(cf1c5480,0,1,b2c5195e,a480a2bc) at sched_switch+0x158 >> mi_switch(1,0,c04d7b33,dc713fb0,ec26a6ac) at mi_switch+0x1d5 >> sleepq_switch(dc713fb0,ec26a6e0,c04bb9ce,dc713fb0,50) at sleepq_switch+0x16f >> sleepq_wait(dc713fb0,50,c0618ef5,0,202122) at sleepq_wait+0x11 >> msleep(dc713fb0,c0658430,50,c0618ef5,0) at msleep+0x3d7 >> acquire(ec26a748,120,60000,15c2e6e0,0) at acquire+0x89 >> lockmgr(dc713fb0,202122,c89855cc,cf1c5480,dc76fe30) at lockmgr+0x45f >> getblk(c8985550,15c2e6e0,0,4000,0) at getblk+0x211 >> breadn(c8985550,15c2e6e0,0,4000,0) at breadn+0x52 >> bread(c8985550,15c2e6e0,0,4000,0) at bread+0x4c >> ffs_vget(c8870000,ae58b3,2,ec26a8d4,8180) at ffs_vget+0x383 >> ffs_valloc(c8d41660,8180,c92e8d00,ec26a8d4,c05f9302) at ffs_valloc+0x154 >> ufs_makeinode(8180,c8d41660,ec26abd4,ec26abe8,ec26aa24) at ufs_makeinode+0x61 >> ufs_create(ec26aa50,ec26aa24,ec26ad04,ec26abc0,ec26ab0c) at ufs_create+0x36 >> VOP_CREATE_APV(c0646cc0,ec26aa50,2,ec26aa50,0) at VOP_CREATE_APV+0x3c >> vn_open_cred(ec26abc0,ec26acc0,180,c92e8d00,6) at vn_open_cred+0x1fe >> vn_open(ec26abc0,ec26acc0,180,6,c679eacb) at vn_open+0x33 >> kern_open(cf1c5480,81416c0,0,a03,180) at kern_open+0xca >> open(cf1c5480,ec26ad04,c,cf1c5480,8169000) at open+0x36 >> syscall(3b,bfbf003b,bfbf003b,0,a02) at syscall+0x324 >> Xint0x80_syscall() at Xint0x80_syscall+0x1f >> >> This doesn't appear to be a buf/memory exhausting problem because >> syncer, bufdaemon, and pagedaemon all appear to be idle. >> >> What does "show lockedbufs" say? >> > > db> show lockedbufs [snip] looks like this is the buf that pid 87150 is waiting for: > buf at 0xdc713f50 > b_flags = 0xa00200a0 > b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 > b_bufobj = (0xc8985610), b_data = 0xe0b7b000, b_blkno = 365094624 > lockstatus = 2, excl count = 1, excl owner 0xcfeb5d80 > b_npages = 4, pages(OBJ, IDX, PA): (0xc8984108, 0x2b85cdc, 0xa89e9000),(0xc8984108, 0x2b85cdd, 0xa852a000),(0xc8984108, 0x2b85cde, 0xa850b000),(0xc8984108, 0x2b85cdf, 0xa836c000) which is locked by this thread: Tracing command sendmail pid 87117 tid 101335 td 0xcfeb5d80 sched_switch(cfeb5d80,0,1,fd1926a,640c65f9) at sched_switch+0x158 mi_switch(1,0,c04d7b33,dc76fe8c,ec883b2c) at mi_switch+0x1d5 sleepq_switch(dc76fe8c,ec883b60,c04bb9ce,dc76fe8c,4c) at sleepq_switch+0x16f sleepq_wait(dc76fe8c,4c,c061e9ac,0,0) at sleepq_wait+0x11 msleep(dc76fe8c,c0662f80,4c,c061e9ac,0) at msleep+0x3d7 getdirtybuf(dc76fe30,c0662f80,1,ec883ba8,0) at getdirtybuf+0x221 softdep_update_inodeblock(cd1bc528,dc713f50,1,4000,0) at softdep_update_inodeblo ck+0x267 ffs_update(cd953bb0,1,0,cd953bb0,ec883c78,c0529a59,0,0,0,4,1,cd953c2c) at ffs_up date+0x27f ffs_syncvnode(cd953bb0,1,4,ec883c78,c05f9a70) at ffs_syncvnode+0x52e ffs_fsync(ec883cb4,ec883cd0,c052468a,c0646cc0,ec883cb4) at ffs_fsync+0x1c VOP_FSYNC_APV(c0646cc0,ec883cb4,0,0,0) at VOP_FSYNC_APV+0x3a fsync(cfeb5d80,ec883d04,4,cfeb5d80,ec883d2c) at fsync+0x1db syscall(3b,3b,3b,80c7c1b,bfbfa6b0) at syscall+0x324 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (95, FreeBSD ELF32, fsync), eip = 0x8830f63f, esp = 0xbfbfa66c, ebp = 0xbfbfaf98 --- Pid 87117 is playing with buf 0xdc76fe30 which is not locked, and is sleeping on the buf's b_xflags member. It looks like 87117 is waiting for an in-progress write to complete. There are a large number of other sendmail processes waiting in this same place. How about "show buffer 0xdc76fe30"? This is getting into an area of the kernel that I do not understand well. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 4 02:09:49 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CB1516A41F; Wed, 4 Jan 2006 02:09:49 +0000 (GMT) (envelope-from gcr+freebsd-stable@tharned.org) Received: from nc8000.tharned.org (rrcs-24-56-87-26.ma.biz.rr.com [24.56.87.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6EEE43D49; Wed, 4 Jan 2006 02:09:48 +0000 (GMT) (envelope-from gcr+freebsd-stable@tharned.org) Received: from nc8000.tharned.org (gcr@localhost [127.0.0.1]) by nc8000.tharned.org (8.13.4/8.13.4) with ESMTP id k0429ibK025289; Tue, 3 Jan 2006 20:09:44 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) Received: from localhost (gcr@localhost) by nc8000.tharned.org (8.13.4/8.13.4/Submit) with ESMTP id k0429iRV025286; Tue, 3 Jan 2006 20:09:44 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) Date: Tue, 3 Jan 2006 20:09:44 -0600 (CST) From: Greg Rivers Sender: gcr@tharned.org To: Don Lewis In-Reply-To: <200601040156.k041u5Z9008271@gw.catspoiler.org> Message-ID: <20060103195956.L798@nc8000.tharned.org> References: <200601040156.k041u5Z9008271@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@FreeBSD.org, Kirk McKusick , Kris Kennaway Subject: Re: Recurring problem: processes block accessing UFS file system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2006 02:09:49 -0000 On Tue, 3 Jan 2006, Don Lewis wrote: >> db> show lockedbufs > > [snip] > > looks like this is the buf that pid 87150 is waiting for: > >> buf at 0xdc713f50 >> b_flags = 0xa00200a0 >> b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 >> b_bufobj = (0xc8985610), b_data = 0xe0b7b000, b_blkno = 365094624 >> lockstatus = 2, excl count = 1, excl owner 0xcfeb5d80 >> b_npages = 4, pages(OBJ, IDX, PA): (0xc8984108, 0x2b85cdc, 0xa89e9000),(0xc8984108, 0x2b85cdd, 0xa852a000),(0xc8984108, 0x2b85cde, 0xa850b000),(0xc8984108, 0x2b85cdf, 0xa836c000) > > which is locked by this thread: > > Tracing command sendmail pid 87117 tid 101335 td 0xcfeb5d80 > sched_switch(cfeb5d80,0,1,fd1926a,640c65f9) at sched_switch+0x158 > mi_switch(1,0,c04d7b33,dc76fe8c,ec883b2c) at mi_switch+0x1d5 > sleepq_switch(dc76fe8c,ec883b60,c04bb9ce,dc76fe8c,4c) at sleepq_switch+0x16f > sleepq_wait(dc76fe8c,4c,c061e9ac,0,0) at sleepq_wait+0x11 > msleep(dc76fe8c,c0662f80,4c,c061e9ac,0) at msleep+0x3d7 > getdirtybuf(dc76fe30,c0662f80,1,ec883ba8,0) at getdirtybuf+0x221 > softdep_update_inodeblock(cd1bc528,dc713f50,1,4000,0) at softdep_update_inodeblo > ck+0x267 > ffs_update(cd953bb0,1,0,cd953bb0,ec883c78,c0529a59,0,0,0,4,1,cd953c2c) at ffs_up > date+0x27f > ffs_syncvnode(cd953bb0,1,4,ec883c78,c05f9a70) at ffs_syncvnode+0x52e > ffs_fsync(ec883cb4,ec883cd0,c052468a,c0646cc0,ec883cb4) at ffs_fsync+0x1c > VOP_FSYNC_APV(c0646cc0,ec883cb4,0,0,0) at VOP_FSYNC_APV+0x3a > fsync(cfeb5d80,ec883d04,4,cfeb5d80,ec883d2c) at fsync+0x1db > syscall(3b,3b,3b,80c7c1b,bfbfa6b0) at syscall+0x324 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (95, FreeBSD ELF32, fsync), eip = 0x8830f63f, esp = 0xbfbfa66c, ebp > = 0xbfbfaf98 --- > > > Pid 87117 is playing with buf 0xdc76fe30 which is not locked, and is > sleeping on the buf's b_xflags member. It looks like 87117 is waiting > for an in-progress write to complete. There are a large number of other > sendmail processes waiting in this same place. > > How about "show buffer 0xdc76fe30"? > db> show buffer 0xdc76fe30 buf at 0xdc76fe30 b_flags = 0x200000a0 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc8985610), b_data = 0xe1d6b000, b_blkno = 365086368 lockstatus = 0, excl count = 0, excl owner 0xffffffff b_npages = 4, pages(OBJ, IDX, PA): (0xc8984108, 0x2b858d4, 0xa8de1000),(0xc8984108, 0x2b858d5, 0xa8c62000),(0xc8984108, 0x2b858d6, 0xa8de3000),(0xc8984108, 0x2b858d7, 0xa8e64000) db> > This is getting into an area of the kernel that I do not understand > well. > For me, we've long since passed that point. :-) -- Greg From owner-freebsd-stable@FreeBSD.ORG Wed Jan 4 09:34:32 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1B0C16A41F for ; Wed, 4 Jan 2006 09:34:32 +0000 (GMT) (envelope-from adler@smtp.ru) Received: from smtp1.pochta.ru (smtp1.pochta.ru [81.211.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED97E43D58 for ; Wed, 4 Jan 2006 09:34:31 +0000 (GMT) (envelope-from adler@smtp.ru) Received: from host-212-0-194-161.mtc.md (host-212-0-194-161.mtc.md [212.0.194.161]) (author=adler@smtp.ru authenticated bits=0) by smtp1.pochta.ru (8.13.1/8.13.1) with ESMTP daemon=POCHTA.RU id k049YObW028851 for ; Wed, 4 Jan 2006 12:34:26 +0300 (MSK) (envelope-from adler@smtp.ru) X-Author: adler@smtp.ru from host-212-0-194-161.mtc.md (host-212-0-194-161.mtc.md [212.0.194.161]) via Free Mail POCHTA.RU Date: Wed, 4 Jan 2006 11:34:21 +0300 From: Alexey Sopov X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <31615625.20060104113421@smtp.ru> To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: 5.4 freezes randomly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: adler List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2006 09:34:32 -0000 I have installed a FreeBSD 5.4-RELEASE router, with mpd4 (for pptp clients) and with ng_netflow for traffic collecting, the machine also performs NAT be means of pfnat. But my machine occasionally freezes. It does not respond to echo requests over ethernet and it even does not respond to keyboard. I have connected this machine with another one via serial cable and when it hang, I've entered debugger (see below). I've tried to install FreeBSD 6.0-RELEASE, mpd4, ng_netflow on another machine with different hardware, and those machine freezes too. Is there any solution? Thank you, sorry for my English. ==========================Cut==================== db> where Tracing pid 26 tid 100020 td 0xc3980000 kdb_enter(c0703955,e563fa0c,63f9c0,e563f900,0) at kdb_enter+0x32 siointr1(c3b6ba80,c396bb80,e563f9f4,c06b09df,c3b67000) at siointr1+0x3ed siointr(c3b67000,c4206600,e563fa28,c3980000,4) at siointr+0x32 intr_execute_handlers(c073be80,e563fa18,21,595,c6617000) at intr_execute_handlers+0xef atpic_handle_intr(4) at atpic_handle_intr+0x4a Xatpic_intr4() at Xatpic_intr4+0x20 --- interrupt, eip = 0xc0554479, esp = 0xe563fa5c, ebp = 0xe563fa68 --- m_adj(c6617000,ffffffdf,0,1,c3efcc80) at m_adj+0x69 ip_fragment(c66170ec,e563fb3c,578,0,1) at ip_fragment+0x293 ip_output(c6617000,0,e563fb08,20,0) at ip_output+0xad8 rip_output(c6617000,c57148dc,2319a8c0,c07224a0,c0746b3c) at rip_output+0x132 rip_send(c57148dc,0,c6608e00,0,0) at rip_send+0x6e sosend(c57148dc,0,0,c6608e00,0) at sosend+0x5f7 ng_ksocket_rcvdata(c41ee900,c57c4880,8,c41eb100,c41eb100) at ng_ksocket_rcvdata+0x202 ng_apply_item(c41eb100,c57c4880,c4026dda,ceb,c57c4880) at ng_apply_item+0x25a ngintr(0,16c,4c813673,3595a917,8) at ngintr+0x1fb swi_net(0,0,0,0,0) at swi_net+0x9b ithread_loop(c396b580,e563fd48,0,0,0) at ithread_loop+0xc4 fork_exit(c04ffe20,c396b580,e563fd48) at fork_exit+0x62 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe563fd7c, ebp = 0 --- db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 11635 c54548d4 0 1540 11635 0004002 [SLPQ select 0xc074c7c4][SLP] top 1540 c55b71c4 0 852 1540 0004002 [SLPQ pause 0xc55b71fc][SLP] csh 1096 c3b748d4 0 790 47 0004000 [SLPQ select 0xc074c7c4][SLP] utm5_radius 858 c3b74a98 0 1 851 0000000 [SLPQ select 0xc074c7c4][SLP] 3dm2 857 c3f561c4 0 1 857 0004002 [SLPQ ttyin 0xc3d0c210][SLP] getty 856 c3f56000 0 1 856 0004002 [SLPQ ttyin 0xc3b6da10][SLP] getty 855 c54541c4 0 1 855 0004002 [SLPQ ttyin 0xc3a1b810][SLP] getty 854 c3f53000 0 1 854 0004002 [SLPQ ttyin 0xc3af6410][SLP] getty 853 c5454a98 0 1 853 0004002 [SLPQ ttyin 0xc3a1c210][SLP] getty 852 c545454c 0 1 852 0004102 [SLPQ wait 0xc545454c][SLP] login 849 c3d66a98 0 795 47 0004002 [SLPQ select 0xc074c7c4][SLP] utm5_rfw 795 c3f56388 0 1 47 0004002 [SLPQ wait 0xc3f56388][SLP] sh 794 c3f531c4 0 787 47 0004002 [SLPQ select 0xc074c7c4][SLP] utm5_core 790 c3f53a98 0 1 47 0004002 [SLPQ wait 0xc3f53a98][SLP] sh 787 c5454e20 0 1 47 0004002 [SLPQ wait 0xc5454e20][SLP] sh 694 c3f53c5c 0 1 694 0008080 (threaded) mpd4 thread 0xc55ae000 ksegrp 0xc397e0e0 [RUNQ] thread 0xc3f18c00 ksegrp 0xc3b73d90 [SLPQ ksesigwait 0xc3f53d5c][SLP] 550 c3d66c5c 0 1 550 0000000 [SLPQ nanslp 0xc07491cc][SLP] cron 538 c3f53710 25 1 538 0000100 [SLPQ pause 0xc3f53748][SLP] sendmail 534 c3f53388 0 1 534 0000100 [SLPQ select 0xc074c7c4][SLP] sendmail 528 c3d66e20 0 1 528 0000100 [SLPQ select 0xc074c7c4][SLP] sshd 507 c3f5354c 0 1 507 0000000 [SLPQ select 0xc074c7c4][SLP] ntpd 447 c3d6654c 0 442 442 0000000 [SLPQ - 0xc3cfcc00][SLP] nfsd 446 c3b74710 0 442 442 0000000 [SLPQ - 0xc3d0d200][SLP] nfsd 444 c3b74e20 0 442 442 0000000 [SLPQ - 0xc3d1a600][SLP] nfsd 443 c3d66710 0 442 442 0000000 [SLPQ - 0xc3d0ce00][SLP] nfsd 442 c3b74388 0 1 442 0000000 [SLPQ select 0xc074c7c4][SLP] nfsd 434 c3d66000 0 1 434 0000000 [SLPQ select 0xc074c7c4][SLP] mountd 380 c3b74c5c 0 1 380 0000000 [SLPQ select 0xc074c7c4][SLP] rpcbind 370 c3b741c4 53 1 370 0008180 (threaded) named thread 0xc3f17900 ksegrp 0xc397ebd0 [SLPQ kserel 0xc397ec10][SLP] thread 0xc5580600 ksegrp 0xc397ebd0 [SLPQ select 0xc074c7c4][SLP] thread 0xc3b76180 ksegrp 0xc397e460 [SLPQ ksesigwait 0xc3b742c4][SLP] 362 c3b7454c 0 1 362 0000000 [SLPQ select 0xc074c7c4][SLP] syslogd 338 c3d661c4 0 1 338 0000000 [SLPQ select 0xc074c7c4][SLP] devd 228 c3d66388 0 1 228 0000000 [SLPQ pause 0xc3d663c0][SLP] adjkerntz 46 c39d1a98 0 0 0 0000204 [SLPQ - 0xe564ed00][SLP] schedcpu 45 c39d1c5c 0 0 0 0000204 [SLPQ - 0xc075498c][SLP] nfsiod 3 44 c39d1e20 0 0 0 0000204 [SLPQ - 0xc0754988][SLP] nfsiod 2 43 c3b71000 0 0 0 0000204 [SLPQ - 0xc0754984][SLP] nfsiod 1 42 c3b711c4 0 0 0 0000204 [SLPQ - 0xc0754980][SLP] nfsiod 0 41 c3b71388 0 0 0 0000204 [SLPQ syncer 0xc0748f4c][SLP] syncer 40 c3b7154c 0 0 0 0000204 [SLPQ vlruwt 0xc3b7154c][SLP] vnlru 39 c3b71710 0 0 0 0000204 [SLPQ psleep 0xc074cd8c][SLP] bufdaemon 38 c3b718d4 0 0 0 000020c [SLPQ pgzero 0xc075b 37 c3b71a98 0 0 0 0000204 [SLPQ pollid 0xc0746b64][SLP] idlepoll 36 c3b71c5c 0 0 0 0000204 [SLPQ psleep 0xc075b248][SLP] vmdaemon 9 c3b71e20 0 0 0 0000204 [SLPQ psleep 0xc075b204][SLP] pagedaemon 35 c3b74000 0 0 0 0000204 [RUNQ] swi0: sio 8 c39c054c 0 0 0 0000204 [SLPQ idle 0xc3adb000][SLP] aic_recovery1 7 c39c0710 0 0 0 0000204 [SLPQ idle 0xc3ad8000][SLP] aic_recovery0 6 c39c08d4 0 0 0 0000204 [SLPQ - 0xc3a1 34 c39c0a98 0 0 0 0000204 [IWAIT] swi6:+ 33 c39c0c5c 0 0 0 0000204 [IWAIT] swi3: cambio 32 c39c0e20 0 0 0 0000204 [IWAIT] swi2: camnet 5 c39d1000 0 0 0 0000204 [SLPQ - 0xc39fb840][SLP] kqueue taskq 31 c39d11c4 0 0 0 0000204 [IWAIT] swi6: task queue 30 c39d1388 0 0 0 0000204 [IWAIT] swi6:+ 29 c39d154c 0 0 0 0000204 [SLPQ - 0xc07409e0][SLP] yarrow 4 c39d1710 0 0 0 0000204 [SLPQ - 0xc0743448][SLP] g_do 3 c39d18d4 0 0 0 0000204 [SLPQ - 0xc0743444][SLP] g_up 2 c397f1c4 0 0 0 0000204 [SLPQ - 0xc074343c][SLP] g_event 28 c397f388 0 0 0 0000204 [IWAIT] swi4: vm 27 c397f54c 0 0 0 000020c [RUNQ] swi5: clock sio 26 c397f710 0 0 0 0000204 [CPU 0] swi1: net 25 c397f8d4 0 0 0 0000204 [IWAIT] irq15: ata1 24 c397fa98 0 0 0 0000204 [IWAIT] irq14: ata0 23 c397fc5c 0 0 0 0000204 [IWAIT] irq13: 22 c397fe20 0 0 0 0000204 [IWAIT] irq12: 21 c39c0000 0 0 0 0000204 [IWAIT] irq11: em1 ahd0 20 c39c01c4 0 0 0 0000204 [IWAIT] irq10: ahd1 twe0 19 c39c0388 0 0 0 0000204 [IWAIT] irq9: fxp1 18 c3978000 0 0 0 0000204 [IWAIT] irq8: 17 c39781c4 0 0 0 0000204 [IWAIT] irq7: 16 c3978388 0 0 0 0000204 [IWAIT] irq6: 15 c397854c 0 0 0 0000204 [IWAIT] irq5: fxp0 em0 14 c3978710 0 0 0 0000204 [IWAIT] irq4: sio0 13 c39788d4 0 0 0 0000204 [IWAIT] irq3: sio1 12 c3978a98 0 0 0 0000204 [RUNQ] irq1: atkbd0 11 c3978c5c 0 0 0 0000204 [IWAIT] irq0: clk 10 c3978e20 0 0 0 000020c [Can run] idle 1 c397f000 0 0 1 0004200 [SLPQ wait 0xc397f000][SLP] init 0 c07434e0 0 0 0 0000200 [SLPQ sched 0xc07434e0][SLP] swapper db> pciconf -lv agp0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x01e010de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 AGP Controller' class = bridge subclass = HOST-PCI none0@pci0:0:1: class=0x050000 card=0x10001695 chip=0x01eb10de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 Memory Controller 1' class = memory subclass = RAM none1@pci0:0:2: class=0x050000 card=0x10001695 chip=0x01ee10de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 Memory Controller 4' class = memory subclass = RAM none2@pci0:0:3: class=0x050000 card=0x10001695 chip=0x01ed10de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 Memory Controller 3' class = memory subclass = RAM none3@pci0:0:4: class=0x050000 card=0x10001695 chip=0x01ec10de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 Memory Controller 2' class = memory subclass = RAM none4@pci0:0:5: class=0x050000 card=0x10001695 chip=0x01ef10de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 Memory Controller 5' class = memory subclass = RAM isab0@pci0:1:0: class=0x060100 card=0x10001695 chip=0x006010de rev=0xa4 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 ISA Bridge' class = bridge subclass = PCI-ISA none5@pci0:1:1: class=0x0c0500 card=0x10001695 chip=0x006410de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP-T? SMBus Controller' class = serial bus subclass = SMBus none6@pci0:2:0: class=0x0c0310 card=0x10001695 chip=0x006710de rev=0xa4 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 OpenHCI USB Controller' class = serial bus subclass = USB none7@pci0:2:1: class=0x0c0310 card=0x10001695 chip=0x006710de rev=0xa4 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 OpenHCI USB Controller' class = serial bus subclass = USB none8@pci0:2:2: class=0x0c0320 card=0x10001695 chip=0x006810de rev=0xa4 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 EHCI USB 2.0 Controller' class = serial bus subclass = USB none9@pci0:4:0: class=0x020000 card=0x10001695 chip=0x006610de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP-T Networking Adapter' class = network subclass = ethernet pcib1@pci0:8:0: class=0x060400 card=0x00000000 chip=0x006c10de rev=0xa3 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce MCP-T CPU to PCI Bridge' class = bridge subclass = PCI-PCI atapci0@pci0:9:0: class=0x01018a card=0x10001695 chip=0x006510de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 EIDE Controller' class = mass storage subclass = ATA pcib2@pci0:30:0: class=0x060400 card=0x00000000 chip=0x01e810de rev=0xc1 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce2 AGP Host to PCI Bridge' class = bridge subclass = PCI-PCI fxp0@pci1:6:0: class=0x020000 card=0x000e8086 chip=0x12298086 rev=0x08 hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class = network subclass = ethernet ahd0@pci1:7:0: class=0x010000 card=0x00409005 chip=0x80109005 rev=0x03 hdr=0x00 vendor = 'Adaptec Inc' device = 'ASC-39320 Ultra320 SCSI Controller' class = mass storage subclass = SCSI ahd1@pci1:7:1: class=0x010000 card=0x00409005 chip=0x80109005 rev=0x03 hdr=0x00 vendor = 'Adaptec Inc' device = 'ASC-39320 Ultra320 SCSI Controller' class = mass storage subclass = SCSI twe0@pci1:8:0: class=0x010400 card=0x100113c1 chip=0x100113c1 rev=0x01 hdr=0x00 vendor = '3ware Inc.' device = '7000 series ATA-100 Storage Controller' class = mass storage subclass = RAID fxp1@pci1:9:0: class=0x020000 card=0x00408086 chip=0x12298086 rev=0x08 hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class = network subclass = ethernet em0@pci1:10:0: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82546EB Dual Port Gigabit Ethernet Controller' class = network subclass = ethernet em1@pci1:10:1: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82546EB Dual Port Gigabit Ethernet Controller' class = network subclass = ethernet none10@pci2:0:0: class=0x030000 card=0x00000000 chip=0x011010de rev=0xb2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NV11 GeForce2 MX / MX 400' class = display subclass = VGA ==================================Cut============================== -- [ /Iexa ] mailto:adler@smtp.ru From owner-freebsd-stable@FreeBSD.ORG Wed Jan 4 09:47:21 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC24B16A41F for ; Wed, 4 Jan 2006 09:47:21 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C71043D49 for ; Wed, 4 Jan 2006 09:47:20 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k049lHNv003285 for ; Wed, 4 Jan 2006 07:47:18 -0200 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR To: freebsd-stable@freebsd.org Date: Wed, 4 Jan 2006 07:47:13 -0200 User-Agent: KMail/1.8.3 References: <20051231212858.9F9D116A420@hub.freebsd.org> <43B71EF7.2010803@errno.com> In-Reply-To: <43B71EF7.2010803@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200601040747.13395.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: problems with wifi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2006 09:47:21 -0000 On Saturday 31 December 2005 22:14, Sam Leffler wrote: > Bill Paul wrote: > >>yes, i can load if_ath, wireless card is found and i can set it up as > >>ath0, but i still have no signal (and there are many ap's - i can see > >>with different pcmcia card) > > > > I think the wireless enable switch controls the connection to the > > antenna(s), and is a separate device from the NIC itself that varies > > in implementation depending on the laptop. The NDIS driver only knows > > <...ndis related stuff deleted...> > > Handling this in the ath driver is actually very simple; I've just never > done it 'cuz none of my laptops have the this setup to test with. When > you hit the switch the driver gets an interrupt from the ath card and > can then toggle the state of the rfkill pin. If you run the latest code > out for testing there is also a sysctl that you can use to control this > manually. > ok until here but this wlan-buttons on notebooks indicate if the "antena is= on=20 or off"=20 =2D by blinking when on but not associated=20 =2D and lit when on and associated to an SSID =2D and the off is obvious. this behaviour worked fine until 6.0B5, later versions the light stays off even if the ath has this rf switch it does not work on this wlan-button-lig= ht=20 issue I do not know if the 6.0b5 had this switch or not but I know that this feat= ure=20 is certainly important and it is missing since then. Certainly it should be hardware related. On windows and fedora the light=20 blinks soon the motherboard is probed but with freebsd it started blinking= =20 soon some configuration is done, independent if kldloading it at runtime or= =20 at boot by loader.conf Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-stable@FreeBSD.ORG Wed Jan 4 13:26:41 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D299316A41F for ; Wed, 4 Jan 2006 13:26:41 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0767743D60 for ; Wed, 4 Jan 2006 13:26:40 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id k04DQMfu009506; Wed, 4 Jan 2006 05:26:26 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200601041326.k04DQMfu009506@gw.catspoiler.org> Date: Wed, 4 Jan 2006 05:26:22 -0800 (PST) From: Don Lewis To: gcr+freebsd-stable@tharned.org In-Reply-To: <20060103195956.L798@nc8000.tharned.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org, freebsd@McKusick.COM, kris@obsecurity.org Subject: Re: Recurring problem: processes block accessing UFS file system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2006 13:26:41 -0000 On 3 Jan, Greg Rivers wrote: > On Tue, 3 Jan 2006, Don Lewis wrote: >> Pid 87117 is playing with buf 0xdc76fe30 which is not locked, and is >> sleeping on the buf's b_xflags member. It looks like 87117 is waiting >> for an in-progress write to complete. There are a large number of other >> sendmail processes waiting in this same place. >> >> How about "show buffer 0xdc76fe30"? >> > > db> show buffer 0xdc76fe30 > buf at 0xdc76fe30 > b_flags = 0x200000a0 > b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 > b_bufobj = (0xc8985610), b_data = 0xe1d6b000, b_blkno = 365086368 > lockstatus = 0, excl count = 0, excl owner 0xffffffff > b_npages = 4, pages(OBJ, IDX, PA): (0xc8984108, 0x2b858d4, 0xa8de1000),(0xc8984108, 0x2b858d5, 0xa8c62000),(0xc8984108, 0x2b858d6, 0xa8de3000),(0xc8984108, 0x2b858d7, 0xa8e64000) > db> Hmn, it would be nice if DDB printed b_vflags so that we would know the state of BV_BKGRDINPROG and BV_BKGRDWAIT. As it is, we don't know if the background write got lost or if we missed the wakeup. At this point, I think it might be easier to do post-mortem debugging on a core file with kgdb and kernel.debug. Unless there is an obvious race condition, I suspect this will be a tough slog. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 4 16:27:54 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E6E216A41F for ; Wed, 4 Jan 2006 16:27:54 +0000 (GMT) (envelope-from tux@kdstv-normannia.de) Received: from mxout03.versatel.de (mxout03.versatel.de [212.7.152.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A6FC43D55 for ; Wed, 4 Jan 2006 16:27:53 +0000 (GMT) (envelope-from tux@kdstv-normannia.de) Received: from mx02.versatel.de (mx02.versatel.de [212.7.146.2]) by mxout03.versatel.de (8.12.11/8.12.11) with ESMTP id k04GRpvg022805 for ; Wed, 4 Jan 2006 17:27:51 +0100 Received: from [10.10.10.20] ([62.214.237.16]) by mx02.versatel.de (8.12.11/8.12.11) with ESMTP id k04GRpDK010036 for ; Wed, 4 Jan 2006 17:27:51 +0100 From: Andreas Ulrich To: freebsd-stable@freebsd.org Content-Type: text/plain Date: Wed, 04 Jan 2006 17:27:45 +0100 Message-Id: <1136392065.29580.8.camel@localhost.tux.de> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: unused ld-elf.so.hints ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2006 16:27:54 -0000 Hello! in view of kdump (and ktrace ...), there will be read the file /var/run/ld-elf.so.hints but its contents not... Or why is every programm trying to load every library from the same search path? e.g. tries first /lib, etc. this happens at least to 5-STABLE and 6-STABLE shouldn't be it more so, that programs open the library in the right directory already for the first time and not have to search? Thanx, Andreas From owner-freebsd-stable@FreeBSD.ORG Wed Jan 4 16:43:56 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF9B516A41F for ; Wed, 4 Jan 2006 16:43:56 +0000 (GMT) (envelope-from dan@ferrarishields.com) Received: from mail.ferrarishields.com (mail.ferrarishields.com [216.82.146.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6381943D5A for ; Wed, 4 Jan 2006 16:43:56 +0000 (GMT) (envelope-from dan@ferrarishields.com) Received: from dan (dan [10.70.153.5]) by mail.ferrarishields.com (Postfix) with SMTP id F363B73028; Wed, 4 Jan 2006 08:43:55 -0800 (PST) Message-ID: <01be01c6114e$160f71b0$0599460a@dan> From: "Dan O'Connor" To: "adler" , References: <31615625.20060104113421@smtp.ru> Date: Wed, 4 Jan 2006 08:44:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Cc: Subject: Re: 5.4 freezes randomly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2006 16:43:56 -0000 >I have installed a FreeBSD 5.4-RELEASE router, with mpd4 (for pptp > clients) and with ng_netflow for traffic collecting, the machine also > performs NAT be means of pfnat. > > But my machine occasionally freezes. It does not respond to echo > requests over ethernet and it even does not respond to keyboard. > > I have connected this machine with another one via serial cable > and when it hang, I've entered debugger (see below). I've tried to > install FreeBSD 6.0-RELEASE, mpd4, ng_netflow on another machine > with different hardware, and those machine freezes too. Is there any > solution? Thank you, sorry for my English. I don't know if this will help, but mpd4 is the development version--I'd try mpd 3 (/usr/ports/net/mpd). I'm using it for a VPN server on FBSD 6.0, without any troubles... Good luck, ~Dan From owner-freebsd-stable@FreeBSD.ORG Wed Jan 4 16:47:40 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 508EA16A41F for ; Wed, 4 Jan 2006 16:47:40 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A56C43D68 for ; Wed, 4 Jan 2006 16:47:30 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 0642AB810 for ; Wed, 4 Jan 2006 11:47:28 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: stable@freebsd.org From: Vivek Khera Date: Wed, 4 Jan 2006 11:47:27 -0500 X-Mailer: Apple Mail (2.746.2) Cc: Subject: rpcbind lingering on IP no longer specified on command line X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2006 16:47:40 -0000 I had rpcbind running with on two interfaces like this: rpcbind -h 192.168.100.200 -h 10.0.0.9 Now, I changed rpcbind_flags in /etc/rc.conf to just have the first address, and I restarted rpcbind. the process list from ps shows it is running like this: rpcbind -h 192.168.100.200 Yet nmap on the other address shows rpcbind is still listening on udp there. How do I stop that? Thanks. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D. Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-301-869-4449 x806 From owner-freebsd-stable@FreeBSD.ORG Wed Jan 4 19:41:33 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C332C16A41F for ; Wed, 4 Jan 2006 19:41:33 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 33E5343D48 for ; Wed, 4 Jan 2006 19:41:33 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 57837 invoked by uid 399); 4 Jan 2006 19:41:32 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 4 Jan 2006 19:41:32 -0000 Message-ID: <43BC24E7.6090800@FreeBSD.org> Date: Wed, 04 Jan 2006 11:41:27 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20051226) MIME-Version: 1.0 To: Vivek Khera References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: rpcbind lingering on IP no longer specified on command line X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2006 19:41:33 -0000 FWIW, this question could probably have been asked on freebsd-questions@ since it doesn't really pertain specifically to an issue about a stable branch, but that's not the end of the world. Vivek Khera wrote: > I had rpcbind running with on two interfaces like this: > > rpcbind -h 192.168.100.200 -h 10.0.0.9 > > Now, I changed rpcbind_flags in /etc/rc.conf to just have the first > address, and I restarted rpcbind. the process list from ps shows it is > running like this: > > rpcbind -h 192.168.100.200 > > Yet nmap on the other address shows rpcbind is still listening on udp > there. How do I stop that? What does 'sockstat | grep rpcbind' tell you? -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Wed Jan 4 19:46:08 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FDC616A41F for ; Wed, 4 Jan 2006 19:46:08 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C85FD43D5E for ; Wed, 4 Jan 2006 19:46:07 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.3/8.13.3) with ESMTP id k04Jk6gY003729; Wed, 4 Jan 2006 22:46:06 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Wed, 4 Jan 2006 22:46:06 +0300 (MSK) From: Dmitry Morozovsky To: Vivek Khera In-Reply-To: Message-ID: <20060104222846.K98554@woozle.rinet.ru> References: X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (woozle.rinet.ru [0.0.0.0]); Wed, 04 Jan 2006 22:46:06 +0300 (MSK) Cc: stable@freebsd.org Subject: Re: rpcbind lingering on IP no longer specified on command line X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2006 19:46:08 -0000 On Wed, 4 Jan 2006, Vivek Khera wrote: VK> I had rpcbind running with on two interfaces like this: VK> VK> rpcbind -h 192.168.100.200 -h 10.0.0.9 VK> VK> Now, I changed rpcbind_flags in /etc/rc.conf to just have the first address, VK> and I restarted rpcbind. the process list from ps shows it is running like VK> this: VK> VK> rpcbind -h 192.168.100.200 VK> VK> Yet nmap on the other address shows rpcbind is still listening on udp there. VK> How do I stop that? As I sometimes looked into this, rpcbind (formely portmap) listens on all described addresses via udp *and* an tcp:*.111 - I tried to dig why is this but did not succeed much. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Jan 4 19:48:29 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E23F316A41F; Wed, 4 Jan 2006 19:48:29 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C29B043D4C; Wed, 4 Jan 2006 19:48:13 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.3/8.13.3) with ESMTP id k04JmCDb003780; Wed, 4 Jan 2006 22:48:12 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Wed, 4 Jan 2006 22:48:12 +0300 (MSK) From: Dmitry Morozovsky To: Doug Barton In-Reply-To: <43BC24E7.6090800@FreeBSD.org> Message-ID: <20060104224642.V98554@woozle.rinet.ru> References: <43BC24E7.6090800@FreeBSD.org> X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (woozle.rinet.ru [0.0.0.0]); Wed, 04 Jan 2006 22:48:12 +0300 (MSK) Cc: Vivek Khera , stable@freebsd.org Subject: Re: rpcbind lingering on IP no longer specified on command line X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2006 19:48:30 -0000 On Wed, 4 Jan 2006, Doug Barton wrote: DB> > rpcbind -h 192.168.100.200 -h 10.0.0.9 DB> > DB> > Now, I changed rpcbind_flags in /etc/rc.conf to just have the first DB> > address, and I restarted rpcbind. the process list from ps shows it is DB> > running like this: DB> > DB> > rpcbind -h 192.168.100.200 DB> > DB> > Yet nmap on the other address shows rpcbind is still listening on udp DB> > there. How do I stop that? DB> DB> What does 'sockstat | grep rpcbind' tell you? Mine (from RELENG_6): marck@chipmunk:/usr/src> sockstat | grep rpc root rpcbind 69422 5 stream /var/run/rpcbind.sock root rpcbind 69422 6 dgram -> /var/run/logpriv root rpcbind 69422 7 udp4 127.0.0.1:111 *:* root rpcbind 69422 8 udp4 10.5.5.2:111 *:* root rpcbind 69422 9 udp4 *:621 *:* root rpcbind 69422 10 tcp4 *:111 *:* marck@chipmunk:/usr/src> ps ax | grep rpc 69422 ?? Is 0:00.00 rpcbind -h 10.5.5.2 69462 p4 R+ 0:00.00 grep rpc marck@chipmunk:/usr/src> Hmmm... I just realized that original question mentions udp, not tcp. However, tcp 'listen-to-any' question is still open for me... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Jan 4 20:44:05 2006 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD9E216A420 for ; Wed, 4 Jan 2006 20:44:05 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id E28DE43D5E for ; Wed, 4 Jan 2006 20:44:02 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 5F3BFB80F for ; Wed, 4 Jan 2006 15:44:01 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43BC24E7.6090800@FreeBSD.org> References: <43BC24E7.6090800@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Wed, 4 Jan 2006 15:44:00 -0500 To: stable@FreeBSD.org X-Mailer: Apple Mail (2.746.2) Cc: Subject: Re: rpcbind lingering on IP no longer specified on command line X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2006 20:44:05 -0000 On Jan 4, 2006, at 2:41 PM, Doug Barton wrote: > What does 'sockstat | grep rpcbind' tell you? # sockstat | grep rpcbind root rpcbind 11382 5 stream /var/run/rpcbind.sock root rpcbind 11382 6 dgram -> /var/run/logpriv root rpcbind 11382 7 udp4 127.0.0.1:111 *:* root rpcbind 11382 8 udp4 192.168.100.200:111 *:* root rpcbind 11382 9 udp4 *:664 *:* root rpcbind 11382 10 tcp4 *:111 *:* As Dmitry Morozovsky points out, it seems it always listens to tcp *: 111 which seems to be a bad thing. I'm running 6.0-RELEASE-p1. This came up because of some security scans we're having run for some compliance certificates we need... Can anyone explain why rpcbind will still bind to all tcp interfaces? From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 01:06:41 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C30F416A41F for ; Thu, 5 Jan 2006 01:06:41 +0000 (GMT) (envelope-from marko@freebsd.org) Received: from pih-relay05.plus.net (pih-relay05.plus.net [212.159.14.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6925843D49 for ; Thu, 5 Jan 2006 01:06:41 +0000 (GMT) (envelope-from marko@freebsd.org) Received: from [80.229.231.20] (helo=[192.168.1.4]) by pih-relay05.plus.net with esmtp (Exim) id 1EuJaS-0001cD-CY for freebsd-stable@freebsd.org; Thu, 05 Jan 2006 01:06:40 +0000 Message-ID: <43BC7150.1020009@freebsd.org> Date: Thu, 05 Jan 2006 01:07:28 +0000 From: Mark Ovens User-Agent: Mail/News 1.6a1 (X11/20051228) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: RELENG_6: Which scheduler for SMP? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 01:06:41 -0000 Pete French wrote: >> What I am trying to decide is whether there any point in making the jump >> from a very stable RELENG_5 system to RELENG_6. AIUI the ULE scheduler >> and it's associated options optimize the use of multiple CPUs and by >> staying with 4BSD I'm not getting the best performance from my system. > > I'm not using ULE either - but I got a 15 percent speedup out of our SMP > systems when moving from RELENG_5 to 6.0-RELEASE. Definitely worth doing > in my opinion and am now upgrading all the production systems to 6.0 > >> Can anyone offer any advice on this please? > > Yes, do it. Its a definite improvement. > OK, I've done it, and am pleased with the result :) Thanks to everyone for the info about the current state of ULE. I'm sticking with 4BSD as the box is rock solid with that. Regards, Mark From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 01:24:41 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BE3416A41F for ; Thu, 5 Jan 2006 01:24:41 +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 7EEEA43D58 for ; Thu, 5 Jan 2006 01:24:37 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.21]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k051OXg5043986 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 5 Jan 2006 11:54:33 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Thu, 5 Jan 2006 11:54:24 +1030 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart59812899.2q9bYJKc66"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601051154.32092.doconnor@gsoft.com.au> X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Subject: RELENG_6 devfs problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 01:24:41 -0000 --nextPart59812899.2q9bYJKc66 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I just installed the latest mgetty and ran it, then found it wasn't talking= to=20 my modem so I disabled it in /etc/ttys and killed the process. I ran fstat /dev/cuad0 to check it was dead and fstat got stuck in the devf= s=20 state. It seems that everything else was stuck too and now the machine is=20 alive but not very functional. What can I do to try and debug it? =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 --nextPart59812899.2q9bYJKc66 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDvHVP5ZPcIHs/zowRAiCYAJ4gUMDEOZXeSmjsStNwF3p8ecEbuQCfZorO tiTft6YSMa7Ejdd+W6yHTik= =a9kj -----END PGP SIGNATURE----- --nextPart59812899.2q9bYJKc66-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 01:43:46 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9315A16A41F for ; Thu, 5 Jan 2006 01:43:46 +0000 (GMT) (envelope-from djplasma@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id A91F143D6A for ; Thu, 5 Jan 2006 01:43:43 +0000 (GMT) (envelope-from djplasma@gmail.com) Received: by wproxy.gmail.com with SMTP id i14so2579444wra for ; Wed, 04 Jan 2006 17:43:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=RBDz5LxyzdYvFIS+lxSGtmhgob3Tg8FxprWHJ8Q35NlCcWf6P9OTPGkIEXFuEtPgQ1RqU6Y8dBjqHZtOfvdzM2p4e6SkARmQm2o3MBdKuY+oc+CUkVE5H1gMNHCRgF3ZFai24nAUwW0t5yTe69jOJrmUL/FKRMWnVe7ShOOCUY0= Received: by 10.54.97.2 with SMTP id u2mr2704082wrb; Wed, 04 Jan 2006 17:43:42 -0800 (PST) Received: by 10.54.63.19 with HTTP; Wed, 4 Jan 2006 17:43:42 -0800 (PST) Message-ID: Date: Wed, 4 Jan 2006 17:43:42 -0800 From: "DJ (e-Plutonia Inc.)" To: freebsd-stable@freebsd.org MIME-Version: 1.0 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 Subject: 5.4 problems with IPFIREWALL_FORWARD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 01:43:46 -0000 I compiled the kernel with options IPFIREWALL_FORWARD, and this is what I still get: ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled Any help with this would be appreciated. -- DJ Fadyeyev Founder - e-Plutonia From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 01:54:07 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7F1C16A41F for ; Thu, 5 Jan 2006 01:54:07 +0000 (GMT) (envelope-from nathan_p_maier@comcast.net) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [63.240.77.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78AF343D58 for ; Thu, 5 Jan 2006 01:54:07 +0000 (GMT) (envelope-from nathan_p_maier@comcast.net) Received: from smailcenter50.comcast.net ([204.127.205.150]) by comcast.net (sccrmhc11) with SMTP id <2006010501540601100dg2eue>; Thu, 5 Jan 2006 01:54:06 +0000 Received: from [24.15.72.99] by smailcenter50.comcast.net; Thu, 05 Jan 2006 01:54:06 +0000 From: nathan_p_maier@comcast.net To: freebsd-stable@freebsd.org Date: Thu, 05 Jan 2006 01:54:06 +0000 Message-Id: <010520060154.13425.43BC7C3E000289400000347122007511509D0A070E03A19FA1020E089B0E02@comcast.net> X-Mailer: AT&T Message Center Version 1 (Aug 4 2005) X-Authenticated-Sender: bmF0aGFuX3BfbWFpZXJAY29tY2FzdC5uZXQ= Subject: Config meet your kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 01:54:08 -0000 Hi, I cannot "make buildkernel" after cvsup from 5.3 to 6-stable doing src-all and ports-all in my cvsup supfile. Then I built my world. Now I get this message when I try "make buildkernel": -----snip 386/conf/GENERIC ERROR: version of config(8) does not match kernel! config version = 500013, version required = 600003 Make sure that /usr/src/usr.sbin/config is in sync with your /usr/src/sys and install a new config binary before trying this again. If running the new config fails check your config file against the GENERIC or LINT config files for changes in config syntax, or option/device naming conventions *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. dhcppc2# I've done cvsup and buildworld several times. I hope that this is enough info. -Nathan M. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 02:17:00 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 225BD16A41F for ; Thu, 5 Jan 2006 02:17:00 +0000 (GMT) (envelope-from jeff@sailorfej.net) Received: from mail.sailorfej.net (mail.sailorfej.net [65.102.14.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id D757A43D5D for ; Thu, 5 Jan 2006 02:16:58 +0000 (GMT) (envelope-from jeff@sailorfej.net) Received: from [192.168.150.40] (doorwarden.sailorfej.net [65.102.14.161]) (authenticated bits=0) by mail.sailorfej.net (8.13.1/8.12.11) with ESMTP id k052GrXc091251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Jan 2006 18:16:54 -0800 (PST) (envelope-from jeff@sailorfej.net) Message-ID: <43BC8190.1060403@sailorfej.net> Date: Wed, 04 Jan 2006 18:16:48 -0800 From: Jeffrey Williams User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.85.1/1229/Wed Jan 4 07:08:11 2006 on mail.sailorfej.net X-Virus-Status: Clean Subject: FreeBSD 6 non-GENERIC kernel build fails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 02:17:00 -0000 Trying to build kernel with the following conf file, output follows, HELP! ***** CONF FILE ****** # # FreeBSD: src/sys/i386/conf/OENS, v1.0, Jeffrey Williams, 01042006-01 # machine i386 cpu I686_CPU ident OENS #options SCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking #options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic # I/O APIC # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bge # Broadcom BCM570xx Gigabit Ethernet # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device ural # Ralink Technology RT2500USB wireless NICs device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Ethernet, requires miibus device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet ***** CONF FILE END ******** ****** TRUNCATED OUTPUT ********* cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror vnode_if.c touch hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=make sh /usr/src/sys/conf/newvers.sh OENS cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror vers.c linking kernel if_ural.o(.text+0x66): In function `ural_free_tx_list': : undefined reference to `ieee80211_free_node' if_ural.o(.text+0x12f): In function `ural_detach': : undefined reference to `ieee80211_ifdetach' if_ural.o(.text+0x2c1): In function `ural_rxeof': : undefined reference to `ieee80211_find_rxnode' if_ural.o(.text+0x2d7): In function `ural_rxeof': : undefined reference to `ieee80211_input' if_ural.o(.text+0x2dd): In function `ural_rxeof': : undefined reference to `ieee80211_free_node' if_ural.o(.text+0x863): In function `ural_start': : undefined reference to `ieee80211_find_txnode' if_ural.o(.text+0x88c): In function `ural_start': : undefined reference to `ieee80211_encap' if_ural.o(.text+0x9cd): In function `ural_start': : undefined reference to `ieee80211_free_node' if_ural.o(.text+0xa05): In function `ural_start': : undefined reference to `ieee80211_encap' if_ural.o(.text+0xa1b): In function `ural_start': : undefined reference to `ieee80211_free_node' if_ural.o(.text+0xa2f): In function `ural_start': : undefined reference to `ieee80211_crypto_encap' if_ural.o(.text+0xe1b): In function `ural_txeof': : undefined reference to `ieee80211_free_node' if_ural.o(.text+0xec2): In function `ural_watchdog': : undefined reference to `ieee80211_watchdog' if_ural.o(.text+0x159b): In function `ural_attach': : undefined reference to `ieee80211_ieee2mhz' if_ural.o(.text+0x15c1): In function `ural_attach': : undefined reference to `ieee80211_ifattach' if_ural.o(.text+0x15f2): In function `ural_attach': : undefined reference to `ieee80211_media_status' if_ural.o(.text+0x15fd): In function `ural_attach': : undefined reference to `ieee80211_media_init' if_ural.o(.text+0x16cb): In function `ural_attach': : undefined reference to `ieee80211_ieee2mhz' if_ural.o(.text+0x16ff): In function `ural_attach': : undefined reference to `ieee80211_ieee2mhz' if_ural.o(.text+0x1734): In function `ural_attach': : undefined reference to `ieee80211_ieee2mhz' if_ural.o(.text+0x1786): In function `ural_attach': : undefined reference to `ieee80211_announce' if_ural.o(.text+0x19b2): In function `ural_set_chan': : undefined reference to `ieee80211_chan2ieee' if_ural.o(.text+0x1ed4): In function `ural_task': : undefined reference to `ieee80211_beacon_alloc' if_ural.o(.text+0x27f4): In function `ural_media_change': : undefined reference to `ieee80211_media_change' if_ural.o(.text+0x2852): In function `ural_media_change': : undefined reference to `ieee80211_media_change' if_ural.o(.text+0x290b): In function `ural_ioctl': : undefined reference to `ieee80211_ioctl' if_ural.o(.text+0x1a1): In function `ural_next_scan': : undefined reference to `ieee80211_next_scan' *** Error code 1 Stop in /usr/obj/usr/src/sys/OENS. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. oens1# ***** END TRUNCATED OUTPUT ****** From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 02:23:50 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC5F316A41F for ; Thu, 5 Jan 2006 02:23:50 +0000 (GMT) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ACE543D5E for ; Thu, 5 Jan 2006 02:23:50 +0000 (GMT) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: (qmail 26628 invoked from network); 5 Jan 2006 02:23:50 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 5 Jan 2006 02:23:50 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 4E97F28420; Wed, 4 Jan 2006 21:23:49 -0500 (EST) Sender: lowell@be-well.ilk.org To: Jeffrey Williams References: <43BC8190.1060403@sailorfej.net> From: Lowell Gilbert Date: 04 Jan 2006 21:23:49 -0500 In-Reply-To: <43BC8190.1060403@sailorfej.net> Message-ID: <44u0cjxvii.fsf@be-well.ilk.org> Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 6 non-GENERIC kernel build fails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 02:23:51 -0000 Jeffrey Williams writes: > Trying to build kernel with the following conf file, output follows, HELP! You have ural(4) in your kernel, but no wlan(4). The ural(4) manual says that wlan(4) is required. In general, the way to figure these things out is to start from the GENERIC kernel, and make a few changes at a time. If something breaks, you know that one of those changes was responsible. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 02:29:55 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C4AD16A41F for ; Thu, 5 Jan 2006 02:29:55 +0000 (GMT) (envelope-from jeff@sailorfej.net) Received: from mail.sailorfej.net (mail.sailorfej.net [65.102.14.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F14743D58 for ; Thu, 5 Jan 2006 02:29:53 +0000 (GMT) (envelope-from jeff@sailorfej.net) Received: from [192.168.150.40] (doorwarden.sailorfej.net [65.102.14.161]) (authenticated bits=0) by mail.sailorfej.net (8.13.1/8.12.11) with ESMTP id k052Tn4V091293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Jan 2006 18:29:50 -0800 (PST) (envelope-from jeff@sailorfej.net) Message-ID: <43BC8498.1050005@sailorfej.net> Date: Wed, 04 Jan 2006 18:29:44 -0800 From: Jeffrey Williams User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <43BC8190.1060403@sailorfej.net> <44u0cjxvii.fsf@be-well.ilk.org> In-Reply-To: <44u0cjxvii.fsf@be-well.ilk.org> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.85.1/1229/Wed Jan 4 07:08:11 2006 on mail.sailorfej.net X-Virus-Status: Clean Subject: Re: FreeBSD 6 non-GENERIC kernel build fails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 02:29:55 -0000 Thanks, I just now saw that myself, being the dilnob I am, I searched the mailing list, relnotes, errata, and forums, but didn't actually read my own kernel conf file until after a I sent my email. Thanks for swift response though Jeff Lowell Gilbert wrote: > Jeffrey Williams writes: > > >>Trying to build kernel with the following conf file, output follows, HELP! > > > You have ural(4) in your kernel, but no wlan(4). > The ural(4) manual says that wlan(4) is required. > > In general, the way to figure these things out is to start from the > GENERIC kernel, and make a few changes at a time. If something > breaks, you know that one of those changes was responsible. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 03:14:15 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1404916A41F for ; Thu, 5 Jan 2006 03:14:15 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from skippyii.compar.com (skippyii.compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 401A543D49 for ; Thu, 5 Jan 2006 03:14:13 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM0011e6ede298.cpe.net.cable.rogers.com [70.28.254.189]) by skippyii.compar.com (8.13.1/8.13.1) with ESMTP id k053FUPL059894; Wed, 4 Jan 2006 22:15:30 -0500 (EST) (envelope-from matt@gsicomp.on.ca) Message-ID: <00af01c611a6$3caad5f0$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: , "Jeffrey Williams" References: <43BC8190.1060403@sailorfej.net> <44u0cjxvii.fsf@be-well.ilk.org> Date: Wed, 4 Jan 2006 22:15:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 6 non-GENERIC kernel build fails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 03:14:15 -0000 > Jeffrey Williams writes: > > > Trying to build kernel with the following conf file, output follows, HELP! > > You have ural(4) in your kernel, but no wlan(4). > The ural(4) manual says that wlan(4) is required. > > In general, the way to figure these things out is to start from the > GENERIC kernel, and make a few changes at a time. If something > breaks, you know that one of those changes was responsible. I'm working on adding dependency checking to config(8) in order to catch these types of problems. If anyone has any suggestions or would like to participate in the implementation and testing, please drop me a line in private email. Regards, -- Matt Emmerton From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 03:24:02 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A6EE16A420; Thu, 5 Jan 2006 03:24:02 +0000 (GMT) (envelope-from gcr+freebsd-stable@tharned.org) Received: from nc8000.tharned.org (rrcs-24-56-87-26.ma.biz.rr.com [24.56.87.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87D4243D75; Thu, 5 Jan 2006 03:23:49 +0000 (GMT) (envelope-from gcr+freebsd-stable@tharned.org) Received: from nc8000.tharned.org (gcr@localhost [127.0.0.1]) by nc8000.tharned.org (8.13.4/8.13.4) with ESMTP id k053NiHQ071680; Wed, 4 Jan 2006 21:23:44 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) Received: from localhost (gcr@localhost) by nc8000.tharned.org (8.13.4/8.13.4/Submit) with ESMTP id k053NDoi071676; Wed, 4 Jan 2006 21:23:14 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) Date: Wed, 4 Jan 2006 21:23:13 -0600 (CST) From: Greg Rivers Sender: gcr@tharned.org To: Don Lewis In-Reply-To: <200601041326.k04DQMfu009506@gw.catspoiler.org> Message-ID: <20060104204821.X798@nc8000.tharned.org> References: <200601041326.k04DQMfu009506@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@FreeBSD.org, Kirk McKusick , Kris Kennaway Subject: Re: Recurring problem: processes block accessing UFS file system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 03:24:02 -0000 On Wed, 4 Jan 2006, Don Lewis wrote: >>> How about "show buffer 0xdc76fe30"? >>> >> >> db> show buffer 0xdc76fe30 >> buf at 0xdc76fe30 >> b_flags = 0x200000a0 >> b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 >> b_bufobj = (0xc8985610), b_data = 0xe1d6b000, b_blkno = 365086368 >> lockstatus = 0, excl count = 0, excl owner 0xffffffff >> b_npages = 4, pages(OBJ, IDX, PA): (0xc8984108, 0x2b858d4, 0xa8de1000),(0xc8984108, 0x2b858d5, 0xa8c62000),(0xc8984108, 0x2b858d6, 0xa8de3000),(0xc8984108, 0x2b858d7, 0xa8e64000) >> db> > > Hmn, it would be nice if DDB printed b_vflags so that we would know the > state of BV_BKGRDINPROG and BV_BKGRDWAIT. As it is, we don't know if > the background write got lost or if we missed the wakeup. > > At this point, I think it might be easier to do post-mortem debugging on > a core file with kgdb and kernel.debug. Unless there is an obvious race > condition, I suspect this will be a tough slog. > I attempted to get a core, but "panic" wedged the machine. I'll try again next time this happens. Thanks again for looking at this. -- Greg db> continue # (free up a partition and set up a dump device...) # sync;sync # sync;sync # sync;sync # KDB: enter: Line break on console [thread pid 13 tid 100003 ] Stopped at kdb_enter+0x30: leave db> panic panic: from debugger cpuid = 0 KDB: stack backtrace: kdb_backtrace(c0625783,0,c060c2d4,e70c5a20,c043bb58) at kdb_backtrace+0x2f panic(c060c2d4,e70c5ad8,c043aaec,c04d13c9,0) at panic+0x129 db_command_loop(c04d13c9,0,ffffffff,e70c5a4c,e70c5a48) at db_command_loop db_command(c06549e4,c062efa0,c0629aa8,c0629aac,e70c5b44) at db_command+0x2a4 db_command_loop(c04d13c9,0,0,0,0) at db_command_loop+0x6a db_trap(3,0,3,c8522a80,e70c5b94) at db_trap+0xe2 kdb_trap(3,0,e70c5b9c,f2db0257,0) at kdb_trap+0xb6 trap(c8710008,28,e70c0028,f9,c8714c00) at trap+0x4d1 calltrap() at calltrap+0x5 --- trap 0x3, eip = 0xc04d13c9, esp = 0xe70c5bdc, ebp = 0xe70c5be4 --- kdb_enter(c0622c7f,679ed6d4,36,c8522a80,c8714c00) at kdb_enter+0x30 siointr1(c8714c00,37f86c,e5857050,c8522a80,c8522a80) at siointr1+0xd1 siointr(c8714c00,2,0,4,c8522a80) at siointr+0x76 intr_execute_handlers(c851a490,e70c5c68,e70c5cac,c05da733,34) at intr_execute_handlers+0x8c lapic_handle_intr(34) at lapic_handle_intr+0x3b Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc078427a, esp = 0xe70c5cac, ebp = 0xe70c5cac --- acpi_cpu_c1(37f867,43d0eea4,7b70cdc0,e70c5ce0,37f867) at acpi_cpu_c1+0x5 acpi_cpu_idle(e70c5d04,c049a72a,1,0,0) at acpi_cpu_idle+0x18a cpu_idle(1,0,0,0,0) at cpu_idle+0x29 idle_proc(0,e70c5d38,0,0,0) at idle_proc+0xad fork_exit(c049a67d,0,e70c5d38) at fork_exit+0x7b fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe70c5d6c, ebp = 0 --- Uptime: 42d10h54m36s GEOM_MIRROR: Device gm1: provider mirror/gm1 destroyed. pid 13: corrected slot count (0->1) From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 04:45:22 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC29516A420 for ; Thu, 5 Jan 2006 04:45:22 +0000 (GMT) (envelope-from rossmarch@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4180943D4C for ; Thu, 5 Jan 2006 04:45:11 +0000 (GMT) (envelope-from rossmarch@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so1972310wxc for ; Wed, 04 Jan 2006 20:45:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=D3FaelsYIin2hrW3sIxUwSDPTCyKBKyXqNtAE6ntYNWXWMNJnMBJ/bVs6Q/cT+rxp36doH/sxtI0KbOvzOmKsGi7wW878Lx2qiJ1m8MjUEpQb9eh35ZFXaAFKF09hvl39VjRKnzLzr8V33MYE6hvkZv0KlpQCdCjLkLbLgsx1DM= Received: by 10.70.124.5 with SMTP id w5mr12199972wxc; Wed, 04 Jan 2006 20:45:08 -0800 (PST) Received: by 10.70.54.12 with HTTP; Wed, 4 Jan 2006 20:45:08 -0800 (PST) Message-ID: <9f96c1770601042045v3e6b8381ua637e8f81b79cb60@mail.gmail.com> Date: Wed, 4 Jan 2006 21:45:08 -0700 From: Ross Marchiafava To: freebsd-stable@freebsd.org MIME-Version: 1.0 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 Subject: 6.0-STABLEThinkpad 600e SMBus IOCTL: Device not configured error & Minor vidcontrol problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 04:45:23 -0000 I'm currently running 6.0-STABLE on my IBM Thinkpad 600e 2645-4AU with a custom kernel. I updated the BIOS to the latest version that IBM offers ( INET36WW http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=3DDSHY-46HLK= Q ). I have two issues that I would love to get some hints on how to resolve. When my laptop comes out of suspend, the video color becomes distorted. I'm using VESA with 'vidcontrol MODE_279' 1024x768x16 it seems that all video modes do the same thing when coming out of suspend. The strange thing is when coming out of suspend and using a different MODE, the color it distorts to changes depending on the current mode. All the login prompts on my ttys are a yellow color. It distorts other colors as well but that's the main color I notice ( MODE_279 ). If I run 'vidcontrol MODE_279' with the color distortion already occurring, the resolution is refreshed and I have no color distortion until the next time the laptop goes in to suspend. Would it be possible to have vidcontrol MODE_279 run every time the laptop resumes from the suspended state? My second issue is with SMBus, i'm getting some IOCTL: Device not configured errors when running chm, I read in a post that intpm ( the driver I'm loading ) requires to use IRQ 9: root 20 0.0 0.0 0 8 ?? WL 12:29PM 0:00.00 [irq9: int= pm0] smbus driver is compiled in to the kernel. When the intpm0 driver is loaded I do have /dev/smb0 created. I also tried using 'chm -I' to see what results I would get and they do not seem to be accurate as well. I figured that since dmesg is not giving me any errors regarding the driver being loaded and it's creating the /dev/smb0 device, that it's properly configured. Am I missing something here? I have listed pciconf, dmesg, loader.conf, device.hints, and kernel config below. I appreciate any help on these issues, I would love to have this laptop working 100%. Thank you. chm -I: ---------------------------------------- Motherboard Temperature: 255 =B0 C CPU_0 Temperature: 0 =B0 C CPU_1 Temperature: 0 =B0 C VCore: 3.98438 V Vit: 3.98438 V Vio: 3.98438 V +5V: 6.65391 V +12V: 15.9375 V -12V: -15.9375 V -5V: -6.65391 V Fan 1: Not Available Fan 2: Not Available Fan 3: Not Available ---------------------------------------- chm: ioctl: Device not configured ---------------------------------------- IOCTL: Device not configured IOCTL: Device not configured IOCTL: Device not configured IOCTL: Device not configured IOCTL: Device not configured IOCTL: Device not configured IOCTL: Device not configured IOCTL: Device not configured IOCTL: Device not configured IOCTL: Device not configured Motherboard Temperature: 191 =B0 C CPU_0 Temperature: 191 =B0 C CPU_1 Temperature: 191 =B0 C IOCTL: Device not configured VCore: 2.98438 V IOCTL: Device not configured Vit: 2.98438 V IOCTL: Device not configured Vio: 2.98438 V IOCTL: Device not configured +5V: 4.98391 V IOCTL: Device not configured +12V: 11.9375 V IOCTL: Device not configured -12V: -11.9375 V IOCTL: Device not configured -5V: -4.98391 V IOCTL: Device not configured Fan 1: 883 rpm IOCTL: Device not configured Fan 2: 1767 rpm IOCTL: Device not configured Fan 3: 3534 rpm ---------------------------------------- pciconf -vl: agp0@pci0:0:0: class=3D0x060000 card=3D0x00000000 chip=3D0x71908086 rev=3D= 0x03 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82443BX/ZX 440BX/ZX CPU to PCI Bridge (AGP Implemented)' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:1:0: class=3D0x060400 card=3D0x00000000 chip=3D0x71918086 rev=3D= 0x03 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82443BX/ZX 440BX/ZX AGPset PCI-to-PCI bridge' class =3D bridge subclass =3D PCI-PCI cbb0@pci0:2:0: class=3D0x060700 card=3D0x00eb1014 chip=3D0xac1d104c rev=3D= 0x00 hdr=3D0x02 vendor =3D 'Texas Instruments (TI)' device =3D 'PCI1251 PC Card CardBus Controller' class =3D bridge subclass =3D PCI-CardBus cbb1@pci0:2:1: class=3D0x060700 card=3D0x00eb1014 chip=3D0xac1d104c rev=3D= 0x00 hdr=3D0x02 vendor =3D 'Texas Instruments (TI)' device =3D 'PCI1251 PC Card CardBus Controller' class =3D bridge subclass =3D PCI-CardBus none0@pci0:6:0: class=3D0x040100 card=3D0x10101014 chip=3D0x60011013 rev=3D= 0x01 hdr=3D0x00 vendor =3D 'Cirrus Logic' device =3D 'CS4610 CrystalClear SoundFusion PCI Audio Accelerator' class =3D multimedia subclass =3D audio isab0@pci0:7:0: class=3D0x068000 card=3D0x00000000 chip=3D0x71108086 rev=3D= 0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82371AB/EB/MB PIIX4/4E/4M ISA Bridge' class =3D bridge atapci0@pci0:7:1: class=3D0x010180 card=3D0x00000000 chip=3D0x7111808= 6 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82371AB/EB/MB PIIX4/4E/4M IDE Controller' class =3D mass storage subclass =3D ATA uhci0@pci0:7:2: class=3D0x0c0300 card=3D0x00000000 chip=3D0x71128086 rev=3D= 0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82371AB/EB/MB PIIX4/4E/4M USB Interface' class =3D serial bus subclass =3D USB intpm0@pci0:7:3: class=3D0x068000 card=3D0x00000000 chip=3D0x7113808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82371AB/EB/MB PIIX4/4E/4M Power Management Controller' class =3D bridge none1@pci1:0:0: class=3D0x030000 card=3D0x00dd1014 chip=3D0x000510c8 rev=3D= 0x20 hdr=3D0x00 vendor =3D 'Neomagic Corporation' device =3D 'NM2200 MagicMedia 256AV' class =3D display subclass =3D VGA Here is my dmesg ( this is after It wakes from the lid being opened after it's closed, I get some ROUTE_INTERRUPT failed mesages : Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-RELEASE #4: Sun Jan 1 03:23:23 MST 2006 emorphix@lurken.pengu.in:/usr/obj/usr/src/sys/LURKEN Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (363.96-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x66a Stepping =3D 10 Features=3D0x183f9ff real memory =3D 134021120 (127 MB) avail memory =3D 120913920 (115 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 agp0: mem 0x40000000-0x43ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) cbb0: mem 0x50102000-0x50102fff irq 11 at device 2.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: mem 0x50101000-0x50101fff irq 11 at device 2.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pci0: at device 6.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfcf0-0xfcff at device 7.1 on pci0 ata0: on atapci0 ata1: on atapci0 uhci0: port 0x8400-0x841f irq 11 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered intpm0: port 0xefa0-0xefaf irq 9 at device 7.3 on pci0 intpm0: I/O mapped efa0 intpm0: intr IRQ 9 enabled revision 0 intpm0: [GIANT-LOCKED] intsmb0: on intpm0 smbus1: on intsmb0 smb0: on smbus1 intpm0: PM I/O mapped ef00 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on= isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x3bc-0x3c3 irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (port) pcm0: at port 0x530-0x537,0x388-0x38b,0x220-0x233 irq 5 drq 1,0 on isa0 pcm0: [GIANT-LOCKED] unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounters tick every 1.000 msec WARNING: apm_saver module requires apm enabled wi0: at port 0x180-0x1bf irq 11 function 0 config 1 on pccard0 wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (8.72.1) wi0: Ethernet address: 00:02:2d:b6:1c:e4 ad0: 6149MB at ata0-master UDMA33 acd0: CDROM at ata1-master PIO4 Trying to mount root from ufs:/dev/ad0s1a wi0: link state changed to DOWN wi0: detached pir0: ROUTE_INTERRUPT on resume for link 0x60 failed. pir0: ROUTE_INTERRUPT on resume for link 0x63 failed. pir0: ROUTE_INTERRUPT on resume for link 0x61 failed. wakeup from sleeping state (slept 00:00:16) wi0: at port 0x180-0x1bf irq 11 function 0 config 1 on pccard0 wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (8.72.1) wi0: Ethernet address: 00:02:2d:b6:1c:e4 this is my /boot/loader.conf: hw.cbb.start_memory=3D"0x20000000" #Without this I get an error from my PCMCIA stating that the card has no functions, with this I'm able to use my Orinoco gold card without a problem= . snd_mss_load=3D"YES" intpm_load=3D"YES" apm_saver_load=3D"YES" this is my /boot/device.hints: I had to specify these inorder to get my sound working prior to updating the BIOS, it seems to be working with it commented out now. #hint.pcm.0.at=3D"isa" #hint.pcm.0.port=3D"0x52c" #hint.pcm.0.irq=3D"5" #hint.pcm.0.drq=3D"1" #hint.pcm.0.flags=3D"0x10" hint.pcm.0.vol=3D"100" hint.fdc.0.at=3D"isa" hint.fdc.0.port=3D"0x3F0" hint.fdc.0.irq=3D"6" hint.fdc.0.drq=3D"2" hint.fd.0.at=3D"fdc0" hint.fd.0.drive=3D"0" hint.fd.1.at=3D"fdc0" hint.fd.1.drive=3D"1" hint.ata.0.at=3D"isa" hint.ata.0.port=3D"0x1F0" hint.ata.0.irq=3D"14" hint.ata.1.at=3D"isa" hint.ata.1.port=3D"0x170" hint.ata.1.irq=3D"15" hint.adv.0.at=3D"isa" hint.adv.0.disabled=3D"1" hint.bt.0.at=3D"isa" hint.bt.0.disabled=3D"1" hint.aha.0.at=3D"isa" hint.aha.0.disabled=3D"1" hint.aic.0.at=3D"isa" hint.aic.0.disabled=3D"1" hint.atkbdc.0.at=3D"isa" hint.atkbdc.0.port=3D"0x060" hint.atkbd.0.at=3D"atkbdc" hint.atkbd.0.irq=3D"1" hint.psm.0.at=3D"atkbdc" hint.psm.0.irq=3D"12" hint.vga.0.at=3D"isa" hint.sc.0.at=3D"isa" hint.sc.0.flags=3D"0x100" hint.vt.0.at=3D"isa" hint.vt.0.disabled=3D"1" hint.apm.0.disabled=3D"0" hint.acpi.0.disabled=3D"1" hint.apm.0.flags=3D"0x20" hint.sio.0.at=3D"isa" hint.sio.0.port=3D"0x3F8" hint.sio.0.flags=3D"0x10" hint.sio.0.irq=3D"4" hint.sio.1.at=3D"isa" hint.sio.1.port=3D"0x2F8" hint.sio.1.irq=3D"3" hint.sio.2.at=3D"isa" hint.sio.2.disabled=3D"1" hint.sio.2.port=3D"0x3E8" hint.sio.2.irq=3D"5" hint.sio.3.at=3D"isa" hint.sio.3.disabled=3D"1" hint.sio.3.port=3D"0x2E8" hint.sio.3.irq=3D"9" hint.ppc.0.at=3D"isa" hint.ppc.0.irq=3D"7" hint.ed.0.at=3D"isa" hint.ed.0.disabled=3D"1" hint.ed.0.port=3D"0x280" hint.ed.0.irq=3D"10" hint.ed.0.maddr=3D"0xd8000" hint.cs.0.at=3D"isa" hint.cs.0.disabled=3D"1" hint.cs.0.port=3D"0x300" hint.sn.0.at=3D"isa" hint.sn.0.disabled=3D"1" hint.sn.0.port=3D"0x300" hint.sn.0.irq=3D"10" hint.ie.0.at=3D"isa" hint.ie.0.disabled=3D"1" hint.ie.0.port=3D"0x300" hint.ie.0.irq=3D"10" hint.ie.0.maddr=3D"0xd0000" hint.fe.0.at=3D"isa" hint.fe.0.disabled=3D"1" hint.fe.0.port=3D"0x300" hint.lnc.0.at=3D"isa" hint.lnc.0.disabled=3D"1" hint.lnc.0.port=3D"0x280" hint.lnc.0.irq=3D"10" hint.lnc.0.drq=3D"0" Here is my kernel conf: machine=09=09i386 cpu=09=09I686_CPU ident=09=09lurken=09 #Console Resultion options=09=09VESA=09 options=09=09SC_HISTORY_SIZE=3D5000 options=09=09SC_ALT_MOUSE_IMAGE options=09=09SC_MOUSE_CHAR=3D0x3 options=09=09SC_PIXEL_MODE #Hardware Monitor ( SMBus ) Support device=09=09smbus device=09=09smb device=09=09iicbus device=09=09iicbb device=09=09ic device=09=09iic device=09=09iicsmb # To statically compile in device wiring instead of /boot/device.hints #hints=09=09"GENERIC.hints"=09=09# Default places to look for devices. makeoptions=09DEBUG=3D-g=09=09# Build kernel with gdb(1) debug symbols #options =09SCHED_ULE=09=09# ULE scheduler options =09SCHED_4BSD=09=09# 4BSD scheduler options =09PREEMPTION=09=09# Enable kernel thread preemption options =09INET=09=09=09# InterNETworking options =09INET6=09=09=09# IPv6 communications protocols options =09FFS=09=09=09# Berkeley Fast Filesystem options =09SOFTUPDATES=09=09# Enable FFS soft updates support options =09UFS_ACL=09=09=09# Support for access control lists options =09UFS_DIRHASH=09=09# Improve performance on big directories options =09MD_ROOT=09=09=09# MD is a potential root device options =09NFSCLIENT=09=09# Network Filesystem Client options =09NFSSERVER=09=09# Network Filesystem Server options =09NFS_ROOT=09=09# NFS usable as /, requires NFSCLIENT options =09MSDOSFS=09=09=09# MSDOS Filesystem options =09CD9660=09=09=09# ISO 9660 Filesystem options =09PROCFS=09=09=09# Process filesystem (requires PSEUDOFS) options =09PSEUDOFS=09=09# Pseudo-filesystem framework options =09GEOM_GPT=09=09# GUID Partition Tables. options =09COMPAT_43=09=09# Compatible with BSD 4.3 [KEEP THIS!] options =09COMPAT_FREEBSD4=09=09# Compatible with FreeBSD4 options =09COMPAT_FREEBSD5=09=09# Compatible with FreeBSD5 options =09SCSI_DELAY=3D5000=09=09# Delay (in ms) before probing SCSI options =09KTRACE=09=09=09# ktrace(1) support options =09SYSVSHM=09=09=09# SYSV-style shared memory options =09SYSVMSG=09=09=09# SYSV-style message queues options =09SYSVSEM=09=09=09# SYSV-style semaphores options =09_KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extension= s options =09KBD_INSTALL_CDEV=09# install a CDEV entry in /dev options =09AHC_REG_PRETTY_PRINT=09# Print register bitfields in debug =09=09=09=09=09# output. Adds ~128k to driver. options =09AHD_REG_PRETTY_PRINT=09# Print register bitfields in debug =09=09=09=09=09# output. Adds ~215k to driver. options =09ADAPTIVE_GIANT=09=09# Giant mutex is adaptive. device=09=09apic=09=09=09# I/O APIC # Bus support. device=09=09eisa device=09=09pci # Floppy drives device=09=09fdc # ATA and ATAPI devices device=09=09ata device=09=09atadisk=09=09# ATA disk drives device=09=09ataraid=09=09# ATA RAID drives device=09=09atapicd=09=09# ATAPI CDROM drives device=09=09atapifd=09=09# ATAPI floppy drives device=09=09atapist=09=09# ATAPI tape drives options =09ATA_STATIC_ID=09# Static device numbering # SCSI Controllers #device=09=09ahb=09=09# EISA AHA1742 family #device=09=09ahc=09=09# AHA2940 and onboard AIC7xxx devices #device=09=09ahd=09=09# AHA39320/29320 and onboard AIC79xx devices #device=09=09amd=09=09# AMD 53C974 (Tekram DC-390(T)) #device=09=09isp=09=09# Qlogic family #device =09ispfw=09=09# Firmware for QLogic HBAs- normally a module #device=09=09mpt=09=09# LSI-Logic MPT-Fusion #device=09=09ncr=09=09# NCR/Symbios Logic #device=09=09sym=09=09# NCR/Symbios Logic (newer chipsets + those of `ncr') #device=09=09trm=09=09# Tekram DC395U/UW/F DC315U adapters #device=09=09adv=09=09# Advansys SCSI adapters #device=09=09adw=09=09# Advansys wide SCSI adapters #device=09=09aha=09=09# Adaptec 154x SCSI adapters #device=09=09aic=09=09# Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device=09=09bt=09=09# Buslogic/Mylex MultiMaster SCSI adapters #device=09=09ncv=09=09# NCR 53C500 #device=09=09nsp=09=09# Workbit Ninja SCSI-3 #device=09=09stg=09=09# TMC 18C30/18C50 # SCSI peripherals device=09=09scbus=09=09# SCSI bus (required for SCSI) #device=09=09ch=09=09# SCSI media changers #device=09=09da=09=09# Direct Access (disks) #device=09=09sa=09=09# Sequential Access (tape etc) device=09=09cd=09=09# CD #device=09=09pass=09=09# Passthrough device (direct SCSI access) #device=09=09ses=09=09# SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device=09=09amr=09=09# AMI MegaRAID #device=09=09arcmsr=09=09# Areca SATA II RAID #device=09=09asr=09=09# DPT SmartRAID V, VI and Adaptec SCSI RAID #device=09=09ciss=09=09# Compaq Smart RAID 5* #device=09=09dpt=09=09# DPT Smartcache III, IV - See NOTES for options #device=09=09hptmv=09=09# Highpoint RocketRAID 182x #device=09=09iir=09=09# Intel Integrated RAID #device=09=09ips=09=09# IBM (Adaptec) ServeRAID #device=09=09mly=09=09# Mylex AcceleRAID/eXtremeRAID #device=09=09twa=09=09# 3ware 9000 series PATA/SATA RAID # RAID controllers #device=09=09aac=09=09# Adaptec FSA RAID #device=09=09aacp=09=09# SCSI passthrough for aac (requires CAM) #device=09=09ida=09=09# Compaq Smart RAID #device=09=09mlx=09=09# Mylex DAC960 family #device=09=09pst=09=09# Promise Supertrak SX6000 #device=09=09twe=09=09# 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device=09=09atkbdc=09=09# AT keyboard controller device=09=09atkbd=09=09# AT keyboard device=09=09psm=09=09# PS/2 mouse device=09=09vga=09=09# VGA video card driver device=09=09splash=09=09# Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device=09=09sc # Enable this for the pcvt (VT220 compatible) console driver #device=09=09vt #options =09XSERVER=09=09# support for X server on a vt console #options =09FAT_CURSOR=09# start with block cursor device=09=09agp=09=09# support several AGP chipsets # Power management support (see NOTES for more options) device=09=09apm # Add suspend/resume support for the i8254. device=09=09pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device=09=09cbb=09=09# cardbus (yenta) bridge device=09=09pccard=09=09# PC Card (16-bit) bus device=09=09cardbus=09=09# CardBus (32-bit) bus # Serial (COM) ports device=09=09sio=09=09# 8250, 16[45]50 based serial ports # Parallel port device=09=09ppc device=09=09ppbus=09=09# Parallel port bus (required) device=09=09lpt=09=09# Printer #device=09=09plip=09=09# TCP/IP over parallel device=09=09ppi=09=09# Parallel port interface device #device=09=09vpo=09=09# Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device=09=09puc # PCI Ethernet NICs. #device=09=09de=09=09# DEC/Intel DC21x4x (``Tulip'') #device=09=09em=09=09# Intel PRO/1000 adapter Gigabit Ethernet Card #device=09=09ixgb=09=09# Intel PRO/10GbE Ethernet Card #device=09=09txp=09=09# 3Com 3cR990 (``Typhoon'') #device=09=09vx=09=09# 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs= ! device=09=09miibus=09=09# MII bus support #device=09=09bfe=09=09# Broadcom BCM440x 10/100 Ethernet #device=09=09bge=09=09# Broadcom BCM570xx Gigabit Ethernet device=09=09dc=09=09# DEC/Intel 21143 and various workalikes device=09=09fxp=09=09# Intel EtherExpress PRO/100B (82557, 82558) device=09=09lge=09=09# Level 1 LXT1001 gigabit Ethernet device=09=09nge=09=09# NatSemi DP83820 gigabit Ethernet #device=09=09nve=09=09# nVidia nForce MCP on-board Ethernet Networking #device=09=09pcn=09=09# AMD Am79C97x PCI 10/100(precedence over 'lnc') device=09=09re=09=09# RealTek 8139C+/8169/8169S/8110S device=09=09rl=09=09# RealTek 8129/8139 device=09=09sf=09=09# Adaptec AIC-6915 (``Starfire'') device=09=09sis=09=09# Silicon Integrated Systems SiS 900/SiS 7016 device=09=09sk=09=09# SysKonnect SK-984x & SK-982x gigabit Ethernet device=09=09ste=09=09# Sundance ST201 (D-Link DFE-550TX) device=09=09ti=09=09# Alteon Networks Tigon I/II gigabit Ethernet device=09=09tl=09=09# Texas Instruments ThunderLAN device=09=09tx=09=09# SMC EtherPower II (83c170 ``EPIC'') device=09=09vge=09=09# VIA VT612x gigabit Ethernet device=09=09vr=09=09# VIA Rhine, Rhine II device=09=09wb=09=09# Winbond W89C840F device=09=09xl=09=09# 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device=09=09cs=09=09# Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device=09=09ed=09=09# NE[12]000, SMC Ultra, 3c503, DS8390 cards device=09=09ex=09=09# Intel EtherExpress Pro/10 and Pro/10+ device=09=09ep=09=09# Etherlink III based cards device=09=09fe=09=09# Fujitsu MB8696x based cards device=09=09ie=09=09# EtherExpress 8/16, 3C507, StarLAN 10 etc. device=09=09lnc=09=09# NE2100, NE32-VL Lance Ethernet cards device=09=09sn=09=09# SMC's 9000 series of Ethernet chips device=09=09xe=09=09# Xircom pccard Ethernet # ISA devices that use the old ISA shims #device=09=09le # Wireless NIC cards device=09=09wlan=09=09# 802.11 support device=09=09wlan_wep=09# 802.11 WEP Support device=09=09an=09=09# Aironet 4500/4800 802.11 wireless NICs. device=09=09awi=09=09# BayStack 660 and others device=09=09ral=09=09# Ralink Technology RT2500 wireless NICs. device=09=09wi=09=09# WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device=09=09wl=09=09# Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device=09=09loop=09=09# Network loopback device=09=09random=09=09# Entropy device device=09=09ether=09=09# Ethernet support device=09=09sl=09=09# Kernel SLIP device=09=09ppp=09=09# Kernel PPP device=09=09tun=09=09# Packet tunnel. device=09=09pty=09=09# Pseudo-ttys (telnet etc) device=09=09md=09=09# Memory "disks" device=09=09gif=09=09# IPv6 and IPv4 tunneling #device=09=09faith=09=09# IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device=09=09bpf=09=09# Berkeley packet filter # USB support device=09=09uhci=09=09# UHCI PCI->USB interface device=09=09ohci=09=09# OHCI PCI->USB interface #device=09=09ehci=09=09# EHCI PCI->USB interface (USB 2.0) device=09=09usb=09=09# USB Bus (required) #device=09=09udbp=09=09# USB Double Bulk Pipe devices device=09=09ugen=09=09# Generic device=09=09uhid=09=09# "Human Interface Devices" device=09=09ukbd=09=09# Keyboard device=09=09ulpt=09=09# Printer device=09=09umass=09=09# Disks/Mass storage - Requires scbus and da device=09=09ums=09=09# Mouse device=09=09ural=09=09# Ralink Technology RT2500USB wireless NICs device=09=09urio=09=09# Diamond Rio 500 MP3 player device=09=09uscanner=09# Scanners # USB Ethernet, requires miibus device=09=09aue=09=09# ADMtek USB Ethernet device=09=09axe=09=09# ASIX Electronics USB Ethernet device=09=09cdce=09=09# Generic USB over Ethernet device=09=09cue=09=09# CATC USB Ethernet device=09=09kue=09=09# Kawasaki LSI USB Ethernet device=09=09rue=09=09# RealTek RTL8150 USB Ethernet # FireWire support #device=09=09firewire=09# FireWire bus code #device=09=09sbp=09=09# SCSI over FireWire (Requires scbus and da) #device=09=09fwe=09=09# Ethernet over FireWire (non-standard!) From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 09:01:57 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F74A16A41F; Thu, 5 Jan 2006 09:01:57 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1FEC43D55; Thu, 5 Jan 2006 09:01:56 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k0590tpJ006134; Thu, 5 Jan 2006 01:01:45 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k0590Uhs003395; Thu, 5 Jan 2006 01:00:30 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k0590U1t003394; Thu, 5 Jan 2006 01:00:30 -0800 (PST) (envelope-from jrhett) Date: Thu, 5 Jan 2006 01:00:30 -0800 From: Jo Rhett To: Mark Linimon Message-ID: <20060105090030.GC1358@svcolo.com> Mail-Followup-To: Mark Linimon , Wilko Bulte , stable@freebsd.org, current References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> <20051222211019.GI39174@svcolo.com> <20051223191320.GA11172@soaustin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051223191320.GA11172@soaustin.net> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: Wilko Bulte , stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 09:01:57 -0000 On Fri, Dec 23, 2005 at 01:13:20PM -0600, Mark Linimon wrote: > On Thu, Dec 22, 2005 at 01:10:19PM -0800, Jo Rhett wrote: > > I and many others have offered to work on this. The core team has > > repeatedly stated that they won't integrate the efforts > > Please provide hard evidence for this assertion. Merely repeating it will > not be sufficiently convincing. I would like to see _specific_ references > (email or other documentation) that that is _exactly_ what core, or anyone > else, has said. I cannot recall any such thing on any of the mailing lists > that I have monitored for the past several years. > > Without that, my high degree of skepticism about this claim will remain. Sorry for the late reply. I saw this and realized that not only will we apparently need to rehash the ball-busting thread giant topic again, but now I need to prove it ever existed Ugh. Yeah, I'll do the research sometime early next week. Mostly to find archives with useful threading so that you can read all the way down the trafic tree. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 09:07:31 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E25816A41F; Thu, 5 Jan 2006 09:07:31 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACB8B43D45; Thu, 5 Jan 2006 09:07:30 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k0596jpP006393; Thu, 5 Jan 2006 01:07:30 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k05965XW004653; Thu, 5 Jan 2006 01:06:05 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k05965Se004652; Thu, 5 Jan 2006 01:06:05 -0800 (PST) (envelope-from jrhett) Date: Thu, 5 Jan 2006 01:06:05 -0800 From: Jo Rhett To: Peter Jeremy Message-ID: <20060105090605.GD1358@svcolo.com> References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> <20051222211019.GI39174@svcolo.com> <20051222213041.GA5746@odin.ac.hmc.edu> <20051222220532.GL39174@svcolo.com> <20051223043820.GG77268@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051223043820.GG77268@cirb503493.alcatel.com.au> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 09:07:31 -0000 On Fri, Dec 23, 2005 at 03:38:20PM +1100, Peter Jeremy wrote: > I agree with Brooks. I don't recall ever seeing a message from -core > (or anyone else talking on behalf of the Project) stating that code to > make binary updates possible would not be integrated. For that matter, > I don't recall ever seeing code offered to implement such a feature. As stated before, let me find some threaded archives and I'll find the relevant topics. Perhaps it wasn't -core that vetoed it, but it was harshly fought against for ivory tower reasons, and nobody from -core ever stood up to show interest. > Core OS packages have been discussed but I don't recall the idea ever > being vetoed. Some work have been done in breaking bits of the base OS > out into packages (perl, games and UUCP come to mind) but packaging the > entire system is a major undertaking. In any case, I don't see how > packaging the system would help you. Taking Solaris as an example of > an OS which is broken up into lots of packages, patches don't replace > whole packages, they replace individual files. Obviously the details need to be ironed out. The current freebsd package system is certainly missing a few key features (in my mind) but most everyone agrees on the basics. Packaged cores allow identification of "what you have". Package databases can store "what you have changed". Package databases can store "how to back out the change". This is pretty much the only things that prevent freebsd-update from working perfectly in production environments, to name the most obvious candidate for adapting to this job. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 09:10:44 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C249116A41F; Thu, 5 Jan 2006 09:10:44 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6793743D49; Thu, 5 Jan 2006 09:10:44 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k0599tpQ006510; Thu, 5 Jan 2006 01:10:39 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k0599fOE005245; Thu, 5 Jan 2006 01:09:41 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k0599exY005241; Thu, 5 Jan 2006 01:09:40 -0800 (PST) (envelope-from jrhett) Date: Thu, 5 Jan 2006 01:09:40 -0800 From: Jo Rhett To: "Matthew D. Fuller" Message-ID: <20060105090940.GE1358@svcolo.com> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <20051218023725.GM63497@over-yonder.net> <20051222210904.GH39174@svcolo.com> <20051223030813.GD63497@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051223030813.GD63497@over-yonder.net> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 09:10:44 -0000 On Thu, Dec 22, 2005 at 09:08:13PM -0600, Matthew D. Fuller wrote: > Having done full OS upgrades a number of times, I can't remember the > last time it took more than 5 or 10 minutes (during most of which the When the servers are in 17 countries around the world, with no CD-ROM access. You keep missing the point about "not your home computer". > > Back to the point, the comments aren't "bad". Your idea that binary > > operating system upgrades from ISO are "easier" demonstrates that > > you're talking about home computers, not production servers. > > Oh, no. Heck, I find that upgrades from SOURCE are "easier". In > fact, just last month I bought my first CD burner, so it wasn't until > a few weeks ago that I even burned my first ISO (and that, just to > test the burner and figure out how to do it), and I've never booted or > installed off one. For small groups of servers, I NFS mount > installworlds, and for larger groups, I rdist out binaries. But it > always comes from source. You can't do source installations on flash-based systems. You can't do NFS across the Internet (we don't even have RPC working at all on production systems) -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 09:12:00 2006 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C197D16A420; Thu, 5 Jan 2006 09:11:59 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id E86C543D6B; Thu, 5 Jan 2006 09:11:50 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k059B5pR006600; Thu, 5 Jan 2006 01:11:50 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k059AspD005490; Thu, 5 Jan 2006 01:10:54 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k059AsHl005489; Thu, 5 Jan 2006 01:10:54 -0800 (PST) (envelope-from jrhett) Date: Thu, 5 Jan 2006 01:10:54 -0800 From: Jo Rhett To: "Matthew D. Fuller" Message-ID: <20060105091054.GF1358@svcolo.com> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <20051218023725.GM63497@over-yonder.net> <20051222210904.GH39174@svcolo.com> <20051223030813.GD63497@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051223030813.GD63497@over-yonder.net> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: stable@FreeBSD.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 09:12:00 -0000 > On Thu, Dec 22, 2005 at 01:09:04PM -0800 I heard the voice of > Jo Rhett, and lo! it spake thus: > > > > No, you're missing the point. More core OS upgrades means less > > incremental patches (which are easier to apply than a full update). On Thu, Dec 22, 2005 at 09:08:13PM -0600, Matthew D. Fuller wrote: > Right. I don't understand how B follows A here. > > These patches come from where? Security advisories, mailing list > discussions, and eating too much beef right before bed and waking up > at 2am with brilliant ideas? Why would there be less of them, just > because RELENG_X_Y_RELEASE tags are laid down more often? FreeBSD provides patches for two major OS revisions, right? If you have more OS revisions in less time, then you have a smaller window of support time. Simple. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 09:26:31 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 315D016A41F; Thu, 5 Jan 2006 09:26:31 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E41E43D4C; Thu, 5 Jan 2006 09:26:30 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k059PupC007295; Thu, 5 Jan 2006 01:26:29 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k059Omnt008120; Thu, 5 Jan 2006 01:24:48 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k059OmHL008119; Thu, 5 Jan 2006 01:24:48 -0800 (PST) (envelope-from jrhett) Date: Thu, 5 Jan 2006 01:24:48 -0800 From: Jo Rhett To: "Daniel O'Connor" Message-ID: <20060105092448.GH1358@svcolo.com> Mail-Followup-To: Daniel O'Connor , freebsd-stable@freebsd.org, Chuck Swiger , stable@freebsd.org, current References: <43A266E5.3080103@samsco.org> <43AB1E65.2030501@mac.com> <20051222221202.GM39174@svcolo.com> <200512231136.12471.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512231136.12471.doconnor@gsoft.com.au> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: stable@freebsd.org, freebsd-stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 09:26:31 -0000 On Fri, Dec 23, 2005 at 11:36:11AM +1030, Daniel O'Connor wrote: > On each 'client' PC.. > NFS mount /usr/src and /usr/obj > installkernel > reboot > installworld Works fine on home computers behind firewalls. Useless on public servers that don't run RPC. Useless on flash-based servers where minimizing writes is necessary. (mergemaster does far far far too many writes) > You are putting words in the mouth of core@ - Sorry. As said before, the topic is always struck down and nobody from core has ever stood up to say "we'll support this". I don't know whose on core this week, nor will I at any given time. I just know that core has either struck it down or been Silent. > I find it very hard to believe > that core would suggest someone NOT implement a good framework for doing full > binary upgrades via the network. A good binary update mechanism shouldn't be just the network. Updates from flash devices, ISO images, etc should all work much the same way. > Unless you mean "core@ said they would not support packaging the base" which > is different. People have clearly identified the problems that prevent a useful binary update mechanism from working, and what they need from core. Some have asked for core packages, others have other ideas, and some have said "anything that gives me versioning ability" and > > For binary upgrades without booting from CD-ROM to be possible, we need > > versioning of some sort at the OS level. Core OS packages are the most > > This is not true - I don't see it as being mandatory to be able to apply > binary updates. (Case in point - freebsd-update works fine without it) freebsd-update works "fine" if you run GENERIC with no build options. Back to "useful for home computers". freebsd-update is hampered by the exact problems I'm listing here. Difficulty determining "what I have", no method to store "what I did" and no effective backout mechanism to speak of. Nobody that I know cares whether or not the solution manifests as core os packages, but some sort of core versioning ability has to be developed and supported by the core. > > popular suggestion, but not the only path. Every year this topic comes up > > and gets struck down again. > > Yes, because a) it isn't necessary, b) it may not solve the problem, c) there > are no patches to evaluate. > > I think the people suggesting it see it as a panacea to fix their problems but > haven't fully evaluated it. You're arguing my own points. Again, nobody (that I know) cares that it manifests as core OS packages. Certainly the existing package system used for ports wouldn't work as-is for this task. But the have/did/undo problems remain to be solved. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 09:26:31 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 315D016A41F; Thu, 5 Jan 2006 09:26:31 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E41E43D4C; Thu, 5 Jan 2006 09:26:30 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k059PupC007295; Thu, 5 Jan 2006 01:26:29 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k059Omnt008120; Thu, 5 Jan 2006 01:24:48 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k059OmHL008119; Thu, 5 Jan 2006 01:24:48 -0800 (PST) (envelope-from jrhett) Date: Thu, 5 Jan 2006 01:24:48 -0800 From: Jo Rhett To: "Daniel O'Connor" Message-ID: <20060105092448.GH1358@svcolo.com> Mail-Followup-To: Daniel O'Connor , freebsd-stable@freebsd.org, Chuck Swiger , stable@freebsd.org, current References: <43A266E5.3080103@samsco.org> <43AB1E65.2030501@mac.com> <20051222221202.GM39174@svcolo.com> <200512231136.12471.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512231136.12471.doconnor@gsoft.com.au> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: stable@freebsd.org, freebsd-stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 09:26:31 -0000 On Fri, Dec 23, 2005 at 11:36:11AM +1030, Daniel O'Connor wrote: > On each 'client' PC.. > NFS mount /usr/src and /usr/obj > installkernel > reboot > installworld Works fine on home computers behind firewalls. Useless on public servers that don't run RPC. Useless on flash-based servers where minimizing writes is necessary. (mergemaster does far far far too many writes) > You are putting words in the mouth of core@ - Sorry. As said before, the topic is always struck down and nobody from core has ever stood up to say "we'll support this". I don't know whose on core this week, nor will I at any given time. I just know that core has either struck it down or been Silent. > I find it very hard to believe > that core would suggest someone NOT implement a good framework for doing full > binary upgrades via the network. A good binary update mechanism shouldn't be just the network. Updates from flash devices, ISO images, etc should all work much the same way. > Unless you mean "core@ said they would not support packaging the base" which > is different. People have clearly identified the problems that prevent a useful binary update mechanism from working, and what they need from core. Some have asked for core packages, others have other ideas, and some have said "anything that gives me versioning ability" and > > For binary upgrades without booting from CD-ROM to be possible, we need > > versioning of some sort at the OS level. Core OS packages are the most > > This is not true - I don't see it as being mandatory to be able to apply > binary updates. (Case in point - freebsd-update works fine without it) freebsd-update works "fine" if you run GENERIC with no build options. Back to "useful for home computers". freebsd-update is hampered by the exact problems I'm listing here. Difficulty determining "what I have", no method to store "what I did" and no effective backout mechanism to speak of. Nobody that I know cares whether or not the solution manifests as core os packages, but some sort of core versioning ability has to be developed and supported by the core. > > popular suggestion, but not the only path. Every year this topic comes up > > and gets struck down again. > > Yes, because a) it isn't necessary, b) it may not solve the problem, c) there > are no patches to evaluate. > > I think the people suggesting it see it as a panacea to fix their problems but > haven't fully evaluated it. You're arguing my own points. Again, nobody (that I know) cares that it manifests as core OS packages. Certainly the existing package system used for ports wouldn't work as-is for this task. But the have/did/undo problems remain to be solved. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 09:27:05 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C4B816A48C; Thu, 5 Jan 2006 09:27:05 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14AF443D48; Thu, 5 Jan 2006 09:27:05 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k059QtpD007331; Thu, 5 Jan 2006 01:27:04 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k059QBdt008408; Thu, 5 Jan 2006 01:26:11 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k059QBwk008407; Thu, 5 Jan 2006 01:26:11 -0800 (PST) (envelope-from jrhett) Date: Thu, 5 Jan 2006 01:26:11 -0800 From: Jo Rhett To: "Matthew D. Fuller" Message-ID: <20060105092611.GI1358@svcolo.com> Mail-Followup-To: "Matthew D. Fuller" , "Patrick M. Hausen" , Daniel O'Connor , freebsd-stable@freebsd.org, current References: <200512231136.12471.doconnor@gsoft.com.au> <200512230851.jBN8pFVv060458@hugo10.ka.punkt.de> <20051223085657.GF63497@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051223085657.GF63497@over-yonder.net> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: freebsd-stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 09:27:05 -0000 > Patrick M. Hausen, and lo! it spake thus: > > Any suggestions for an alternative to NFS if your 'client' servers > > are located "all over the world" and you want to installworld across > > the Internet? I was planning to use NFS/TCP secured by IPSec > > transport mode, but anything less complicated would be greatly > > appreciated ;-) On Fri, Dec 23, 2005 at 02:56:57AM -0600, Matthew D. Fuller wrote: > This is one of the situations where r{dist,sync}'ing out the binaries > makes more sense than NFS mounting and running installworld (which > would be awful awful slow, above and beyond security and convenience > issues). This works fine for small patches (ie cvs patch last year). How do you handle configuration changes/comparisons? (ie mergemaster stuff?) -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 09:34:07 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7348D16A41F; Thu, 5 Jan 2006 09:34:07 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77BBB43D4C; Thu, 5 Jan 2006 09:34:00 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k059WtpF007651; Thu, 5 Jan 2006 01:33:19 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k059WLCL009640; Thu, 5 Jan 2006 01:32:21 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k059WK3J009637; Thu, 5 Jan 2006 01:32:20 -0800 (PST) (envelope-from jrhett) Date: Thu, 5 Jan 2006 01:32:20 -0800 From: Jo Rhett To: "Daniel O'Connor" Message-ID: <20060105093220.GJ1358@svcolo.com> Mail-Followup-To: Daniel O'Connor , freebsd-stable@freebsd.org, Scott Long , Peter Jeremy , stable@freebsd.org, K?vesd?n G?bor , current References: <43A266E5.3080103@samsco.org> <43A4B91D.8040304@samsco.org> <20051222211730.GK39174@svcolo.com> <200512231126.51500.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512231126.51500.doconnor@gsoft.com.au> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: freebsd-stable@freebsd.org, current , Peter Jeremy , stable@freebsd.org, K?vesd?n G?bor Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 09:34:07 -0000 > On Fri, 23 Dec 2005 07:47, Jo Rhett wrote: > > But FreeBSD Update suffers from all of the same limitations that I've been > > describing because of lack of integration with the Core OS. > > > > 1. modified kernels are foobar > > ..yet are practically mandatory on production systems > > > > 2. modified sources are foobar > > ..yet many common production situations require source compilation > > options On Fri, Dec 23, 2005 at 11:26:44AM +1030, Daniel O'Connor wrote: > How do you expect these two to be handled in a binary upgrade? > I can't see how it's possible.. Look around. Every major commercial OS does it just fine. Most of the open source OSes do it just fine. Debian had probably the easiest to use system, and they've risen, owned the world and fallen all while FreeBSD has been debating this issue. > I don't think integrating it with the core OS (whatever that means) will > magically fix this. If you knew what it meant, you would understand why it would help. > Not having run jails I am not very qualified to comment Exactly. Sorry, not trying to be rude but if you have never felt the pain don't try and say it doesn't exist. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 09:34:07 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7348D16A41F; Thu, 5 Jan 2006 09:34:07 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77BBB43D4C; Thu, 5 Jan 2006 09:34:00 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k059WtpF007651; Thu, 5 Jan 2006 01:33:19 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k059WLCL009640; Thu, 5 Jan 2006 01:32:21 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k059WK3J009637; Thu, 5 Jan 2006 01:32:20 -0800 (PST) (envelope-from jrhett) Date: Thu, 5 Jan 2006 01:32:20 -0800 From: Jo Rhett To: "Daniel O'Connor" Message-ID: <20060105093220.GJ1358@svcolo.com> Mail-Followup-To: Daniel O'Connor , freebsd-stable@freebsd.org, Scott Long , Peter Jeremy , stable@freebsd.org, K?vesd?n G?bor , current References: <43A266E5.3080103@samsco.org> <43A4B91D.8040304@samsco.org> <20051222211730.GK39174@svcolo.com> <200512231126.51500.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512231126.51500.doconnor@gsoft.com.au> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: freebsd-stable@freebsd.org, current , Peter Jeremy , stable@freebsd.org, K?vesd?n G?bor Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 09:34:07 -0000 > On Fri, 23 Dec 2005 07:47, Jo Rhett wrote: > > But FreeBSD Update suffers from all of the same limitations that I've been > > describing because of lack of integration with the Core OS. > > > > 1. modified kernels are foobar > > ..yet are practically mandatory on production systems > > > > 2. modified sources are foobar > > ..yet many common production situations require source compilation > > options On Fri, Dec 23, 2005 at 11:26:44AM +1030, Daniel O'Connor wrote: > How do you expect these two to be handled in a binary upgrade? > I can't see how it's possible.. Look around. Every major commercial OS does it just fine. Most of the open source OSes do it just fine. Debian had probably the easiest to use system, and they've risen, owned the world and fallen all while FreeBSD has been debating this issue. > I don't think integrating it with the core OS (whatever that means) will > magically fix this. If you knew what it meant, you would understand why it would help. > Not having run jails I am not very qualified to comment Exactly. Sorry, not trying to be rude but if you have never felt the pain don't try and say it doesn't exist. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 09:38:20 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7103D16A423; Thu, 5 Jan 2006 09:38:20 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3020D43D83; Thu, 5 Jan 2006 09:38:05 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k059btpP007872; Thu, 5 Jan 2006 01:38:04 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k059bRGl010613; Thu, 5 Jan 2006 01:37:27 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k059bRGR010612; Thu, 5 Jan 2006 01:37:27 -0800 (PST) (envelope-from jrhett) Date: Thu, 5 Jan 2006 01:37:27 -0800 From: Jo Rhett To: Peter Jeremy Message-ID: <20060105093727.GK1358@svcolo.com> References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> <43A492B6.6050305@t-hosting.hu> <20051217232856.GT77268@cirb503493.alcatel.com.au> <43A4B91D.8040304@samsco.org> <20051222211730.GK39174@svcolo.com> <20051223045648.GH77268@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051223045648.GH77268@cirb503493.alcatel.com.au> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: stable@freebsd.org, current Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 09:38:20 -0000 > On Thu, 2005-Dec-22 13:17:30 -0800, Jo Rhett wrote: > >But FreeBSD Update suffers from all of the same limitations that I've been > >describing because of lack of integration with the Core OS. > > > >1. modified kernels are foobar > > ..yet are practically mandatory on production systems > > > >2. modified sources are foobar > > ..yet many common production situations require source compilation options On Fri, Dec 23, 2005 at 03:56:48PM +1100, Peter Jeremy wrote: > So you want to be able to make arbitrary changes you your source code > and compilation options and then expect the FreeBSD project to provide > a tool that will apply binary fixes to the resultant executables? No. I want a binary update mechanism. Obviously if we have local configuration options we'll have to compile our own binaries. But doing the work of tracking system updates currently requires us to build our own patch tracking mechanism, and then re-write it for every new release. If the core OS supported the necessary features for handling patches to the core, then we could stop building all these tools ourselves and focus on real work. > I don't know that modified kernels are mandatory. A lot of work has > been going on to reduce the need to re-compile the kernel for common > situations. Likewise, I don't know that "many common" and "require" > go together - IMHO, 'desire' or 'would be nice' are more appropriate > descriptions. Would you care to provide some details of what you > believe can be done to reduce your need to re-compile the OS. It's not a recompile issue. It's a tracking/update/backout issue. I don't mind recompiling, if I could somehow push the updates to all the right systems and they would have it stored somewhere that they were patched... > I'm not sure that FreeBSD Update is totally unusable for you. If you > have the situation where you have a modified FreeBSD that you need to > roll out to a large number of hosts, you just need to have your own > FreeBSD Update server - you test the changes in your environment and > then roll them out as you require. I've looked it over, and our current mechanism works better than freebsd-update at the moment. Always subject to change. > I don't run jails so I'm not familiar with the problems here. Maybe you'd > like to explain the problems you run into. It's really just the same problem. Some mechanism to find out what is, and store what has been done. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 09:47:47 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 552B916A41F; Thu, 5 Jan 2006 09:47:47 +0000 (GMT) (envelope-from hausen@punkt.de) Received: from gate.ka.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F99C43D5D; Thu, 5 Jan 2006 09:47:46 +0000 (GMT) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [10.0.0.110]) by gate.ka.punkt.de with ESMTP id k059ljba024233; Thu, 5 Jan 2006 10:47:45 +0100 (CET) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.12.10/8.12.10) with ESMTP id k059lcuL024289; Thu, 5 Jan 2006 10:47:38 +0100 (CET) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.12.10/8.12.10/Submit) id k059lctk024288; Thu, 5 Jan 2006 10:47:38 +0100 (CET) (envelope-from ry93) From: "Patrick M. Hausen" Message-Id: <200601050947.k059lctk024288@hugo10.ka.punkt.de> In-Reply-To: <20060105093220.GJ1358@svcolo.com> To: Jo Rhett Date: Thu, 5 Jan 2006 10:47:38 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL99f (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: stable@freebsd.org, freebsd-stable@freebsd.org, current , K?vesd?n G?bor , Peter Jeremy Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 09:47:47 -0000 Hello! > > > 1. modified kernels are foobar > > > ..yet are practically mandatory on production systems > Look around. Every major commercial OS does it just fine. While I agree with much of your reasoning, I know exactly zero people running a modified kernel of any version of Windows, Mac OS X or Solaris, to name just three commercial OS's. And third party drivers (which one could count as "kernel modifications") did fail and will fail sometimes in weird ways even for minor version upgrades/patches. BTDT - Windows Services Packs, Solaris patches, Mac OS X updates, reboot, *boom*, because some hardware suppliers driver didn't adhere to the OS manufacturer's standards or because the latter silently changed something undocumented. While I would appreciate a packaged core system or at least a better definition of "core system" at all, I strongly believe that binary updating a custom kernel is impossible. With "better definition of core system" I mean, if you have a long lived production system that you might have upgraded from 4.x to 5.x to 6.0, you will have a lot of cruft lying on your filesystem that once was part of the "core" and now isn't. And there is no simple and automated way to find out what to delete ... Just some thoughts, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25 Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 09:47:47 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 552B916A41F; Thu, 5 Jan 2006 09:47:47 +0000 (GMT) (envelope-from hausen@punkt.de) Received: from gate.ka.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F99C43D5D; Thu, 5 Jan 2006 09:47:46 +0000 (GMT) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [10.0.0.110]) by gate.ka.punkt.de with ESMTP id k059ljba024233; Thu, 5 Jan 2006 10:47:45 +0100 (CET) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.12.10/8.12.10) with ESMTP id k059lcuL024289; Thu, 5 Jan 2006 10:47:38 +0100 (CET) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.12.10/8.12.10/Submit) id k059lctk024288; Thu, 5 Jan 2006 10:47:38 +0100 (CET) (envelope-from ry93) From: "Patrick M. Hausen" Message-Id: <200601050947.k059lctk024288@hugo10.ka.punkt.de> In-Reply-To: <20060105093220.GJ1358@svcolo.com> To: Jo Rhett Date: Thu, 5 Jan 2006 10:47:38 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL99f (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: stable@freebsd.org, freebsd-stable@freebsd.org, current , K?vesd?n G?bor , Peter Jeremy Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 09:47:47 -0000 Hello! > > > 1. modified kernels are foobar > > > ..yet are practically mandatory on production systems > Look around. Every major commercial OS does it just fine. While I agree with much of your reasoning, I know exactly zero people running a modified kernel of any version of Windows, Mac OS X or Solaris, to name just three commercial OS's. And third party drivers (which one could count as "kernel modifications") did fail and will fail sometimes in weird ways even for minor version upgrades/patches. BTDT - Windows Services Packs, Solaris patches, Mac OS X updates, reboot, *boom*, because some hardware suppliers driver didn't adhere to the OS manufacturer's standards or because the latter silently changed something undocumented. While I would appreciate a packaged core system or at least a better definition of "core system" at all, I strongly believe that binary updating a custom kernel is impossible. With "better definition of core system" I mean, if you have a long lived production system that you might have upgraded from 4.x to 5.x to 6.0, you will have a lot of cruft lying on your filesystem that once was part of the "core" and now isn't. And there is no simple and automated way to find out what to delete ... Just some thoughts, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25 Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 10:42:37 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D72716A41F; Thu, 5 Jan 2006 10:42:37 +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 8501F43D46; Thu, 5 Jan 2006 10:42:34 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp232-237.lns2.adl4.internode.on.net [203.122.232.237]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k05AgBiw082555 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 5 Jan 2006 21:12:12 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Jo Rhett Date: Thu, 5 Jan 2006 21:11:58 +1030 User-Agent: KMail/1.8.3 References: <43A266E5.3080103@samsco.org> <200512231126.51500.doconnor@gsoft.com.au> <20060105093220.GJ1358@svcolo.com> In-Reply-To: <20060105093220.GJ1358@svcolo.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4565128.1sz4yHWUgZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601052112.09446.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: freebsd-stable@freebsd.org, current , Peter Jeremy , stable@freebsd.org, K?vesd?n G?bor Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 10:42:37 -0000 --nextPart4565128.1sz4yHWUgZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 5 Jan 2006 20:02, Jo Rhett wrote: > On Fri, Dec 23, 2005 at 11:26:44AM +1030, Daniel O'Connor wrote: > > How do you expect these two to be handled in a binary upgrade? > > I can't see how it's possible.. > > Look around. Every major commercial OS does it just fine. Most of the > open source OSes do it just fine. Debian had probably the easiest to use > system, and they've risen, owned the world and fallen all while FreeBSD h= as > been debating this issue. You appear to be misunderstanding what I said. I'm not arguing binary upgrades shouldn't be done but I'm suggesting that i= t=20 isn't NECESSARY to version and package the base install to do it. > > I don't think integrating it with the core OS (whatever that means) will > > magically fix this. > > If you knew what it meant, you would understand why it would help. Ah what a great explanation of what is meant. There are several people who don't know what is meant here and I haven't se= en=20 a decent explanation forthcoming. > > Not having run jails I am not very qualified to comment > > Exactly. Sorry, not trying to be rude but if you have never felt the pain > don't try and say it doesn't exist. Just because I don't run jails doesn't mean I don't know the pain of upgrad= ing=20 a system. =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 --nextPart4565128.1sz4yHWUgZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDvPgB5ZPcIHs/zowRAptBAJ9nSXeZUYkCicFxhv5CrNcuAQ7e/gCdFTXh oT226YogorSiHAgu2EmN0hs= =SGCC -----END PGP SIGNATURE----- --nextPart4565128.1sz4yHWUgZ-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 10:42:37 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D72716A41F; Thu, 5 Jan 2006 10:42:37 +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 8501F43D46; Thu, 5 Jan 2006 10:42:34 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp232-237.lns2.adl4.internode.on.net [203.122.232.237]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k05AgBiw082555 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 5 Jan 2006 21:12:12 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Jo Rhett Date: Thu, 5 Jan 2006 21:11:58 +1030 User-Agent: KMail/1.8.3 References: <43A266E5.3080103@samsco.org> <200512231126.51500.doconnor@gsoft.com.au> <20060105093220.GJ1358@svcolo.com> In-Reply-To: <20060105093220.GJ1358@svcolo.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4565128.1sz4yHWUgZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601052112.09446.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: freebsd-stable@freebsd.org, current , Peter Jeremy , stable@freebsd.org, K?vesd?n G?bor Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 10:42:37 -0000 --nextPart4565128.1sz4yHWUgZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 5 Jan 2006 20:02, Jo Rhett wrote: > On Fri, Dec 23, 2005 at 11:26:44AM +1030, Daniel O'Connor wrote: > > How do you expect these two to be handled in a binary upgrade? > > I can't see how it's possible.. > > Look around. Every major commercial OS does it just fine. Most of the > open source OSes do it just fine. Debian had probably the easiest to use > system, and they've risen, owned the world and fallen all while FreeBSD h= as > been debating this issue. You appear to be misunderstanding what I said. I'm not arguing binary upgrades shouldn't be done but I'm suggesting that i= t=20 isn't NECESSARY to version and package the base install to do it. > > I don't think integrating it with the core OS (whatever that means) will > > magically fix this. > > If you knew what it meant, you would understand why it would help. Ah what a great explanation of what is meant. There are several people who don't know what is meant here and I haven't se= en=20 a decent explanation forthcoming. > > Not having run jails I am not very qualified to comment > > Exactly. Sorry, not trying to be rude but if you have never felt the pain > don't try and say it doesn't exist. Just because I don't run jails doesn't mean I don't know the pain of upgrad= ing=20 a system. =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 --nextPart4565128.1sz4yHWUgZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDvPgB5ZPcIHs/zowRAptBAJ9nSXeZUYkCicFxhv5CrNcuAQ7e/gCdFTXh oT226YogorSiHAgu2EmN0hs= =SGCC -----END PGP SIGNATURE----- --nextPart4565128.1sz4yHWUgZ-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 11:10:33 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 159A716A420 for ; Thu, 5 Jan 2006 11:10:33 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AA1143D55 for ; Thu, 5 Jan 2006 11:10:31 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy-128.york.ac.uk [144.32.128.160]) by mail-gw1.york.ac.uk (8.12.10/8.12.10) with ESMTP id k05B6k6w000306; Thu, 5 Jan 2006 11:06:46 GMT Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.4/8.13.4) with ESMTP id k05B6j8a011885; Thu, 5 Jan 2006 11:06:45 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.4/8.13.4/Submit) id k05B6j8m011884; Thu, 5 Jan 2006 11:06:45 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Vivek Khera In-Reply-To: References: <43BC24E7.6090800@FreeBSD.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 05 Jan 2006 11:06:45 +0000 Message-Id: <1136459205.11648.4.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: stable@freebsd.org Subject: Re: rpcbind lingering on IP no longer specified on command line X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 11:10:33 -0000 On Wed, 2006-01-04 at 15:44 -0500, Vivek Khera wrote: > On Jan 4, 2006, at 2:41 PM, Doug Barton wrote: > > > What does 'sockstat | grep rpcbind' tell you? > > # sockstat | grep rpcbind > root rpcbind 11382 5 stream /var/run/rpcbind.sock > root rpcbind 11382 6 dgram -> /var/run/logpriv > root rpcbind 11382 7 udp4 127.0.0.1:111 *:* > root rpcbind 11382 8 udp4 192.168.100.200:111 *:* > root rpcbind 11382 9 udp4 *:664 *:* > root rpcbind 11382 10 tcp4 *:111 *:* > > As Dmitry Morozovsky points out, it seems it always listens to tcp *: > 111 which seems to be a bad thing. I'm running 6.0-RELEASE-p1. > > This came up because of some security scans we're having run for some > compliance certificates we need... > > Can anyone explain why rpcbind will still bind to all tcp interfaces? Although I believe this is a bug, it is actually working as documented: from rpcbind(8): -h bindip Specify specific IP addresses to bind to for UDP requests. Gavin From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 11:41:03 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D2A116A41F; Thu, 5 Jan 2006 11:41:03 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DC9843D5C; Thu, 5 Jan 2006 11:41:00 +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 mail04.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k05BewI1008763 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 5 Jan 2006 22:40:58 +1100 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 k05BevHh050117; Thu, 5 Jan 2006 22:40:57 +1100 (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 k05BevOZ050116; Thu, 5 Jan 2006 22:40:57 +1100 (EST) (envelope-from pjeremy) Date: Thu, 5 Jan 2006 22:40:56 +1100 From: Peter Jeremy To: Jo Rhett Message-ID: <20060105114056.GN42228@cirb503493.alcatel.com.au> References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> <43A492B6.6050305@t-hosting.hu> <20051217232856.GT77268@cirb503493.alcatel.com.au> <43A4B91D.8040304@samsco.org> <20051222211730.GK39174@svcolo.com> <20051223045648.GH77268@cirb503493.alcatel.com.au> <20060105093727.GK1358@svcolo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060105093727.GK1358@svcolo.com> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: stable@freebsd.org, current Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 11:41:03 -0000 On Thu, 2006-Jan-05 01:37:27 -0800, Jo Rhett wrote: >No. I want a binary update mechanism. Obviously if we have local >configuration options we'll have to compile our own binaries. But doing >the work of tracking system updates currently requires us to build our own >patch tracking mechanism, and then re-write it for every new release. If you're willing to do your own compiles: 1) CVSup or cvs update to whatever branch you want 2) make build{world,kernel} 3) make DESTDIR=/updates install{world,kernel} 4) mergemaster -D /updates 5) rsync or similar It seems fairly obvious that you are frustrated by FreeBSD's inability to meet your needs as far as updating is concerned. I suspect I'm not alone in being uncertain exactly what your requirements are and what additional features FreeBSD needs to satisfy you. How would you like to write a formal requirements specification and post it here (or in -arch). >It's not a recompile issue. It's a tracking/update/backout issue. I don't >mind recompiling, if I could somehow push the updates to all the right >systems and they would have it stored somewhere that they were patched... Have you looked at tools like Bcfg2 ( http://www.mcs.anl.gov/cobalt/bcfg2/ )? -- Peter Jeremy From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 12:41:37 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25E5516A420 for ; Thu, 5 Jan 2006 12:41:37 +0000 (GMT) (envelope-from marius.nuennerich@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 9511F43D60 for ; Thu, 5 Jan 2006 12:41:36 +0000 (GMT) (envelope-from marius.nuennerich@gmx.net) Received: (qmail invoked by alias); 05 Jan 2006 12:41:34 -0000 Received: from p508380C1.dip0.t-ipconnect.de (EHLO sol) [80.131.128.193] by mail.gmx.net (mp008) with SMTP; 05 Jan 2006 13:41:34 +0100 X-Authenticated: #5707313 Date: Thu, 5 Jan 2006 13:41:33 +0100 From: Marius Nuennerich To: freebsd-stable@freebsd.org Message-ID: <20060105134133.61aef78f@sol> X-Mailer: Sylpheed-Claws 1.9.100 (GTK+ 2.8.9; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: /boot/nextboot.conf not deactivated after one boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 12:41:37 -0000 Hi folks, it seems like /boot/nextboot.conf is neither deleted nor nextboot_enable set to NO on the first line after a reboot. So it isn't a one shot anymore as the manpage claims. System is 6.0-RELEASE. It would also be fine imo, if the -k option would be optional and the next kernel defaults to "kernel". regards Marius From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 14:04:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24AA916A41F for ; Thu, 5 Jan 2006 14:04:09 +0000 (GMT) (envelope-from pan@cnptia.embrapa.br) Received: from norma.cnptia.embrapa.br (norma.cnptia.embrapa.br [200.0.70.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD6B143D49 for ; Thu, 5 Jan 2006 14:04:07 +0000 (GMT) (envelope-from pan@cnptia.embrapa.br) Received: from localhost (localhost.cnptia.embrapa.br [127.0.0.1]) by norma.cnptia.embrapa.br (Postfix) with ESMTP id 1C74A45003 for ; Thu, 5 Jan 2006 12:04:08 -0200 (BRST) Received: from [200.0.70.114] (hadar.cnptia.embrapa.br [200.0.70.114]) by norma.cnptia.embrapa.br (Postfix) with ESMTP id A86D3450C5 for ; Thu, 5 Jan 2006 12:04:06 -0200 (BRST) Message-ID: <43BD2794.8020000@cnptia.embrapa.br> Date: Thu, 05 Jan 2006 12:05:08 -0200 From: Carlos Fernando Assis Paniago User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd 0.1 Subject: Postfix and faststart X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 14:04:09 -0000 Hi: after the last cvsup, my FreeBSD 6.0, i386 is not capable to start postfix. I'm using the link in the /usr/local/etc/rc.d/postfix.sh to start the postfix program. Looking in the code, I saw that we need to change this in a file in /usr/local/etc/postfix/postfix-script to have the "faststart" flag.. Someone else find this problem? -- Paniago -- Carlos F. A. Paniago pan@cnptia.embrapa.br http://www.cnptia.embrapa.br/ Fone: +55 (19) 3789-5815 From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 14:46:00 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC75216A41F for ; Thu, 5 Jan 2006 14:46:00 +0000 (GMT) (envelope-from ptroot@iaces.com) Received: from iaces.com (horton.iaces.com [204.147.87.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB21043D60 for ; Thu, 5 Jan 2006 14:45:58 +0000 (GMT) (envelope-from ptroot@iaces.com) Received: from [204.147.87.125] (borg.iaces.com [204.147.87.125]) (authenticated bits=0) by iaces.com (8.13.4/8.13.3) with ESMTP id k05EjqC5026774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jan 2006 08:45:52 -0600 (CST) (envelope-from ptroot@iaces.com) Message-ID: <43BD315A.4070800@iaces.com> Date: Thu, 05 Jan 2006 08:46:50 -0600 From: "Paul T. Root" User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: keyboard failing on Dell laptop with 6.0-Stable this week. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 14:46:00 -0000 I have an old Dell Inspiron 5000 (800MHz, 512M RAM), that I've been running 6.0 since it was released. It was running great with -Stable cvsupped around Dec 18th or so. Tuesday, I saw that a problem with NFS locking was fixed, and I was having an nfs/amd problem on a desktop Vectra, so I cvsupped both machines and did a buildworld, etc. The Vectra had no problem. I'm not sure if the NFS issue is solved, I haven't had opportunity to be on that machine this week. Anyway, after coming up in full user mode, the keyboard is locked up on the Dell. I searched the archives and it seems that 5.4-S has some problems in this regard and that devd is the culprit. I commented out the 8-10 lines in devd.conf that have ukbd0 in them. But that didn't help at all. I tried turning off devd, big mistake, the network didn't come up then. Makes sense. I tried coming up without DBUS, as that was the last thing I'd done before the holiday's on the machine. No help. I have a usb keyboard at home, but this machine is at work, and I forgot it over night. Anybody have any other ideas. Oh, I had a custom kernel, also tried the GENERIC kernel and the old kernel. I re-cvsupped on Wednesday and built again. Thanks, Paul. -- ______ Paul T. Root / _ \ 1977 MGB / /|| \\ ||\/ || _ | || || || \ ||__// \______/ From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 15:31:37 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2708016A41F for ; Thu, 5 Jan 2006 15:31:37 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21B6A43D7B for ; Thu, 5 Jan 2006 15:31:34 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id DD1B2B80F for ; Thu, 5 Jan 2006 10:31:33 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <1136459205.11648.4.camel@buffy.york.ac.uk> References: <43BC24E7.6090800@FreeBSD.org> <1136459205.11648.4.camel@buffy.york.ac.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <51DD97C7-4002-4459-A709-1B72DC1189A7@khera.org> Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Thu, 5 Jan 2006 10:31:33 -0500 To: stable@freebsd.org X-Mailer: Apple Mail (2.746.2) Cc: Subject: Re: rpcbind lingering on IP no longer specified on command line X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 15:31:37 -0000 On Jan 5, 2006, at 6:06 AM, Gavin Atkinson wrote: >> Can anyone explain why rpcbind will still bind to all tcp interfaces? > > Although I believe this is a bug, it is actually working as > documented: > > from rpcbind(8): > -h bindip > Specify specific IP addresses to bind to for UDP > requests. Yeah, I noticed that little tiny "UDP requests" note in the -h docs too. There's no reason to bind to all tcp addresses, and it is causing me heartburn for getting the server certified... From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 18:24:24 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E20C16A41F; Thu, 5 Jan 2006 18:24:24 +0000 (GMT) (envelope-from dsh@vlink.ru) Received: from deliver.smtp.vlink.ru (vlink-1.avtlg.ru [83.239.142.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37D6343D5D; Thu, 5 Jan 2006 18:24:21 +0000 (GMT) (envelope-from dsh@vlink.ru) Received: from smtp.smtp.vlink.ru (clamav.smtp.vlink.ru [192.168.4.1]) by deliver.smtp.vlink.ru (Postfix) with ESMTP id 21DDAFECDE3; Thu, 5 Jan 2006 21:24:19 +0300 (MSK) Received: from neva.vlink.ru (neva.vlink.ru [217.107.252.66]) by smtp.smtp.vlink.ru (Postfix) with ESMTP id 35B831009AB3; Thu, 5 Jan 2006 21:24:18 +0300 (MSK) Received: from neva.vlink.ru (localhost [127.0.0.1]) by neva.vlink.ru (8.13.4/8.13.4) with ESMTP id k05HckYt006032; Thu, 5 Jan 2006 20:38:47 +0300 (MSK) (envelope-from dsh@vlink.ru) Received: (from dsh@localhost) by neva.vlink.ru (8.13.4/8.13.4/Submit) id k05Hciih006029; Thu, 5 Jan 2006 20:38:44 +0300 (MSK) (envelope-from dsh@vlink.ru) X-Comment-To: Greg Rivers To: Greg Rivers References: <20051121164139.T48994@w10.sac.fedex.com> <20051122021224.GA12402@xor.obsecurity.org> <20051121205535.W32523@nc8000.tharned.org> <20051122043952.GA14168@xor.obsecurity.org> <20051122211507.P32523@nc8000.tharned.org> <20060103135624.A798@nc8000.tharned.org> From: Denis Shaposhnikov Date: Thu, 05 Jan 2006 20:38:44 +0300 In-Reply-To: <20060103135624.A798@nc8000.tharned.org> (Greg Rivers's message of "Tue, 3 Jan 2006 14:03:06 -0600 (CST)") Message-ID: <8764oyinh7.fsf@neva.vlink.ru> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV using ClamSMTP Cc: Kirk McKusick , Don Lewis , freebsd-stable@freebsd.org, Kris Kennaway Subject: Re: Recurring problem: processes block accessing UFS file system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 18:24:24 -0000 Hi! >>>>> "Greg" == Greg Rivers writes: Greg> It's taken more than a month, but the problem has recurred Greg> without snapshots ever having been run. I've got a good trace I think that I have the same problem on a fresh CURRENT. For some processes I see MWCHAN = ufs and "D" in the STAT. And I can't kill such processes even with -9. And system can't kill them too on shutdown. So, system can't do shutdown and wait forever after "All buffers synced" message. At this moment I've entered to KDB do "show lockedvnods": Locked vnodes 0xc687cb58: tag ufs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags () v_object 0xcb5b1934 ref 0 pages 0 lock type ufs: EXCL (count 1) by thread 0xc795d600 (pid 74686) with 1 pending ino 2072602, on dev ad4s1g 0xc687ca50: tag ufs, type VDIR usecount 31, writecount 0, refcount 32 mountedhere 0 flags () v_object 0xc85d2744 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc7683d80 (pid 74178) with 6 pending ino 2072603, on dev ad4s1g 0xc687c948: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc875d000 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc91f3300 (pid 65610) with 1 pending ino 2072615, on dev ad4s1g 0xc691f420: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc8a773e0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc68e5780 (pid 519) with 1 pending ino 2072680, on dev ad4s1g 0xc691f318: tag ufs, type VDIR usecount 3, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc8a7b2e8 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc7019780 (pid 74103) with 2 pending ino 2072795, on dev ad4s1g 0xc69bb528: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc7890744 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc91f4600 (pid 74129) with 1 pending ino 2072767, on dev ad4s1g Locked vnodes 0xc687cb58: tag ufs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags () v_object 0xcb5b1934 ref 0 pages 0 lock type ufs: EXCL (count 1) by thread 0xc795d600 (pid 74686) with 1 pending ino 2072602, on dev ad4s1g 0xc687ca50: tag ufs, type VDIR usecount 31, writecount 0, refcount 32 mountedhere 0 flags () v_object 0xc85d2744 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc7683d80 (pid 74178) with 6 pending ino 2072603, on dev ad4s1g 0xc687c948: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc875d000 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc91f3300 (pid 65610) with 1 pending ino 2072615, on dev ad4s1g 0xc691f420: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc8a773e0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc68e5780 (pid 519) with 1 pending ino 2072680, on dev ad4s1g 0xc691f318: tag ufs, type VDIR usecount 3, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc8a7b2e8 ref 0 pages 1 lock type ufs: EXCL (count 1) by t(kgdb) After that I've done "call doadump" and got vmcore. ps show me: (kgdb) ps During symbol reading, Incomplete CFI data; unspecified registers at 0xc04d97eb. pid proc uid ppid pgrp flag stat comm wchan 74686 c9464000 0 1 1 000000 1 sh ufs c687caa8 74195 c970d000 0 3074 74195 4000100 1 sshd ufs c687caa8 74178 c7682adc 0 3074 74178 004000 1 sshd ufs c687c9a0 74129 c9b82adc 1008 1 5504 004000 1 parser3.cgi ufs c691f370 74103 c70b5458 1008 1 5504 000000 1 httpd ufs c69bb580 65610 c92c0458 1005 1 65610 004000 1 sftp-server ufs c691f478 5518 c6247458 1008 1 5516 004002 1 perl5.8.7 ufs c687caa8 3081 c7523d08 0 1 3081 000000 1 cron ufs c687caa8 3074 c7682d08 0 1 3074 000100 1 sshd ufs c687caa8 3016 c7523adc 0 1 3016 000000 1 syslogd ufs c687caa8 519 c68e4d08 80 1 518 000100 1 nginx ufs c691f370 34 c6260000 0 0 0 000204 1 schedcpu - e88b3cf0 33 c62438b0 0 0 0 000204 1 syncer ktsusp c6243938 32 c6243adc 0 0 0 000204 1 vnlru ktsusp c6243b64 31 c6243d08 0 0 0 000204 1 bufdaemon ktsusp c6243d90 30 c6244000 0 0 0 00020c 1 pagezero pgzero c06c21a0 29 c624422c 0 0 0 000204 1 vmdaemon psleep c06c1d08 28 c6244458 0 0 0 000204 1 pagedaemon psleep c06c1cc8 27 c602e684 0 0 0 000204 1 irq1: atkbd0 26 c602e8b0 0 0 0 000204 1 swi0: sio 25 c602eadc 0 0 0 000204 1 irq18: atapci1 24 c602ed08 0 0 0 000204 1 irq15: ata1 23 c6074000 0 0 0 000204 1 irq14: ata0 22 c607422c 0 0 0 000204 1 irq27: em1 21 c6074458 0 0 0 000204 1 irq26: em0 20 c6074684 0 0 0 000204 1 irq9: acpi0 19 c60748b0 0 0 0 000204 1 swi2: cambio 18 c6074adc 0 0 0 000204 1 swi6: task queue 9 c5fd822c 0 0 0 000204 1 acpi_task2 - c6061e40 8 c5fd8458 0 0 0 000204 1 acpi_task1 - c6061e40 7 c5fd8684 0 0 0 000204 1 acpi_task0 - c6061e40 17 c5fd88b0 0 0 0 000204 1 swi6: Giant taskq 6 c5fd8adc 0 0 0 000204 1 thread taskq - c6062040 16 c5fd8d08 0 0 0 000204 1 swi5: Fast taskq 5 c602e000 0 0 0 000204 1 kqueue taskq - c6062100 15 c602e22c 0 0 0 000204 1 yarrow - c06b1720 4 c602e458 0 0 0 000204 1 g_down - c06b1fc0 3 c5fd3000 0 0 0 000204 1 g_up - c06b1fbc 2 c5fd322c 0 0 0 000204 1 g_event - c06b1fb4 14 c5fd3458 0 0 0 000204 1 swi3: vm 13 c5fd3684 0 0 0 00020c 1 swi4: clock sio 12 c5fd38b0 0 0 0 000204 1 swi1: net 11 c5fd3adc 0 0 0 00020c 1 idle: cpu0 10 c5fd3d08 0 0 0 00020c 1 idle: cpu1 1 c5fd8000 0 0 1 004200 1 init ufs c687cbb0 0 c06b20c0 0 0 0 000200 1 swapper There is no member named p_pptr. Note, I've tried to check v_object addresses from "show lockedvnodes": (kgdb) p/x *0xcb5b1934 $1 = 0xc068f280 (kgdb) p/x *0xc85d2744 $2 = 0xc068f280 (kgdb) p/x *0xc875d000 $3 = 0xc068f280 (kgdb) p/x *0xc8a773e0 $4 = 0xc068f280 ... and so on. May be that's important? PS. I have a crash dump but already have no the kernel for that dump. Thank you for your attention. -- DSS5-RIPE DSS-RIPN 2:550/5068@fidonet 2:550/5069@fidonet mailto:dsh@vlink.ru http://neva.vlink.ru/~dsh/ From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 18:28:34 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DC8F16A41F; Thu, 5 Jan 2006 18:28:34 +0000 (GMT) (envelope-from ender@tog.net) Received: from tog.net (tog.net [216.89.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F11043D91; Thu, 5 Jan 2006 18:28:13 +0000 (GMT) (envelope-from ender@tog.net) Received: by tog.net (Postfix, from userid 96) id 18BB329B6C6; Thu, 5 Jan 2006 13:28:12 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.0-terranovanet_v6 (2005-09-13) on doppelganger.terranova.net X-Spam-Level: X-Spam-Status: No, score=-5.1 required=7.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0-terranovanet_v6 Received: from [192.168.8.150] (host-216-89-225-138.terranova.net [216.89.225.138]) by tog.net (Postfix) with ESMTP id 02A3E29B6A3; Thu, 5 Jan 2006 13:28:06 -0500 (EST) Message-ID: <43BD64C4.4090307@tog.net> Date: Thu, 05 Jan 2006 13:26:12 -0500 From: Ender User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel O'Connor References: <43A266E5.3080103@samsco.org> <200512231126.51500.doconnor@gsoft.com.au> <20060105093220.GJ1358@svcolo.com> <200601052112.09446.doconnor@gsoft.com.au> In-Reply-To: <200601052112.09446.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, freebsd-stable@freebsd.org, current , Jo Rhett , K?vesd?n G?bor , Peter Jeremy Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 18:28:34 -0000 Daniel O'Connor wrote: >On Thu, 5 Jan 2006 20:02, Jo Rhett wrote: > > >>On Fri, Dec 23, 2005 at 11:26:44AM +1030, Daniel O'Connor wrote: >> >> >>>How do you expect these two to be handled in a binary upgrade? >>>I can't see how it's possible.. >>> >>> >>Look around. Every major commercial OS does it just fine. Most of the >>open source OSes do it just fine. Debian had probably the easiest to use >>system, and they've risen, owned the world and fallen all while FreeBSD has >>been debating this issue. >> >> > >You appear to be misunderstanding what I said. > >I'm not arguing binary upgrades shouldn't be done but I'm suggesting that it >isn't NECESSARY to version and package the base install to do it. > > > >>>I don't think integrating it with the core OS (whatever that means) will >>>magically fix this. >>> >>> >>If you knew what it meant, you would understand why it would help. >> >> > >Ah what a great explanation of what is meant. >There are several people who don't know what is meant here and I haven't seen >a decent explanation forthcoming. > > > I think what "integrated with the core OS" means from a user standpoint is: from a fresh minimum install of freebsd I can type "freebsd-update-whatever" and it will update my system. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 18:28:34 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DC8F16A41F; Thu, 5 Jan 2006 18:28:34 +0000 (GMT) (envelope-from ender@tog.net) Received: from tog.net (tog.net [216.89.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F11043D91; Thu, 5 Jan 2006 18:28:13 +0000 (GMT) (envelope-from ender@tog.net) Received: by tog.net (Postfix, from userid 96) id 18BB329B6C6; Thu, 5 Jan 2006 13:28:12 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.0-terranovanet_v6 (2005-09-13) on doppelganger.terranova.net X-Spam-Level: X-Spam-Status: No, score=-5.1 required=7.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0-terranovanet_v6 Received: from [192.168.8.150] (host-216-89-225-138.terranova.net [216.89.225.138]) by tog.net (Postfix) with ESMTP id 02A3E29B6A3; Thu, 5 Jan 2006 13:28:06 -0500 (EST) Message-ID: <43BD64C4.4090307@tog.net> Date: Thu, 05 Jan 2006 13:26:12 -0500 From: Ender User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel O'Connor References: <43A266E5.3080103@samsco.org> <200512231126.51500.doconnor@gsoft.com.au> <20060105093220.GJ1358@svcolo.com> <200601052112.09446.doconnor@gsoft.com.au> In-Reply-To: <200601052112.09446.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, freebsd-stable@freebsd.org, current , Jo Rhett , K?vesd?n G?bor , Peter Jeremy Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 18:28:34 -0000 Daniel O'Connor wrote: >On Thu, 5 Jan 2006 20:02, Jo Rhett wrote: > > >>On Fri, Dec 23, 2005 at 11:26:44AM +1030, Daniel O'Connor wrote: >> >> >>>How do you expect these two to be handled in a binary upgrade? >>>I can't see how it's possible.. >>> >>> >>Look around. Every major commercial OS does it just fine. Most of the >>open source OSes do it just fine. Debian had probably the easiest to use >>system, and they've risen, owned the world and fallen all while FreeBSD has >>been debating this issue. >> >> > >You appear to be misunderstanding what I said. > >I'm not arguing binary upgrades shouldn't be done but I'm suggesting that it >isn't NECESSARY to version and package the base install to do it. > > > >>>I don't think integrating it with the core OS (whatever that means) will >>>magically fix this. >>> >>> >>If you knew what it meant, you would understand why it would help. >> >> > >Ah what a great explanation of what is meant. >There are several people who don't know what is meant here and I haven't seen >a decent explanation forthcoming. > > > I think what "integrated with the core OS" means from a user standpoint is: from a fresh minimum install of freebsd I can type "freebsd-update-whatever" and it will update my system. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 18:42:11 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B77016A41F; Thu, 5 Jan 2006 18:42:11 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F97443D77; Thu, 5 Jan 2006 18:41:57 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id k05IfoBT067226; Thu, 5 Jan 2006 10:41:50 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id k05Ifl1L067225; Thu, 5 Jan 2006 10:41:47 -0800 (PST) (envelope-from jmg) Date: Thu, 5 Jan 2006 10:41:47 -0800 From: John-Mark Gurney To: "Daniel O'Connor" , freebsd-stable@freebsd.org, Chuck Swiger , current Message-ID: <20060105184147.GD69162@funkthat.com> Mail-Followup-To: Daniel O'Connor , freebsd-stable@freebsd.org, Chuck Swiger , current References: <43A266E5.3080103@samsco.org> <43AB1E65.2030501@mac.com> <20051222221202.GM39174@svcolo.com> <200512231136.12471.doconnor@gsoft.com.au> <20060105092448.GH1358@svcolo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060105092448.GH1358@svcolo.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 18:42:11 -0000 Jo Rhett wrote this message on Thu, Jan 05, 2006 at 01:24 -0800: > > You are putting words in the mouth of core@ - > > Sorry. As said before, the topic is always struck down and nobody from > core has ever stood up to say "we'll support this". I don't know whose on > core this week, nor will I at any given time. I just know that core has > either struck it down or been Silent. I believe core has a policy of never supporting vaporware... There is always the chicken and egg problem with arguments like this... I'll code this if you agree to support it and maintain it/I will agree to support it once you code it... In FreeBSD, and many open source projects, no code, no support, how can you support or even agree to support something that doesn't exist? And then as soon as FreeBSD agrees to support something that doesn't exist, either a) other people who were interested in the project stop, even if you end up never producing a bit of code, or b) someone else produces better code, drops the support for the original, but then the author complains about being told they'd support his code, and going with another code base... Bottom line: Once code exists, then support can be talked about.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 18:46:06 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 230C016A426 for ; Thu, 5 Jan 2006 18:46:06 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9C4D43D76 for ; Thu, 5 Jan 2006 18:45:29 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id k05IjGCI015543; Thu, 5 Jan 2006 10:45:20 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200601051845.k05IjGCI015543@gw.catspoiler.org> Date: Thu, 5 Jan 2006 10:45:16 -0800 (PST) From: Don Lewis To: dsh@vlink.ru In-Reply-To: <8764oyinh7.fsf@neva.vlink.ru> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: gcr+freebsd-stable@tharned.org, freebsd@McKusick.COM, freebsd-stable@FreeBSD.org, kris@obsecurity.org Subject: Re: Recurring problem: processes block accessing UFS file system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 18:46:06 -0000 On 5 Jan, Denis Shaposhnikov wrote: > Hi! > >>>>>> "Greg" == Greg Rivers writes: > > Greg> It's taken more than a month, but the problem has recurred > Greg> without snapshots ever having been run. I've got a good trace > > I think that I have the same problem on a fresh CURRENT. For some > processes I see MWCHAN = ufs and "D" in the STAT. And I can't kill > such processes even with -9. And system can't kill them too on > shutdown. So, system can't do shutdown and wait forever after "All > buffers synced" message. At this moment I've entered to KDB do "show > lockedvnods": > > Locked vnodes > > 0xc687cb58: tag ufs, type VDIR > usecount 1, writecount 0, refcount 2 mountedhere 0 > flags () > v_object 0xcb5b1934 ref 0 pages 0 > lock type ufs: EXCL (count 1) by thread 0xc795d600 (pid 74686) with 1 pending > ino 2072602, on dev ad4s1g > > 0xc687ca50: tag ufs, type VDIR > usecount 31, writecount 0, refcount 32 mountedhere 0 > flags () > v_object 0xc85d2744 ref 0 pages 1 > lock type ufs: EXCL (count 1) by thread 0xc7683d80 (pid 74178) with 6 pending > ino 2072603, on dev ad4s1g > > 0xc687c948: tag ufs, type VDIR > usecount 2, writecount 0, refcount 3 mountedhere 0 > flags () > v_object 0xc875d000 ref 0 pages 1 > lock type ufs: EXCL (count 1) by thread 0xc91f3300 (pid 65610) with 1 pending > ino 2072615, on dev ad4s1g > > 0xc691f420: tag ufs, type VDIR > usecount 2, writecount 0, refcount 3 mountedhere 0 > flags () > v_object 0xc8a773e0 ref 0 pages 1 > lock type ufs: EXCL (count 1) by thread 0xc68e5780 (pid 519) with 1 pending > ino 2072680, on dev ad4s1g > > 0xc691f318: tag ufs, type VDIR > usecount 3, writecount 0, refcount 4 mountedhere 0 > flags () > v_object 0xc8a7b2e8 ref 0 pages 1 > lock type ufs: EXCL (count 1) by thread 0xc7019780 (pid 74103) with 2 pending > ino 2072795, on dev ad4s1g > > 0xc69bb528: tag ufs, type VDIR > usecount 2, writecount 0, refcount 3 mountedhere 0 > flags () > v_object 0xc7890744 ref 0 pages 1 > lock type ufs: EXCL (count 1) by thread 0xc91f4600 (pid 74129) with 1 pending > ino 2072767, on dev ad4s1g > Locked vnodes > > 0xc687cb58: tag ufs, type VDIR > usecount 1, writecount 0, refcount 2 mountedhere 0 > flags () > v_object 0xcb5b1934 ref 0 pages 0 > lock type ufs: EXCL (count 1) by thread 0xc795d600 (pid 74686) with 1 pending > ino 2072602, on dev ad4s1g > > 0xc687ca50: tag ufs, type VDIR > usecount 31, writecount 0, refcount 32 mountedhere 0 > flags () > v_object 0xc85d2744 ref 0 pages 1 > lock type ufs: EXCL (count 1) by thread 0xc7683d80 (pid 74178) with 6 pending > ino 2072603, on dev ad4s1g > > 0xc687c948: tag ufs, type VDIR > usecount 2, writecount 0, refcount 3 mountedhere 0 > flags () > v_object 0xc875d000 ref 0 pages 1 > lock type ufs: EXCL (count 1) by thread 0xc91f3300 (pid 65610) with 1 pending > ino 2072615, on dev ad4s1g > > 0xc691f420: tag ufs, type VDIR > usecount 2, writecount 0, refcount 3 mountedhere 0 > flags () > v_object 0xc8a773e0 ref 0 pages 1 > lock type ufs: EXCL (count 1) by thread 0xc68e5780 (pid 519) with 1 pending > ino 2072680, on dev ad4s1g > > 0xc691f318: tag ufs, type VDIR > usecount 3, writecount 0, refcount 4 mountedhere 0 > flags () > v_object 0xc8a7b2e8 ref 0 pages 1 > lock type ufs: EXCL (count 1) by t(kgdb) > > After that I've done "call doadump" and got vmcore. > > ps show me: > > (kgdb) ps > During symbol reading, Incomplete CFI data; unspecified registers at 0xc04d97eb. > pid proc uid ppid pgrp flag stat comm wchan > 74686 c9464000 0 1 1 000000 1 sh ufs c687caa8 > 74195 c970d000 0 3074 74195 4000100 1 sshd ufs c687caa8 > 74178 c7682adc 0 3074 74178 004000 1 sshd ufs c687c9a0 > 74129 c9b82adc 1008 1 5504 004000 1 parser3.cgi ufs c691f370 > 74103 c70b5458 1008 1 5504 000000 1 httpd ufs c69bb580 > 65610 c92c0458 1005 1 65610 004000 1 sftp-server ufs c691f478 > 5518 c6247458 1008 1 5516 004002 1 perl5.8.7 ufs c687caa8 > 3081 c7523d08 0 1 3081 000000 1 cron ufs c687caa8 > 3074 c7682d08 0 1 3074 000100 1 sshd ufs c687caa8 > 3016 c7523adc 0 1 3016 000000 1 syslogd ufs c687caa8 > 519 c68e4d08 80 1 518 000100 1 nginx ufs c691f370 > 34 c6260000 0 0 0 000204 1 schedcpu - e88b3cf0 > 33 c62438b0 0 0 0 000204 1 syncer ktsusp c6243938 > 32 c6243adc 0 0 0 000204 1 vnlru ktsusp c6243b64 > 31 c6243d08 0 0 0 000204 1 bufdaemon ktsusp c6243d90 > 30 c6244000 0 0 0 00020c 1 pagezero pgzero c06c21a0 > 29 c624422c 0 0 0 000204 1 vmdaemon psleep c06c1d08 > 28 c6244458 0 0 0 000204 1 pagedaemon psleep c06c1cc8 > 27 c602e684 0 0 0 000204 1 irq1: atkbd0 > 26 c602e8b0 0 0 0 000204 1 swi0: sio > 25 c602eadc 0 0 0 000204 1 irq18: atapci1 > 24 c602ed08 0 0 0 000204 1 irq15: ata1 > 23 c6074000 0 0 0 000204 1 irq14: ata0 > 22 c607422c 0 0 0 000204 1 irq27: em1 > 21 c6074458 0 0 0 000204 1 irq26: em0 > 20 c6074684 0 0 0 000204 1 irq9: acpi0 > 19 c60748b0 0 0 0 000204 1 swi2: cambio > 18 c6074adc 0 0 0 000204 1 swi6: task queue > 9 c5fd822c 0 0 0 000204 1 acpi_task2 - c6061e40 > 8 c5fd8458 0 0 0 000204 1 acpi_task1 - c6061e40 > 7 c5fd8684 0 0 0 000204 1 acpi_task0 - c6061e40 > 17 c5fd88b0 0 0 0 000204 1 swi6: Giant taskq > 6 c5fd8adc 0 0 0 000204 1 thread taskq - c6062040 > 16 c5fd8d08 0 0 0 000204 1 swi5: Fast taskq > 5 c602e000 0 0 0 000204 1 kqueue taskq - c6062100 > 15 c602e22c 0 0 0 000204 1 yarrow - c06b1720 > 4 c602e458 0 0 0 000204 1 g_down - c06b1fc0 > 3 c5fd3000 0 0 0 000204 1 g_up - c06b1fbc > 2 c5fd322c 0 0 0 000204 1 g_event - c06b1fb4 > 14 c5fd3458 0 0 0 000204 1 swi3: vm > 13 c5fd3684 0 0 0 00020c 1 swi4: clock sio > 12 c5fd38b0 0 0 0 000204 1 swi1: net > 11 c5fd3adc 0 0 0 00020c 1 idle: cpu0 > 10 c5fd3d08 0 0 0 00020c 1 idle: cpu1 > 1 c5fd8000 0 0 1 004200 1 init ufs c687cbb0 > 0 c06b20c0 0 0 0 000200 1 swapper > There is no member named p_pptr. This is different because only vnode locks appear to be involved. One thread holding a vnode lock is getting stuck, and then all the other threads pile up behind it. I traced the list of locked vnodes and get stuck here: > 0xc691f318: tag ufs, type VDIR > usecount 3, writecount 0, refcount 4 mountedhere 0 > flags () > v_object 0xc8a7b2e8 ref 0 pages 1 > lock type ufs: EXCL (count 1) by t(kgdb) pid 519 wants to lock this vnode but some other thread is holding the vnode lock. Unfortunately we don't know who the lock holder is because the message is truncated. This might just be a vnode lock leak. Build a debug kernel with the DEBUG_VFS_LOCKS and DEBUG_LOCKS options and see if anything shows up. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 19:22:24 2006 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5054216A420 for ; Thu, 5 Jan 2006 19:22:24 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48AF943D46 for ; Thu, 5 Jan 2006 19:22:23 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id k05JMGMc015613 for ; Thu, 5 Jan 2006 11:22:20 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200601051922.k05JMGMc015613@gw.catspoiler.org> Date: Thu, 5 Jan 2006 11:22:16 -0800 (PST) From: Don Lewis To: stable@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: Subject: WITNESS speedup patch for RELENG_5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 19:22:24 -0000 If you are running RELENG_5 and using WITNESS, you might want to try the patch below. It speeds up WITNESS rather dramatically. This patch was committed to HEAD in late August (subr_witness.c 1.198) and early September (subr_witness.c 1.200). It was MFC'ed to RELENG_6 in the last few days. I'd like to MFC it to RELENG_5, but I think it should get a bit more exposure before I do. Index: sys/kern/subr_witness.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_witness.c,v retrieving revision 1.178.2.8 diff -u -r1.178.2.8 subr_witness.c --- sys/kern/subr_witness.c 4 May 2005 19:26:30 -0000 1.178.2.8 +++ sys/kern/subr_witness.c 12 Sep 2005 04:52:53 -0000 @@ -165,16 +165,9 @@ static int isitmychild(struct witness *parent, struct witness *child); static int isitmydescendant(struct witness *parent, struct witness *child); static int itismychild(struct witness *parent, struct witness *child); -static int rebalancetree(struct witness_list *list); static void removechild(struct witness *parent, struct witness *child); -static int reparentchildren(struct witness *newparent, - struct witness *oldparent); static int sysctl_debug_witness_watch(SYSCTL_HANDLER_ARGS); -static void witness_displaydescendants(void(*)(const char *fmt, ...), - struct witness *, int indent); static const char *fixup_filename(const char *file); -static void witness_leveldescendents(struct witness *parent, int level); -static void witness_levelall(void); static struct witness *witness_get(void); static void witness_free(struct witness *m); static struct witness_child_list_entry *witness_child_get(void); @@ -185,20 +178,21 @@ struct lock_object *lock); static void witness_list_lock(struct lock_instance *instance); #ifdef DDB -static void witness_list(struct thread *td); +static void witness_leveldescendents(struct witness *parent, int level); +static void witness_levelall(void); +static void witness_displaydescendants(void(*)(const char *fmt, ...), + struct witness *, int indent); static void witness_display_list(void(*prnt)(const char *fmt, ...), struct witness_list *list); static void witness_display(void(*)(const char *fmt, ...)); +static void witness_list(struct thread *td); #endif SYSCTL_NODE(_debug, OID_AUTO, witness, CTLFLAG_RW, 0, "Witness Locking"); /* - * If set to 0, witness is disabled. If set to 1, witness performs full lock - * order checking for all locks. If set to 2 or higher, then witness skips - * the full lock order check if the lock being acquired is at a higher level - * (i.e. farther down in the tree) than the current lock. This last mode is - * somewhat experimental and not considered fully safe. At runtime, this + * If set to 0, witness is disabled. If set to a non-zero value, witness + * performs full lock order checking for all locks. At runtime, this * value may be set to 0 to turn off witness. witness is not allowed be * turned on once it is turned off, however. */ @@ -250,6 +244,16 @@ static struct witness_child_list_entry *w_child_free = NULL; static struct lock_list_entry *w_lock_list_free = NULL; +static int w_free_cnt, w_spin_cnt, w_sleep_cnt, w_child_free_cnt, w_child_cnt; +SYSCTL_INT(_debug_witness, OID_AUTO, free_cnt, CTLFLAG_RD, &w_free_cnt, 0, ""); +SYSCTL_INT(_debug_witness, OID_AUTO, spin_cnt, CTLFLAG_RD, &w_spin_cnt, 0, ""); +SYSCTL_INT(_debug_witness, OID_AUTO, sleep_cnt, CTLFLAG_RD, &w_sleep_cnt, 0, + ""); +SYSCTL_INT(_debug_witness, OID_AUTO, child_free_cnt, CTLFLAG_RD, + &w_child_free_cnt, 0, ""); +SYSCTL_INT(_debug_witness, OID_AUTO, child_cnt, CTLFLAG_RD, &w_child_cnt, 0, + ""); + static struct witness w_data[WITNESS_COUNT]; static struct witness_child_list_entry w_childdata[WITNESS_CHILDCOUNT]; static struct lock_list_entry w_locklistdata[LOCK_CHILDCOUNT]; @@ -575,6 +579,87 @@ #ifdef DDB static void +witness_levelall (void) +{ + struct witness_list *list; + struct witness *w, *w1; + + /* + * First clear all levels. + */ + STAILQ_FOREACH(w, &w_all, w_list) { + w->w_level = 0; + } + + /* + * Look for locks with no parent and level all their descendants. + */ + STAILQ_FOREACH(w, &w_all, w_list) { + /* + * This is just an optimization, technically we could get + * away just walking the all list each time. + */ + if (w->w_class->lc_flags & LC_SLEEPLOCK) + list = &w_sleep; + else + list = &w_spin; + STAILQ_FOREACH(w1, list, w_typelist) { + if (isitmychild(w1, w)) + goto skip; + } + witness_leveldescendents(w, 0); + skip: + ; /* silence GCC 3.x */ + } +} + +static void +witness_leveldescendents(struct witness *parent, int level) +{ + struct witness_child_list_entry *wcl; + int i; + + if (parent->w_level < level) + parent->w_level = level; + level++; + for (wcl = parent->w_children; wcl != NULL; wcl = wcl->wcl_next) + for (i = 0; i < wcl->wcl_count; i++) + witness_leveldescendents(wcl->wcl_children[i], level); +} + +static void +witness_displaydescendants(void(*prnt)(const char *fmt, ...), + struct witness *parent, int indent) +{ + struct witness_child_list_entry *wcl; + int i, level; + + level = parent->w_level; + prnt("%-2d", level); + for (i = 0; i < indent; i++) + prnt(" "); + if (parent->w_refcount > 0) + prnt("%s", parent->w_name); + else + prnt("(dead)"); + if (parent->w_displayed) { + prnt(" -- (already displayed)\n"); + return; + } + parent->w_displayed = 1; + if (parent->w_refcount > 0) { + if (parent->w_file != NULL) + prnt(" -- last acquired @ %s:%d", parent->w_file, + parent->w_line); + } + prnt("\n"); + for (wcl = parent->w_children; wcl != NULL; wcl = wcl->wcl_next) + for (i = 0; i < wcl->wcl_count; i++) + witness_displaydescendants(prnt, + wcl->wcl_children[i], indent + 1); +} + +static void witness_display_list(void(*prnt)(const char *fmt, ...), struct witness_list *list) { @@ -795,18 +880,11 @@ MPASS(!mtx_owned(&w_mtx)); mtx_lock_spin(&w_mtx); /* - * If we have a known higher number just say ok - */ - if (witness_watch > 1 && w->w_level > w1->w_level) { - mtx_unlock_spin(&w_mtx); - return; - } - /* * If we know that the the lock we are acquiring comes after * the lock we most recently acquired in the lock order tree, * then there is no need for any further checks. */ - if (isitmydescendant(w1, w)) { + if (isitmychild(w1, w)) { mtx_unlock_spin(&w_mtx); return; } @@ -1287,11 +1365,13 @@ w->w_class = lock_class; w->w_refcount = 1; STAILQ_INSERT_HEAD(&w_all, w, w_list); - if (lock_class->lc_flags & LC_SPINLOCK) + if (lock_class->lc_flags & LC_SPINLOCK) { STAILQ_INSERT_HEAD(&w_spin, w, w_typelist); - else if (lock_class->lc_flags & LC_SLEEPLOCK) + w_spin_cnt++; + } else if (lock_class->lc_flags & LC_SLEEPLOCK) { STAILQ_INSERT_HEAD(&w_sleep, w, w_typelist); - else { + w_sleep_cnt++; + } else { mtx_unlock_spin(&w_mtx); panic("lock class %s is not sleep or spin", lock_class->lc_name); @@ -1309,10 +1389,13 @@ struct witness *parent; MPASS(w->w_refcount == 0); - if (w->w_class->lc_flags & LC_SLEEPLOCK) + if (w->w_class->lc_flags & LC_SLEEPLOCK) { list = &w_sleep; - else + w_sleep_cnt--; + } else { list = &w_spin; + w_spin_cnt--; + } /* * First, we run through the entire tree looking for any * witnesses that the outgoing witness is a child of. For @@ -1323,8 +1406,6 @@ if (!isitmychild(parent, w)) continue; removechild(parent, w); - if (!reparentchildren(parent, w)) - return (0); } /* @@ -1333,6 +1414,7 @@ */ for (wcl = w->w_children; wcl != NULL; wcl = nwcl) { nwcl = wcl->wcl_next; + w_child_cnt--; witness_child_free(wcl); } @@ -1343,34 +1425,6 @@ STAILQ_REMOVE(&w_all, w, witness, w_list); witness_free(w); - /* Finally, fixup the tree. */ - return (rebalancetree(list)); -} - -/* - * Prune an entire lock order tree. We look for cases where a lock - * is now both a descendant and a direct child of a given lock. In - * that case, we want to remove the direct child link from the tree. - * - * Returns false if insertchild() fails. - */ -static int -rebalancetree(struct witness_list *list) -{ - struct witness *child, *parent; - - STAILQ_FOREACH(child, list, w_typelist) { - STAILQ_FOREACH(parent, list, w_typelist) { - if (!isitmychild(parent, child)) - continue; - removechild(parent, child); - if (isitmydescendant(parent, child)) - continue; - if (!insertchild(parent, child)) - return (0); - } - } - witness_levelall(); return (1); } @@ -1395,31 +1449,13 @@ *wcl = witness_child_get(); if (*wcl == NULL) return (0); + w_child_cnt++; } (*wcl)->wcl_children[(*wcl)->wcl_count++] = child; return (1); } -/* - * Make all the direct descendants of oldparent be direct descendants - * of newparent. - */ -static int -reparentchildren(struct witness *newparent, struct witness *oldparent) -{ - struct witness_child_list_entry *wcl; - int i; - - /* Avoid making a witness a child of itself. */ - MPASS(!isitmychild(oldparent, newparent)); - - for (wcl = oldparent->w_children; wcl != NULL; wcl = wcl->wcl_next) - for (i = 0; i < wcl->wcl_count; i++) - if (!insertchild(newparent, wcl->wcl_children[i])) - return (0); - return (1); -} static int itismychild(struct witness *parent, struct witness *child) @@ -1441,7 +1477,7 @@ list = &w_sleep; else list = &w_spin; - return (rebalancetree(list)); + return (1); } static void @@ -1465,6 +1501,7 @@ return; wcl1 = *wcl; *wcl = wcl1->wcl_next; + w_child_cnt--; witness_child_free(wcl1); } @@ -1503,87 +1540,6 @@ return (0); } -static void -witness_levelall (void) -{ - struct witness_list *list; - struct witness *w, *w1; - - /* - * First clear all levels. - */ - STAILQ_FOREACH(w, &w_all, w_list) { - w->w_level = 0; - } - - /* - * Look for locks with no parent and level all their descendants. - */ - STAILQ_FOREACH(w, &w_all, w_list) { - /* - * This is just an optimization, technically we could get - * away just walking the all list each time. - */ - if (w->w_class->lc_flags & LC_SLEEPLOCK) - list = &w_sleep; - else - list = &w_spin; - STAILQ_FOREACH(w1, list, w_typelist) { - if (isitmychild(w1, w)) - goto skip; - } - witness_leveldescendents(w, 0); - skip: - ; /* silence GCC 3.x */ - } -} - -static void -witness_leveldescendents(struct witness *parent, int level) -{ - struct witness_child_list_entry *wcl; - int i; - - if (parent->w_level < level) - parent->w_level = level; - level++; - for (wcl = parent->w_children; wcl != NULL; wcl = wcl->wcl_next) - for (i = 0; i < wcl->wcl_count; i++) - witness_leveldescendents(wcl->wcl_children[i], level); -} - -static void -witness_displaydescendants(void(*prnt)(const char *fmt, ...), - struct witness *parent, int indent) -{ - struct witness_child_list_entry *wcl; - int i, level; - - level = parent->w_level; - prnt("%-2d", level); - for (i = 0; i < indent; i++) - prnt(" "); - if (parent->w_refcount > 0) - prnt("%s", parent->w_name); - else - prnt("(dead)"); - if (parent->w_displayed) { - prnt(" -- (already displayed)\n"); - return; - } - parent->w_displayed = 1; - if (parent->w_refcount > 0) { - if (parent->w_file != NULL) - prnt(" -- last acquired @ %s:%d", parent->w_file, - parent->w_line); - } - prnt("\n"); - for (wcl = parent->w_children; wcl != NULL; wcl = wcl->wcl_next) - for (i = 0; i < wcl->wcl_count; i++) - witness_displaydescendants(prnt, - wcl->wcl_children[i], indent + 1); -} - #ifdef BLESSING static int blessed(struct witness *w1, struct witness *w2) @@ -1623,6 +1579,7 @@ } w = STAILQ_FIRST(&w_free); STAILQ_REMOVE_HEAD(&w_free, w_list); + w_free_cnt--; bzero(w, sizeof(*w)); return (w); } @@ -1632,6 +1589,7 @@ { STAILQ_INSERT_HEAD(&w_free, w, w_list); + w_free_cnt++; } static struct witness_child_list_entry * @@ -1651,6 +1609,7 @@ return (NULL); } w_child_free = wcl->wcl_next; + w_child_free_cnt--; bzero(wcl, sizeof(*wcl)); return (wcl); } @@ -1661,6 +1620,7 @@ wcl->wcl_next = w_child_free; w_child_free = wcl; + w_child_free_cnt++; } static struct lock_list_entry * From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 19:42:01 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45F3716A420; Thu, 5 Jan 2006 19:42:01 +0000 (GMT) (envelope-from dsh@vlink.ru) Received: from deliver.smtp.vlink.ru (vlink-1.avtlg.ru [83.239.142.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id C496E43D67; Thu, 5 Jan 2006 19:41:53 +0000 (GMT) (envelope-from dsh@vlink.ru) Received: from smtp.smtp.vlink.ru (clamav.smtp.vlink.ru [192.168.4.1]) by deliver.smtp.vlink.ru (Postfix) with ESMTP id 144F3FECDF1; Thu, 5 Jan 2006 22:41:51 +0300 (MSK) Received: from neva.vlink.ru (neva.vlink.ru [217.107.252.66]) by smtp.smtp.vlink.ru (Postfix) with ESMTP id DED701009AAA; Thu, 5 Jan 2006 22:41:50 +0300 (MSK) Received: from neva.vlink.ru (localhost [127.0.0.1]) by neva.vlink.ru (8.13.4/8.13.4) with ESMTP id k05JfefX006916; Thu, 5 Jan 2006 22:41:40 +0300 (MSK) (envelope-from dsh@vlink.ru) Received: (from dsh@localhost) by neva.vlink.ru (8.13.4/8.13.4/Submit) id k05Jfe2K006913; Thu, 5 Jan 2006 22:41:40 +0300 (MSK) (envelope-from dsh@vlink.ru) X-Comment-To: Don Lewis To: Don Lewis References: <200601051845.k05IjGCI015543@gw.catspoiler.org> From: Denis Shaposhnikov Date: Thu, 05 Jan 2006 22:41:40 +0300 In-Reply-To: <200601051845.k05IjGCI015543@gw.catspoiler.org> (Don Lewis's message of "Thu, 5 Jan 2006 10:45:16 -0800 (PST)") Message-ID: <87bqyqa2dn.fsf@neva.vlink.ru> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV using ClamSMTP Cc: gcr+freebsd-stable@tharned.org, freebsd@McKusick.COM, freebsd-stable@FreeBSD.org, kris@obsecurity.org Subject: Re: Recurring problem: processes block accessing UFS file system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 19:42:01 -0000 >>>>> "Don" == Don Lewis writes: Don> pid 519 wants to lock this vnode but some other thread is Don> holding the vnode lock. Unfortunately we don't know who the Don> lock holder is because the message is truncated. Is it possible to find out the answer from the crashdump? Don> This might just be a vnode lock leak. Build a debug kernel with Don> the DEBUG_VFS_LOCKS and DEBUG_LOCKS options and see if anything Don> shows up. I'll try, thank you. -- DSS5-RIPE DSS-RIPN 2:550/5068@fidonet 2:550/5069@fidonet mailto:dsh@vlink.ru http://neva.vlink.ru/~dsh/ From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 19:53:33 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A047A16A41F for ; Thu, 5 Jan 2006 19:53:33 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B813D43D6A for ; Thu, 5 Jan 2006 19:53:32 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id k05JrOmx015661; Thu, 5 Jan 2006 11:53:28 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200601051953.k05JrOmx015661@gw.catspoiler.org> Date: Thu, 5 Jan 2006 11:53:24 -0800 (PST) From: Don Lewis To: dsh@vlink.ru In-Reply-To: <87bqyqa2dn.fsf@neva.vlink.ru> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org Subject: Re: Recurring problem: processes block accessing UFS file system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 19:53:33 -0000 On 5 Jan, Denis Shaposhnikov wrote: >>>>>> "Don" == Don Lewis writes: > > Don> pid 519 wants to lock this vnode but some other thread is > Don> holding the vnode lock. Unfortunately we don't know who the > Don> lock holder is because the message is truncated. > > Is it possible to find out the answer from the crashdump? It's possible if you have the matching debug kernel, though it is more painful. In kgdb: print *(struct vnode *)0xc691f318 print (struct vnode *)0xc691f318->v_vnlock->lk_lockholder->td_proc->p_pid) or something like that. > Don> This might just be a vnode lock leak. Build a debug kernel with > Don> the DEBUG_VFS_LOCKS and DEBUG_LOCKS options and see if anything > Don> shows up. > > I'll try, thank you. Are you using any unusual file systems, such as nullfs or unionfs? From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 20:33:54 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC56016A41F; Thu, 5 Jan 2006 20:33:54 +0000 (GMT) (envelope-from dsh@vlink.ru) Received: from deliver.smtp.vlink.ru (vlink-1.avtlg.ru [83.239.142.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id E08AE43D45; Thu, 5 Jan 2006 20:33:53 +0000 (GMT) (envelope-from dsh@vlink.ru) Received: from smtp.smtp.vlink.ru (clamav.smtp.vlink.ru [192.168.4.1]) by deliver.smtp.vlink.ru (Postfix) with ESMTP id 65CBFFECDEF; Thu, 5 Jan 2006 23:33:52 +0300 (MSK) Received: from neva.vlink.ru (neva.vlink.ru [217.107.252.66]) by smtp.smtp.vlink.ru (Postfix) with ESMTP id 2D2551009AAA; Thu, 5 Jan 2006 23:33:51 +0300 (MSK) Received: from neva.vlink.ru (localhost [127.0.0.1]) by neva.vlink.ru (8.13.4/8.13.4) with ESMTP id k05KXfqF007178; Thu, 5 Jan 2006 23:33:41 +0300 (MSK) (envelope-from dsh@vlink.ru) Received: (from dsh@localhost) by neva.vlink.ru (8.13.4/8.13.4/Submit) id k05KXf7N007175; Thu, 5 Jan 2006 23:33:41 +0300 (MSK) (envelope-from dsh@vlink.ru) X-Comment-To: Don Lewis To: Don Lewis References: <200601051953.k05JrOmx015661@gw.catspoiler.org> From: Denis Shaposhnikov Date: Thu, 05 Jan 2006 23:33:41 +0300 In-Reply-To: <200601051953.k05JrOmx015661@gw.catspoiler.org> (Don Lewis's message of "Thu, 5 Jan 2006 11:53:24 -0800 (PST)") Message-ID: <873bk2fm8q.fsf@neva.vlink.ru> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-stable@FreeBSD.org Subject: Re: Recurring problem: processes block accessing UFS file system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 20:33:55 -0000 >>>>> "Don" == Don Lewis writes: Don> Are you using any unusual file systems, such as nullfs or Don> unionfs? Yes, I'm use a lots of nullfs. This is a host system for about 20 jails with nullfs mounted ro system: /dev/mirror/gm0s1a on / (ufs, local, read-only) devfs on /dev (devfs, local) /dev/mirror/gm0s1d on /usr/local (ufs, local) /dev/mirror/gm0s1e on /home (ufs, local, nosuid) /dev/mirror/gm0s1f on /tmp (ufs, local, noexec) /dev/mirror/gm0s1g on /var (ufs, NFS exported, local) procfs on /proc (procfs, local) devfs on /var/named/dev (devfs, local) /var/jail/build/the.jail on /var/jail/netflow/the.jail/.build (nullfs, local, read-only) /var/jail/netflow/the.jail.etc on /var/jail/netflow/the.jail/.build/etc (nullfs, local, read-only) /var/jail/netflow/the.jail.local on /var/jail/netflow/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/netflow/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/mysql/the.jail/.build (nullfs, local, read-only) /var/jail/mysql/the.jail.etc on /var/jail/mysql/the.jail/.build/etc (nullfs, local, read-only) /var/jail/mysql/the.jail.local on /var/jail/mysql/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/mysql/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/dspam/the.jail/.build (nullfs, local, read-only) /var/jail/dspam/the.jail.etc on /var/jail/dspam/the.jail/.build/etc (nullfs, local, read-only) /var/jail/dspam/the.jail.local on /var/jail/dspam/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/dspam/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/deliver_smtp/the.jail/.build (nullfs, local, read-only) /var/jail/deliver_smtp/the.jail.etc on /var/jail/deliver_smtp/the.jail/.build/etc (nullfs, local, read-only) /var/jail/deliver_smtp/the.jail.local on /var/jail/deliver_smtp/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/deliver_smtp/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/clamav/the.jail/.build (nullfs, local, read-only) /var/jail/clamav/the.jail.etc on /var/jail/clamav/the.jail/.build/etc (nullfs, local, read-only) /var/jail/clamav/the.jail.local on /var/jail/clamav/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/clamav/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/mx1_smtp/the.jail/.build (nullfs, local, read-only) /var/jail/mx1_smtp/the.jail.etc on /var/jail/mx1_smtp/the.jail/.build/etc (nullfs, local, read-only) /var/jail/mx1_smtp/the.jail.local on /var/jail/mx1_smtp/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/mx1_smtp/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/smtp_smtp/the.jail/.build (nullfs, local, read-only) /var/jail/smtp_smtp/the.jail.etc on /var/jail/smtp_smtp/the.jail/.build/etc (nullfs, local, read-only) /var/jail/smtp_smtp/the.jail.local on /var/jail/smtp_smtp/the.jail/.build/usr/local (nullfs, local, read-only) /var/jail/mx1_smtp/the.jail/var/db/postfix on /var/jail/smtp_smtp/the.jail/var/db/postfix (nullfs, local, read-only) devfs on /var/jail/smtp_smtp/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/cacti/the.jail/.build (nullfs, local, read-only) /var/jail/cacti/the.jail.etc on /var/jail/cacti/the.jail/.build/etc (nullfs, local, read-only) /var/jail/cacti/the.jail.local on /var/jail/cacti/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/cacti/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/rk80/the.jail/.build (nullfs, local, read-only) /var/jail/rk80/the.jail.etc on /var/jail/rk80/the.jail/.build/etc (nullfs, local, read-only) /var/jail/rk80/the.jail.local on /var/jail/rk80/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/rk80/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/syslog/the.jail/.build (nullfs, local, read-only) /var/jail/syslog/the.jail.etc on /var/jail/syslog/the.jail/.build/etc (nullfs, local, read-only) /var/jail/syslog/the.jail.local on /var/jail/syslog/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/syslog/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/tftpboot/the.jail/.build (nullfs, local, read-only) /var/jail/tftpboot/the.jail.etc on /var/jail/tftpboot/the.jail/.build/etc (nullfs, local, read-only) /var/jail/tftpboot/the.jail.local on /var/jail/tftpboot/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/tftpboot/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/clickon/the.jail/.build (nullfs, local, read-only) /var/jail/clickon/the.jail.etc on /var/jail/clickon/the.jail/.build/etc (nullfs, local, read-only) /var/jail/clickon/the.jail.local on /var/jail/clickon/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/clickon/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/sulci/the.jail/.build (nullfs, local, read-only) /var/jail/sulci/the.jail.etc on /var/jail/sulci/the.jail/.build/etc (nullfs, local, read-only) /var/jail/sulci/the.jail.local on /var/jail/sulci/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/sulci/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/sites_clickon/the.jail/.build (nullfs, local, read-only) /var/jail/sites_clickon/the.jail.etc on /var/jail/sites_clickon/the.jail/.build/etc (nullfs, local, read-only) /var/jail/sites_clickon/the.jail.local on /var/jail/sites_clickon/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/sites_clickon/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/cvs/the.jail/.build (nullfs, local, read-only) /var/jail/cvs/the.jail.etc on /var/jail/cvs/the.jail/.build/etc (nullfs, local, read-only) /var/jail/cvs/the.jail.local on /var/jail/cvs/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/cvs/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/plone/the.jail/.build (nullfs, local, read-only) /var/jail/plone/the.jail.etc on /var/jail/plone/the.jail/.build/etc (nullfs, local, read-only) /var/jail/plone/the.jail.local on /var/jail/plone/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/plone/the.jail/dev (devfs, local) devfs on /var/jail/build/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/svn/the.jail/.build (nullfs, local, read-only) /var/jail/svn/the.jail.etc on /var/jail/svn/the.jail/.build/etc (nullfs, local, read-only) /var/jail/svn/the.jail.local on /var/jail/svn/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/svn/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/blax/the.jail/.build (nullfs, local, read-only) /var/jail/blax/the.jail.etc on /var/jail/blax/the.jail/.build/etc (nullfs, local, read-only) /var/jail/blax/the.jail.local on /var/jail/blax/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/blax/the.jail/dev (devfs, local) /var/jail/build/the.jail on /var/jail/awstats/the.jail/.build (nullfs, local, read-only) /var/jail/awstats/the.jail.etc on /var/jail/awstats/the.jail/.build/etc (nullfs, local, read-only) /var/jail/awstats/the.jail.local on /var/jail/awstats/the.jail/.build/usr/local (nullfs, local, read-only) devfs on /var/jail/awstats/the.jail/dev (devfs, local) -- DSS5-RIPE DSS-RIPN 2:550/5068@fidonet 2:550/5069@fidonet mailto:dsh@vlink.ru http://neva.vlink.ru/~dsh/ From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 21:27:40 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C358416A41F for ; Thu, 5 Jan 2006 21:27:40 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A26343D5D for ; Thu, 5 Jan 2006 21:27:39 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 865ECB85A for ; Thu, 5 Jan 2006 16:27:38 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <6CADC5BD-FBF5-472E-8087-8494AD03549C@khera.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-stable From: Vivek Khera Date: Thu, 5 Jan 2006 16:27:37 -0500 X-Mailer: Apple Mail (2.746.2) Subject: SCSI RAID card recommendation (1/2 height PCI-X U320 SCSI dual channel) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 21:27:40 -0000 Boy... what a major disappointment I just had... I got in my SunFire X4100 dual opteron server and a LSI MegaRAID 320-2X PCI-X card. Unfortunately, the Sun seems to only accept 1/2 height cards. Totally lame. Anyhow, I'm having a hard time finding 1/2 height U320 RAID cards with dual channels (I can't imagine how the connectors would fit, but hey I can hope). Does anyone have any recommendations? Naturally I'm going to run 6.0-RELEASE on it. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 21:35:05 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A405916A41F for ; Thu, 5 Jan 2006 21:35:05 +0000 (GMT) (envelope-from rjk@wintek.com) Received: from smtp1.wintek.com (smtp1.wintek.com [199.233.104.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A49843D45 for ; Thu, 5 Jan 2006 21:35:04 +0000 (GMT) (envelope-from rjk@wintek.com) Received: from [172.28.1.248] (rjk.wintek.com [206.230.2.248]) by smtp1.wintek.com (8.13.4/8.13.4/Wintek) with ESMTP id k05LY93o022022 for ; Thu, 5 Jan 2006 16:34:09 -0500 (EST) (envelope-from rjk@wintek.com) Message-ID: <43BD90E9.3020305@wintek.com> Date: Thu, 05 Jan 2006 16:34:33 -0500 From: Richard Kuhns User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051130) X-Accept-Language: en-us, en MIME-Version: 1.0 To: stable@freebsd.org X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (smtp1.wintek.com [199.233.104.106]); Thu, 05 Jan 2006 16:34:10 -0500 (EST) Cc: Subject: gdm problem with kernel as of 2005-01-04 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 21:35:05 -0000 I just finished a buildworld/buildkernel/mergemaster on my Dell Inspiron 9300. Upon rebooting, I noticed that gdm seemed to start earlier in the boot process than it used to. When the login screen appeared, the mouse seemed to work fine, but nothing I typed appeared. Attempting to use C-A-F1 to switch to vty0 just beeped. C-A-Del worked to reboot the laptop. I booted single user, commented out gdm_enable="YES" in /etc/rc.conf, and rebooted -- everything was fine. I put the gdm_enable back and ran /usr/X11R6/etc/rc.d/gdm.sh start -- gdm started, fully functional. I rebooted again -- gdm ignored the keyboard. After several reboots, I've found that gdm seems to work fine as long as I don't have 'gdm_enable="YES"' in /etc/rc.conf when the machine boots. I've just finished upgrading gdm (using portmanager); still the same problem. If anyone has suggestions/wants me to try anything, just say so. Thanks! - Rich -- Richard Kuhns Wintek Corporation E-mail: rjk@wintek.com 427 N 6th Street Tel: +1 (765) 742-8428 Lafayette, IN 47901-1126 Fax: +1 (765) 742-0646 United States of America From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 21:57:27 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3669616A41F for ; Thu, 5 Jan 2006 21:57:27 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACCED43D60 for ; Thu, 5 Jan 2006 21:57:26 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id k05LvJV0015906; Thu, 5 Jan 2006 13:57:23 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200601052157.k05LvJV0015906@gw.catspoiler.org> Date: Thu, 5 Jan 2006 13:57:19 -0800 (PST) From: Don Lewis To: dsh@vlink.ru In-Reply-To: <873bk2fm8q.fsf@neva.vlink.ru> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org Subject: Re: Recurring problem: processes block accessing UFS file system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 21:57:27 -0000 On 5 Jan, Denis Shaposhnikov wrote: >>>>>> "Don" == Don Lewis writes: > > Don> Are you using any unusual file systems, such as nullfs or > Don> unionfs? > > Yes, I'm use a lots of nullfs. This is a host system for about 20 > jails with nullfs mounted ro system: That would be my guess as to the cause of the problem. Hopefully DEBUG_VFS_LOCKS will help pinpoint the bug. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 22:24:11 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 250BA16A41F for ; Thu, 5 Jan 2006 22:24:11 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63CA143D5A for ; Thu, 5 Jan 2006 22:24:10 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 94046B85A for ; Thu, 5 Jan 2006 17:24:09 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <6CADC5BD-FBF5-472E-8087-8494AD03549C@khera.org> References: <6CADC5BD-FBF5-472E-8087-8494AD03549C@khera.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Thu, 5 Jan 2006 17:24:09 -0500 To: freebsd-stable X-Mailer: Apple Mail (2.746.2) Subject: Re: SCSI RAID card recommendation (1/2 height PCI-X U320 SCSI dual channel) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 22:24:11 -0000 On Jan 5, 2006, at 4:27 PM, Vivek Khera wrote: > Anyhow, I'm having a hard time finding 1/2 height U320 RAID cards > with dual channels (I can't imagine how the connectors would fit, > but hey I can hope). Does anyone have any recommendations? > Naturally I'm going to run 6.0-RELEASE on it. Ok... seems that my only likely candidate is the Adaptec 2230SLP. I'm not a big adaptec fan so I have little experience with these. There was a discussion on the -scsi list a year ago and the card is listed as supported, but it is hard to find how stable these cards are and how well they perform under heavy I/O + network load. The only other aac controller I have is a Dell PERC type which is god- awful slow, but I hear that's dell's fault not adaptec's. I don't know what to believe there. That card is quite stable however. Any experiences with this that anyone wishes to share? From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 22:41:56 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EC4E16A41F for ; Thu, 5 Jan 2006 22:41:56 +0000 (GMT) (envelope-from scott@fishballoon.org) Received: from mta09-winn.ispmail.ntl.com (mta09-winn.ispmail.ntl.com [81.103.221.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 138BD43D62 for ; Thu, 5 Jan 2006 22:41:54 +0000 (GMT) (envelope-from scott@fishballoon.org) Received: from aamta09-winn.ispmail.ntl.com ([81.103.221.35]) by mta09-winn.ispmail.ntl.com with ESMTP id <20060105224153.JKDX8609.mta09-winn.ispmail.ntl.com@aamta09-winn.ispmail.ntl.com> for ; Thu, 5 Jan 2006 22:41:53 +0000 Received: from llama.fishballoon.org ([81.104.195.171]) by aamta09-winn.ispmail.ntl.com with ESMTP id <20060105224153.XKSP13162.aamta09-winn.ispmail.ntl.com@llama.fishballoon.org> for ; Thu, 5 Jan 2006 22:41:53 +0000 Received: from tuatara.fishballoon.org ([192.168.1.6]) by llama.fishballoon.org with esmtp (Exim 4.52 (FreeBSD)) id 1Eudnr-0002xX-Ns for freebsd-stable@freebsd.org; Thu, 05 Jan 2006 22:41:51 +0000 Received: (from scott@localhost) by tuatara.fishballoon.org (8.13.4/8.13.4/Submit) id k05MfoEv001307 for freebsd-stable@freebsd.org; Thu, 5 Jan 2006 22:41:50 GMT (envelope-from scott) Date: Thu, 5 Jan 2006 22:41:50 +0000 From: Scott Mitchell To: freebsd-stable@freebsd.org Message-ID: <20060105224150.GA991@tuatara.fishballoon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-STABLE i386 Subject: 6.0 on Dell 1850 with PERC4e/DC RAID? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 22:41:56 -0000 Hi all, I may be getting a new Dell PE1850 soon, to replace our ancient CVS server (still running 4-STABLE). The new machine will ideally run 6.0 and have a PERC4e/DC RAID card - the one with battery-backed cache. This is listed as supported by amr(4), but I'm wondering how well it actually works in the case of a disk failure. Will the driver tell me that disk has failed (a syslog message would be enough) or will I have to make a daily trip into the server room to check the front panel lights? Presumably it handles hot-swapping a replacement drive OK? I found some posts mentioning some management/monitoring tools for these controllers that were allegedly available from the www.lsilogic.com website, but I can't find anything on there for FreeBSD. Do the Linux tools work? Cheers, Scott -- =========================================================================== Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" scott at fishballoon.org | 0xAA775B8B | -- Anon From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 23:32:28 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FD1C16A41F; Thu, 5 Jan 2006 23:32:28 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C479743D45; Thu, 5 Jan 2006 23:32:27 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id CD7954B6F; Thu, 5 Jan 2006 17:32:26 -0600 (CST) Date: Thu, 5 Jan 2006 17:32:26 -0600 To: jrhett@svcolo.com, freebsd-stable@freebsd.org, current Message-ID: <20060105233226.GC17890@soaustin.net> References: <43A266E5.3080103@samsco.org> <43AB1E65.2030501@mac.com> <20051222221202.GM39174@svcolo.com> <200512231136.12471.doconnor@gsoft.com.au> <20060105092448.GH1358@svcolo.com> <20060105184147.GD69162@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512231136.12471.doconnor@gsoft.com.au> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) Cc: Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 23:32:28 -0000 > Jo Rhett wrote this message on Thu, Jan 05, 2006 at 01:24 -0800: > Sorry. As said before, the topic is always struck down and nobody from > core has ever stood up to say "we'll support this". I don't know whose on > core this week, nor will I at any given time. This information is publicly available if you want to do the research. > I just know that core has either struck it down or been Silent. The latter is an entirely different case from the former, and you've been claiming core has done the former. This, and the above, tell me that you're not interested in checking your facts before making an accusation. (And, as well, that you do not even understand the role the core plays in the project. Hint: it is not primarily technical in nature.) Because of this, it's more much difficult for me to give your technical arguments as much credence as I would otherwise. As a final observation, FreeBSD is rarely advanced by postings of the form 'FreeBSD must do XYZ'. This is primarily because volunteers work on whatever they feel interested in doing with their free time, rather than the priorities anyone else sets for them. But your mileage may vary. mcl From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 23:34:26 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA7C616A41F for ; Thu, 5 Jan 2006 23:34:26 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99AA843D48 for ; Thu, 5 Jan 2006 23:34:24 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 7526672DD9; Thu, 5 Jan 2006 15:34:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 73AC772DD4; Thu, 5 Jan 2006 15:34:24 -0800 (PST) Date: Thu, 5 Jan 2006 15:34:24 -0800 (PST) From: Doug White To: Scott Mitchell In-Reply-To: <20060105224150.GA991@tuatara.fishballoon.org> Message-ID: <20060105153250.D58957@carver.gumbysoft.com> References: <20060105224150.GA991@tuatara.fishballoon.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org Subject: Re: 6.0 on Dell 1850 with PERC4e/DC RAID? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 23:34:26 -0000 On Thu, 5 Jan 2006, Scott Mitchell wrote: > Hi all, > > I may be getting a new Dell PE1850 soon, to replace our ancient CVS server > (still running 4-STABLE). The new machine will ideally run 6.0 and have a > PERC4e/DC RAID card - the one with battery-backed cache. This is listed as > supported by amr(4), but I'm wondering how well it actually works in the > case of a disk failure. Will the driver tell me that disk has failed (a > syslog message would be enough) or will I have to make a daily trip into > the server room to check the front panel lights? Presumably it handles > hot-swapping a replacement drive OK? >From what I remember, you will receive status-change kernel messages when disks disappear, rebuilds start, and so forth. So for most day-to-day manipulation you should be fine. You may want to make sure the auto rebuild option is enabled in the controller's BIOS since no working control programs from userland are generally available at this time. That also means you can't create new volumes at runtime, but thats not so horrible... -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 00:01:24 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4179A16A41F for ; Fri, 6 Jan 2006 00:01:24 +0000 (GMT) (envelope-from scott@fishballoon.org) Received: from mta07-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id A264B43D4C for ; Fri, 6 Jan 2006 00:01:20 +0000 (GMT) (envelope-from scott@fishballoon.org) Received: from aamta09-winn.ispmail.ntl.com ([81.103.221.35]) by mta07-winn.ispmail.ntl.com with ESMTP id <20060106000119.NZJK21883.mta07-winn.ispmail.ntl.com@aamta09-winn.ispmail.ntl.com>; Fri, 6 Jan 2006 00:01:19 +0000 Received: from llama.fishballoon.org ([81.104.195.171]) by aamta09-winn.ispmail.ntl.com with ESMTP id <20060106000119.YKFB13162.aamta09-winn.ispmail.ntl.com@llama.fishballoon.org>; Fri, 6 Jan 2006 00:01:19 +0000 Received: from tuatara.fishballoon.org ([192.168.1.6]) by llama.fishballoon.org with esmtp (Exim 4.52 (FreeBSD)) id 1Euf2j-00033x-AL; Fri, 06 Jan 2006 00:01:17 +0000 Received: (from scott@localhost) by tuatara.fishballoon.org (8.13.4/8.13.4/Submit) id k0601G7Q001605; Fri, 6 Jan 2006 00:01:16 GMT (envelope-from scott) Date: Fri, 6 Jan 2006 00:01:16 +0000 From: Scott Mitchell To: Doug White Message-ID: <20060106000116.GB991@tuatara.fishballoon.org> References: <20060105224150.GA991@tuatara.fishballoon.org> <20060105153250.D58957@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060105153250.D58957@carver.gumbysoft.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-STABLE i386 Cc: freebsd-stable@freebsd.org Subject: Re: 6.0 on Dell 1850 with PERC4e/DC RAID? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 00:01:24 -0000 On Thu, Jan 05, 2006 at 03:34:24PM -0800, Doug White wrote: > On Thu, 5 Jan 2006, Scott Mitchell wrote: > > > Hi all, > > > > I may be getting a new Dell PE1850 soon, to replace our ancient CVS server > > (still running 4-STABLE). The new machine will ideally run 6.0 and have a > > PERC4e/DC RAID card - the one with battery-backed cache. This is listed as > > supported by amr(4), but I'm wondering how well it actually works in the > > case of a disk failure. Will the driver tell me that disk has failed (a > > syslog message would be enough) or will I have to make a daily trip into > > the server room to check the front panel lights? Presumably it handles > > hot-swapping a replacement drive OK? > > >From what I remember, you will receive status-change kernel messages when > disks disappear, rebuilds start, and so forth. So for most day-to-day > manipulation you should be fine. That would be fine - as long as there's some notification of important events. > You may want to make sure the auto rebuild option is enabled in the > controller's BIOS since no working control programs from userland are > generally available at this time. That also means you can't create new > volumes at runtime, but thats not so horrible... I expect there will only ever be one volume, so that's unlikely to be a problem :) Many thanks, Scott -- =========================================================================== Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" scott at fishballoon.org | 0xAA775B8B | -- Anon From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 00:09:35 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D94AE16A41F for ; Fri, 6 Jan 2006 00:09:35 +0000 (GMT) (envelope-from dsze@mail.distrust.net) Received: from mail.distrust.net (mail.distrust.net [69.93.230.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 536F843D5C for ; Fri, 6 Jan 2006 00:09:35 +0000 (GMT) (envelope-from dsze@mail.distrust.net) Received: from mail.distrust.net (localhost [127.0.0.1]) by mail.distrust.net (8.13.3/8.13.3) with ESMTP id k06099jS001314; Thu, 5 Jan 2006 18:09:09 -0600 (CST) (envelope-from dsze@mail.distrust.net) Received: (from dsze@localhost) by mail.distrust.net (8.13.3/8.13.3/Submit) id k06099MK001313; Thu, 5 Jan 2006 18:09:09 -0600 (CST) (envelope-from dsze) Date: Thu, 5 Jan 2006 18:09:09 -0600 From: David Sze To: Doug White Message-ID: <20060106000909.GA97739@mail.distrust.net> References: <20060105224150.GA991@tuatara.fishballoon.org> <20060105153250.D58957@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060105153250.D58957@carver.gumbysoft.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.87.1/1230/Thu Jan 5 05:49:56 2006 on mail.distrust.net X-Virus-Status: Clean Cc: Scott Mitchell , freebsd-stable@freebsd.org Subject: Re: 6.0 on Dell 1850 with PERC4e/DC RAID? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 00:09:36 -0000 On Thu, Jan 05, 2006 at 03:34:24PM -0800, Doug White wrote: > On Thu, 5 Jan 2006, Scott Mitchell wrote: > > > Hi all, > > > > I may be getting a new Dell PE1850 soon, to replace our ancient CVS server > > (still running 4-STABLE). The new machine will ideally run 6.0 and have a > > PERC4e/DC RAID card - the one with battery-backed cache. This is listed as > > supported by amr(4), but I'm wondering how well it actually works in the > > case of a disk failure. Will the driver tell me that disk has failed (a > > syslog message would be enough) or will I have to make a daily trip into > > the server room to check the front panel lights? Presumably it handles > > hot-swapping a replacement drive OK? > > >From what I remember, you will receive status-change kernel messages when > disks disappear, rebuilds start, and so forth. So for most day-to-day > manipulation you should be fine. > > You may want to make sure the auto rebuild option is enabled in the > controller's BIOS since no working control programs from userland are > generally available at this time. That also means you can't create new > volumes at runtime, but thats not so horrible... The sysutils/megarc port appears to work for both status change polling and runtime configuration (at least on a PE800 and a PE2850 that I tested on). From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 00:24:24 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86EF516A41F for ; Fri, 6 Jan 2006 00:24:24 +0000 (GMT) (envelope-from scott@fishballoon.org) Received: from mta07-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C61A43D48 for ; Fri, 6 Jan 2006 00:24:23 +0000 (GMT) (envelope-from scott@fishballoon.org) Received: from aamta10-winn.ispmail.ntl.com ([81.103.221.35]) by mta07-winn.ispmail.ntl.com with ESMTP id <20060106002422.OLNQ21883.mta07-winn.ispmail.ntl.com@aamta10-winn.ispmail.ntl.com>; Fri, 6 Jan 2006 00:24:22 +0000 Received: from llama.fishballoon.org ([81.104.195.171]) by aamta10-winn.ispmail.ntl.com with ESMTP id <20060106002422.VBBQ1068.aamta10-winn.ispmail.ntl.com@llama.fishballoon.org>; Fri, 6 Jan 2006 00:24:22 +0000 Received: from tuatara.fishballoon.org ([192.168.1.6]) by llama.fishballoon.org with esmtp (Exim 4.52 (FreeBSD)) id 1EufP2-00035g-8t; Fri, 06 Jan 2006 00:24:20 +0000 Received: (from scott@localhost) by tuatara.fishballoon.org (8.13.4/8.13.4/Submit) id k060OJ0f001865; Fri, 6 Jan 2006 00:24:19 GMT (envelope-from scott) Date: Fri, 6 Jan 2006 00:24:19 +0000 From: Scott Mitchell To: David Sze Message-ID: <20060106002419.GC991@tuatara.fishballoon.org> References: <20060105224150.GA991@tuatara.fishballoon.org> <20060105153250.D58957@carver.gumbysoft.com> <20060106000909.GA97739@mail.distrust.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060106000909.GA97739@mail.distrust.net> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-STABLE i386 Cc: freebsd-stable@freebsd.org Subject: Re: 6.0 on Dell 1850 with PERC4e/DC RAID? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 00:24:24 -0000 On Thu, Jan 05, 2006 at 06:09:09PM -0600, David Sze wrote: > On Thu, Jan 05, 2006 at 03:34:24PM -0800, Doug White wrote: > > On Thu, 5 Jan 2006, Scott Mitchell wrote: > > > supported by amr(4), but I'm wondering how well it actually works in the > > > case of a disk failure. Will the driver tell me that disk has failed (a > > > syslog message would be enough) or will I have to make a daily trip into > > > the server room to check the front panel lights? Presumably it handles > > > hot-swapping a replacement drive OK? > > > > >From what I remember, you will receive status-change kernel messages when > > disks disappear, rebuilds start, and so forth. So for most day-to-day > > manipulation you should be fine. > > > > You may want to make sure the auto rebuild option is enabled in the > > controller's BIOS since no working control programs from userland are > > generally available at this time. That also means you can't create new > > volumes at runtime, but thats not so horrible... > > The sysutils/megarc port appears to work for both status change polling > and runtime configuration (at least on a PE800 and a PE2850 that I tested > on). Cool, I'll check that out when the hardware arrives. Many thanks, Scott -- =========================================================================== Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" scott at fishballoon.org | 0xAA775B8B | -- Anon From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 00:50:19 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E62916A41F; Fri, 6 Jan 2006 00:50:19 +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 2F90543D45; Fri, 6 Jan 2006 00:50:17 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.21]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k060oEp4015334 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 6 Jan 2006 11:20:16 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Jo Rhett Date: Fri, 6 Jan 2006 11:20:13 +1030 User-Agent: KMail/1.8.3 References: <43A266E5.3080103@samsco.org> <200512231136.12471.doconnor@gsoft.com.au> <20060105092448.GH1358@svcolo.com> In-Reply-To: <20060105092448.GH1358@svcolo.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1266678.4ed0llI9s7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601061120.14707.doconnor@gsoft.com.au> X-Spam-Score: -1.36 () ALL_TRUSTED,SUBJECT_EXCESS_QP X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: freebsd-stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 00:50:19 -0000 --nextPart1266678.4ed0llI9s7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [cross post to -current removed] On Thu, 5 Jan 2006 19:54, Jo Rhett wrote: > On Fri, Dec 23, 2005 at 11:36:11AM +1030, Daniel O'Connor wrote: > > On each 'client' PC.. > > NFS mount /usr/src and /usr/obj > > installkernel > > reboot > > installworld > > Works fine on home computers behind firewalls. > > Useless on public servers that don't run RPC. > Useless on flash-based servers where minimizing writes is necessary. > (mergemaster does far far far too many writes) =46or NFS mount, read: any network file system. You can also use, say IPSEC= to=20 protect the NFS packets (although I'm not claiming it's a trivial thing to= =20 set up..) As for restricting the number of writes - that is a totally separate issue = and=20 isn't very relevant to this discussion. > > You are putting words in the mouth of core@ - > > Sorry. As said before, the topic is always struck down and nobody from > core has ever stood up to say "we'll support this". I don't know whose on > core this week, nor will I at any given time. I just know that core has > either struck it down or been Silent. In general core IS silent. Core isn't some governing body that decides what happens in FreeBSD and pla= ns=20 in detail what happens. You are showing a fundamental misunderstanding abou= t=20 how FreeBSD "works". Also, you just said "... the topic is always struck down ..." - what do you= =20 mean? Are you claiming someone from (or claiming to be from core) said "Don= 't=20 do this, we won't allow it"? If so, can you supply proof? > A good binary update mechanism shouldn't be just the network. Updates fr= om > flash devices, ISO images, etc should all work much the same way. Absolutely. In fact you could put /usr/src and /usr/obj on a CD/DVD/Flash drive and=20 upgrade that way. I would *welcome* a more sophisticated method for binary upgrades that was = a=20 lot smarter. I imagine pretty much everyone else would too. > > Unless you mean "core@ said they would not support packaging the base" > > which is different. > > People have clearly identified the problems that prevent a useful binary > update mechanism from working, and what they need from core. Some have > asked for core packages, others have other ideas, and some have said > "anything that gives me versioning ability" and and..? Anyway, so what? Nothing stops you writing such a system, and I contend it= =20 isn't necessary to version the base system, or package it specially to do=20 binary upgrades. Something similar to freebsd-update could do it. > > This is not true - I don't see it as being mandatory to be able to apply > > binary updates. (Case in point - freebsd-update works fine without it) > > freebsd-update works "fine" if you run GENERIC with no build options. > Back to "useful for home computers". So, uhh, how would your magical binary upgrade system handle custom kernels? Why would it be any different? You still haven't explained how this would=20 work.. > freebsd-update is hampered by the exact problems I'm listing here. > Difficulty determining "what I have", no method to store "what I did" and > no effective backout mechanism to speak of. Then feel free to expand on it. This IS an open source project - you can see how everything is written, if = you=20 want to improve it > Nobody that I know cares whether or not the solution manifests as core os > packages, but some sort of core versioning ability has to be developed and > supported by the core. I don't think core is really very relevant here - core is there to mostly=20 settle disputes. The way forward is to achieve consensus and have working=20 solutions. If you supply a working framework then I think you'll find a lot of support= =20 materialises. The problem is when you are just proposing vapourware solutio= ns=20 everyone steps in and wants it done their way. Code speaks louder than words :) =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 --nextPart1266678.4ed0llI9s7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDvb7G5ZPcIHs/zowRAnY0AJ9Ny5aDvmRhRlYzB9iVANDTHK0IbACfdG9f 8VJRrdpxZqqee85xpei2O3Y= =oKH9 -----END PGP SIGNATURE----- --nextPart1266678.4ed0llI9s7-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 02:21:58 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C1EE16A41F for ; Fri, 6 Jan 2006 02:21:58 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF89043D46 for ; Fri, 6 Jan 2006 02:21:57 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id D61CB4D20E; Fri, 6 Jan 2006 02:22:03 +0000 (GMT) Received: from [192.168.0.2] (ppp157-158.static.internode.on.net [150.101.157.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id DE1214D21A; Fri, 6 Jan 2006 02:22:02 +0000 (GMT) Message-ID: <43BDD444.80509@roq.com> Date: Fri, 06 Jan 2006 13:21:56 +1100 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20051208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Mitchell References: <20060105224150.GA991@tuatara.fishballoon.org> In-Reply-To: <20060105224150.GA991@tuatara.fishballoon.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-stable@freebsd.org Subject: Re: 6.0 on Dell 1850 with PERC4e/DC RAID? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 02:21:58 -0000 Scott Mitchell wrote: >Hi all, > >I may be getting a new Dell PE1850 soon, to replace our ancient CVS server >(still running 4-STABLE). The new machine will ideally run 6.0 and have a >PERC4e/DC RAID card - the one with battery-backed cache. This is listed as >supported by amr(4), but I'm wondering how well it actually works in the >case of a disk failure. Will the driver tell me that disk has failed (a >syslog message would be enough) or will I have to make a daily trip into >the server room to check the front panel lights? Presumably it handles >hot-swapping a replacement drive OK? > >I found some posts mentioning some management/monitoring tools for these >controllers that were allegedly available from the www.lsilogic.com >website, but I can't find anything on there for FreeBSD. Do the Linux >tools work? > > FYI there also has been a big update to the amr driver which claims to dramatically increase performance among other things, interestingly enought it was augmented by Yahoo, I can only assume they are moving to Dell, yahoo for me (and now you :). The updates are still in -current but it will be MFC'ed into stable sooner or later. http://lists.freebsd.org/pipermail/cvs-src/2005-December/056814.html Log: Mega update to the LSI MegaRAID driver: 1. Implement a large set of ioctl shims so that the Linux management apps from LSI will work. This includes infrastructure to support adding, deleting and rescanning arrays at runtime. This is based on work from Doug Ambrosko, heavily augmented by LSI and Yahoo. 2. Implement full 64-bit DMA support. Systems with more than 4GB of RAM can now operate without the cost of bounce buffers. Cards that cannot do 64-bit DMA will automatically revert to using bounce buffers. This option can be forced off by setting the 'hw.amr.force_sg32" tunable in the loader. It should only be turned off for debugging purposes. This work was sponsored by Yahoo. 3. Streamline the command delivery and interrupt handler paths after much discussion with Dell and LSI. The logic now closely matches the intended design, making it both more robust and much faster. Certain i/o failures under heavy load should be fixed with this. 4. Optimize the locking. In the interrupt handler, the card can be checked for completed commands without any locks held, due to the handler being implicitely serialized and there being no need to look at any shared data. Only grab the lock to return the command structure to the free pool. A small optimization can still be made to collect all of the completions together and then free them together under a single lock. Items 3 and 4 significantly increase the performance of the driver. On an LSI 320-2X card, transactions per second went from 13,000 to 31,000 in my testing with these changes. However, these changes are still fairly experimental and shouldn't be merged to 6.x until there is more testing. Thanks to Doug Ambrosko, LSI, Dell, and Yahoo for contributing towards this. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 03:24:04 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3392B16A420 for ; Fri, 6 Jan 2006 03:24:04 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3C6343D55 for ; Fri, 6 Jan 2006 03:24:02 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so2141019wxc for ; Thu, 05 Jan 2006 19:24:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jmk+ODjk8kOeBh2l/3gWBrSuIov0CvuiD0vbDv1KbHI226uYfiGRWlJ57PvhFP4olravuBGuAbMGEUsBuHUsPUg13nupeEyDAuNT2eKM2qqe8ZoSwRKbAf1fF2D5nfi/G/XbMxOGxnaH/WtGRXxt7CDV71UCTx407fU7el7eELc= Received: by 10.70.54.3 with SMTP id c3mr2825546wxa; Thu, 05 Jan 2006 19:24:01 -0800 (PST) Received: by 10.70.105.2 with HTTP; Thu, 5 Jan 2006 19:24:01 -0800 (PST) Message-ID: <84dead720601051924v55cad2bv7685a7f87a3e50a1@mail.gmail.com> Date: Fri, 6 Jan 2006 08:54:01 +0530 From: Joseph Koshy To: jrhett@svcolo.com In-Reply-To: <20060105233226.GC17890@soaustin.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43A266E5.3080103@samsco.org> <43AB1E65.2030501@mac.com> <20051222221202.GM39174@svcolo.com> <20060105092448.GH1358@svcolo.com> <20060105184147.GD69162@funkthat.com> <200512231136.12471.doconnor@gsoft.com.au> <20060105233226.GC17890@soaustin.net> Cc: Mark Linimon , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 03:24:04 -0000 ml> (And, as well, that you do not even understand the role the core plays ml> in the project. Hint: it is not primarily technical in nature.) For those curious to know how the project works, the following online resources may help: A project model for the FreeBSD Project http://www.freebsd.org/doc/en_US.ISO8859-1/books/dev-model/index.html The FreeBSD development process: a case study http://www.cs.colostate.edu/puml/pub/FreeBSD_TSEVersion.pdf The FreeBSD Committers Guide http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/ -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 04:08:12 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8B4F16A41F for ; Fri, 6 Jan 2006 04:08:12 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 627A343D5F for ; Fri, 6 Jan 2006 04:08:06 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 83CFA5DE5; Thu, 5 Jan 2006 23:08:05 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00531-02; Thu, 5 Jan 2006 23:08:04 -0500 (EST) Received: from [192.168.1.3] (pool-68-161-122-227.ny325.east.verizon.net [68.161.122.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 07DB85DDA; Thu, 5 Jan 2006 23:08:03 -0500 (EST) Message-ID: <43BDED2E.7090803@mac.com> Date: Thu, 05 Jan 2006 23:08:14 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vivek Khera References: <6CADC5BD-FBF5-472E-8087-8494AD03549C@khera.org> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-stable Subject: Re: SCSI RAID card recommendation (1/2 height PCI-X U320 SCSI dual channel) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 04:08:13 -0000 Vivek Khera wrote: [ ... ] > The only other aac controller I have is a Dell PERC type which is god- > awful slow, but I hear that's dell's fault not adaptec's. I don't know > what to believe there. That card is quite stable however. > > Any experiences with this that anyone wishes to share? There's an interesting thread about the AMR RAID controller used in the newer 18x0/28x0 Dells with the PERC/4 controller, and I know of enough people using them that such improvements (by Doug Ambrisko?) will be welcomed. If you've got the older PERC/3 AAC controller, it looks something like this: 6-pi# dmesg | grep aac aac0: mem 0xf0000000-0xf7ffffff irq 31 at device 2.1 on pci2 aac0: i960RX 100MHz, 118MB cache memory, optional battery present aac0: Kernel 2.5-0, Build 2991, S/N xxxxx aac0: Supported Options=0 aacd0: on aac0 aacd0: 17355MB (35544576 sectors) Mounting root from ufs:/dev/aacd0s1a 7-pi# diskinfo -v -t aacd0 aacd0 512 # sectorsize 18198822912 # mediasize in bytes (17G) 35544576 # mediasize in sectors 2212 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: 250 iter in 1.344172 sec = 5.377 msec Half stroke: 250 iter in 1.300260 sec = 5.201 msec Quarter stroke: 500 iter in 2.705104 sec = 5.410 msec Short forward: 400 iter in 2.605101 sec = 6.513 msec Short backward: 400 iter in 2.157570 sec = 5.394 msec Seq outer: 2048 iter in 0.954848 sec = 0.466 msec Seq inner: 2048 iter in 0.952256 sec = 0.465 msec Transfer rates: outside: 102400 kbytes in 3.248853 sec = 31519 kbytes/sec middle: 102400 kbytes in 3.174779 sec = 32254 kbytes/sec inside: 102400 kbytes in 4.612511 sec = 22200 kbytes/sec 8-pi# uname -a FreeBSD pi.codefab.com 5.4-STABLE FreeBSD 5.4-STABLE #0: Wed Nov 9 23:04:08 EST 2005 root@pi.codefab.com:/usr/obj/usr/src/sys/PI i386 ...set up as a RAID-1 mirror using a pair of 18 GB, hmm, 10K RPM Seagates, IIRC? Seems a bit slower under 5 than under 4, but not unreasonably so. -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 09:03:25 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21A1A16A41F for ; Fri, 6 Jan 2006 09:03:25 +0000 (GMT) (envelope-from adler@smtp.ru) Received: from smtp1.pochta.ru (smtp1.pochta.ru [81.211.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44B7743D45 for ; Fri, 6 Jan 2006 09:03:23 +0000 (GMT) (envelope-from adler@smtp.ru) Received: from host-212-0-195-28.mtc.md (host-212-0-195-28.mtc.md [212.0.195.28]) (author=adler@smtp.ru authenticated bits=0) by smtp1.pochta.ru (8.13.1/8.13.1) with ESMTP daemon=POCHTA.RU id k0693EN6048514; Fri, 6 Jan 2006 12:03:16 +0300 (MSK) (envelope-from adler@smtp.ru) X-Author: adler@smtp.ru from host-212-0-195-28.mtc.md (host-212-0-195-28.mtc.md [212.0.195.28]) via Free Mail POCHTA.RU Date: Fri, 6 Jan 2006 11:03:11 +0300 From: Alexey Sopov X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <1878539143.20060106110311@smtp.ru> To: "Dan O'Connor" In-Reply-To: <01be01c6114e$160f71b0$0599460a@dan> References: <31615625.20060104113421@smtp.ru> <01be01c6114e$160f71b0$0599460a@dan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re[2]: 5.4 freezes randomly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: adler List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 09:03:25 -0000 DOC> I don't know if this will help, but mpd4 is the development version--I'd DOC> try mpd 3 (/usr/ports/net/mpd). I'm using it for a VPN server on FBSD DOC> 6.0, without any troubles... The problem was solved. There was a tunnel loop. With 400+ users mpd4 works much better than mpd3.18 -- [ /Iexa ] mailto:adler@smtp.ru From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 09:07:47 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 742AC16A41F for ; Fri, 6 Jan 2006 09:07:47 +0000 (GMT) (envelope-from todor@ilux.g00net.org) Received: from ilux.g00net.org (linuxfan.interbild.net [195.138.138.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id A020443D53 for ; Fri, 6 Jan 2006 09:07:46 +0000 (GMT) (envelope-from todor@ilux.g00net.org) Received: by ilux.g00net.org (Postfix, from userid 1001) id A0435613E; Fri, 6 Jan 2006 11:08:54 +0200 (EET) Date: Fri, 6 Jan 2006 11:08:54 +0200 From: Todor Dragnev To: freebsd-stable@freebsd.org Message-ID: <20060106090854.GA36654@linuxfan.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [jonathan.glass@oit.gatech.edu: Re: [Flow-tools] Memory leak ?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 09:07:47 -0000 Can someone help with this ? ----- Forwarded message from Jonathan Glass ----- From: Jonathan Glass To: Mike Hunter Cc: Todor Dragnev , flow-tools@list.splintered.net Subject: Re: [Flow-tools] Memory leak ? Date: Thu, 05 Jan 2006 09:27:10 -0500 User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) Message-ID: <43BD2CBE.4060403@oit.gatech.edu> Mike Hunter wrote: >On Jan 04, "Todor Dragnev" wrote: > > >>Hello list, >> >>I use flow-control from about 1 week. My OS is FreeBSD 6.0-RELEASE #0 >>for AMD64. All works fine but yesterday I found this in dmesg: >> >>Jan 4 21:30:58 katana kernel: swap_pager_getswapspace(16): failed >>Jan 4 21:30:58 katana kernel: swap_pager_getswapspace(12): failed >>Jan 4 21:30:58 katana kernel: swap_pager_getswapspace(6): failed >> >>I have 1024MB RAM and 2GB swapspace >>On this PC I have squid-cache running, but when check which program use >>more >>memory I found this: >> >>last pid: 49917; load averages: 0.94, 0.96, 0.79 up 1+05:58:05 >>21:58:29 >>187 processes: 2 running, 184 sleeping, 1 lock >>CPU states: 5.5% user, 0.0% nice, 25.6% system, 21.3% interrupt, 47.6% >>idle >>Mem: 678M Active, 59M Inact, 166M Wired, 36M Cache, 111M Buf, 1636K Free >>Swap: 2048M Total, 2048M Used, K Free, 100% Inuse, 4K In, 32K Out >> >>PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND >>518 root 1 96 0 2648M 104M select 0:33 0.00% flow-capture >>635 www 1 4 0 18504K 8908K kqread 0:22 0.00% thttpd >> >> >>My starting line for flow-capture is: >> >>/usr/local/bin/flow-capture -p /var/run/flow-capture.pid -n 287 -N 0 -w >>/var/log/netflows/ -S 5 /127.0.0.1/8899 >> >>Is that huge memory usage is memory leak or I do something wrong ? > > >There could be a 64-bit problem. Our setup has some 32-bit collectors that >feed (among other things) a 64-bit cruncher. Building out the 64-bit >cruncher lead me to finding some 32-bit vs. 64-bit bugs: > >http://mailman.splintered.net/pipermail/flow-tools/2004-December/002501.html > >But I haven't had to deal with flow-capture on 64-bit.... > >Is anybody out there running flow-capture on amd64/x86_64 or another 64 >bit platform? > >I think the easiest way to start looking at this would be to run >flow-capture under a memory debugger of some sort, like efence >(Electric Fence Malloc Debugger). > >Mike I'm running flow-capture on AMD64 on Fedora Core 3 with no problems. The only issue I run into is lack of disk space! Sometimes 50GB is not enough! Linux netflow 2.6.10-1.766_FC3smp #1 SMP Wed Feb 9 23:17:48 EST 2005 x86_64 x86_64 x86_64 GNU/Linux /usr/local/netflow/bin/flow-capture -d1 -w /var/netflow/ -z3 -V5 -N3 -n96 -S1 -E48G 127.0.0.1/0/2057 > /var/netflow/flowc.log flow-tools version 0.67: built by root@netflow on Mon Mar 21 21:21:42 EST 2005 Jonathan Glass Information Security Engineer III OIT Information Security Georgia Institute of Technology ----- End forwarded message ----- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 09:40:31 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DC6A16A41F for ; Fri, 6 Jan 2006 09:40:31 +0000 (GMT) (envelope-from james_mapson@umpquanet.com) Received: from ns.museum.rain.com (gw-ipinc.museum.rain.com [65.75.192.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D5A543D45 for ; Fri, 6 Jan 2006 09:40:30 +0000 (GMT) (envelope-from james_mapson@umpquanet.com) Received: from ns.museum.rain.com (localhost [127.0.0.1]) by ns.museum.rain.com (8.13.4/8.13.4) with ESMTP id k069eP2S043897 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 6 Jan 2006 01:40:25 -0800 (PST) (envelope-from james@umpquanet.com) Received: (from james@localhost) by ns.museum.rain.com (8.13.4/8.13.4/Submit) id k069eOXo043893; Fri, 6 Jan 2006 01:40:24 -0800 (PST) (envelope-from james) Date: Fri, 6 Jan 2006 01:40:24 -0800 From: James Long To: freebsd-stable@freebsd.org Message-ID: <20060106094024.GA43299@ns.museum.rain.com> References: <20060106040839.A38DE16A46C@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060106040839.A38DE16A46C@hub.freebsd.org> User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-101.4 required=5.0 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on ns.museum.rain.com Cc: Vivek Khera Subject: Re: rpcbind lingering on IP no longer specified on command line X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 09:40:31 -0000 > Date: Thu, 5 Jan 2006 10:31:33 -0500 > From: Vivek Khera > Subject: Re: rpcbind lingering on IP no longer specified on command > line > To: stable@freebsd.org > Message-ID: <51DD97C7-4002-4459-A709-1B72DC1189A7@khera.org> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On Jan 5, 2006, at 6:06 AM, Gavin Atkinson wrote: > > >> Can anyone explain why rpcbind will still bind to all tcp interfaces? > > > > Although I believe this is a bug, it is actually working as > > documented: > > > > from rpcbind(8): > > -h bindip > > Specify specific IP addresses to bind to for UDP > > requests. > > Yeah, I noticed that little tiny "UDP requests" note in the -h docs > too. There's no reason to bind to all tcp addresses, and it is > causing me heartburn for getting the server certified... Good grief, why not just firewall off the undesired UDP ports and call it good? From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 09:51:24 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB6DB16A422 for ; Fri, 6 Jan 2006 09:51:24 +0000 (GMT) (envelope-from v.haisman@sh.cvut.cz) Received: from service.sh.cvut.cz (service.sh.cvut.cz [147.32.127.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE48343D45 for ; Fri, 6 Jan 2006 09:51:23 +0000 (GMT) (envelope-from v.haisman@sh.cvut.cz) Received: from localhost (localhost [127.0.0.1]) by service.sh.cvut.cz (Postfix) with ESMTP id 202311A3359 for ; Fri, 6 Jan 2006 10:51:22 +0100 (CET) Received: from service.sh.cvut.cz ([127.0.0.1]) by localhost (service [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12498-02 for ; Fri, 6 Jan 2006 10:51:18 +0100 (CET) Received: from logout.sh.cvut.cz (logout.sh.cvut.cz [147.32.127.203]) by service.sh.cvut.cz (Postfix) with ESMTP id 5530C1A335B for ; Fri, 6 Jan 2006 10:51:18 +0100 (CET) Received: from [192.168.1.2] (localhost [127.0.0.1]) by logout.sh.cvut.cz (Postfix) with ESMTP id 21BF661C39 for ; Fri, 6 Jan 2006 10:51:18 +0100 (CET) Message-ID: <43BE3D81.6090402@sh.cvut.cz> Date: Fri, 06 Jan 2006 10:50:57 +0100 From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.93.0.0 OpenPGP: id=63B6B297 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1D66027537CEE2C8A1A4647C" X-Virus-Scanned: by amavisd-new at sh.cvut.cz Subject: [6.0] Snapshot removes acls flag from fs. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 09:51:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1D66027537CEE2C8A1A4647C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit When I make snapshot of fs it removes "acls" flag from mount. While the command is "mount -u -o snapshot etc." I don't think it should remove the flag because it is not specified besides the snapshot option. Vaclav Haisman --------------enig1D66027537CEE2C8A1A4647C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQ749lW56zbtzMDG0AQKbmAf/VTl3OeNwpxQKVyo8tDd86arrFBrlnBpA rZ9LHaGndmgJ/5SWd3vhW42CTkXatmj2UtbcajVYlAOOux6WNZ9mxALZLluQ44aY e9CN3rDInnJ06Lq/SNpDi8RicJbJVhcne1c6AhV1ZNry9IsTTavtNGRymjNGJQ6U 4R4j3nHHG9vDItZ1+9FtAd1sSNF9pbIObgXGjvSqzkkxChMJrz8igV8iGEStyWBl 6pz4CfAWwIfslKzWZ5go+s9D9paPiil0XHh7mCcXNqv+zsq8OHychWKKs+LmmmlZ qzM2R5pq/XDy0vejcE7m7xbQUtVp4bAXsdV7SjQGuL08vl6aBilJSw== =iTmP -----END PGP SIGNATURE----- --------------enig1D66027537CEE2C8A1A4647C-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 10:36:12 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFABB16A41F; Fri, 6 Jan 2006 10:36:12 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39A3343D45; Fri, 6 Jan 2006 10:36:12 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k06AZQpA079593; Fri, 6 Jan 2006 02:35:58 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k06AYfTE056690; Fri, 6 Jan 2006 02:34:41 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k06AYesb056687; Fri, 6 Jan 2006 02:34:40 -0800 (PST) (envelope-from jrhett) Date: Fri, 6 Jan 2006 02:34:40 -0800 From: Jo Rhett To: "Patrick M. Hausen" Message-ID: <20060106103440.GB54324@svcolo.com> Mail-Followup-To: "Patrick M. Hausen" , Daniel O'Connor , freebsd-stable@freebsd.org, current , Peter Jeremy , stable@freebsd.org, K?vesd?n G?bor References: <20060105093220.GJ1358@svcolo.com> <200601050947.k059lctk024288@hugo10.ka.punkt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601050947.k059lctk024288@hugo10.ka.punkt.de> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: stable@freebsd.org, freebsd-stable@freebsd.org, current , K?vesd?n G?bor , Peter Jeremy Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 10:36:13 -0000 On Thu, Jan 05, 2006 at 10:47:38AM +0100, Patrick M. Hausen wrote: > > > > 1. modified kernels are foobar > > > > ..yet are practically mandatory on production systems > > > Look around. Every major commercial OS does it just fine. > > While I agree with much of your reasoning, I know exactly zero > people running a modified kernel of any version of Windows, > Mac OS X or Solaris, to name just three commercial OS's. You're tickling a different subject here. All three of these operating systems have loadable kernel modules that work. I mean, they dynamically load the modules they need, and you can disable kernel modules in configuration files. FreeBSD has loadable kernel modules, but they don't autoload (you have to modify rc files) and you can't trim down the kernel to minimize unused memory without recompiling. To give you a specific example: if we could remove NFS and the 3ware driver from the kernel in a configuration file, we could probably run GENERIC. (we do *a lot* of other modifications, but NFS is the main memory hog we have to remove on small footprint systems, and the 3ware driver we have to update independently, which requires that it be a loadable module and not compiled in) So yeah, this is a different problem. However I wasn't going to tackle this issue in this thread because the -core team appears to be very aware of this issue and it seems to improve a bit in every release. > And third party drivers (which one could count as "kernel modifications") > did fail and will fail sometimes in weird ways even for minor > version upgrades/patches. BTDT - Windows Services Packs, Solaris patches, > Mac OS X updates, reboot, *boom*, because some hardware suppliers > driver didn't adhere to the OS manufacturer's standards or because > the latter silently changed something undocumented. I don't know what you're trying to say here. I don't disagree, I'm just not sure what you mean. It almost sounds like you're trying to make my own point about having the ability to backout patches, which we don't have today. > While I would appreciate a packaged core system or at least a > better definition of "core system" at all, I strongly believe > that binary updating a custom kernel is impossible. If the kernel is consistent across the enterprise (but not, say GENERIC) then binary updates would be trivial. > With "better definition of core system" I mean, if you have a > long lived production system that you might have upgraded > from 4.x to 5.x to 6.0, you will have a lot of cruft lying > on your filesystem that once was part of the "core" and now > isn't. And there is no simple and automated way to find out > what to delete ... That's another good point for having file revisions. We don't have that particular problem, but I can easily imagine how having versioning of the core OS would be useful to help isolate these orphaned files. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 10:36:12 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFABB16A41F; Fri, 6 Jan 2006 10:36:12 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39A3343D45; Fri, 6 Jan 2006 10:36:12 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k06AZQpA079593; Fri, 6 Jan 2006 02:35:58 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k06AYfTE056690; Fri, 6 Jan 2006 02:34:41 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k06AYesb056687; Fri, 6 Jan 2006 02:34:40 -0800 (PST) (envelope-from jrhett) Date: Fri, 6 Jan 2006 02:34:40 -0800 From: Jo Rhett To: "Patrick M. Hausen" Message-ID: <20060106103440.GB54324@svcolo.com> Mail-Followup-To: "Patrick M. Hausen" , Daniel O'Connor , freebsd-stable@freebsd.org, current , Peter Jeremy , stable@freebsd.org, K?vesd?n G?bor References: <20060105093220.GJ1358@svcolo.com> <200601050947.k059lctk024288@hugo10.ka.punkt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601050947.k059lctk024288@hugo10.ka.punkt.de> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: stable@freebsd.org, freebsd-stable@freebsd.org, current , K?vesd?n G?bor , Peter Jeremy Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 10:36:13 -0000 On Thu, Jan 05, 2006 at 10:47:38AM +0100, Patrick M. Hausen wrote: > > > > 1. modified kernels are foobar > > > > ..yet are practically mandatory on production systems > > > Look around. Every major commercial OS does it just fine. > > While I agree with much of your reasoning, I know exactly zero > people running a modified kernel of any version of Windows, > Mac OS X or Solaris, to name just three commercial OS's. You're tickling a different subject here. All three of these operating systems have loadable kernel modules that work. I mean, they dynamically load the modules they need, and you can disable kernel modules in configuration files. FreeBSD has loadable kernel modules, but they don't autoload (you have to modify rc files) and you can't trim down the kernel to minimize unused memory without recompiling. To give you a specific example: if we could remove NFS and the 3ware driver from the kernel in a configuration file, we could probably run GENERIC. (we do *a lot* of other modifications, but NFS is the main memory hog we have to remove on small footprint systems, and the 3ware driver we have to update independently, which requires that it be a loadable module and not compiled in) So yeah, this is a different problem. However I wasn't going to tackle this issue in this thread because the -core team appears to be very aware of this issue and it seems to improve a bit in every release. > And third party drivers (which one could count as "kernel modifications") > did fail and will fail sometimes in weird ways even for minor > version upgrades/patches. BTDT - Windows Services Packs, Solaris patches, > Mac OS X updates, reboot, *boom*, because some hardware suppliers > driver didn't adhere to the OS manufacturer's standards or because > the latter silently changed something undocumented. I don't know what you're trying to say here. I don't disagree, I'm just not sure what you mean. It almost sounds like you're trying to make my own point about having the ability to backout patches, which we don't have today. > While I would appreciate a packaged core system or at least a > better definition of "core system" at all, I strongly believe > that binary updating a custom kernel is impossible. If the kernel is consistent across the enterprise (but not, say GENERIC) then binary updates would be trivial. > With "better definition of core system" I mean, if you have a > long lived production system that you might have upgraded > from 4.x to 5.x to 6.0, you will have a lot of cruft lying > on your filesystem that once was part of the "core" and now > isn't. And there is no simple and automated way to find out > what to delete ... That's another good point for having file revisions. We don't have that particular problem, but I can easily imagine how having versioning of the core OS would be useful to help isolate these orphaned files. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 10:37:31 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62F0416A41F for ; Fri, 6 Jan 2006 10:37:31 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-3-1-cust208.cdif.cable.ntl.com [82.31.78.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46FA543D49 for ; Fri, 6 Jan 2006 10:37:30 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EuoyK-0003su-Nx; Fri, 06 Jan 2006 10:37:24 +0000 Date: Fri, 6 Jan 2006 10:37:24 +0000 From: Ceri Davies To: Dmitry Morozovsky Message-ID: <20060106103648.GJ31522@submonkey.net> Mail-Followup-To: Ceri Davies , Dmitry Morozovsky , Vivek Khera , stable@freebsd.org References: <20060104222846.K98554@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KMIs29sPfC/9Gbii" Content-Disposition: inline In-Reply-To: <20060104222846.K98554@woozle.rinet.ru> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.11 Sender: Ceri Davies Cc: Vivek Khera , stable@freebsd.org Subject: Re: rpcbind lingering on IP no longer specified on command line X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 10:37:31 -0000 --KMIs29sPfC/9Gbii Content-Type: multipart/mixed; boundary="xFHWmGwbilGjB8dh" Content-Disposition: inline --xFHWmGwbilGjB8dh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 04, 2006 at 10:46:06PM +0300, Dmitry Morozovsky wrote: > On Wed, 4 Jan 2006, Vivek Khera wrote: >=20 > VK> I had rpcbind running with on two interfaces like this: > VK>=20 > VK> rpcbind -h 192.168.100.200 -h 10.0.0.9 > VK>=20 > VK> Now, I changed rpcbind_flags in /etc/rc.conf to just have the first a= ddress, > VK> and I restarted rpcbind. the process list from ps shows it is runnin= g like > VK> this: > VK>=20 > VK> rpcbind -h 192.168.100.200 > VK>=20 > VK> Yet nmap on the other address shows rpcbind is still listening on udp= there. > VK> How do I stop that? >=20 > As I sometimes looked into this, rpcbind (formely portmap) listens on all= =20 > described addresses via udp *and* an tcp:*.111 - I tried to dig why is th= is but=20 > did not succeed much. Please test this patch. It's probably a very naive fix, but seems to work OK. Ceri --=20 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Einstein (attrib.) --xFHWmGwbilGjB8dh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rpcbind.diff" Content-Transfer-Encoding: quoted-printable Index: rpcbind.8 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/home/ncvs/src/usr.sbin/rpcbind/rpcbind.8,v retrieving revision 1.7 diff -u -r1.7 rpcbind.8 --- rpcbind.8 18 Jan 2005 20:02:43 -0000 1.7 +++ rpcbind.8 6 Jan 2006 10:35:02 -0000 @@ -83,7 +83,7 @@ With this option, the name-to-address translation consistency checks are shown in detail. .It Fl h Ar bindip -Specify specific IP addresses to bind to for UDP requests. +Specify specific IP addresses to bind to. This option may be specified multiple times and is typically necessary when running on a multi-homed host. @@ -95,14 +95,14 @@ .Dv INADDR_ANY , which could lead to problems on a multi-homed host due to .Nm -returning a UDP packet from a different IP address than it was +returning a packet from a different IP address than it was sent to. Note that when specifying IP addresses with .Fl h , .Nm will automatically add .Li 127.0.0.1 -and if IPv6 is enabled, +and, if IPv6 is enabled, .Li ::1 to the list. .It Fl i Index: rpcbind.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/home/ncvs/src/usr.sbin/rpcbind/rpcbind.c,v retrieving revision 1.14 diff -u -r1.14 rpcbind.c --- rpcbind.c 7 Nov 2004 04:32:51 -0000 1.14 +++ rpcbind.c 6 Jan 2006 10:28:10 -0000 @@ -209,11 +209,11 @@ struct passwd *p; =20 if((p =3D getpwnam(RUN_AS)) =3D=3D NULL) { - syslog(LOG_ERR, "cannot get uid of daemon: %m"); + syslog(LOG_ERR, "cannot get uid of %s: %m", RUN_AS); exit(1); } if (setuid(p->pw_uid) =3D=3D -1) { - syslog(LOG_ERR, "setuid to daemon failed: %m"); + syslog(LOG_ERR, "setuid to %s failed: %m", RUN_AS); exit(1); } } @@ -272,7 +272,8 @@ * XXX - using RPC library internal functions. For NC_TPI_CLTS * we call this later, for each socket we like to bind. */ - if (nconf->nc_semantics !=3D NC_TPI_CLTS) { + if (nconf->nc_semantics !=3D NC_TPI_CLTS && + nconf->nc_semantics !=3D NC_TPI_COTS_ORD) { if ((fd =3D __rpc_nconf2fd(nconf)) < 0) { int non_fatal =3D 0; =20 @@ -308,7 +309,8 @@ hints.ai_socktype =3D si.si_socktype; hints.ai_protocol =3D si.si_proto; } - if (nconf->nc_semantics =3D=3D NC_TPI_CLTS) { + if (nconf->nc_semantics =3D=3D NC_TPI_CLTS || + nconf->nc_semantics =3D=3D NC_TPI_COTS_ORD) { /* * If no hosts were specified, just bind to INADDR_ANY. Otherwise * make sure 127.0.0.1 is added to the list. @@ -348,7 +350,7 @@ hints.ai_flags &=3D AI_NUMERICHOST; } else { /* - * Skip if we have an AF_INET6 adress. + * Skip if we have an AF_INET6 address. */ if (inet_pton(AF_INET6, hosts[nhostsbak], host_addr) =3D=3D 1) @@ -361,7 +363,7 @@ hints.ai_flags &=3D AI_NUMERICHOST; } else { /* - * Skip if we have an AF_INET adress. + * Skip if we have an AF_INET address. */ if (inet_pton(AF_INET, hosts[nhostsbak], host_addr) =3D=3D 1) --xFHWmGwbilGjB8dh-- --KMIs29sPfC/9Gbii Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDvkhkocfcwTS3JF8RAj/PAJ4l5xgLINb2Qdghce/JCDhHUPJFVwCdEoFH qkZ/ImmHGjcL0cdcQueMgkM= =1tD7 -----END PGP SIGNATURE----- --KMIs29sPfC/9Gbii-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 10:42:42 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCCDA16A41F; Fri, 6 Jan 2006 10:42:41 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 941E143D81; Fri, 6 Jan 2006 10:42:24 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k06AfCpD079773; Fri, 6 Jan 2006 02:42:15 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k06AeQgt057708; Fri, 6 Jan 2006 02:40:26 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k06AePwi057703; Fri, 6 Jan 2006 02:40:25 -0800 (PST) (envelope-from jrhett) Date: Fri, 6 Jan 2006 02:40:25 -0800 From: Jo Rhett To: "Daniel O'Connor" Message-ID: <20060106104025.GC54324@svcolo.com> Mail-Followup-To: Daniel O'Connor , freebsd-stable@freebsd.org, Scott Long , Peter Jeremy , stable@freebsd.org, K?vesd?n G?bor , current References: <43A266E5.3080103@samsco.org> <200512231126.51500.doconnor@gsoft.com.au> <20060105093220.GJ1358@svcolo.com> <200601052112.09446.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601052112.09446.doconnor@gsoft.com.au> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: freebsd-stable@freebsd.org, current , Peter Jeremy , stable@freebsd.org, K?vesd?n G?bor Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 10:42:42 -0000 On Thu, Jan 05, 2006 at 09:11:58PM +1030, Daniel O'Connor wrote: > On Thu, 5 Jan 2006 20:02, Jo Rhett wrote: > > On Fri, Dec 23, 2005 at 11:26:44AM +1030, Daniel O'Connor wrote: > > > How do you expect these two to be handled in a binary upgrade? > > > I can't see how it's possible.. > > > > Look around. Every major commercial OS does it just fine. Most of the > > open source OSes do it just fine. Debian had probably the easiest to use > > system, and they've risen, owned the world and fallen all while FreeBSD has > > been debating this issue. > > You appear to be misunderstanding what I said. > > I'm not arguing binary upgrades shouldn't be done but I'm suggesting that it > isn't NECESSARY to version and package the base install to do it. Whether or not the core is 'packaged' is an implementation detail. I've heard good arguements either way. But some sort of versioning is required. How do you know what to update? How do you know if it has been updated already? Checksum analysis is the VERY long way around and incredibly CPU intensive. And it requires an extensive database of all possible combinations. > > > I don't think integrating it with the core OS (whatever that means) will > > > magically fix this. > > > > If you knew what it meant, you would understand why it would help. > > Ah what a great explanation of what is meant. > There are several people who don't know what is meant here and I haven't seen > a decent explanation forthcoming. I had explained it several times in other replies, and wasn't going to repeat it again. Especially not against a global wide open "I don't think it will help" without any backing arguements or qualifications to the statement. It's just too broad to work with. In short, not trying to be rude but would prefer to focus on solutions that explain the 10k view. > Just because I don't run jails doesn't mean I don't know the pain of upgrading > a system. Just because you've upgraded a system doesn't mean you understand or even grasp the issues involved in managing jails. You can tell me that driving a car should give you the experience to argue riding motorcycles with me, but I'm going to have trouble taking you seriously ;-) (no offense intended, really... just trying to be clear) -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 10:42:42 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCCDA16A41F; Fri, 6 Jan 2006 10:42:41 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 941E143D81; Fri, 6 Jan 2006 10:42:24 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k06AfCpD079773; Fri, 6 Jan 2006 02:42:15 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k06AeQgt057708; Fri, 6 Jan 2006 02:40:26 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k06AePwi057703; Fri, 6 Jan 2006 02:40:25 -0800 (PST) (envelope-from jrhett) Date: Fri, 6 Jan 2006 02:40:25 -0800 From: Jo Rhett To: "Daniel O'Connor" Message-ID: <20060106104025.GC54324@svcolo.com> Mail-Followup-To: Daniel O'Connor , freebsd-stable@freebsd.org, Scott Long , Peter Jeremy , stable@freebsd.org, K?vesd?n G?bor , current References: <43A266E5.3080103@samsco.org> <200512231126.51500.doconnor@gsoft.com.au> <20060105093220.GJ1358@svcolo.com> <200601052112.09446.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601052112.09446.doconnor@gsoft.com.au> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: freebsd-stable@freebsd.org, current , Peter Jeremy , stable@freebsd.org, K?vesd?n G?bor Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 10:42:42 -0000 On Thu, Jan 05, 2006 at 09:11:58PM +1030, Daniel O'Connor wrote: > On Thu, 5 Jan 2006 20:02, Jo Rhett wrote: > > On Fri, Dec 23, 2005 at 11:26:44AM +1030, Daniel O'Connor wrote: > > > How do you expect these two to be handled in a binary upgrade? > > > I can't see how it's possible.. > > > > Look around. Every major commercial OS does it just fine. Most of the > > open source OSes do it just fine. Debian had probably the easiest to use > > system, and they've risen, owned the world and fallen all while FreeBSD has > > been debating this issue. > > You appear to be misunderstanding what I said. > > I'm not arguing binary upgrades shouldn't be done but I'm suggesting that it > isn't NECESSARY to version and package the base install to do it. Whether or not the core is 'packaged' is an implementation detail. I've heard good arguements either way. But some sort of versioning is required. How do you know what to update? How do you know if it has been updated already? Checksum analysis is the VERY long way around and incredibly CPU intensive. And it requires an extensive database of all possible combinations. > > > I don't think integrating it with the core OS (whatever that means) will > > > magically fix this. > > > > If you knew what it meant, you would understand why it would help. > > Ah what a great explanation of what is meant. > There are several people who don't know what is meant here and I haven't seen > a decent explanation forthcoming. I had explained it several times in other replies, and wasn't going to repeat it again. Especially not against a global wide open "I don't think it will help" without any backing arguements or qualifications to the statement. It's just too broad to work with. In short, not trying to be rude but would prefer to focus on solutions that explain the 10k view. > Just because I don't run jails doesn't mean I don't know the pain of upgrading > a system. Just because you've upgraded a system doesn't mean you understand or even grasp the issues involved in managing jails. You can tell me that driving a car should give you the experience to argue riding motorcycles with me, but I'm going to have trouble taking you seriously ;-) (no offense intended, really... just trying to be clear) -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 10:44:46 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7341D16A41F; Fri, 6 Jan 2006 10:44:46 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBF9643D6D; Fri, 6 Jan 2006 10:44:45 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k06AhMpF079827; Fri, 6 Jan 2006 02:44:39 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k06AhABq058133; Fri, 6 Jan 2006 02:43:10 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k06Ah9wp058132; Fri, 6 Jan 2006 02:43:09 -0800 (PST) (envelope-from jrhett) Date: Fri, 6 Jan 2006 02:43:09 -0800 From: Jo Rhett To: Ender Message-ID: <20060106104309.GD54324@svcolo.com> Mail-Followup-To: Ender , Daniel O'Connor , freebsd-stable@freebsd.org, current , Peter Jeremy , stable@freebsd.org, K?vesd?n G?bor References: <43A266E5.3080103@samsco.org> <200512231126.51500.doconnor@gsoft.com.au> <20060105093220.GJ1358@svcolo.com> <200601052112.09446.doconnor@gsoft.com.au> <43BD64C4.4090307@tog.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43BD64C4.4090307@tog.net> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: stable@freebsd.org, freebsd-stable@freebsd.org, current , K?vesd?n G?bor , Peter Jeremy Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 10:44:46 -0000 On Thu, Jan 05, 2006 at 01:26:12PM -0500, Ender wrote: > I think what "integrated with the core OS" means from a user standpoint > is: from a fresh minimum install of freebsd I can type > "freebsd-update-whatever" and it will update my system. Just "freebsd-update" ;-) That works fairly well with the current freebsd-update (or bsdupdates.com) solutions. For most GENERIC installed systems, it works fairly well. I use on 3 systems at my home for this, and I'm pretty happy with it. It doesn't work very well in environments with compiled options, custom kernels, and other situations. That's what I'm trying to tackle here. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 10:44:46 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7341D16A41F; Fri, 6 Jan 2006 10:44:46 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBF9643D6D; Fri, 6 Jan 2006 10:44:45 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k06AhMpF079827; Fri, 6 Jan 2006 02:44:39 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k06AhABq058133; Fri, 6 Jan 2006 02:43:10 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k06Ah9wp058132; Fri, 6 Jan 2006 02:43:09 -0800 (PST) (envelope-from jrhett) Date: Fri, 6 Jan 2006 02:43:09 -0800 From: Jo Rhett To: Ender Message-ID: <20060106104309.GD54324@svcolo.com> Mail-Followup-To: Ender , Daniel O'Connor , freebsd-stable@freebsd.org, current , Peter Jeremy , stable@freebsd.org, K?vesd?n G?bor References: <43A266E5.3080103@samsco.org> <200512231126.51500.doconnor@gsoft.com.au> <20060105093220.GJ1358@svcolo.com> <200601052112.09446.doconnor@gsoft.com.au> <43BD64C4.4090307@tog.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43BD64C4.4090307@tog.net> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: stable@freebsd.org, freebsd-stable@freebsd.org, current , K?vesd?n G?bor , Peter Jeremy Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 10:44:46 -0000 On Thu, Jan 05, 2006 at 01:26:12PM -0500, Ender wrote: > I think what "integrated with the core OS" means from a user standpoint > is: from a fresh minimum install of freebsd I can type > "freebsd-update-whatever" and it will update my system. Just "freebsd-update" ;-) That works fairly well with the current freebsd-update (or bsdupdates.com) solutions. For most GENERIC installed systems, it works fairly well. I use on 3 systems at my home for this, and I'm pretty happy with it. It doesn't work very well in environments with compiled options, custom kernels, and other situations. That's what I'm trying to tackle here. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 10:53:55 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D05E016A41F; Fri, 6 Jan 2006 10:53:55 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CAF243D66; Fri, 6 Jan 2006 10:53:51 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k06ArMpD080213; Fri, 6 Jan 2006 02:53:50 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k06AqRHJ059732; Fri, 6 Jan 2006 02:52:27 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k06AqRbo059731; Fri, 6 Jan 2006 02:52:27 -0800 (PST) (envelope-from jrhett) Date: Fri, 6 Jan 2006 02:52:27 -0800 From: Jo Rhett To: Peter Jeremy Message-ID: <20060106105227.GE54324@svcolo.com> References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> <43A492B6.6050305@t-hosting.hu> <20051217232856.GT77268@cirb503493.alcatel.com.au> <43A4B91D.8040304@samsco.org> <20051222211730.GK39174@svcolo.com> <20051223045648.GH77268@cirb503493.alcatel.com.au> <20060105093727.GK1358@svcolo.com> <20060105114056.GN42228@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060105114056.GN42228@cirb503493.alcatel.com.au> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: stable@freebsd.org, current Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 10:53:56 -0000 On Thu, Jan 05, 2006 at 10:40:56PM +1100, Peter Jeremy wrote: > >No. I want a binary update mechanism. Obviously if we have local > >configuration options we'll have to compile our own binaries. But doing > >the work of tracking system updates currently requires us to build our own > >patch tracking mechanism, and then re-write it for every new release. > On Thu, 2006-Jan-05 01:37:27 -0800, Jo Rhett wrote: > If you're willing to do your own compiles: > 1) CVSup or cvs update to whatever branch you want > 2) make build{world,kernel} > 3) make DESTDIR=/updates install{world,kernel} > 4) mergemaster -D /updates > 5) rsync or similar Hm. So how do I know which systems need the upgrade? So what occurs if the wrong version is rsynced to the wrong system? What do I do if a kernel module upgrade fails? How do I restore state? This problem is solved fairly well in every other OS I can think of. But for FreeBSD we're currently solving it with very complex cfengine management tied to lots of local databases and thousands of lines of our own code. It's all the long way around a problem that is very simple to solve in the core. > It seems fairly obvious that you are frustrated by FreeBSD's inability > to meet your needs as far as updating is concerned. I suspect I'm not > alone in being uncertain exactly what your requirements are and what > additional features FreeBSD needs to satisfy you. Some implementation (any!) that versions the core. Something you can query to ask what is, update to say what you've done, and revert to restore a previous state. > How would you like > to write a formal requirements specification and post it here (or in > -arch). This has been written many times, by people better at explaining the issues than I am. I'll find someone elses and forward it to you. > Have you looked at tools like Bcfg2 ( http://www.mcs.anl.gov/cobalt/bcfg2/ )? I haven't compared bcfg2 to what we're doing now (cfengine) but it would likely have all of the same problems. Namely, we'd have to build and maintain a database of all possible software combinations, and what systems are running which patches, and then write scripts that do the right updates to the right systems. Again, thousands of lines of perl/ruby/shell to work around a very well known limitation in freebsd. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 10:55:15 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F4BA16A41F for ; Fri, 6 Jan 2006 10:55:15 +0000 (GMT) (envelope-from scott@fishballoon.org) Received: from mta07-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47CAD43D49 for ; Fri, 6 Jan 2006 10:55:11 +0000 (GMT) (envelope-from scott@fishballoon.org) Received: from aamta11-winn.ispmail.ntl.com ([81.103.221.35]) by mta07-winn.ispmail.ntl.com with ESMTP id <20060106105504.ZWYE21883.mta07-winn.ispmail.ntl.com@aamta11-winn.ispmail.ntl.com>; Fri, 6 Jan 2006 10:55:04 +0000 Received: from llama.fishballoon.org ([81.104.195.171]) by aamta11-winn.ispmail.ntl.com with ESMTP id <20060106105504.YGVQ29634.aamta11-winn.ispmail.ntl.com@llama.fishballoon.org>; Fri, 6 Jan 2006 10:55:04 +0000 Received: from scott by llama.fishballoon.org with local (Exim 4.52 (FreeBSD)) id 1EupFO-00059O-8o; Fri, 06 Jan 2006 10:55:02 +0000 Date: Fri, 6 Jan 2006 10:55:02 +0000 From: Scott Mitchell To: Michael Vince Message-ID: <20060106105501.GA19690@llama.fishballoon.org> References: <20060105224150.GA991@tuatara.fishballoon.org> <43BDD444.80509@roq.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43BDD444.80509@roq.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 4.11-RELEASE i386 Sender: Scott Mitchell Cc: freebsd-stable@freebsd.org Subject: Re: 6.0 on Dell 1850 with PERC4e/DC RAID? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 10:55:15 -0000 On Fri, Jan 06, 2006 at 01:21:56PM +1100, Michael Vince wrote: > FYI there also has been a big update to the amr driver which claims to > dramatically increase performance among other things, interestingly > enought it was augmented by Yahoo, I can only assume they are moving to > Dell, yahoo for me (and now you :). > The updates are still in -current but it will be MFC'ed into stable > sooner or later. > > http://lists.freebsd.org/pipermail/cvs-src/2005-December/056814.html Yeah, I saw that, and it sounds most excellent. Good to see some real support from the likes of Dell and LSI, too. I might be able to get away with running -stable on this machine, but -current will be right out. Hopefully these changes can be MFCed in time for 6.1. Scott > Log: > Mega update to the LSI MegaRAID driver: > > 1. Implement a large set of ioctl shims so that the Linux management apps > from LSI will work. This includes infrastructure to support adding, > deleting > and rescanning arrays at runtime. This is based on work from Doug > Ambrosko, > heavily augmented by LSI and Yahoo. > > 2. Implement full 64-bit DMA support. Systems with more than 4GB of RAM > can now operate without the cost of bounce buffers. Cards that cannot do > 64-bit DMA will automatically revert to using bounce buffers. This option > can be forced off by setting the 'hw.amr.force_sg32" tunable in the loader. > It should only be turned off for debugging purposes. This work was > sponsored > by Yahoo. > > 3. Streamline the command delivery and interrupt handler paths after > much discussion with Dell and LSI. The logic now closely matches the > intended design, making it both more robust and much faster. Certain > i/o failures under heavy load should be fixed with this. > > 4. Optimize the locking. In the interrupt handler, the card can be > checked > for completed commands without any locks held, due to the handler being > implicitely serialized and there being no need to look at any shared data. > Only grab the lock to return the command structure to the free pool. A > small optimization can still be made to collect all of the completions > together and then free them together under a single lock. > > Items 3 and 4 significantly increase the performance of the driver. On an > LSI 320-2X card, transactions per second went from 13,000 to 31,000 in my > testing with these changes. However, these changes are still fairly > experimental and shouldn't be merged to 6.x until there is more testing. > > Thanks to Doug Ambrosko, LSI, Dell, and Yahoo for contributing towards > this. > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- =========================================================================== Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" scott at fishballoon.org | 0xAA775B8B | -- Anon From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 10:57:33 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 185D516A41F for ; Fri, 6 Jan 2006 10:57:33 +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 2E37843DB2 for ; Fri, 6 Jan 2006 10:57:14 +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 ; 6 Jan 2006 10:57:12 +0000 (GMT) Date: Fri, 6 Jan 2006 10:57:12 +0000 From: David Malone To: V??clav Haisman Message-ID: <20060106105712.GA46889@walton.maths.tcd.ie> References: <43BE3D81.6090402@sh.cvut.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43BE3D81.6090402@sh.cvut.cz> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-stable@freebsd.org Subject: Re: [6.0] Snapshot removes acls flag from fs. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 10:57:33 -0000 On Fri, Jan 06, 2006 at 10:50:57AM +0100, V??clav Haisman wrote: > When I make snapshot of fs it removes "acls" flag from mount. While the > command is "mount -u -o snapshot etc." I don't think it should remove > the flag because it is not specified besides the snapshot option. You probably want something like: mount -u -o cur,snapshot ... See the "current" and "fstab" options in the mount man page. An easier way to do this would be to use the mksnap_ffs command, which should preserve the old options. David. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 11:05:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E3FB16A41F; Fri, 6 Jan 2006 11:05:09 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id B060043D46; Fri, 6 Jan 2006 11:05:08 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k06B4CpC081491; Fri, 6 Jan 2006 03:05:08 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k06B3I5H061974; Fri, 6 Jan 2006 03:03:18 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k06B3I9J061973; Fri, 6 Jan 2006 03:03:18 -0800 (PST) (envelope-from jrhett) Date: Fri, 6 Jan 2006 03:03:18 -0800 From: Jo Rhett To: "Daniel O'Connor" , freebsd-stable@freebsd.org, Chuck Swiger , current Message-ID: <20060106110318.GF54324@svcolo.com> Mail-Followup-To: Daniel O'Connor , freebsd-stable@freebsd.org, Chuck Swiger , current References: <43A266E5.3080103@samsco.org> <43AB1E65.2030501@mac.com> <20051222221202.GM39174@svcolo.com> <200512231136.12471.doconnor@gsoft.com.au> <20060105092448.GH1358@svcolo.com> <20060105184147.GD69162@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060105184147.GD69162@funkthat.com> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 11:05:09 -0000 On Thu, Jan 05, 2006 at 10:41:47AM -0800, John-Mark Gurney wrote: > I believe core has a policy of never supporting vaporware... There is > always the chicken and egg problem with arguments like this... I'll > code this if you agree to support it and maintain it/I will agree to > support it once you code it... In FreeBSD, and many open source > projects, no code, no support, how can you support or even agree to > support something that doesn't exist? And then as soon as FreeBSD > agrees to support something that doesn't exist, either a) other people who > were interested in the project stop, even if you end up never producing > a bit of code, or b) someone else produces better code, drops the > support for the original, but then the author complains about being > told they'd support his code, and going with another code base... > > Bottom line: Once code exists, then support can be talked about.. This is the chicken and egg problem that will kill FreeBSD. I don't bother writing up patches for FreeBSD because every time I do they sit in a PR and get ignored for several years. Then someone that does have commit rights makes their own patch (which often is less useful) but they own it and the best I've ever succeeded at was convincing them to put some of the ideas from my patch into their code. Note that none of these patches were ever rejected for any technical or political or any other reason. They just don't get paid attention to. Thus, I try to get consensus that the idea has merit. IF freebsd committers can be bothered to pay attention to the idea, I'll write code for it. But I'm too old and tired to spend another week writing up something that will get ignored for X years and then dropped for obsoletion again. AND there are a lot of opinions and politics around how to version the core that have nothing to do with code. There's no value in writing code that will be ignored because it doesn't agree with -core's view of "should be". I'm a coder, not a politician. If we can get consensus on what type of implementation would be acceptable to core, then I and many others would be happy to write code to implement this idea. But this is a considerable amount of work that will be closely tied to the operation system installation. It's not something that you can churn out 7 different implementations of just to see which one fits the current polical environment. Back to your finale: > Bottom line: Once code exists, then support can be talked about.. This is bullhockey and you know it. Once the project is done, we'll authorize a budget for it? Once the season is over we'll know who should be on the starting team? Yeah, hindsight is sweet. But this isn't a simple change. It will require very close integration with the installation and kernel modules at least (and probably more). So having some sort of consensus that (a) the project has interest and (b) what flavors would be acceptable to the existing groups - are both necessary for this project to even mumble it's first line of code. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 11:15:35 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C3A916A41F for ; Fri, 6 Jan 2006 11:15:35 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A98343D48 for ; Fri, 6 Jan 2006 11:15:34 +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 mail05.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k06BFWfg004956 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 6 Jan 2006 22:15:32 +1100 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 k06BFWHh052071; Fri, 6 Jan 2006 22:15:32 +1100 (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 k06BFVfx052070; Fri, 6 Jan 2006 22:15:31 +1100 (EST) (envelope-from pjeremy) Date: Fri, 6 Jan 2006 22:15:31 +1100 From: Peter Jeremy To: Todor Dragnev Message-ID: <20060106111531.GC51452@cirb503493.alcatel.com.au> References: <20060106090854.GA36654@linuxfan.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060106090854.GA36654@linuxfan.org> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: freebsd-stable@freebsd.org Subject: Re: [jonathan.glass@oit.gatech.edu: Re: [Flow-tools] Memory leak ?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 11:15:35 -0000 [flow-capture process too large] On Fri, 2006-Jan-06 11:08:54 +0200, Todor Dragnev wrote: >Can someone help with this ? Help how? AFAIK, flow-control/flow-capture is not a FreeBSD port so finding someone here with knowledge of it may be difficult. If you think it's a problem with FreeBSD, you're going to need to supply more information so that we can help you. >>>I use flow-control from about 1 week. My OS is FreeBSD 6.0-RELEASE #0 >>>for AMD64. All works fine but yesterday I found this in dmesg: >>> >>>Jan 4 21:30:58 katana kernel: swap_pager_getswapspace(16): failed >>>Jan 4 21:30:58 katana kernel: swap_pager_getswapspace(12): failed >>>Jan 4 21:30:58 katana kernel: swap_pager_getswapspace(6): failed ... >>>518 root 1 96 0 2648M 104M select 0:33 0.00% flow-capture This means you've run out of swap space. The top output shows that the offending process was flow-capture. Presumably you already knew this much. >>>My starting line for flow-capture is: >>> >>>/usr/local/bin/flow-capture -p /var/run/flow-capture.pid -n 287 -N 0 -w >>>/var/log/netflows/ -S 5 /127.0.0.1/8899 >>> >>>Is that huge memory usage is memory leak or I do something wrong ? The command line means nothing to me. How big a process size were you expecting? If you kill and restart the process, how big is it initially? What libraries is it using? What does it do? >>I think the easiest way to start looking at this would be to run >>flow-capture under a memory debugger of some sort, like efence >>(Electric Fence Malloc Debugger). Have you tried this suggestion? Note that phkmalloc (the standard FreeBSD malloc) has some good debugging facilities built in - check malloc(3) for details. >I'm running flow-capture on AMD64 on Fedora Core 3 with no problems. >The only issue I run into is lack of disk space! Sometimes 50GB is not >enough! Unfortunately, Jonathan didn't say what the process size he saw was so this doesn't help much. -- Peter Jeremy From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 11:25:52 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BD5616A420; Fri, 6 Jan 2006 11:25:52 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7915743D49; Fri, 6 Jan 2006 11:25:46 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k06BOCp9082381; Fri, 6 Jan 2006 03:25:45 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k06BNT6U065864; Fri, 6 Jan 2006 03:23:29 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k06BNTVv065863; Fri, 6 Jan 2006 03:23:29 -0800 (PST) (envelope-from jrhett) Date: Fri, 6 Jan 2006 03:23:29 -0800 From: Jo Rhett To: "Daniel O'Connor" Message-ID: <20060106112329.GG54324@svcolo.com> Mail-Followup-To: Daniel O'Connor , freebsd-stable@freebsd.org, current References: <43A266E5.3080103@samsco.org> <200512231136.12471.doconnor@gsoft.com.au> <20060105092448.GH1358@svcolo.com> <200601061120.14707.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601061120.14707.doconnor@gsoft.com.au> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: freebsd-stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 11:25:52 -0000 On Fri, Jan 06, 2006 at 11:20:13AM +1030, Daniel O'Connor wrote: > For NFS mount, read: any network file system. You can also use, say IPSEC to > protect the NFS packets (although I'm not claiming it's a trivial thing to > set up..) IPsec is trivial compared to the amount of code and localized databases we use to manage system versioning information today. > As for restricting the number of writes - that is a totally separate issue and > isn't very relevant to this discussion. Agreed. > In general core IS silent. > Core isn't some governing body that decides what happens in FreeBSD and plans > in detail what happens. You are showing a fundamental misunderstanding about > how FreeBSD "works". > Also, you just said "... the topic is always struck down ..." - what do you > mean? Are you claiming someone from (or claiming to be from core) said "Don't > do this, we won't allow it"? If so, can you supply proof? I used to write a lot of patches to freebsd. I used to submit a lot of bug reports. I've found over the years that unless you have gotten pre-agreement from others about the nature of the patch, or agreement to focus on the problem, neither one amounts to a hill of beans. Installation problems that existed in 4.4 are still alive and well in the 6.0 installer, for example. How FreeBSD "works" is by getting someone in the core team to care about the issue. No amount of problem reports, patches or code will generate even a millimeter of movement otherwise. So yeah, I take Silence as a negative. I've got zero experience to demonstrate otherwise. > I would *welcome* a more sophisticated method for binary upgrades that was a > lot smarter. I imagine pretty much everyone else would too. Really? I'm about to give up again and bring it up next year. It's become the annual gonzo-thread that never generates anything. > Anyway, so what? Nothing stops you writing such a system, Nothing stops me, but it will become useless without constant maintenance. And core would have no obligation to consider the effects of their changes on this. > and I contend it > isn't necessary to version the base system, or package it specially to do > binary upgrades. Something similar to freebsd-update could do it. I've already spelled out the problems here. Freebsd-update/bsdupdates.com spell out the problems with their approach in their documentation. Many others have written on this issue. That said, if we can actually get a real conversation going about how to handle this then I'd love to hear your input on how to solve all of the problems we've raised without versioning of the core. --but not now, in this thread. This thread appears to be DOA and I'm not going to keep wasting time on this without even a hint that core would be interested in a solution to this problem. (not a blank check, just an expression of interest) > > freebsd-update works "fine" if you run GENERIC with no build options. > > Back to "useful for home computers". > > So, uhh, how would your magical binary upgrade system handle custom kernels? > Why would it be any different? You still haven't explained how this would > work.. Versioning of the core package would tell you WHAT you have with a query. It's trivial to then install the matching patches. Right now every enterprise has to build a backend database tracking core os, installed options, compile options, etc for every single installed system. Or build a checksum database that can be used to derive this information from the system (if all systems have the CPU/RAM to spare to play this game) > > freebsd-update is hampered by the exact problems I'm listing here. > > Difficulty determining "what I have", no method to store "what I did" and > > no effective backout mechanism to speak of. > > Then feel free to expand on it. > This IS an open source project - you can see how everything is written, if you > want to improve it I would be happy to write code. See my other messages about "waste of time". Without a comittment to the idea from someone with commit access, writing patches or new code just sits in PRs and dies of old age. > > Nobody that I know cares whether or not the solution manifests as core os > > packages, but some sort of core versioning ability has to be developed and > > supported by the core. > > I don't think core is really very relevant here - core is there to mostly > settle disputes. The way forward is to achieve consensus and have working > solutions. Sorry, I was mixing my uses of 'core' here. My bad. The "unpackaged" part of freebsd needs some sort of versioning ability. But yes, you are making my point for me. Without core's agreement that this is a worthwhile project (as in: to be considered - not a blank check) no amount of code will ever amount to anything other than another unsupported freebsd-update style project. We need support from the freebsd core developers that this is a worthwhile idea, and what kind of solutions would be acceptable to them. Once we have a direction to go in, code can be written. > If you supply a working framework then I think you'll find a lot of support > materialises. The problem is when you are just proposing vapourware solutions > everyone steps in and wants it done their way. > > Code speaks louder than words :) I've written far too much code for various freebsd problems, and it has always been ignored. Not rejected, ignored. Unless someone with commit rights thinks it's a good idea, writing code for freebsd is a waste of time. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 11:30:40 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACA8116A41F; Fri, 6 Jan 2006 11:30:40 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50ABA43D45; Fri, 6 Jan 2006 11:30:38 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k06BU2p7082616; Fri, 6 Jan 2006 03:30:38 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k06BSFeQ066668; Fri, 6 Jan 2006 03:28:15 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k06BSFs0066667; Fri, 6 Jan 2006 03:28:15 -0800 (PST) (envelope-from jrhett) Date: Fri, 6 Jan 2006 03:28:15 -0800 From: Jo Rhett To: Mark Linimon Message-ID: <20060106112815.GH54324@svcolo.com> Mail-Followup-To: Mark Linimon , freebsd-stable@freebsd.org, current References: <43A266E5.3080103@samsco.org> <43AB1E65.2030501@mac.com> <20051222221202.GM39174@svcolo.com> <200512231136.12471.doconnor@gsoft.com.au> <20060105092448.GH1358@svcolo.com> <20060105184147.GD69162@funkthat.com> <20060105233226.GC17890@soaustin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060105233226.GC17890@soaustin.net> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: freebsd-stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 11:30:40 -0000 > > I just know that core has either struck it down or been Silent. On Thu, Jan 05, 2006 at 05:32:26PM -0600, Mark Linimon wrote: > The latter is an entirely different case from the former, and you've been > claiming core has done the former. This, and the above, tell me that > you're not interested in checking your facts before making an accusation. > (And, as well, that you do not even understand the role the core plays > in the project. Hint: it is not primarily technical in nature.) I agree with most of what you said here. This was known and understood. Agreement on direction is what I was expecting, er, dreaming about. Not technical issues. Sorry if that surprises you. But I have to take objection to this: > As a final observation, FreeBSD is rarely advanced by postings of the > form 'FreeBSD must do XYZ'. This is primarily because volunteers work on > whatever they feel interested in doing with their free time, rather than > the priorities anyone else sets for them. First, this is obvious and true for all open source projects. But no, FreeBSD _never_ advances because someone writes code that does something well. FreeBSD _only_ advances when the core developers agree that this thing is worthy of their interest. And I'm not even saying this is a bad thing. It just means that writing code without buy-in from the core developers is GUARANTEED to be a waste of time. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 11:50:25 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F018816A41F; Fri, 6 Jan 2006 11:50:25 +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 922B443D49; Fri, 6 Jan 2006 11:50:22 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp232-237.lns2.adl4.internode.on.net [203.122.232.237]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k06BoHrD041706 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 6 Jan 2006 22:20:20 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Jo Rhett Date: Fri, 6 Jan 2006 22:20:11 +1030 User-Agent: KMail/1.8.3 References: <43A266E5.3080103@samsco.org> <200601061120.14707.doconnor@gsoft.com.au> <20060106112329.GG54324@svcolo.com> In-Reply-To: <20060106112329.GG54324@svcolo.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart17759608.RyVHtf6x3N"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601062220.13417.doconnor@gsoft.com.au> X-Spam-Score: 0 () SUBJECT_EXCESS_QP X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: freebsd-stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 11:50:26 -0000 --nextPart17759608.RyVHtf6x3N Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 6 Jan 2006 21:53, Jo Rhett wrote: > > you mean? Are you claiming someone from (or claiming to be from core) > > said "Don't do this, we won't allow it"? If so, can you supply proof? > > I used to write a lot of patches to freebsd. I used to submit a lot of b= ug > reports. I've found over the years that unless you have gotten > pre-agreement from others about the nature of the patch, or agreement to > focus on the problem, neither one amounts to a hill of beans. Installati= on > problems that existed in 4.4 are still alive and well in the 6.0 installe= r, > for example. That is not my experience. > How FreeBSD "works" is by getting someone in the core team to care about > the issue. No amount of problem reports, patches or code will generate > even a millimeter of movement otherwise. You are mistaking core@ for developers@.. Like I've said before, core is largely irrelevant in FreeBSD when it comes = to=20 deciding what stuff gets added. > I've written far too much code for various freebsd problems, and it has > always been ignored. Not rejected, ignored. Unless someone with commit > rights thinks it's a good idea, writing code for freebsd is a waste of > time. Yes.. and those people AREN'T CORE. Please, please stop confusing your term= s,=20 it makes the discussion much harder than it needs to be. You ARE right if what you mean is that "We need interested committers to he= lp=20 thrash out a system for making upgrades simpler". I imagine there are a few committers interested, but I'd say you need to as= k=20 the right way first.. =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 --nextPart17759608.RyVHtf6x3N Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDvll15ZPcIHs/zowRAmo8AJ9ocN73YZijfX5s6c0b5FL4AhIKgwCeIL4j oC06ZOPLwTvNrCdlTzdm/i8= =hJ81 -----END PGP SIGNATURE----- --nextPart17759608.RyVHtf6x3N-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 12:23:03 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E29BB16A41F; Fri, 6 Jan 2006 12:23:02 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from crivens.unixoid.de (crivens.unixoid.de [81.169.171.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C5FE43D48; Fri, 6 Jan 2006 12:23:02 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from localhost (localhost [127.0.0.1]) by crivens.unixoid.de (Postfix) with ESMTP id 43F693F7E; Fri, 6 Jan 2006 13:23:00 +0100 (CET) Received: from crivens.unixoid.de ([127.0.0.1]) by localhost (crivens.unixoid.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95718-16; Fri, 6 Jan 2006 13:22:56 +0100 (CET) Received: from [10.38.0.120] (unknown [213.238.63.253]) by crivens.unixoid.de (Postfix) with ESMTP id 1356E41BD; Fri, 6 Jan 2006 13:22:56 +0100 (CET) Message-ID: <43BE6226.5000103@kernel32.de> Date: Fri, 06 Jan 2006 13:27:18 +0100 From: Marian Hettwer User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jo Rhett References: <43A266E5.3080103@samsco.org> <200512231136.12471.doconnor@gsoft.com.au> <20060105092448.GH1358@svcolo.com> <200601061120.14707.doconnor@gsoft.com.au> <20060106112329.GG54324@svcolo.com> In-Reply-To: <20060106112329.GG54324@svcolo.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at unixoid.de Cc: freebsd-stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 12:23:03 -0000 Hi there, Jo Rhett wrote: > On Fri, Jan 06, 2006 at 11:20:13AM +1030, Daniel O'Connor wrote: >> >>So, uhh, how would your magical binary upgrade system handle custom kernels? >>Why would it be any different? You still haven't explained how this would >>work.. > > > Versioning of the core package would tell you WHAT you have with a query. > It's trivial to then install the matching patches. Right now every > enterprise has to build a backend database tracking core os, installed > options, compile options, etc for every single installed system. Or build > a checksum database that can be used to derive this information from the > system (if all systems have the CPU/RAM to spare to play this game) > I'm actually wondering how yahoo for instance handles this situation. To my knowledge, they have several thousand of FreeBSD based servers. Either they are all the same in regards to configuration and version, or they have some other cunning way to solve the issue of patching. > > We need support from the freebsd core developers that this is a worthwhile > idea, and what kind of solutions would be acceptable to them. Once we have > a direction to go in, code can be written. > Generally speaking: Your statement is true. You don't start writing code without an agreement that the direction choosen is a direction where FreeBSD wants to evolve. However, you (as in, you as a developer) could come up with a proof of concept. Start with an implementation like you would like to have it. And even if it's just a piece of paper and some code. Then start this thread over again, fine tune the concept and hopefully some others will jump aboard and help developing. I would like to, but I do lack knowledge in C. Shell and a wee bit of Perl is fine. Definitly too few knowledge for a project like that :-/ > >>If you supply a working framework then I think you'll find a lot of support >>materialises. The problem is when you are just proposing vapourware solutions >>everyone steps in and wants it done their way. >> >>Code speaks louder than words :) > > > I've written far too much code for various freebsd problems, and it has > always been ignored. Not rejected, ignored. Unless someone with commit > rights thinks it's a good idea, writing code for freebsd is a waste of > time. > That statement ain't true. If the code solves your problem, fine. If it solves problems of others too, even better. Chances are higher that it doesn't get ignored... regards, Marian From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 13:57:22 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D4DA16A41F for ; Fri, 6 Jan 2006 13:57:22 +0000 (GMT) (envelope-from scott@fishballoon.org) Received: from mta07-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72F4243D45 for ; Fri, 6 Jan 2006 13:57:21 +0000 (GMT) (envelope-from scott@fishballoon.org) Received: from aamta12-winn.ispmail.ntl.com ([81.103.221.35]) by mta07-winn.ispmail.ntl.com with ESMTP id <20060106135720.HTNK21883.mta07-winn.ispmail.ntl.com@aamta12-winn.ispmail.ntl.com> for ; Fri, 6 Jan 2006 13:57:20 +0000 Received: from llama.fishballoon.org ([81.104.195.171]) by aamta12-winn.ispmail.ntl.com with ESMTP id <20060106135720.NYR774.aamta12-winn.ispmail.ntl.com@llama.fishballoon.org> for ; Fri, 6 Jan 2006 13:57:20 +0000 Received: from scott by llama.fishballoon.org with local (Exim 4.52 (FreeBSD)) id 1Eus5m-0005O7-3l for freebsd-stable@freebsd.org; Fri, 06 Jan 2006 13:57:18 +0000 Date: Fri, 6 Jan 2006 13:57:18 +0000 From: Scott Mitchell To: freebsd-stable@freebsd.org Message-ID: <20060106135717.GA20651@llama.fishballoon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 4.11-RELEASE i386 Sender: Scott Mitchell Subject: 6.0 on Dell 1850 with DRAC4 management card? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 13:57:22 -0000 Hi all, On to my next question about running 6.0 on a Dell PE1850, since it seems that the RAID card will work just fine... I'm thinking about getting the machine with a DRAC4 remote management card. This looks to be OS-independent (you can configure through the BIOS) so I expect it will just work. I've seen various posts talking about how it tends to take over the keyboard and render the real console inaccessible, but there are workarounds for that. Does anyone have the console redirection working? I'd like to leave the 'real' console (actually a USB keyboard attached to a KVM) active so the machine is accessible to someone actually in the server room, but still be able to get to the console remotely when necessary. The Dell docs imply that you can just point a browser at the DRAC and fire up a new console, but I'd like to hear from someone who's done this with FreeBSD! Apologies for all the dumb questions... I'd try all this stuff myself but the hardware isn't here yet and has to go into production pretty quickly once it arrives. All the similar machines in the building are already running Windows and someone would object if I 'liberated' any of them :) Cheers, Scott -- =========================================================================== Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" scott at fishballoon.org | 0xAA775B8B | -- Anon From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 14:10:53 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68EBB16A424 for ; Fri, 6 Jan 2006 14:10:53 +0000 (GMT) (envelope-from rhempel@bmts.com) Received: from mail.bmts.com (mail.bmts.com [216.183.128.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0149443D7B for ; Fri, 6 Jan 2006 14:10:45 +0000 (GMT) (envelope-from rhempel@bmts.com) Received: from [192.168.254.102] (cheetah-bar-ppp054.bmts.com [216.183.159.55]) by mail.bmts.com (8.12.10/8.12.10) with ESMTP id k06E2j4a012930; Fri, 6 Jan 2006 09:02:45 -0500 (EST) Message-ID: <43BE7AB6.5020106@bmts.com> Date: Fri, 06 Jan 2006 09:12:06 -0500 From: Ralph Hempel User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Scott Mitchell References: <20060106135717.GA20651@llama.fishballoon.org> In-Reply-To: <20060106135717.GA20651@llama.fishballoon.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 6.0 on Dell 1850 with DRAC4 management card? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rhempel@bmts.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 14:10:53 -0000 Scott Mitchell wrote: > Hi all, > > On to my next question about running 6.0 on a Dell PE1850, since it seems > that the RAID card will work just fine... > > I'm thinking about getting the machine with a DRAC4 remote management card. > This looks to be OS-independent (you can configure through the BIOS) so I > expect it will just work. I've seen various posts talking about how it > tends to take over the keyboard and render the real console inaccessible, > but there are workarounds for that. I'm not sure about that, but I have 15 of these machines in locations all over Ontario, running Windows2003 Server. To make the thing as secure as possible, there is no keyboard or monitor on the server, I attach through the client's LAN. The DRAC gets a static IP on the local subnet, so using a laptop with a connection (hard or wireless), I can access and control the server from inside the server room, from an office or desk in the building, or from anywhere in the world there is an Internet connection. The last option means having VPN access to the local building network. > Does anyone have the console redirection working? I'd like to leave the > 'real' console (actually a USB keyboard attached to a KVM) active so the > machine is accessible to someone actually in the server room, but still be > able to get to the console remotely when necessary. The Dell docs imply > that you can just point a browser at the DRAC and fire up a new console, > but I'd like to hear from someone who's done this with FreeBSD! Works for me! It's really cool! You can access multiple servers through additional browser windows. As long as there is another computer in the server room with access to your server, they can control it through the browser interface. No KBD or monitor are necessary. I'd like to assume FreeBSD will "just work". Ralph From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 14:20:26 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9009716A41F for ; Fri, 6 Jan 2006 14:20:26 +0000 (GMT) (envelope-from todor.dragnev@gmail.com) Received: from mail.sistechnology.com (torro.sistechnology.com [217.79.65.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B72943D49 for ; Fri, 6 Jan 2006 14:20:23 +0000 (GMT) (envelope-from todor.dragnev@gmail.com) Received: from localhost (localhost [127.0.0.1]) by mail.sistechnology.com (Postfix) with ESMTP id 167DC46BFE; Fri, 6 Jan 2006 16:20:21 +0200 (EET) Received: from mail.sistechnology.com ([217.79.65.130]) by localhost (torro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28155-07; Fri, 6 Jan 2006 16:20:19 +0200 (EET) Received: from nova.sistechnology.com (unknown [192.168.7.3]) by mail.sistechnology.com (Postfix) with ESMTP id 4C7E846BFB; Fri, 6 Jan 2006 16:20:19 +0200 (EET) From: Todor Dragnev To: Peter Jeremy Date: Fri, 6 Jan 2006 15:19:29 +0200 User-Agent: KMail/1.6.2 References: <20060106090854.GA36654@linuxfan.org> <20060106111531.GC51452@cirb503493.alcatel.com.au> In-Reply-To: <20060106111531.GC51452@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200601061519.30260.todor.dragnev@gmail.com> X-Virus-Scanned: by the vKeeper at sistechnology.com Cc: freebsd-stable@freebsd.org Subject: Re: [jonathan.glass@oit.gatech.edu: Re: [Flow-tools] Memory leak ?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: todor.dragnev@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 14:20:26 -0000 Hello, I will try with malloc and Electric Fence. I have no idea how big must be a process, because I use flow-capture for first time on this machine. Please, if someone have experience with this tool, to share some statistics. Only for information - flow-capture is a part of flow-tools in /usr/ports category net-mgmt. To collect netflow-data I use softflowd. Thank you for your email. On Friday 06 January 2006 13:15, you wrote: > [flow-capture process too large] > > On Fri, 2006-Jan-06 11:08:54 +0200, Todor Dragnev wrote: > >Can someone help with this ? > > Help how? AFAIK, flow-control/flow-capture is not a FreeBSD port so > finding someone here with knowledge of it may be difficult. If you > think it's a problem with FreeBSD, you're going to need to supply more > information so that we can help you. > From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 14:35:30 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A85C416A41F; Fri, 6 Jan 2006 14:35:30 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5F8B43D49; Fri, 6 Jan 2006 14:35:29 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.3/8.13.3) with ESMTP id k06EZSUj011636; Fri, 6 Jan 2006 17:35:28 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Fri, 6 Jan 2006 17:35:28 +0300 (MSK) From: Dmitry Morozovsky To: Ceri Davies In-Reply-To: <20060106103648.GJ31522@submonkey.net> Message-ID: <20060106173204.P87428@woozle.rinet.ru> References: <20060104222846.K98554@woozle.rinet.ru> <20060106103648.GJ31522@submonkey.net> X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (woozle.rinet.ru [0.0.0.0]); Fri, 06 Jan 2006 17:35:28 +0300 (MSK) Cc: Vivek Khera , stable@freebsd.org Subject: Re: rpcbind lingering on IP no longer specified on command line X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 14:35:30 -0000 On Fri, 6 Jan 2006, Ceri Davies wrote: CD> > VK> I had rpcbind running with on two interfaces like this: CD> > VK> CD> > VK> rpcbind -h 192.168.100.200 -h 10.0.0.9 CD> > VK> CD> > VK> Now, I changed rpcbind_flags in /etc/rc.conf to just have the first address, CD> > VK> and I restarted rpcbind. the process list from ps shows it is running like CD> > VK> this: CD> > VK> CD> > VK> rpcbind -h 192.168.100.200 CD> > VK> CD> > VK> Yet nmap on the other address shows rpcbind is still listening on udp there. CD> > VK> How do I stop that? CD> > CD> > As I sometimes looked into this, rpcbind (formely portmap) listens on all CD> > described addresses via udp *and* an tcp:*.111 - I tried to dig why is this but CD> > did not succeed much. CD> CD> Please test this patch. It's probably a very naive fix, but seems to CD> work OK. Well, two objections: - (obvious and dumb ;): three kinds of changes inside: behaviour, style and typo ;-))) - serious: no way to run on NO_INET6 kernel: root@mole:/usr/src/usr.sbin/rpcbind# pid rpc 83231 ?? Ss 0:00.00 /usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind root@mole:/usr/src/usr.sbin/rpcbind# killall rpcbind root@mole:/usr/src/usr.sbin/rpcbind# pid rpc root@mole:/usr/src/usr.sbin/rpcbind# rpcbind root@mole:/usr/src/usr.sbin/rpcbind# rpcinfo -p program vers proto port service 100000 4 tcp 111 rpcbind 100000 3 tcp 111 rpcbind 100000 2 tcp 111 rpcbind 100000 4 udp 111 rpcbind 100000 3 udp 111 rpcbind 100000 2 udp 111 rpcbind 100000 4 local 111 rpcbind 100000 3 local 111 rpcbind 100000 2 local 111 rpcbind root@mole:/usr/src/usr.sbin/rpcbind# killall rpcbind root@mole:/usr/src/usr.sbin/rpcbind# /usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind root@mole:/usr/src/usr.sbin/rpcbind# rpcinfo -p rpcinfo: can't contact portmapper: RPC: Port mapper failure - RPC: Success root@mole:/usr/src/usr.sbin/rpcbind# sockstat -4 | grep rpc root rpcbind 83332 7 udp4 *:111 *:* root rpcbind 83332 8 udp4 *:608 *:* root rpcbind 83332 9 tcp4 *:111 *:* Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 14:43:16 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F56F16A41F for ; Fri, 6 Jan 2006 14:43:16 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from crivens.unixoid.de (crivens.unixoid.de [81.169.171.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 874CA43D45 for ; Fri, 6 Jan 2006 14:43:15 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from localhost (localhost [127.0.0.1]) by crivens.unixoid.de (Postfix) with ESMTP id 114D84006; Fri, 6 Jan 2006 15:43:14 +0100 (CET) Received: from crivens.unixoid.de ([127.0.0.1]) by localhost (crivens.unixoid.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11077-02; Fri, 6 Jan 2006 15:43:10 +0100 (CET) Received: from [10.38.0.120] (unknown [213.238.63.253]) by crivens.unixoid.de (Postfix) with ESMTP id 4A44E3F2A; Fri, 6 Jan 2006 15:43:10 +0100 (CET) Message-ID: <43BE8304.2010709@kernel32.de> Date: Fri, 06 Jan 2006 15:47:32 +0100 From: Marian Hettwer User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Mitchell References: <20060106135717.GA20651@llama.fishballoon.org> In-Reply-To: <20060106135717.GA20651@llama.fishballoon.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at unixoid.de Cc: freebsd-stable@freebsd.org Subject: Re: 6.0 on Dell 1850 with DRAC4 management card? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 14:43:16 -0000 Hi there, Scott Mitchell wrote: > Hi all, > > > I'm thinking about getting the machine with a DRAC4 remote management card. > This looks to be OS-independent (you can configure through the BIOS) so I > expect it will just work. I've seen various posts talking about how it > tends to take over the keyboard and render the real console inaccessible, > but there are workarounds for that. I don't know about the DRAC with FreeBSD, but I assume that the BIOS of this Dell still supports BIOS redirection to serial port. If so, you can have Monitor and Keyboard connected locally and use the serial console remote. Just get a small console server (depending on the amount of servers you have remote), for instance an old cyclades TS. Connect them and you can get on your serial port through the console server via ssh. There you go ;) ssh username:yourserver@console-server A pretty nice way to do remote management. HTH, Marian PS.: If you need additional informations, ask me. At work we have approx 1000 servers (appr. 300 dell's) remote managed with console servers. And it's working fine. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 14:43:43 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6671616A41F for ; Fri, 6 Jan 2006 14:43:43 +0000 (GMT) (envelope-from scott@fishballoon.org) Received: from mta08-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EC6B43D46 for ; Fri, 6 Jan 2006 14:43:41 +0000 (GMT) (envelope-from scott@fishballoon.org) Received: from aamta11-winn.ispmail.ntl.com ([81.103.221.35]) by mta08-winn.ispmail.ntl.com with ESMTP id <20060106144340.QCPC17804.mta08-winn.ispmail.ntl.com@aamta11-winn.ispmail.ntl.com>; Fri, 6 Jan 2006 14:43:40 +0000 Received: from llama.fishballoon.org ([81.104.195.171]) by aamta11-winn.ispmail.ntl.com with ESMTP id <20060106144340.BWRE29634.aamta11-winn.ispmail.ntl.com@llama.fishballoon.org>; Fri, 6 Jan 2006 14:43:40 +0000 Received: from scott by llama.fishballoon.org with local (Exim 4.52 (FreeBSD)) id 1Eusoc-0005U2-6n; Fri, 06 Jan 2006 14:43:38 +0000 Date: Fri, 6 Jan 2006 14:43:38 +0000 From: Scott Mitchell To: Ralph Hempel Message-ID: <20060106144337.GB20651@llama.fishballoon.org> References: <20060106135717.GA20651@llama.fishballoon.org> <43BE7AB6.5020106@bmts.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43BE7AB6.5020106@bmts.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 4.11-RELEASE i386 Sender: Scott Mitchell Cc: freebsd-stable@freebsd.org Subject: Re: 6.0 on Dell 1850 with DRAC4 management card? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 14:43:43 -0000 On Fri, Jan 06, 2006 at 09:12:06AM -0500, Ralph Hempel wrote: > Scott Mitchell wrote: > >Hi all, > > > >On to my next question about running 6.0 on a Dell PE1850, since it seems > >that the RAID card will work just fine... > > > >I'm thinking about getting the machine with a DRAC4 remote management card. > >This looks to be OS-independent (you can configure through the BIOS) so I > >expect it will just work. I've seen various posts talking about how it > >tends to take over the keyboard and render the real console inaccessible, > >but there are workarounds for that. > > I'm not sure about that, but I have 15 of these machines in locations > all over Ontario, running Windows2003 Server. I should have said that this was really a FreeBSD issue rather than a problem with the DRAC - apparently it attaches as a second keyboard and mouse, but FreeBSD has historically only allowed a single 'console' keyboard to exist. 6.0 has the kbdmux(4) driver that might solve this without and messing about with keyboard attachments. > To make the thing as secure as possible, there is no keyboard or > monitor on the server, I attach through the client's LAN. > > The DRAC gets a static IP on the local subnet, so using a laptop with > a connection (hard or wireless), I can access and control the server > from inside the server room, from an office or desk in the building, > or from anywhere in the world there is an Internet connection. > > The last option means having VPN access to the local building network. That sounds cool. The server room is right behind my desk so it's not a big deal go in there, but being able to reboot a stuck machine from home is nice! > >Does anyone have the console redirection working? I'd like to leave the > >'real' console (actually a USB keyboard attached to a KVM) active so the > >machine is accessible to someone actually in the server room, but still be > >able to get to the console remotely when necessary. The Dell docs imply > >that you can just point a browser at the DRAC and fire up a new console, > >but I'd like to hear from someone who's done this with FreeBSD! > > Works for me! It's really cool! You can access multiple servers through > additional browser windows. As long as there is another computer in the > server room with access to your server, they can control it through > the browser interface. No KBD or monitor are necessary. > > I'd like to assume FreeBSD will "just work". Me too. Sounds like it will mostly behave itself. Scott -- =========================================================================== Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" scott at fishballoon.org | 0xAA775B8B | -- Anon From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 15:11:14 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B38EE16A41F for ; Fri, 6 Jan 2006 15:11:14 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6128943D48 for ; Fri, 6 Jan 2006 15:11:14 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id D785AB864 for ; Fri, 6 Jan 2006 10:11:12 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43BDED2E.7090803@mac.com> References: <6CADC5BD-FBF5-472E-8087-8494AD03549C@khera.org> <43BDED2E.7090803@mac.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <701B6D67-507A-4361-8875-2D5527729E86@khera.org> Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Fri, 6 Jan 2006 10:11:12 -0500 To: freebsd-stable X-Mailer: Apple Mail (2.746.2) Subject: Re: SCSI RAID card recommendation (1/2 height PCI-X U320 SCSI dual channel) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 15:11:14 -0000 On Jan 5, 2006, at 11:08 PM, Chuck Swiger wrote: > There's an interesting thread about the AMR RAID controller used in > the newer 18x0/28x0 Dells with the PERC/4 controller, and I know of > enough people using them that such improvements (by Doug Ambrisko?) > will be welcomed. Thanks for your note. Turns out I have more than one Dell system with aac controllers in them :-) One happens to be a PE 1750 with the PERC 3/Di in it running RAID1. It is lightly loaded but is sufficient for that server's needs, but is running FreeBSD 4.11 on it. Is there a way to backport this diskinfo utility to 4.x or 5.x? Looks most useful! On my 6.0 box with a PERC 3/Si card (aac driver too) it is showing seek times slower than yours but transfer rates faster. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 15:14:44 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65B2416A41F for ; Fri, 6 Jan 2006 15:14:44 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-3-1-cust208.cdif.cable.ntl.com [82.31.78.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CB3D43D46 for ; Fri, 6 Jan 2006 15:14:43 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EutIf-0007F7-Ad; Fri, 06 Jan 2006 15:14:41 +0000 Date: Fri, 6 Jan 2006 15:14:41 +0000 From: Ceri Davies To: Marius Nuennerich Message-ID: <20060106151441.GE86645@submonkey.net> Mail-Followup-To: Ceri Davies , Marius Nuennerich , freebsd-stable@freebsd.org References: <20060105134133.61aef78f@sol> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FLPM4o+7JoHGki3m" Content-Disposition: inline In-Reply-To: <20060105134133.61aef78f@sol> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.11 Sender: Ceri Davies Cc: freebsd-stable@freebsd.org Subject: Re: /boot/nextboot.conf not deactivated after one boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 15:14:44 -0000 --FLPM4o+7JoHGki3m Content-Type: multipart/mixed; boundary="DNUSDXU7R7AVVM8C" Content-Disposition: inline --DNUSDXU7R7AVVM8C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 05, 2006 at 01:41:33PM +0100, Marius Nuennerich wrote: > Hi folks, >=20 > it seems like /boot/nextboot.conf is neither deleted nor > nextboot_enable set to NO on the first line after a reboot. > So it isn't a one shot anymore as the manpage claims. >=20 > System is 6.0-RELEASE. I think this is down to a typo in /etc/rc.d/root; at least I can't find any other reference to /boot/nextkernel in src/. Patch attached (root.diff). > It would also be fine imo, if the -k option would be optional and the > next kernel defaults to "kernel". I'm not sure if getopts can be persuaded to take an optional argument to an option. If not, the attached patch (nextboot.diff) should work for you. Ceri --=20 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Einstein (attrib.) --DNUSDXU7R7AVVM8C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="root.diff" Content-Transfer-Encoding: quoted-printable Index: etc/rc.d/root =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/etc/rc.d/root,v retrieving revision 1.11 diff -u -r1.11 root --- etc/rc.d/root 2 Dec 2005 21:33:43 -0000 1.11 +++ etc/rc.d/root 6 Jan 2006 14:37:51 -0000 @@ -34,8 +34,8 @@ =20 # If we booted a special kernel remove the record # so we will boot the default kernel next time. - if [ -e /boot/nextkernel ]; then - rm -f /boot/nextkernel + if [ -e /boot/nextboot.conf ]; then + rm -f /boot/nextboot.conf fi } =20 --DNUSDXU7R7AVVM8C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nextboot.diff" Content-Transfer-Encoding: quoted-printable Index: sbin/reboot/nextboot.8 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/reboot/nextboot.8,v retrieving revision 1.4 diff -u -r1.4 nextboot.8 --- sbin/reboot/nextboot.8 12 Dec 2002 17:25:56 -0000 1.4 +++ sbin/reboot/nextboot.8 6 Jan 2006 15:13:24 -0000 @@ -24,7 +24,7 @@ .\" .\" $FreeBSD: src/sbin/reboot/nextboot.8,v 1.4 2002/12/12 17:25:56 ru Exp $ .\" -.Dd November 4, 2002 +.Dd January 6, 2006 .Dt NEXTBOOT 8 .Os .Sh NAME @@ -33,8 +33,8 @@ .Sh SYNOPSIS .Nm .Op Fl f +.Op Fl k Ar kernel .Op Fl o Ar options -.Fl k Ar kernel .Nm .Fl D .Sh DESCRIPTION @@ -68,6 +68,8 @@ This option specifies a kernel directory relative to .Pa /boot to load the kernel and any modules from. +If this option is not provided, defaults to +.Dq Li kernel . .It Fl o Ar options This option allows the passing of kernel flags for the next boot. @@ -90,7 +92,7 @@ .Pp To enable into single user mode with the normal kernel: .Pp -.Dl "nextboot -o ""-s"" -k kernel" +.Dl "nextboot -o ""-s""" .Pp To remove an existing nextboot configuration: .Pp Index: sbin/reboot/nextboot.sh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/reboot/nextboot.sh,v retrieving revision 1.1 diff -u -r1.1 nextboot.sh --- sbin/reboot/nextboot.sh 24 May 2002 04:06:03 -0000 1.1 +++ sbin/reboot/nextboot.sh 6 Jan 2006 15:13:24 -0000 @@ -10,10 +10,12 @@ nextboot_file=3D"/boot/nextboot.conf" =20 display_usage() { - echo "Usage: nextboot [-f] [-o options] -k kernel" + echo "Usage: nextboot [-f] [-k kernel] [-o options]" echo " nextboot -D" } =20 +kernel=3D"kernel" + while getopts "Dfk:o:" argument ; do case "${argument}" in D) @@ -40,11 +42,6 @@ exit 0 fi =20 -if [ "xxx${kernel}" =3D "xxx" ]; then - display_usage - exit 1 -fi - if [ ${force} =3D "NO" -a ! -d /boot/${kernel} ]; then echo "Error: /boot/${kernel} doesn't exist. Use -f to override." exit 1 --DNUSDXU7R7AVVM8C-- --FLPM4o+7JoHGki3m Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDvolgocfcwTS3JF8RAhFVAKCN2aly+flyu0EsLVlKjbfJAE9d+gCdGVgb R0ydiWezxExLQGmhglucSFA= =T+Rv -----END PGP SIGNATURE----- --FLPM4o+7JoHGki3m-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 15:22:45 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5411A16A41F for ; Fri, 6 Jan 2006 15:22:45 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 048CA43D46 for ; Fri, 6 Jan 2006 15:22:44 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 44F5EB864; Fri, 6 Jan 2006 10:22:44 -0500 (EST) In-Reply-To: <20060106094024.GA43299@ns.museum.rain.com> References: <20060106040839.A38DE16A46C@hub.freebsd.org> <20060106094024.GA43299@ns.museum.rain.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Fri, 6 Jan 2006 10:22:43 -0500 To: James Long X-Mailer: Apple Mail (2.746.2) Cc: freebsd-stable@freebsd.org Subject: Re: rpcbind lingering on IP no longer specified on command line X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 15:22:45 -0000 On Jan 6, 2006, at 4:40 AM, James Long wrote: >> Yeah, I noticed that little tiny "UDP requests" note in the -h docs >> too. There's no reason to bind to all tcp addresses, and it is >> causing me heartburn for getting the server certified... > > Good grief, why not just firewall off the undesired UDP ports and call > it good? I guess we could take that band-aid approach... however, how do you know what port RPC decides to listen on other than the 111 port? It is more or less random. That makes it very difficult to firewall. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 15:35:47 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C28516A41F for ; Fri, 6 Jan 2006 15:35:47 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39DDA43D46 for ; Fri, 6 Jan 2006 15:35:47 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id C0011B865 for ; Fri, 6 Jan 2006 10:35:46 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060105224150.GA991@tuatara.fishballoon.org> References: <20060105224150.GA991@tuatara.fishballoon.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Fri, 6 Jan 2006 10:35:46 -0500 To: freebsd-stable X-Mailer: Apple Mail (2.746.2) Subject: Re: 6.0 on Dell 1850 with PERC4e/DC RAID? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 15:35:47 -0000 On Jan 5, 2006, at 5:41 PM, Scott Mitchell wrote: > I may be getting a new Dell PE1850 soon, to replace our ancient CVS > server > (still running 4-STABLE). The new machine will ideally run 6.0 and > have a > PERC4e/DC RAID card - the one with battery-backed cache. This is > listed as I have an 1850 with the buil-in PERC 4e/Si since all I needed was the RAID1 mirror of the internal drives. It works extremely well, and the speed is quite good. As for notices of when the drives go bad, under 4.x I've had disk failures with the amr driver (different PERC cards) and not gotten any such notices in the syslog that I recall. I did find a program posted to one of the freebsd lists called 'amrstat' that I run nightly. It produces this kind of output: Drive 0: 68.24 GB, RAID1 optimal If it says "degraded" it is time to fix a drive. You just fire up the lsi megaraid tools and find out which drive it is. If you go to the LSI download area, they have one file for FreeBSD, which is labeled the driver. In that zip file is also the management software for freebsd. You'll want that. Personally, I like the "MEGAMGR" software which was released for freebsd 4.x and mimics the BIOS' interface in a terminal window. The rebuild on LSI controllers is set to automatic on the dells as default. It just works as expected. Overall, I'm a big fan of the LSI cards and the amr driver... Unfortunately for me, the latest equipment I just got only takes low- profile cards, and LSI doesn't offer a dual channel RAID card in low- profile configuration... so I need to look at adaptec. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 15:42:37 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DDA916A41F for ; Fri, 6 Jan 2006 15:42:37 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-3-1-cust208.cdif.cable.ntl.com [82.31.78.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5477C43D45 for ; Fri, 6 Jan 2006 15:42:36 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eutjc-000CmX-UC; Fri, 06 Jan 2006 15:42:32 +0000 Date: Fri, 6 Jan 2006 15:42:32 +0000 From: Ceri Davies To: Dmitry Morozovsky Message-ID: <20060106154232.GF86645@submonkey.net> Mail-Followup-To: Ceri Davies , Dmitry Morozovsky , Vivek Khera , stable@freebsd.org References: <20060104222846.K98554@woozle.rinet.ru> <20060106103648.GJ31522@submonkey.net> <20060106173204.P87428@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wjoFZxbW4tu+iR6v" Content-Disposition: inline In-Reply-To: <20060106173204.P87428@woozle.rinet.ru> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.11 Sender: Ceri Davies Cc: Vivek Khera , stable@freebsd.org Subject: Re: rpcbind lingering on IP no longer specified on command line X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 15:42:37 -0000 --wjoFZxbW4tu+iR6v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 06, 2006 at 05:35:28PM +0300, Dmitry Morozovsky wrote: > On Fri, 6 Jan 2006, Ceri Davies wrote: >=20 > CD> > VK> I had rpcbind running with on two interfaces like this: > CD> > VK>=20 > CD> > VK> rpcbind -h 192.168.100.200 -h 10.0.0.9 > CD> > VK>=20 > CD> > VK> Now, I changed rpcbind_flags in /etc/rc.conf to just have the f= irst address, > CD> > VK> and I restarted rpcbind. the process list from ps shows it is = running like > CD> > VK> this: > CD> > VK>=20 > CD> > VK> rpcbind -h 192.168.100.200 > CD> > VK>=20 > CD> > VK> Yet nmap on the other address shows rpcbind is still listening = on udp there. > CD> > VK> How do I stop that? > CD> >=20 > CD> > As I sometimes looked into this, rpcbind (formely portmap) listens = on all=20 > CD> > described addresses via udp *and* an tcp:*.111 - I tried to dig why= is this but=20 > CD> > did not succeed much. > CD>=20 > CD> Please test this patch. It's probably a very naive fix, but seems to > CD> work OK. >=20 > Well, two objections: >=20 > - (obvious and dumb ;): three kinds of changes inside: behaviour, style a= nd=20 > typo ;-))) Well yeah, but I figured that didn't matter for now. I disagree that the RUN_AS stuff is style though; the previous hardcoded "daemon" completely takes away the point of the '#define RUN_AS "daemon"'. If you are referring to my indentation, again that's just a "keep the patch simple" thing. Anyway... > - serious: no way to run on NO_INET6 kernel: >=20 > root@mole:/usr/src/usr.sbin/rpcbind# pid rpc > 83231 ?? Ss 0:00.00 /usr/obj/ar/src.6/usr.sbin/rpcbind/rpcbind > root@mole:/usr/src/usr.sbin/rpcbind# killall rpcbind > root@mole:/usr/src/usr.sbin/rpcbind# pid rpc > root@mole:/usr/src/usr.sbin/rpcbind# rpcbind > root@mole:/usr/src/usr.sbin/rpcbind# rpcinfo -p > program vers proto port service > 100000 4 tcp 111 rpcbind > 100000 3 tcp 111 rpcbind > 100000 2 tcp 111 rpcbind > 100000 4 udp 111 rpcbind > 100000 3 udp 111 rpcbind > 100000 2 udp 111 rpcbind > 100000 4 local 111 rpcbind > 100000 3 local 111 rpcbind > 100000 2 local 111 rpcbind > root@mole:/usr/src/usr.sbin/rpcbind# killall rpcbind > root@mole:/usr/src/usr.sbin/rpcbind# /usr/obj/ar/src.6/usr.sbin/rpcbind/r= pcbind > root@mole:/usr/src/usr.sbin/rpcbind# rpcinfo -p > rpcinfo: can't contact portmapper: RPC: Port mapper failure - RPC: Success > root@mole:/usr/src/usr.sbin/rpcbind# sockstat -4 | grep rpc > root rpcbind 83332 7 udp4 *:111 *:* > root rpcbind 83332 8 udp4 *:608 *:* > root rpcbind 83332 9 tcp4 *:111 *:* That's more annoying. It's not INET6 though; it's because the local transport is also tpi_cots_ord, so /var/run/rpcbind.sock is not getting created. I'll take another go at this over the weekend. Ceri --=20 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Einstein (attrib.) --wjoFZxbW4tu+iR6v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDvo/oocfcwTS3JF8RAu81AJ4r/8hTqZB+RYHxq7GxfIXVD1XDcACgvU+t JbrajR1idB3Oe+1PQ63rXi8= =dppg -----END PGP SIGNATURE----- --wjoFZxbW4tu+iR6v-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 15:43:53 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E05D716A41F for ; Fri, 6 Jan 2006 15:43:53 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A8EF43D48 for ; Fri, 6 Jan 2006 15:43:53 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 1DD71B85A for ; Fri, 6 Jan 2006 10:43:53 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43BE8304.2010709@kernel32.de> References: <20060106135717.GA20651@llama.fishballoon.org> <43BE8304.2010709@kernel32.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Fri, 6 Jan 2006 10:43:52 -0500 To: freebsd-stable X-Mailer: Apple Mail (2.746.2) Subject: Re: 6.0 on Dell 1850 with DRAC4 management card? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 15:43:54 -0000 On Jan 6, 2006, at 9:47 AM, Marian Hettwer wrote: > I don't know about the DRAC with FreeBSD, but I assume that the > BIOS of > this Dell still supports BIOS redirection to serial port. If so, > you can > have Monitor and Keyboard connected locally and use the serial console > remote. > Just get a small console server (depending on the amount of servers > you > have remote), for instance an old cyclades TS. Connect them and you > can > get on your serial port through the console server via ssh. This is precisely what I do. The cyclades work extremely well, except for one flaw: if you power cycle them they send a BREAK signal down every serial port. So just make sure you don't have BREAK_TO_DEBUGGER enabled on your kernels and you're safe. Otherwise expect every server to break to debugger on a power cycle of your cyclade. Not that you need to ever reboot those little boxes, but you never know.... I've never enabled the DRAC card on any dell I have that came with them... From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 16:17:47 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E129216A41F for ; Fri, 6 Jan 2006 16:17:47 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from crivens.unixoid.de (crivens.unixoid.de [81.169.171.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6693743D46 for ; Fri, 6 Jan 2006 16:17:47 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from localhost (localhost [127.0.0.1]) by crivens.unixoid.de (Postfix) with ESMTP id D50964140; Fri, 6 Jan 2006 17:17:45 +0100 (CET) Received: from crivens.unixoid.de ([127.0.0.1]) by localhost (crivens.unixoid.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11077-10; Fri, 6 Jan 2006 17:17:42 +0100 (CET) Received: from [10.38.0.120] (unknown [213.238.63.253]) by crivens.unixoid.de (Postfix) with ESMTP id 4274D4006; Fri, 6 Jan 2006 17:17:42 +0100 (CET) Message-ID: <43BE992C.5030506@kernel32.de> Date: Fri, 06 Jan 2006 17:22:04 +0100 From: Marian Hettwer User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vivek Khera References: <20060106135717.GA20651@llama.fishballoon.org> <43BE8304.2010709@kernel32.de> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at unixoid.de Cc: freebsd-stable Subject: Re: 6.0 on Dell 1850 with DRAC4 management card? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 16:17:48 -0000 Vivek Khera wrote: > > On Jan 6, 2006, at 9:47 AM, Marian Hettwer wrote: > >> I don't know about the DRAC with FreeBSD, but I assume that the BIOS of >> this Dell still supports BIOS redirection to serial port. If so, you can >> have Monitor and Keyboard connected locally and use the serial console >> remote. >> Just get a small console server (depending on the amount of servers you >> have remote), for instance an old cyclades TS. Connect them and you can >> get on your serial port through the console server via ssh. > > > This is precisely what I do. The cyclades work extremely well, except > for one flaw: if you power cycle them they send a BREAK signal down > every serial port. So just make sure you don't have BREAK_TO_DEBUGGER > enabled on your kernels and you're safe. Otherwise expect every server > to break to debugger on a power cycle of your cyclade. Not that you > need to ever reboot those little boxes, but you never know.... > How old is your Cyclades box? Since mid 2002 these boxes don't send a break when power cycled. And I know what I say, being an ex-employee of cyclades (o' course, technician). We had customers with quite a large amount of sun servers and these are usually pretty sensitive regarding breaks. Never had an issue due to power cycles... hm... consider a replacement :) The old boxes had 5 years of warranty. So, go for it ;)) > I've never enabled the DRAC card on any dell I have that came with them... > I'd rather stick with a good old console which I can access remotely via ssh, too. So Long, Marian From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 16:19:30 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E05F16A41F for ; Fri, 6 Jan 2006 16:19:30 +0000 (GMT) (envelope-from rhempel@bmts.com) Received: from mail.bmts.com (mail.bmts.com [216.183.128.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46EDC43D46 for ; Fri, 6 Jan 2006 16:19:28 +0000 (GMT) (envelope-from rhempel@bmts.com) Received: from [192.168.254.102] (cheetah-bar-ppp054.bmts.com [216.183.159.55]) by mail.bmts.com (8.12.10/8.12.10) with ESMTP id k06GBi4a027389 for ; Fri, 6 Jan 2006 11:11:45 -0500 (EST) Message-ID: <43BE98F3.3000507@bmts.com> Date: Fri, 06 Jan 2006 11:21:07 -0500 From: Ralph Hempel User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 CC: freebsd-stable References: <20060106135717.GA20651@llama.fishballoon.org> <43BE8304.2010709@kernel32.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 6.0 on Dell 1850 with DRAC4 management card? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rhempel@bmts.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 16:19:30 -0000 > I've never enabled the DRAC card on any dell I have that came with them... Hmmm. The DRAC card can save you a long drive sometimes. You actually get to look at the hardware boot process and can even adjust BIOS settings if needed. To get to a FreeBSD console, I think that the OS actually needs to boot. The DRAC lets you control the server BEFORE the OS is even loaded, all through a browser interface. Ralph From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 16:25:21 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2F7816A41F for ; Fri, 6 Jan 2006 16:25:21 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id A80D243D75 for ; Fri, 6 Jan 2006 16:25:02 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id A96FFB864; Fri, 6 Jan 2006 11:25:01 -0500 (EST) In-Reply-To: <43BE992C.5030506@kernel32.de> References: <20060106135717.GA20651@llama.fishballoon.org> <43BE8304.2010709@kernel32.de> <43BE992C.5030506@kernel32.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Fri, 6 Jan 2006 11:25:00 -0500 To: Marian Hettwer X-Mailer: Apple Mail (2.746.2) Cc: freebsd-stable Subject: Re: 6.0 on Dell 1850 with DRAC4 management card? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 16:25:21 -0000 On Jan 6, 2006, at 11:22 AM, Marian Hettwer wrote: > How old is your Cyclades box? Since mid 2002 these boxes don't send a > break when power cycled. And I know what I say, being an ex- > employee of > cyclades (o' course, technician). We had customers with quite a large > amount of sun servers and these are usually pretty sensitive regarding > breaks. > Never had an issue due to power cycles... > hm... consider a replacement :) > The old boxes had 5 years of warranty. So, go for it ;)) thanks for the note. it was an original ts1000 i bought new in spring 2001. it recently died so I got a replacement for the $100 repair fee. i haven't tried a power cycle on this one: i unplugged everything before I powered it on :-) From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 16:29:27 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D24A816A423 for ; Fri, 6 Jan 2006 16:29:27 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from crivens.unixoid.de (crivens.unixoid.de [81.169.171.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10A0943D8D for ; Fri, 6 Jan 2006 16:29:07 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from localhost (localhost [127.0.0.1]) by crivens.unixoid.de (Postfix) with ESMTP id 365674140; Fri, 6 Jan 2006 17:28:35 +0100 (CET) Received: from crivens.unixoid.de ([127.0.0.1]) by localhost (crivens.unixoid.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11077-13; Fri, 6 Jan 2006 17:28:31 +0100 (CET) Received: from [10.38.0.120] (unknown [213.238.63.253]) by crivens.unixoid.de (Postfix) with ESMTP id BDDC43F12; Fri, 6 Jan 2006 17:28:31 +0100 (CET) Message-ID: <43BE9BB6.2000002@kernel32.de> Date: Fri, 06 Jan 2006 17:32:54 +0100 From: Marian Hettwer User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rhempel@bmts.com References: <20060106135717.GA20651@llama.fishballoon.org> <43BE8304.2010709@kernel32.de> <43BE98F3.3000507@bmts.com> In-Reply-To: <43BE98F3.3000507@bmts.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at unixoid.de Cc: freebsd-stable Subject: Re: 6.0 on Dell 1850 with DRAC4 management card? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 16:29:28 -0000 Ralph Hempel wrote: > >> I've never enabled the DRAC card on any dell I have that came with >> them... > > > Hmmm. The DRAC card can save you a long drive sometimes. You actually > get to look at the hardware boot process and can even adjust > BIOS settings if needed. To get to a FreeBSD console, I think that > the OS actually needs to boot. > > The DRAC lets you control the server BEFORE the OS is even loaded, > all through a browser interface. > Well, you can do that too, if you enable Console Redirection to Serial Port in the BIOS. The old DELL 1550 and 1650 were definetly capable of doing so. I don't know about the 1850, but I assume they can redirect the console too. Usually the BIOS accepts VT100 or ANSI input. Of course you want to go with VT100. And from your workstation: export TERM=vt100 ssh user:server@console-server and of you go. The only thing missing would be hardware power down. if that can be done via DRAC, that'll be an advantage :) - Marian From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 16:35:01 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D55D116A41F for ; Fri, 6 Jan 2006 16:35:01 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FCAC43D70 for ; Fri, 6 Jan 2006 16:35:00 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.3/8.13.3) with ESMTP id k06GYxj4013871; Fri, 6 Jan 2006 19:34:59 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Fri, 6 Jan 2006 19:34:59 +0300 (MSK) From: Dmitry Morozovsky To: Ceri Davies In-Reply-To: <20060106154232.GF86645@submonkey.net> Message-ID: <20060106193432.B87428@woozle.rinet.ru> References: <20060104222846.K98554@woozle.rinet.ru> <20060106103648.GJ31522@submonkey.net> <20060106173204.P87428@woozle.rinet.ru> <20060106154232.GF86645@submonkey.net> X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (woozle.rinet.ru [0.0.0.0]); Fri, 06 Jan 2006 19:34:59 +0300 (MSK) Cc: Vivek Khera , stable@freebsd.org Subject: Re: rpcbind lingering on IP no longer specified on command line X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 16:35:01 -0000 On Fri, 6 Jan 2006, Ceri Davies wrote: CD> > root@mole:/usr/src/usr.sbin/rpcbind# rpcinfo -p CD> > rpcinfo: can't contact portmapper: RPC: Port mapper failure - RPC: Success CD> CD> That's more annoying. It's not INET6 though; it's because the local CD> transport is also tpi_cots_ord, so /var/run/rpcbind.sock is not getting CD> created. I'll take another go at this over the weekend. Ah yes, I did not check sockets other than tcp4. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 16:35:06 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38CF516A41F for ; Fri, 6 Jan 2006 16:35:06 +0000 (GMT) (envelope-from rhempel@bmts.com) Received: from mail.bmts.com (mail.bmts.com [216.183.128.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93CC143D67 for ; Fri, 6 Jan 2006 16:35:05 +0000 (GMT) (envelope-from rhempel@bmts.com) Received: from [192.168.254.102] (cheetah-bar-ppp054.bmts.com [216.183.159.55]) by mail.bmts.com (8.12.10/8.12.10) with ESMTP id k06GRJ4a013735 for ; Fri, 6 Jan 2006 11:27:19 -0500 (EST) Message-ID: <43BE9C99.5050201@bmts.com> Date: Fri, 06 Jan 2006 11:36:41 -0500 From: Ralph Hempel User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 CC: freebsd-stable References: <20060106135717.GA20651@llama.fishballoon.org> <43BE8304.2010709@kernel32.de> <43BE98F3.3000507@bmts.com> <43BE9BB6.2000002@kernel32.de> In-Reply-To: <43BE9BB6.2000002@kernel32.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 6.0 on Dell 1850 with DRAC4 management card? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rhempel@bmts.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 16:35:06 -0000 > The only thing missing would be hardware power down. if that can be done > via DRAC, that'll be an advantage :) Yes, you get that too. Full hardware power down. Wait as long as you want, then power the machine up. It's not the same as a remote reboot where you HOPE the server comes up far enough to get a console session. Plus you don't need anything mote than an Ethernet connection to your existing infrastructure to make it all work. If you are paranoid and/or have a lot of servers, you can put all the DRAC ports on a separate subnet and their own VPN... Ralph From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 16:44:36 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76B7F16A41F for ; Fri, 6 Jan 2006 16:44:36 +0000 (GMT) (envelope-from carsten@betaversion.net) Received: from rosencrantz.zeitform.de (rosencrantz.zeitform.de [146.140.212.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0723A43D6A for ; Fri, 6 Jan 2006 16:44:34 +0000 (GMT) (envelope-from carsten@betaversion.net) Received: (qmail 934 invoked by uid 89); 6 Jan 2006 16:44:31 -0000 Received: by simscan 1.1.0 ppid: 929, pid: 931, t: 0.0113s scanners: attach: 1.1.0 clamav: 0.87.1/m:35/d:1234 Received: from host1900.igd.fhg.de (HELO weevee.igd.fhg.de) (carsten@zeitform.de@146.140.8.108) by rosencrantz.zeitform.de with ESMTPA; 6 Jan 2006 16:44:31 -0000 From: "Carsten \"CC\" Wald" Organization: betaversion.net To: freebsd-stable@freebsd.org Date: Fri, 6 Jan 2006 16:43:15 +0000 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601061643.15259.carsten@betaversion.net> Subject: ucom.ko and palm pilot m500 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 16:44:36 -0000 Hello List, I own an old palm pilot -- a m500 model -- and have the following problem when I try to sync under 6-STABLE. Whenever I pressed the HotSync-Button of that device -- connected to my 6-STABLE box via a USB cable, the pilot was recognized as a ugen0 device. Using the pilot-xfer program then failed. After some investigation on pilot-link.org I learned, that Palm devices work with FreeBSD over USB only with the ucom driver (while for those of Handspring, the generic ugen driver is sufficient). -- Well, I made sure, that ucom.ko was loaded, but the device was still detected by the ugen.ko-module instead. Even after unloading the generic driver, the ucom driver still wasn't able to detect the palm pilot. Just a few minutes ago, I cvsuped the kernel sources and rebuilt and installed the kernel along with the modules (and rebooted), but it still doesn't work. Am I the only one with that problem (and such an old pilot)? -- I have searched the FreeBSD documentation, pilot-link docu, etc.. but didn't find anything. Is it possible to somehow force the ucom driver to "accept" the pilot, or give him some hints? Thanks in advance. -- bye Carsten From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 17:14:15 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF66C16A41F for ; Fri, 6 Jan 2006 17:14:15 +0000 (GMT) (envelope-from ptroot@iaces.com) Received: from iaces.com (horton.iaces.com [204.147.87.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CC5D43D45 for ; Fri, 6 Jan 2006 17:14:14 +0000 (GMT) (envelope-from ptroot@iaces.com) Received: from [204.147.87.125] (borg.iaces.com [204.147.87.125]) (authenticated bits=0) by iaces.com (8.13.4/8.13.3) with ESMTP id k06HE8xC046344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jan 2006 11:14:09 -0600 (CST) (envelope-from ptroot@iaces.com) Message-ID: <43BEA59D.3060206@iaces.com> Date: Fri, 06 Jan 2006 11:15:09 -0600 From: "Paul T. Root" User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Richard Kuhns References: <43BD90E9.3020305@wintek.com> In-Reply-To: <43BD90E9.3020305@wintek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: gdm problem with kernel as of 2005-01-04 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 17:14:15 -0000 I'm in at work and turned off gdm in my rc.conf and rebooted. The keyboard works fine! Then manually starting gdm and it still works. That's great. I think that something happened in the rc files that makes it start earlier and that's conflicting with something that freezes the keyboard. Richard Kuhns wrote: > I just finished a buildworld/buildkernel/mergemaster on my Dell Inspiron > 9300. Upon rebooting, I noticed that gdm seemed to start earlier in the > boot process than it used to. When the login screen appeared, the mouse > seemed to work fine, but nothing I typed appeared. Attempting to use > C-A-F1 to switch to vty0 just beeped. C-A-Del worked to reboot the > laptop. I booted single user, commented out gdm_enable="YES" in > /etc/rc.conf, and rebooted -- everything was fine. I put the gdm_enable > back and ran /usr/X11R6/etc/rc.d/gdm.sh start -- gdm started, fully > functional. > > I rebooted again -- gdm ignored the keyboard. > > After several reboots, I've found that gdm seems to work fine as long as > I don't have 'gdm_enable="YES"' in /etc/rc.conf when the machine boots. > > I've just finished upgrading gdm (using portmanager); still the same > problem. > > If anyone has suggestions/wants me to try anything, just say so. > > Thanks! > - Rich -- ______ Paul T. Root / _ \ 1977 MGB / /|| \\ ||\/ || _ | || || || \ ||__// \______/ From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 17:20:06 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00CE216A41F for ; Fri, 6 Jan 2006 17:20:06 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from crivens.unixoid.de (crivens.unixoid.de [81.169.171.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7947243D46 for ; Fri, 6 Jan 2006 17:20:05 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from localhost (localhost [127.0.0.1]) by crivens.unixoid.de (Postfix) with ESMTP id 0B8F441BD; Fri, 6 Jan 2006 18:20:03 +0100 (CET) Received: from crivens.unixoid.de ([127.0.0.1]) by localhost (crivens.unixoid.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11077-20; Fri, 6 Jan 2006 18:19:59 +0100 (CET) Received: from [10.38.0.120] (unknown [213.238.63.253]) by crivens.unixoid.de (Postfix) with ESMTP id 2C58D3F7E; Fri, 6 Jan 2006 18:19:59 +0100 (CET) Message-ID: <43BEA7C5.9040206@kernel32.de> Date: Fri, 06 Jan 2006 18:24:21 +0100 From: Marian Hettwer User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rhempel@bmts.com References: <20060106135717.GA20651@llama.fishballoon.org> <43BE8304.2010709@kernel32.de> <43BE98F3.3000507@bmts.com> <43BE9BB6.2000002@kernel32.de> <43BE9C99.5050201@bmts.com> In-Reply-To: <43BE9C99.5050201@bmts.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at unixoid.de Cc: freebsd-stable Subject: Re: 6.0 on Dell 1850 with DRAC4 management card? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 17:20:06 -0000 Hej there, Ralph Hempel wrote: > Yes, you get that too. Full hardware power down. Wait as long as > you want, then power the machine up. It's not the same as a remote > reboot where you HOPE the server comes up far enough to get > a console session. > Well, if the BIOS can do console redirection, the server will come up far enough ;) If I don't see a BIOS screen, although console redirection is enabled, there's something really really wrong... > Plus you don't need anything mote than an Ethernet connection to > your existing infrastructure to make it all work. > same counts for a console server (say 48 ports, 1 U) and all servers connected to it. One IP adress, ethernet... > If you are paranoid and/or have a lot of servers, you can > put all the DRAC ports on a separate subnet and their own > VPN... > I would do that anyway... IMO an out-of-band network belongs into its own subnet (vlan) and you want to secure it in some way for remote access (ssh only, VPN, whatever) Marian From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 17:23:56 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55D5716A41F for ; Fri, 6 Jan 2006 17:23:56 +0000 (GMT) (envelope-from skv1040@post.cz) Received: from mail.mikroservis.cz (mail.mikroservis.cz [213.180.44.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87B5743D45 for ; Fri, 6 Jan 2006 17:23:55 +0000 (GMT) (envelope-from skv1040@post.cz) Received: from localhost (mail.mikroservis.cz [127.0.0.1]) by mail.mikroservis.cz (8.13.4/8.13.4) with ESMTP id k06HNsku021997 for ; Fri, 6 Jan 2006 18:23:54 +0100 Received: from mail.mikroservis.cz ([127.0.0.1]) by localhost (mail.mikroservis.cz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21545-18 for ; Fri, 6 Jan 2006 18:23:52 +0100 (CET) Received: from [127.0.0.1] ([82.150.183.249]) by mail.mikroservis.cz (8.13.4/8.13.4) with ESMTP id k06HNltG021992 for ; Fri, 6 Jan 2006 18:23:47 +0100 Message-ID: <43BEA873.2030408@post.cz> Date: Fri, 06 Jan 2006 18:27:15 +0100 From: skv1040 User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0601-3, 06.01.2006), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: amavisd-new 2.3.2 (20050629) at mikroservis.cz Subject: nsswitch - pflog problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 17:23:56 -0000 Hi, I have a little (I hope) problem with my FreeBSD 6-STABLE. I had pf+pflog working fine... I added nss_ldap, pam_ldap etc. Everything worked fine, until reboot. I noticed strange message: pflogd[244]: NSSWITCH(nss_method_lookup): ldap, passwd, endpwent, not found Nevertheless everything works. After some experiments I discovered the message being triggered by /etc/nsswitch.conf: when I change "passwd: files" to "passwd: files ldap" message appears. Thanks in advance Tim From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 17:24:50 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68E4916A41F for ; Fri, 6 Jan 2006 17:24:50 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC04743D5C for ; Fri, 6 Jan 2006 17:24:49 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id k06HObxn018094; Fri, 6 Jan 2006 09:24:42 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200601061724.k06HObxn018094@gw.catspoiler.org> Date: Fri, 6 Jan 2006 09:24:37 -0800 (PST) From: Don Lewis To: lars+lister.freebsd@adventuras.no In-Reply-To: <50410.80.111.250.79.1136231832.squirrel@mail.adventuras.no> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org Subject: Re: Swapfile problem in 6? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 17:24:50 -0000 On 2 Jan, Lars Kristiansen wrote: >> Attempting to catch up with my backlog of unread email, only 12K unread >> messages to go ... >> >> On 24 Nov, Rob wrote: >> >>> I have cvsup'ed the sources to STABLE as of Nov. 23rd >>> 2005. >>> After recompiling/installing world and debug-kernel, >>> I again get a kernel deadlock when using swapfile: >>> http://surfion.snu.ac.kr/~lahaye/swapfile2.txt >>> >>> Previous deadlocks are still documented here >>> http://surfion.snu.ac.kr/~lahaye/swapfile.txt >>> >>> I hope this is of use for fixing this bug in 6. >>> If further investigation is needed, then please let me >>> know. >> >> This is a deadlock caused by memory exhaustion. The pagedaemon only has >> a limited number of bufs that it uses for writing dirty pages to swap to >> prevent it from saturating the I/O subsystem with large numbers of >> writes. In this case, pagedaemon is trying to free up memory by writing >> dirty pages, and it has used up all of its bufs and is waiting for the >> write requests to complete and the bufs the bufs to be returned to it. >> This isn't happening because md0 is stuck waiting for memory. This is a >> little bit suprising to me because it looks like writes to vnode backed >> devices are done synchronously by default. >> >> If you have a chance to test this again, a stack trace of md0 in the >> deadlock state would be interesting. I'd like to know where md0 is >> getting stuck. >> >> I wonder if pagedaemon should scan ahead and more agressively discard >> clean pages when it has run out of bufs to write dirty pages, especially >> in low memory situations. Preventing the creation of more dirty pages >> would be nice, but I don't know how to do that ... > > Just in case it can help. Do not have this machine available for testing > at the moment but this is the last debuginfo I did get from it. > Here is a trace from a situation when a possible idle system got stuck > during the night and db showed only one locked vnode: > > db> show lockedvnods > Locked vnodes > > 0xc1309330: tag ufs, type VREG > usecount 1, writecount 1, refcount 154 mountedhere 0 > flags () > v_object 0xc12cb39c ref 0 pages 606 > lock type ufs: EXCL (count 1) by thread 0xc126b900 (pid 178) > ino 8155, on dev ad0s1f > db> trace 178 > Tracing pid 178 tid 100058 td 0xc126b900 > sched_switch(c126b900,0,1) at 0xc066a4db = sched_switch+0x17b > mi_switch(1,0) at 0xc065f49e = mi_switch+0x27e > sleepq_switch(c09b2a98,c484bacc,c065f0e3,c09b2a98,0) at 0xc0677f00 = > sleepq_switch+0xe0 > sleepq_wait(c09b2a98,0,0,c08ad92d,37b) at 0xc0678100 = sleepq_wait+0x30 > msleep(c09b2a98,c09b2d00,244,c08adb6a,0) at 0xc065f0e3 = msleep+0x333 > vm_wait(c12cb39c,0,c08990f3,ad7,c06512a4) at 0xc07c6a71 = vm_wait+0x91 > allocbuf(c28fa9d8,4000,354000,0,354000) at 0xc06a2f89 = allocbuf+0x4e9 > getblk(c1309330,d5,0,4000,0) at 0xc06a29cb = getblk+0x4eb > cluster_read(c1309330,10000000,0,d5,0) at 0xc06a5d65 = cluster_read+0xe5 > ffs_read(c484bc9c) at 0xc07a631f = ffs_read+0x28f > VOP_READ_APV(c09309a0,c484bc9c) at 0xc0838aab = VOP_READ_APV+0x7b > mdstart_vnode(c1310800,c1634294,c1310820,1,c0566e10) at 0xc056688c = > mdstart_vnode+0xec > md_kthread(c1310800,c484bd38,c1310800,c0566e10,0) at 0xc0566f7f = > md_kthread+0x16f > fork_exit(c0566e10,c1310800,c484bd38) at 0xc0645618 = fork_exit+0xa8 > fork_trampoline() at 0xc0816f3c = fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xc484bd6c, ebp = 0 --- The md thread is stuck waiting for memory to be freed by pagedaemon. Pagedaemon is stuck waiting for at least one of its pageout requests to complete. The pageout requests are probably all stuck waiting for md. I had expected that the problem is that while pagedaemon is allowed to dig deeper into the free page pool, I didn't think that the md thread would be allowed to, allowing the md thread to get wedged first. That does not appear to be the case because the vm_page_alloc() call in allocbuf() has the VM_ALLOC_SYSTEM flag set, which should match vm_page_alloc()'s treatment of requests by pagedaemon. I don't see how the md thread could be consuming a large number of reserved pages, but it looks like that must be what is happening. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 17:35:06 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFCA616A41F for ; Fri, 6 Jan 2006 17:35:06 +0000 (GMT) (envelope-from dsze@mail.distrust.net) Received: from mail.distrust.net (mail.distrust.net [69.93.230.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D02443D46 for ; Fri, 6 Jan 2006 17:35:06 +0000 (GMT) (envelope-from dsze@mail.distrust.net) Received: from mail.distrust.net (localhost [127.0.0.1]) by mail.distrust.net (8.13.3/8.13.3) with ESMTP id k06HZ0Pb007601; Fri, 6 Jan 2006 11:35:00 -0600 (CST) (envelope-from dsze@mail.distrust.net) Received: (from dsze@localhost) by mail.distrust.net (8.13.3/8.13.3/Submit) id k06HYxON007600; Fri, 6 Jan 2006 11:34:59 -0600 (CST) (envelope-from dsze) Date: Fri, 6 Jan 2006 11:34:59 -0600 From: David Sze To: Marian Hettwer Message-ID: <20060106173459.GA6765@mail.distrust.net> References: <20060106135717.GA20651@llama.fishballoon.org> <43BE8304.2010709@kernel32.de> <43BE98F3.3000507@bmts.com> <43BE9BB6.2000002@kernel32.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43BE9BB6.2000002@kernel32.de> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.87.1/1234/Fri Jan 6 07:54:31 2006 on mail.distrust.net X-Virus-Status: Clean Cc: freebsd-stable , rhempel@bmts.com Subject: Re: 6.0 on Dell 1850 with DRAC4 management card? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 17:35:06 -0000 On Fri, Jan 06, 2006 at 05:32:54PM +0100, Marian Hettwer wrote: > > The only thing missing would be hardware power down. if that can be done > via DRAC, that'll be an advantage :) One big advantage of the DRAC is virtual media (floppy, CD) support. Good for BIOS/firmware upgrades, booting a rescue/repair CD, or even reinstalling the OS. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 17:51:18 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D526116A41F for ; Fri, 6 Jan 2006 17:51:18 +0000 (GMT) (envelope-from gkozyrev@ukr.net) Received: from computer.ukrsat.com (computer.ukrsat.com [212.35.160.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A85343D46 for ; Fri, 6 Jan 2006 17:51:17 +0000 (GMT) (envelope-from gkozyrev@ukr.net) Received: from gleb.kozyrev.name (juli.slnet.kiev.ua [195.49.149.86]) by computer.ukrsat.com (8.12.8/8.12.8) with SMTP id k06HaFHs021866; Fri, 6 Jan 2006 19:36:18 +0200 Received: from Gleb ([127.0.0.1]) by Gleb (192.168.48.1) with smtp ; Fri, 06 Jan 2006 19:51:07 +0200 Message-ID: <000501c612e9$c57b2620$0130a8c0@Gleb> From: "Gleb Kozyrev" To: "Carsten \"CC\" Wald" , References: <200601061643.15259.carsten@betaversion.net> Date: Fri, 6 Jan 2006 19:51:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16 Cc: Subject: Re: ucom.ko and palm pilot m500 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 17:51:18 -0000 Carsten "CC" Wald wrote to on Fri, 6 Jan 2006 16:43:15 +0000: CCW> I own an old palm pilot -- a m500 model -- and have the following CCW> problem when I try to sync under 6-STABLE. CCW> Whenever I pressed the HotSync-Button of that device -- connected to my CCW> 6-STABLE box via a USB cable, the pilot was recognized as a ugen0 CCW> device. man uvisor -- With best regards, Gleb Kozyrev. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 18:27:25 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDBA516A41F for ; Fri, 6 Jan 2006 18:27:25 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 481CB43D45 for ; Fri, 6 Jan 2006 18:27:25 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 98E925DDA; Fri, 6 Jan 2006 13:27:24 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31787-02; Fri, 6 Jan 2006 13:27:22 -0500 (EST) Received: from [192.168.1.3] (pool-68-161-122-227.ny325.east.verizon.net [68.161.122.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id CC3135C56; Fri, 6 Jan 2006 13:27:21 -0500 (EST) Message-ID: <43BEB693.3060805@mac.com> Date: Fri, 06 Jan 2006 13:27:31 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vivek Khera References: <6CADC5BD-FBF5-472E-8087-8494AD03549C@khera.org> <43BDED2E.7090803@mac.com> <701B6D67-507A-4361-8875-2D5527729E86@khera.org> In-Reply-To: <701B6D67-507A-4361-8875-2D5527729E86@khera.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-stable Subject: Re: SCSI RAID card recommendation (1/2 height PCI-X U320 SCSI dual channel) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 18:27:25 -0000 Vivek Khera wrote: > On Jan 5, 2006, at 11:08 PM, Chuck Swiger wrote: >> There's an interesting thread about the AMR RAID controller used in >> the newer 18x0/28x0 Dells with the PERC/4 controller, and I know of >> enough people using them that such improvements (by Doug Ambrisko?) >> will be welcomed. > > Thanks for your note. Turns out I have more than one Dell system with > aac controllers in them :-) They seem to be OK, although I like the AMR's a little better. I had to update the RAID BIOS on the PE 2650 before auto-rebuild of a broken mirror would work right using the aac controller. (It's either rackrounted Dells or HP 370/380 Proliants for me, depending upon the specific client in question.) > One happens to be a PE 1750 with the PERC 3/Di in it running RAID1. It > is lightly loaded but is sufficient for that server's needs, but is > running FreeBSD 4.11 on it. > > Is there a way to backport this diskinfo utility to 4.x or 5.x? Looks > most useful! On my 6.0 box with a PERC 3/Si card (aac driver too) it > is showing seek times slower than yours but transfer rates faster. diskinfo runs on 5.x, at least. I'm not sure about 4.x; I think some of the underlying infrastructure which smarttools also depends upon wasn't available until 5.x... -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 18:53:32 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C2D116A41F for ; Fri, 6 Jan 2006 18:53:32 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id E81A443D46 for ; Fri, 6 Jan 2006 18:53:31 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 3B503B864 for ; Fri, 6 Jan 2006 13:53:31 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43BDD444.80509@roq.com> References: <20060105224150.GA991@tuatara.fishballoon.org> <43BDD444.80509@roq.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Vivek Khera Date: Fri, 6 Jan 2006 13:53:30 -0500 To: freebsd-stable X-Mailer: Apple Mail (2.746.2) Subject: Re: 6.0 on Dell 1850 with PERC4e/DC RAID? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 18:53:32 -0000 On Jan 5, 2006, at 9:21 PM, Michael Vince wrote: > Items 3 and 4 significantly increase the performance of the =20 > driver. On an > LSI 320-2X card, transactions per second went from 13,000 to =20 > 31,000 in my > testing with these changes. However, these changes are still fairly > experimental and shouldn't be merged to 6.x until there is more =20 > testing. > Thanks to Doug Ambrosko, LSI, Dell, and Yahoo for contributing =20 > towards > this. Damn that's awesome! Thanks to all who helped with this... This =20 will be great for some of my servers. Now, does anyone have any numbers to compare this with other RAID =20 cards? Particularly the 2230SLP? :-) =05/me wishes LSI maid low profile dual channel cards... From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 18:57:51 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD0C716A41F for ; Fri, 6 Jan 2006 18:57:51 +0000 (GMT) (envelope-from carsten@betaversion.net) Received: from rosencrantz.zeitform.de (rosencrantz.zeitform.de [146.140.212.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AD0D43D46 for ; Fri, 6 Jan 2006 18:57:50 +0000 (GMT) (envelope-from carsten@betaversion.net) Received: (qmail 10508 invoked by uid 89); 6 Jan 2006 18:57:48 -0000 Received: by simscan 1.1.0 ppid: 10502, pid: 10504, t: 0.0109s scanners: attach: 1.1.0 clamav: 0.87.1/m:35/d:1234 Received: from host1900.igd.fhg.de (HELO weevee.igd.fhg.de) (carsten@zeitform.de@146.140.8.108) by rosencrantz.zeitform.de with ESMTPA; 6 Jan 2006 18:57:48 -0000 From: Carsten Wald Organization: betaversion.net To: freebsd-stable@freebsd.org Date: Fri, 6 Jan 2006 18:56:32 +0000 User-Agent: KMail/1.8.2 References: <200601061643.15259.carsten@betaversion.net> <000501c612e9$c57b2620$0130a8c0@Gleb> In-Reply-To: <000501c612e9$c57b2620$0130a8c0@Gleb> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601061856.32626.carsten@betaversion.net> Subject: Re: ucom.ko and palm pilot m500 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 18:57:51 -0000 On Friday 06 January 2006 17:51, Gleb Kozyrev wrote: > man uvisor Great! Thank you. That's what I needed! -- uvisor.ko apparently uses ucom.ko and the ucom0 device I looked for is (temporarily) created. However, after pressing the sync button the pilot can then be accessed through the /dev/ttyU0 device. Since I didn't find this information at kpilot.org or pilot-link.org or whatsoever (although they oftern refer to FreeBSD) and somebody else might have the same problem ... here is what I did: 1. Load the proper kernel modules. Among others this is uvisor.ko. $ kldload /boot/kernel/uvisor.ko (In addition, I configured this in /boot/loader.conf) 2. Configure /etc/usbd.conf in such a way, that the permissions of the proper device will be set when it appears after pressing the HotSync button. This is /dev/ttyU0 in my case. I just synced as a normal user and it works. -- bye Carsten From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 19:00:07 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D08C16A420 for ; Fri, 6 Jan 2006 19:00:07 +0000 (GMT) (envelope-from olivier.boudeville@online.fr) Received: from Smtp.neuf.fr (sp604001mt.neufgp.fr [84.96.92.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C7DF43D46 for ; Fri, 6 Jan 2006 19:00:06 +0000 (GMT) (envelope-from olivier.boudeville@online.fr) Received: from [192.168.0.5] ([81.185.33.106]) by sp604001mt.gpm.neuf.ld (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0ISO005DZPX7J9F0@sp604001mt.gpm.neuf.ld> for freebsd-stable@freebsd.org; Fri, 06 Jan 2006 19:55:56 +0100 (CET) Date: Fri, 06 Jan 2006 19:55:10 +0100 From: Olivier Boudeville To: freebsd-stable@freebsd.org Message-id: <43BEBD0E.4030103@online.fr> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051110) Subject: 6.0 hangs at boot on Toshiba laptop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 19:00:07 -0000 Hi everybody, I tried to install on my laptop (Toshiba M60-176) FreeBSD 6.0 STABLE and it failed despite careful installation and web/archives search. It is a multiboot installation (Windows XP/Linux Ubuntu/FreeBSD) driven by GRUB 4.95. After the whole installation process ended, the reboot is performed and the bootstrap goes until the FreeBSD menu is displayed. Whatever the chosen option (default, without ACPI, fail-safe, verbose, etc.) the system hangs immediately. For example with the first choice, we have : /boot/kernel/acpi.ko/boot/kernel/acpi.ko text=0x40c2c data=0x2160+0x1090 [..] and everything stops. The situation is explained very clearly here : http://marc.theaimsgroup.com/?l=freebsd-mobile&m=113177565322135&w=2 I do not think it is related to GRUB (the real boot has started, this version allows for UFS2 access, various GRUB settings have been tried, unsucessfully) nor to ACPI since even when disabled, thanks to the relevant menu option, the boot hangs as well (same behaviour, without the ACPI module line being displayed). I cannot disable Legacy USB in my BIOS, if ever it was a common workaround. If it can help, I detailed my full installation process here : http://osdl.sourceforge.net/OSDL/OSDL-0.3/src/doc/web/main/documentation/misc/Toshiba.html#freebsd (by the way, there seems to be a bug when aborting/restarting under sysinstall : apparently in some cases it tries to install FreeBSD on the ramdisk instead of the requested slice). Thanks in advance for any hint, kind regards, Olivier. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 19:11:08 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F92016A41F for ; Fri, 6 Jan 2006 19:11:08 +0000 (GMT) (envelope-from paul.lkw@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CA3B43D48 for ; Fri, 6 Jan 2006 19:11:07 +0000 (GMT) (envelope-from paul.lkw@gmail.com) Received: by wproxy.gmail.com with SMTP id i20so3168867wra for ; Fri, 06 Jan 2006 11:11:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=nhIVgcsUygiBtcD0oBquiv3Jp/ADPmkxi9X4mI4Attv3o2qSRmChEfY/7zHuoztFHjBUiGe58tgK9tTE9I+Whsf//RkUU2fBUQPQfDp8eddS9WS1qZEOzowFRexN0fJ2GeMUuMizsLKIbSTx2n2PPzIx5u8cEt1ID8OU2qi9GqM= Received: by 10.65.115.10 with SMTP id s10mr1978722qbm; Fri, 06 Jan 2006 11:11:06 -0800 (PST) Received: by 10.65.114.7 with HTTP; Fri, 6 Jan 2006 11:11:06 -0800 (PST) Message-ID: Date: Sat, 7 Jan 2006 03:11:06 +0800 From: "Paul.LKW" To: freebsd-stable@freebsd.org MIME-Version: 1.0 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 Subject: asr-util Not work after upgrade to 5.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 19:11:08 -0000 Dear all: As I upgraded to 5.4 I found the raid utilities 'asr-util' no longer work for me. I tried to deinstall and install again, but the problem still ! The error message in the console after the comman 'raidutil -L raid' is : Engine connect failed: COMPATILITY number Any one know now to solve it. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 19:36:40 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B203316A41F for ; Fri, 6 Jan 2006 19:36:40 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id D21DD43D46 for ; Fri, 6 Jan 2006 19:36:39 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id k06Jg0Ua075821 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 6 Jan 2006 14:42:06 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Carsten Wald (betaversion.net) Date: Fri, 6 Jan 2006 14:38:45 -0500 User-Agent: KMail/1.8.3 References: <200601061643.15259.carsten@betaversion.net> <000501c612e9$c57b2620$0130a8c0@Gleb> <200601061856.32626.carsten@betaversion.net> In-Reply-To: <200601061856.32626.carsten@betaversion.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12937380.AJ3OZjyBsB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601061438.53125.mistry.7@osu.edu> X-Spam-Status: No, score=-3.8 required=5.0 tests=ALL_TRUSTED,BAYES_40, J_CHICKENPOX_42,J_CHICKENPOX_62,MYFREEBSD3 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.87/1234/Fri Jan 6 08:54:31 2006 on mail.united-ware.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: ucom.ko and palm pilot m500 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 19:36:40 -0000 --nextPart12937380.AJ3OZjyBsB Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 06 January 2006 01:56 pm, Carsten Wald wrote: > On Friday 06 January 2006 17:51, Gleb Kozyrev wrote: > > man uvisor > > Great! Thank you. That's what I needed! -- uvisor.ko apparently > uses ucom.ko and the ucom0 device I looked for is (temporarily) > created. However, after pressing the sync button the pilot can > then be accessed through the /dev/ttyU0 device. > > Since I didn't find this information at kpilot.org or > pilot-link.org or whatsoever (although they oftern refer to > FreeBSD) and somebody else might have the same problem ... here is > what I did: > > 1. Load the proper kernel modules. Among others this is uvisor.ko. > > $ kldload /boot/kernel/uvisor.ko > > (In addition, I configured this in /boot/loader.conf) > > 2. Configure /etc/usbd.conf in such a way, that the permissions of > the proper device will be set when it appears after pressing the > HotSync button. This is /dev/ttyU0 in my case. > > I just synced as a normal user and it works. You shouldn't be using usbd/usbd.conf as it is going away (It's=20 already gone in CURRENT). You should configure it using=20 devd/devd.conf instead. =2D-=20 Anish Mistry --nextPart12937380.AJ3OZjyBsB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDvsdNxqA5ziudZT0RAnZ8AJ9DC34pVZxN7bx1KbFwmjguDFlnVQCfYfbJ LeFNwYJqXIJduf4c1TZMUqQ= =Gd5Z -----END PGP SIGNATURE----- --nextPart12937380.AJ3OZjyBsB-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 19:44:45 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4140816A41F; Fri, 6 Jan 2006 19:44:45 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32C6043D48; Fri, 6 Jan 2006 19:44:43 +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 mail01.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k06Jib48032747 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 7 Jan 2006 06:44:37 +1100 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 k06JiaHh055435; Sat, 7 Jan 2006 06:44:36 +1100 (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 k06Jia2n055434; Sat, 7 Jan 2006 06:44:36 +1100 (EST) (envelope-from pjeremy) Date: Sat, 7 Jan 2006 06:44:36 +1100 From: Peter Jeremy To: freebsd-stable@freebsd.org, current Message-ID: <20060106194436.GD51452@cirb503493.alcatel.com.au> References: <43A266E5.3080103@samsco.org> <43AB1E65.2030501@mac.com> <20051222221202.GM39174@svcolo.com> <200512231136.12471.doconnor@gsoft.com.au> <20060105092448.GH1358@svcolo.com> <20060105184147.GD69162@funkthat.com> <20060106110318.GF54324@svcolo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060106110318.GF54324@svcolo.com> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 19:44:45 -0000 On Fri, 2006-Jan-06 03:03:18 -0800, Jo Rhett wrote: >> Bottom line: Once code exists, then support can be talked about.. > >This is bullhockey and you know it. Once the project is done, we'll >authorize a budget for it? Once the season is over we'll know who should >be on the starting team? In general, volunteer projects have a surfeit of ideas and a shortage of real implementations. The Project is never going to agree to import an idea without some substance. > Yeah, hindsight is sweet. But this isn't a >simple change. It will require very close integration with the installation >and kernel modules at least (and probably more). So having some sort of >consensus that (a) the project has interest and (b) what flavors would be >acceptable to the existing groups - are both necessary for this project to >even mumble it's first line of code. In which case you need to move this thread to freebsd-arch where these sort of issues are discussed. You need to clearly define your goals and suggest a design to meet them. If your idea has merit, you'll be able to convince at least one committer to work with you to implement your design. -- Peter Jeremy From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 20:31:23 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74ACA16A41F; Fri, 6 Jan 2006 20:31:23 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail24.syd.optusnet.com.au (mail24.syd.optusnet.com.au [211.29.133.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id B98BB43D46; Fri, 6 Jan 2006 20:31:22 +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 mail24.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k06KVKCQ001186 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 7 Jan 2006 07:31:21 +1100 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 k06KVKHh055483; Sat, 7 Jan 2006 07:31:20 +1100 (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 k06KVKvY055482; Sat, 7 Jan 2006 07:31:20 +1100 (EST) (envelope-from pjeremy) Date: Sat, 7 Jan 2006 07:31:20 +1100 From: Peter Jeremy To: freebsd-stable@freebsd.org, current Message-ID: <20060106203120.GE51452@cirb503493.alcatel.com.au> References: <20060105093220.GJ1358@svcolo.com> <200601050947.k059lctk024288@hugo10.ka.punkt.de> <20060106103440.GB54324@svcolo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060106103440.GB54324@svcolo.com> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 20:31:23 -0000 On Fri, 2006-Jan-06 02:34:40 -0800, Jo Rhett wrote: >On Thu, Jan 05, 2006 at 10:47:38AM +0100, Patrick M. Hausen wrote: >> While I agree with much of your reasoning, I know exactly zero >> people running a modified kernel of any version of Windows, >> Mac OS X or Solaris, to name just three commercial OS's. > >You're tickling a different subject here. All three of these operating >systems have loadable kernel modules that work. As does FreeBSD. > I mean, they dynamically >load the modules they need, and you can disable kernel modules in >configuration files. FreeBSD has loadable kernel modules, but they don't >autoload (you have to modify rc files) This isn't quite true. FreeBSD does not currently have the tools to automatically load kernel modules for most hardware device drivers and they need to either be built into the kernel or specified in loader.conf. Writing a tool to do this automatically would be fairly simple - either use pciconf(8) and a database of PCI ID to driver mappings or (as Solaris and X do) load every module and see if it can attach to anything, unload it if it can't. To date, no-one has been sufficiently motivated to do so. FreeBSD will autoload kernel modules for many software functions if their functionality is required (NFS, SysV IPC, firewalls). In some cases this is automatic (NFS client loads automatically if NFS filesystems are found). In other cases, (eg firewalls) you need to configure the functionality anyway. > and you can't trim down the kernel >to minimize unused memory without recompiling. In the absence of tools to automatically detect your configuration and load the appropriate modules, GENERIC includes a fairly standard set of drivers that also exist as modules. GENERIC probably could be cut down somewhat but this isn't the forum to discuss that. >To give you a specific example: if we could remove NFS and the 3ware >driver from the kernel in a configuration file, we could probably run >GENERIC. IMHO, NFS server could be removed without problems (it will autoload), as could tw{a,e} (which are loadable). NFS client can't be removed because it has to be built in to support diskless operation. >hog we have to remove on small footprint systems FreeBSD has never claimed to optimally support small footprint systems without customisation. There are too many variables and some kernel functionality can't be readily converted to modules (eg IPv6 support). In any case, the way to minimise the kernel footprint is to statically load all the required functionality and not have any modules. -- Peter Jeremy From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 21:16:46 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F1AF16A420; Fri, 6 Jan 2006 21:16:46 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id D96F243D48; Fri, 6 Jan 2006 21:16:45 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id k06LGb9h003864; Fri, 6 Jan 2006 13:16:37 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id k06LGa4a003863; Fri, 6 Jan 2006 13:16:36 -0800 (PST) (envelope-from jmg) Date: Fri, 6 Jan 2006 13:16:36 -0800 From: John-Mark Gurney To: "Daniel O'Connor" , freebsd-stable@freebsd.org, Chuck Swiger , current Message-ID: <20060106211636.GF69162@funkthat.com> Mail-Followup-To: Daniel O'Connor , freebsd-stable@freebsd.org, Chuck Swiger , current References: <43A266E5.3080103@samsco.org> <43AB1E65.2030501@mac.com> <20051222221202.GM39174@svcolo.com> <200512231136.12471.doconnor@gsoft.com.au> <20060105092448.GH1358@svcolo.com> <20060105184147.GD69162@funkthat.com> <20060106110318.GF54324@svcolo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060106110318.GF54324@svcolo.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 21:16:46 -0000 Jo Rhett wrote this message on Fri, Jan 06, 2006 at 03:03 -0800: > On Thu, Jan 05, 2006 at 10:41:47AM -0800, John-Mark Gurney wrote: > > I believe core has a policy of never supporting vaporware... There is > > always the chicken and egg problem with arguments like this... I'll > > code this if you agree to support it and maintain it/I will agree to > > support it once you code it... In FreeBSD, and many open source > > projects, no code, no support, how can you support or even agree to > > support something that doesn't exist? And then as soon as FreeBSD > > agrees to support something that doesn't exist, either a) other people who > > were interested in the project stop, even if you end up never producing > > a bit of code, or b) someone else produces better code, drops the > > support for the original, but then the author complains about being > > told they'd support his code, and going with another code base... > > > > Bottom line: Once code exists, then support can be talked about.. > > This is the chicken and egg problem that will kill FreeBSD. I don't And many other open source software projects... FreeBSD isn't unique in this.. I've submitted patches to many other projects just to have them ignored for years too... It's a problem of voluteer orginizations.. > bother writing up patches for FreeBSD because every time I do they sit in a > PR and get ignored for several years. Then someone that does have commit > rights makes their own patch (which often is less useful) but they own it > and the best I've ever succeeded at was convincing them to put some of the > ideas from my patch into their code. > > Note that none of these patches were ever rejected for any technical or > political or any other reason. They just don't get paid attention to. > > Thus, I try to get consensus that the idea has merit. IF freebsd > committers can be bothered to pay attention to the idea, I'll write code > for it. But I'm too old and tired to spend another week writing up > something that will get ignored for X years and then dropped for obsoletion > again. You're trying to target to large of an audience... You need to get _A_ committer interested in your work, and get HIM to guide you and commit your work... > AND there are a lot of opinions and politics around how to version the core > that have nothing to do with code. There's no value in writing code that > will be ignored because it doesn't agree with -core's view of "should be". > I'm a coder, not a politician. If we can get consensus on what type of > implementation would be acceptable to core, then I and many others would be > happy to write code to implement this idea. But this is a considerable > amount of work that will be closely tied to the operation system > installation. It's not something that you can churn out 7 different > implementations of just to see which one fits the current polical > environment. stop talking about core... -core makes absolutely no technical decisions about how FreeBSD is.. it is the developers, and previously there was a technical review board for settling differences between developers that were pure "technical" in nature... And if you claim you didn't know this, then you better read the email you respond to more closely, since this has been pointed out to you numerous times.. and you said in another email: > First, this is obvious and true for all open source projects. But no, > FreeBSD _never_ advances because someone writes code that does something > well. FreeBSD _only_ advances when the core developers agree that this > thing is worthy of their interest. hmmm... you really are choosing to completely ignore what people have said about core, that at least you did add developers after core, which makes it appear less likely that you're talking about -core.. but lots of stuff gets done w/o core developers... I did lots of work on -sparc64, and I'm pretty sure you wouldn't call me a core developer.. and I also got TS-7200 arm support (though it hasn't been committed to cvs due to issues that I haven't resolved with device configuration)... As for the whole installation thing, you need to talk with re (release engineering) as they are the ones to really have final say in what installation and releases look like... > Back to your finale: > > > Bottom line: Once code exists, then support can be talked about.. > > This is bullhockey and you know it. Once the project is done, we'll > authorize a budget for it? Once the season is over we'll know who should FreeBSD isn't commercial, so you can't talk about budgets... And most orgs want some sort of prototypes and feasibility study done before they'll commit any budget to it... > be on the starting team? Yeah, hindsight is sweet. But this isn't a > simple change. It will require very close integration with the installation > and kernel modules at least (and probably more). So having some sort of > consensus that (a) the project has interest and (b) what flavors would be > acceptable to the existing groups - are both necessary for this project to > even mumble it's first line of code. Yeh, you can get a & b, but you can't get commitment to accept what comes out of a & b... Unless of course you can make the time between findout what a & b are and having code that implements a & b down to zero... None of this prevents you from getting a basic prototype that works, but isn't complete with bells and whistles.. Look at what Colin did with FreeBSD update, I didn't see him demanding anyone in FreeBSD to sign off on his work... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 22:03:28 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71CDC16A41F for ; Fri, 6 Jan 2006 22:03:28 +0000 (GMT) (envelope-from oystein@holmen.cc) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3B4D43D7D for ; Fri, 6 Jan 2006 22:03:25 +0000 (GMT) (envelope-from oystein@holmen.cc) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0ISO00H15YTZ2080@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Fri, 06 Jan 2006 23:08:23 +0100 (CET) Received: from [192.168.1.34] ([84.48.131.57]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0ISO000GHYQ1FE50@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Fri, 06 Jan 2006 23:06:01 +0100 (CET) Date: Fri, 06 Jan 2006 23:03:18 +0100 From: =?ISO-8859-1?Q?=D8ystein_Holmen?= To: freebsd-stable@freebsd.org Message-id: <5B4D3B12-8528-4D07-9B03-874D0A7A52B5@holmen.cc> MIME-version: 1.0 X-Mailer: Apple Mail (2.746.2) Content-type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Content-transfer-encoding: quoted-printable Subject: Motherboard X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 22:03:28 -0000 Hi all! I'm setting up a new server with FreeBSD 6.0. The motherboard I am =20 planning to use is Asus A8N-SLI Premium. Does anyone know if the on-=20 board ethernet controller (nve(4)) works? Also I'm planning on getting this graphics controller: Gainward =20 GeForce 6200 TurboCache, PCI-Express. Sincerely, =D8ystein Holmen= From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 22:18:42 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE5E616A41F for ; Fri, 6 Jan 2006 22:18:42 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A26143D45 for ; Fri, 6 Jan 2006 22:18:41 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id k06MIe8Z049222; Fri, 6 Jan 2006 23:18:40 +0100 (CET) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.3/8.12.9/Submit) id k06MIeBO049221; Fri, 6 Jan 2006 17:18:40 -0500 (EST) (envelope-from cracauer) Date: Fri, 6 Jan 2006 17:18:40 -0500 From: Martin Cracauer To: =?iso-8859-1?Q?=D8ystein_Holmen?= Message-ID: <20060106171840.A49126@cons.org> References: <5B4D3B12-8528-4D07-9B03-874D0A7A52B5@holmen.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <5B4D3B12-8528-4D07-9B03-874D0A7A52B5@holmen.cc>; from oystein@holmen.cc on Fri, Jan 06, 2006 at 11:03:18PM +0100 Cc: freebsd-stable@freebsd.org Subject: Re: Motherboard X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 22:18:42 -0000 Øystein Holmen wrote on Fri, Jan 06, 2006 at 11:03:18PM +0100: > Hi all! > > I'm setting up a new server with FreeBSD 6.0. The motherboard I am > planning to use is Asus A8N-SLI Premium. Does anyone know if the on- > board ethernet controller (nve(4)) works? Works for me with the newest 7-current commits, but losing carrier means temporary machine hang. The other GbE on the board works, too. Temperature monitoring is also functional. Be warned that this board even with the newest BIOS does not correctly do remapping of the physical memory between 3-4 GB to above 4 GB. > Also I'm planning on getting this graphics controller: Gainward > GeForce 6200 TurboCache, PCI-Express. Works for me, "nv" driver. No "nvidia" driver for FreeBSD/AMD64. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 23:39:08 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53ABE16A41F for ; Fri, 6 Jan 2006 23:39:08 +0000 (GMT) (envelope-from scott@fishballoon.org) Received: from mta09-winn.ispmail.ntl.com (mta09-winn.ispmail.ntl.com [81.103.221.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7309E43D46 for ; Fri, 6 Jan 2006 23:39:07 +0000 (GMT) (envelope-from scott@fishballoon.org) Received: from aamta10-winn.ispmail.ntl.com ([81.103.221.35]) by mta09-winn.ispmail.ntl.com with ESMTP id <20060106233906.YRHO8609.mta09-winn.ispmail.ntl.com@aamta10-winn.ispmail.ntl.com>; Fri, 6 Jan 2006 23:39:06 +0000 Received: from llama.fishballoon.org ([81.104.195.171]) by aamta10-winn.ispmail.ntl.com with ESMTP id <20060106233905.DADM24348.aamta10-winn.ispmail.ntl.com@llama.fishballoon.org>; Fri, 6 Jan 2006 23:39:05 +0000 Received: from tuatara.fishballoon.org ([192.168.1.6]) by llama.fishballoon.org with esmtp (Exim 4.52 (FreeBSD)) id 1Ev1Al-0000D7-Qi; Fri, 06 Jan 2006 23:39:03 +0000 Received: (from scott@localhost) by tuatara.fishballoon.org (8.13.4/8.13.4/Submit) id k06Ncvvj001663; Fri, 6 Jan 2006 23:38:57 GMT (envelope-from scott) Date: Fri, 6 Jan 2006 23:38:57 +0000 From: Scott Mitchell To: Vivek Khera Message-ID: <20060106233857.GA997@tuatara.fishballoon.org> References: <20060105224150.GA991@tuatara.fishballoon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-STABLE i386 Cc: freebsd-stable Subject: Re: 6.0 on Dell 1850 with PERC4e/DC RAID? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 23:39:08 -0000 On Fri, Jan 06, 2006 at 10:35:46AM -0500, Vivek Khera wrote: > > On Jan 5, 2006, at 5:41 PM, Scott Mitchell wrote: > > >I may be getting a new Dell PE1850 soon, to replace our ancient CVS > >server > >(still running 4-STABLE). The new machine will ideally run 6.0 and > >have a > >PERC4e/DC RAID card - the one with battery-backed cache. This is > >listed as > > I have an 1850 with the buil-in PERC 4e/Si since all I needed was the > RAID1 mirror of the internal drives. It works extremely well, and > the speed is quite good. We'll only be mirroring the internal drives too for now - the 4e/DC seems to be the only RAID option on the 1850 with battery-backed cache, and doesn't cost much more for the extra peace-of-mind. > As for notices of when the drives go bad, under 4.x I've had disk > failures with the amr driver (different PERC cards) and not gotten > any such notices in the syslog that I recall. That's a pity. Maybe Doug was thinking of one of the aac(4) based PERC cards? Still, something I can run out of cron to check the array status should be fine. > I did find a program > posted to one of the freebsd lists called 'amrstat' that I run > nightly. It produces this kind of output: > > Drive 0: 68.24 GB, RAID1 io> optimal > > If it says "degraded" it is time to fix a drive. You just fire up > the lsi megaraid tools and find out which drive it is. > > If you go to the LSI download area, they have one file for FreeBSD, > which is labeled the driver. In that zip file is also the management > software for freebsd. You'll want that. Personally, I like the > "MEGAMGR" software which was released for freebsd 4.x and mimics the > BIOS' interface in a terminal window. There's a port of the management software now: sysutils/megarc > The rebuild on LSI controllers is set to automatic on the dells as > default. It just works as expected. Cool. > Overall, I'm a big fan of the LSI cards and the amr driver... > > Unfortunately for me, the latest equipment I just got only takes low- > profile cards, and LSI doesn't offer a dual channel RAID card in low- > profile configuration... so I need to look at adaptec. This is on your x4100? Nice machine. We have a v20z with dual Opteron 270s that I totally love. Looking at getting an x4100 too... sadly these are product development machines so they'll be running RedHat and Solaris. Doesn't the x4100 have h/w RAID built in? Or does that not work with FreeBSD? Scott -- =========================================================================== Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" scott at fishballoon.org | 0xAA775B8B | -- Anon From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 23:48:52 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0402116A41F for ; Fri, 6 Jan 2006 23:48:52 +0000 (GMT) (envelope-from scott@fishballoon.org) Received: from mta08-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25E8F43D45 for ; Fri, 6 Jan 2006 23:48:50 +0000 (GMT) (envelope-from scott@fishballoon.org) Received: from aamta11-winn.ispmail.ntl.com ([81.103.221.35]) by mta08-winn.ispmail.ntl.com with ESMTP id <20060106234849.LRIY17804.mta08-winn.ispmail.ntl.com@aamta11-winn.ispmail.ntl.com>; Fri, 6 Jan 2006 23:48:49 +0000 Received: from llama.fishballoon.org ([81.104.195.171]) by aamta11-winn.ispmail.ntl.com with ESMTP id <20060106234849.DEYY19063.aamta11-winn.ispmail.ntl.com@llama.fishballoon.org>; Fri, 6 Jan 2006 23:48:49 +0000 Received: from tuatara.fishballoon.org ([192.168.1.6]) by llama.fishballoon.org with esmtp (Exim 4.52 (FreeBSD)) id 1Ev1KB-0000Dt-PF; Fri, 06 Jan 2006 23:48:47 +0000 Received: (from scott@localhost) by tuatara.fishballoon.org (8.13.4/8.13.4/Submit) id k06NmldM001686; Fri, 6 Jan 2006 23:48:47 GMT (envelope-from scott) Date: Fri, 6 Jan 2006 23:48:47 +0000 From: Scott Mitchell To: Marian Hettwer Message-ID: <20060106234847.GB997@tuatara.fishballoon.org> References: <20060106135717.GA20651@llama.fishballoon.org> <43BE8304.2010709@kernel32.de> <43BE992C.5030506@kernel32.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43BE992C.5030506@kernel32.de> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-STABLE i386 Cc: Vivek Khera , freebsd-stable Subject: Re: 6.0 on Dell 1850 with DRAC4 management card? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 23:48:52 -0000 On Fri, Jan 06, 2006 at 05:22:04PM +0100, Marian Hettwer wrote: > > Vivek Khera wrote: > > > > On Jan 6, 2006, at 9:47 AM, Marian Hettwer wrote: > > > >> I don't know about the DRAC with FreeBSD, but I assume that the BIOS of > >> this Dell still supports BIOS redirection to serial port. If so, you can > >> have Monitor and Keyboard connected locally and use the serial console > >> remote. > >> Just get a small console server (depending on the amount of servers you > >> have remote), for instance an old cyclades TS. Connect them and you can > >> get on your serial port through the console server via ssh. Thanks all for the replies - this is good stuff. I have been thinking about something like that - we have a bunch of old Sun boxes with their serial ports chained together for console access, would be nice to have that done properly. On the other hand the Windows guys seem to really like the DRAC cards on the Dells they look after. > > I've never enabled the DRAC card on any dell I have that came with them... > > > I'd rather stick with a good old console which I can access remotely via > ssh, too. I agree that is the best way. Sun have got this right on their Opteron servers: Ethernet port for the management board, ssh access into that then just start a console session. Cheers, Scott -- =========================================================================== Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" scott at fishballoon.org | 0xAA775B8B | -- Anon From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 00:35:37 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DED516A41F for ; Sat, 7 Jan 2006 00:35:37 +0000 (GMT) (envelope-from marius.nuennerich@gmx.net) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 8C19043D45 for ; Sat, 7 Jan 2006 00:35:36 +0000 (GMT) (envelope-from marius.nuennerich@gmx.net) Received: (qmail invoked by alias); 07 Jan 2006 00:35:35 -0000 Received: from p5083C665.dip0.t-ipconnect.de (EHLO sol) [80.131.198.101] by mail.gmx.net (mp035) with SMTP; 07 Jan 2006 01:35:35 +0100 X-Authenticated: #5707313 Date: Sat, 7 Jan 2006 01:35:34 +0100 From: Marius Nuennerich To: Ceri Davies Message-ID: <20060107013534.6b1ebdab@sol> In-Reply-To: <20060106151441.GE86645@submonkey.net> References: <20060105134133.61aef78f@sol> <20060106151441.GE86645@submonkey.net> X-Mailer: Sylpheed-Claws 1.9.100 (GTK+ 2.8.9; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-stable@freebsd.org Subject: Re: /boot/nextboot.conf not deactivated after one boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 00:35:37 -0000 On Fri, 6 Jan 2006 15:14:41 +0000 Ceri Davies wrote: > On Thu, Jan 05, 2006 at 01:41:33PM +0100, Marius Nuennerich wrote: > > Hi folks, > > > > it seems like /boot/nextboot.conf is neither deleted nor > > nextboot_enable set to NO on the first line after a reboot. > > So it isn't a one shot anymore as the manpage claims. > > > > System is 6.0-RELEASE. > > I think this is down to a typo in /etc/rc.d/root; at least I can't find > any other reference to /boot/nextkernel in src/. Patch attached > (root.diff). > > > It would also be fine imo, if the -k option would be optional and the > > next kernel defaults to "kernel". > > I'm not sure if getopts can be persuaded to take an optional argument to > an option. If not, the attached patch (nextboot.diff) should work for > you. I tested both patches and they work as they should. Please commit :) Thanks Marius From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 01:59:54 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5A5316A420 for ; Sat, 7 Jan 2006 01:59:53 +0000 (GMT) (envelope-from V.Haisman@sh.cvut.cz) Received: from service.sh.cvut.cz (service.sh.cvut.cz [147.32.127.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF71E43D72 for ; Sat, 7 Jan 2006 01:59:34 +0000 (GMT) (envelope-from V.Haisman@sh.cvut.cz) Received: from localhost (localhost [127.0.0.1]) by service.sh.cvut.cz (Postfix) with ESMTP id 8B2D71A3426; Sat, 7 Jan 2006 02:59:33 +0100 (CET) Received: from service.sh.cvut.cz ([127.0.0.1]) by localhost (service [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03400-01; Sat, 7 Jan 2006 02:59:30 +0100 (CET) Received: from logout.sh.cvut.cz (logout.sh.cvut.cz [147.32.127.203]) by service.sh.cvut.cz (Postfix) with ESMTP id 01D631A3420; Sat, 7 Jan 2006 02:59:30 +0100 (CET) Received: from [192.168.1.2] (localhost [127.0.0.1]) by logout.sh.cvut.cz (Postfix) with ESMTP id BC09A61C39; Sat, 7 Jan 2006 02:59:29 +0100 (CET) Message-ID: <43BF2079.30508@sh.cvut.cz> Date: Sat, 07 Jan 2006 02:59:21 +0100 From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Malone References: <43BE3D81.6090402@sh.cvut.cz> <20060106105712.GA46889@walton.maths.tcd.ie> In-Reply-To: <20060106105712.GA46889@walton.maths.tcd.ie> X-Enigmail-Version: 0.93.0.0 OpenPGP: id=733031B4 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEUnMzWJm5S+0864pn5r blp/hnW2up7X7uqftbNRVUrW1LGBdGfHwJqPi3ScoYtBQzhDxGEwAAAAB3RJTUUH1QoQDDgyQtx8 HQAAAkNJREFUeJzFU0toU0EUPYu66CpGdCUUmoUJkpUDQUoNBVEUrBJsq1Ki2EIKIUZ8mydBhYi0 wVUXJVCLCrFN4DIEQdxIqdBIFsMkWD9YJClCRGKjJaviynjfe8RPogtXPcObuXPOPXd+PHj+Aeyo QNmobGLXVeANGM+GsP0B2yqHHNVoCD2LwLglVGZx7yXSlADR0uZu9C4Bpy3hUxPvH/cuUw6UoPCL h64I8KAJuMpwRU8uUMJy0OIpHVeXmulZoCc/t0LlTbJLEY1EudPRcnVjgAP5Osdl4K5HVP4+2bAI okaUA0Iq6Q59+Zy2eMWN6EpFTsa3+uD1+JKj4TPHuYTSMaLScLAaqk94YJqG4ds30hojOVgYoNJc NTztNU2TBYbhu9Aafnq08ORja37da1NwBrN/b7NVEc+b8yecuYkp08vNvLYneVZRaSH1vS0UnfHm OUPzWaZufHPmCWSdWrfeGVQQKmcsO4If8pAdXJ/xF4QQAeOVY1AQQcfirwkLUWeWVTgi6vaGt2xe BGzBEIMQorru8RxgPqY1V6uxYnwVBRZEI1ytCm3dE8mC2DgcbzCJGHdBEVDKuWDSwsrSGoqzJmNt 2jJpNueIH0qS8/0JrDKnVBdvOzIsdVr4zaX9dn9xcLLKdCtQGfutVacLE9Ja+yfbDvO4aMWrklfK /JYv15C8Kw9S10kup5Bys0N1bLdcn4HvTl/Xlh6Fpllwj5/XpH9BUXn/ym0Dvv7Rt2MywojpYiSi i7Hsscaa19zZ//y/hR+BT/ns80nmJAAAAABJRU5ErkJggg== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig77EC7B7A2EEC51B86D86C4DB" X-Virus-Scanned: by amavisd-new at sh.cvut.cz Cc: freebsd-stable@freebsd.org Subject: Re: [6.0] Snapshot removes acls flag from fs. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 01:59:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig77EC7B7A2EEC51B86D86C4DB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit David Malone wrote: > On Fri, Jan 06, 2006 at 10:50:57AM +0100, V??clav Haisman wrote: > >>When I make snapshot of fs it removes "acls" flag from mount. While the >>command is "mount -u -o snapshot etc." I don't think it should remove >>the flag because it is not specified besides the snapshot option. > > > You probably want something like: > > mount -u -o cur,snapshot ... > > See the "current" and "fstab" options in the mount man page. An > easier way to do this would be to use the mksnap_ffs command, which > should preserve the old options. > > David. Hmmm, I use the sysutils/snapshot port that allows to automates this through periodic.conf... I guess I should rather complain to them then. VH --------------enig77EC7B7A2EEC51B86D86C4DB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQ78ggW56zbtzMDG0AQK1BQgAn3w5rVtd8l4/mK/OAGcCJrPD6QZWqtqn QMwiQKQx4TVRkQGa6OeP91W+KhSmghUYEcqZX7aheWbrjPSnxaWPelw/exWnvXw+ bEhcpN0J0qNDol78G41ji3z7bVHp2+ZuxUU0odEJjn8Pv8bz7GQu7Ki/kPRA65Fu JYjEPQ/mlFZtTdHuCKBHipANV8XKuDcG52vKaIG215dDUmwQ3TcJC2FyR7wSD9sc 7Jw5vWO84aF0zvs1Q8QbrWfJ2QCfucAe02+LsJMkMYMazM/f/4KGjGMQM7beHDAv /w3FpgvheQWGqTH1je3u63AzK+LDpG3yhtvCXC3H8HobN536nE5jsg== =iZ8O -----END PGP SIGNATURE----- --------------enig77EC7B7A2EEC51B86D86C4DB-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 02:13:36 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C27A216A420 for ; Sat, 7 Jan 2006 02:13:36 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by mx1.FreeBSD.org (Postfix) with SMTP id 2254343D46 for ; Sat, 7 Jan 2006 02:13:35 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: (qmail 38986 invoked from network); 7 Jan 2006 02:13:35 -0000 Received: from unknown (HELO optimator.noacks.org) (noackjr@supercrime.org@24.99.22.177 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 7 Jan 2006 02:13:35 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 9146561AD; Fri, 6 Jan 2006 21:13:34 -0500 (EST) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 74978-03; Fri, 6 Jan 2006 21:13:33 -0500 (EST) Received: from [192.168.1.9] (bastion.noacks.org [192.168.1.9]) by optimator.noacks.org (Postfix) with ESMTP id 8F47360CE; Fri, 6 Jan 2006 21:13:33 -0500 (EST) Message-ID: <43BF23D2.1080801@alumni.rice.edu> Date: Fri, 06 Jan 2006 21:13:38 -0500 From: Jonathan Noack User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Paul.LKW" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at noacks.org Cc: freebsd-stable@freebsd.org Subject: Re: asr-util Not work after upgrade to 5.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 02:13:36 -0000 Paul.LKW wrote: > As I upgraded to 5.4 I found the raid utilities 'asr-util' no longer work > for me. > I tried to deinstall and install again, but the problem still ! > The error message in the console after the comman 'raidutil -L raid' is : > Engine connect failed: COMPATILITY number > > Any one know now to solve it. Add 'options ASR_COMPAT' to your kernel config and compile a new kernel. This is listed in /sys/i386/conf/NOTES but didn't make it into the release notes. -Jonathan From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 02:43:18 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 402AD16A41F for ; Sat, 7 Jan 2006 02:43:18 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E44E43D46 for ; Sat, 7 Jan 2006 02:43:17 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.1.6] (unknown [192.168.1.6]) by yertle.kcilink.com (Postfix) with ESMTP id 6B59EB85A for ; Fri, 6 Jan 2006 21:43:16 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060106233857.GA997@tuatara.fishballoon.org> References: <20060105224150.GA991@tuatara.fishballoon.org> <20060106233857.GA997@tuatara.fishballoon.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Fri, 6 Jan 2006 21:43:17 -0500 To: freebsd-stable X-Mailer: Apple Mail (2.746.2) Subject: Re: 6.0 on Dell 1850 with PERC4e/DC RAID? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 02:43:18 -0000 On Jan 6, 2006, at 6:38 PM, Scott Mitchell wrote: > We'll only be mirroring the internal drives too for now - the 4e/DC > seems > to be the only RAID option on the 1850 with battery-backed cache, and > doesn't cost much more for the extra peace-of-mind. Then you'll be pleasantly surprised to know that the 4e/Si has a battery too. I certainly was... and it even has 256MB of cache RAM. Quite the bargain! I'll send you screen shots of the config menus in private email. >> Unfortunately for me, the latest equipment I just got only takes low- >> profile cards, and LSI doesn't offer a dual channel RAID card in low- >> profile configuration... so I need to look at adaptec. > > This is on your x4100? Nice machine. We have a v20z with dual > Opteron > 270s that I totally love. Looking at getting an x4100 too... sadly > these > are product development machines so they'll be running RedHat and > Solaris. > Doesn't the x4100 have h/w RAID built in? Or does that not work with > FreeBSD? Yes, this is the X4100. It only has room for two low-profile PCI-X cards, which the 320-2X certainly is not. Curiously, LSI has on their web site some big announcements about some deals with Sun to use their products, so one would hope they would have a low-profile high-end card. Currently they only have a low-end card that is low profile. I'm biting the bullet and getting an Adaptec 2230 low profile card. I hope it is fast. if not, then back to the drawing board... sigh. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 03:03:43 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D94B016A41F for ; Sat, 7 Jan 2006 03:03:43 +0000 (GMT) (envelope-from lars@adventuras.no) Received: from mail.adventuras.no (mail.adventuras.no [194.63.250.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E68F43D48 for ; Sat, 7 Jan 2006 03:03:42 +0000 (GMT) (envelope-from lars@adventuras.no) Received: from mail.adventuras.no (seven [127.0.0.1]) by mail.adventuras.no (8.12.10/8.12.10) with ESMTP id k07330jt004527 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 7 Jan 2006 04:03:00 +0100 Received: (from apache@localhost) by mail.adventuras.no (8.12.10/8.12.10/Submit) id k0732viK004525; Sat, 7 Jan 2006 04:02:57 +0100 Received: from 80.111.250.79 (SquirrelMail authenticated user lars) by mail.adventuras.no with HTTP; Sat, 7 Jan 2006 04:02:57 +0100 (CET) Message-ID: <55637.80.111.250.79.1136602977.squirrel@mail.adventuras.no> In-Reply-To: <43BF2079.30508@sh.cvut.cz> References: <43BE3D81.6090402@sh.cvut.cz> <20060106105712.GA46889@walton.maths.tcd.ie> <43BF2079.30508@sh.cvut.cz> Date: Sat, 7 Jan 2006 04:02:57 +0100 (CET) From: "Lars Kristiansen" To: =?iso-8859-1?Q?V=C3=A1clav_Haisman?= User-Agent: SquirrelMail/1.4.4-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Adventuras-MailScanner-Information: Please contact the ISP for more information X-Adventuras: du kan filtrere etter AdvSpamScore over 5-10 X-Adventuras-SpamCheck: not spam, SpamAssassin (score=-4.351, required 6, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.05, BAYES_00 -2.60) X-MailScanner-From: lars@adventuras.no Cc: freebsd-stable@freebsd.org Subject: Re: [6.0] Snapshot removes acls flag from fs. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 03:03:44 -0000 > > > David Malone wrote: >> On Fri, Jan 06, 2006 at 10:50:57AM +0100, V??clav Haisman wrote: >> >>>When I make snapshot of fs it removes "acls" flag from mount. While the >>>command is "mount -u -o snapshot etc." I don't think it should remove >>>the flag because it is not specified besides the snapshot option. >> >> >> You probably want something like: >> >> mount -u -o cur,snapshot ... >> >> See the "current" and "fstab" options in the mount man page. An >> easier way to do this would be to use the mksnap_ffs command, which >> should preserve the old options. >> >> David. > Hmmm, I use the sysutils/snapshot port that allows to automates this > through periodic.conf... I guess I should rather complain to them then. And as a workaround you could remount immediately after taking a snapshot. Example command in crontab if you want to use the options from fstab: /usr/local/sbin/periodic-snapshot daily ; mount -a -u -o fstab -t nomfs -- Lars > > VH > From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 03:24:14 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9855316A41F for ; Sat, 7 Jan 2006 03:24:14 +0000 (GMT) (envelope-from james_mapson@umpquanet.com) Received: from ns.museum.rain.com (gw-ipinc.museum.rain.com [65.75.192.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0B7343D45 for ; Sat, 7 Jan 2006 03:24:13 +0000 (GMT) (envelope-from james_mapson@umpquanet.com) Received: from ns.museum.rain.com (localhost [127.0.0.1]) by ns.museum.rain.com (8.13.4/8.13.4) with ESMTP id k073O8jm075709 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 6 Jan 2006 19:24:08 -0800 (PST) (envelope-from james@umpquanet.com) Received: (from james@localhost) by ns.museum.rain.com (8.13.4/8.13.4/Submit) id k073O8P6075708; Fri, 6 Jan 2006 19:24:08 -0800 (PST) (envelope-from james) Date: Fri, 6 Jan 2006 19:24:08 -0800 From: James Long To: Vivek Khera Message-ID: <20060107032408.GA75676@ns.museum.rain.com> References: <20060106040839.A38DE16A46C@hub.freebsd.org> <20060106094024.GA43299@ns.museum.rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-101.4 required=5.0 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on ns.museum.rain.com Cc: freebsd-stable@freebsd.org Subject: Re: rpcbind lingering on IP no longer specified on command line X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 03:24:14 -0000 On Fri, Jan 06, 2006 at 10:22:43AM -0500, Vivek Khera wrote: > > On Jan 6, 2006, at 4:40 AM, James Long wrote: > > >>Yeah, I noticed that little tiny "UDP requests" note in the -h docs > >>too. There's no reason to bind to all tcp addresses, and it is > >>causing me heartburn for getting the server certified... > > > >Good grief, why not just firewall off the undesired UDP ports and call > >it good? > > I guess we could take that band-aid approach... however, how do you > know what port RPC decides to listen on other than the 111 port? It > is more or less random. That makes it very difficult to firewall. P-shaw. If you're enduring "heartburn for getting the server certified" then firewall off the rpcbind service from unwanted IPs and voila, you get your get your server certified and business goes on. Then you'll have the luxury of time to debug the true problem with rpcbind, and your testing is done behind the privacy of your firewall. As far as unpredictable listening ports opened by rpc, that is exactly why a secure firewall opens only selected ports on selected IPs, and blocks everything else. It doesn't matter if it listens on port X of IP y when your firewall doesn't permit incoming connections on that port and IP in the first place. Jim ># sockstat | grep rpcbind >root rpcbind 11382 5 stream /var/run/rpcbind.sock >root rpcbind 11382 6 dgram -> /var/run/logpriv >root rpcbind 11382 7 udp4 127.0.0.1:111 *:* >root rpcbind 11382 8 udp4 192.168.100.200:111 *:* >root rpcbind 11382 9 udp4 *:664 *:* >root rpcbind 11382 10 tcp4 *:111 *:* From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 05:56:28 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0ACF316A41F for ; Sat, 7 Jan 2006 05:56:28 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F2B043D45 for ; Sat, 7 Jan 2006 05:56:26 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id k0761sHi081628 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 7 Jan 2006 01:01:59 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-stable@freebsd.org Date: Sat, 7 Jan 2006 00:58:31 -0500 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5518894.zU5UQKIybz"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601070058.44347.mistry.7@osu.edu> X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED, BAYES_20, BIZ_TLD, MYFREEBSD2 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.87/1234/Fri Jan 6 08:54:31 2006 on mail.united-ware.com X-Virus-Status: Clean Subject: panic: vm_object_backing_scan: object mismatch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 05:56:28 -0000 --nextPart5518894.zU5UQKIybz Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I just upgraded to RELENG_6 from 6.0 and after running for about a day=20 I got the following panic: Jan 6 21:37:47 bigguy kernel: pid 30546 (gaim), uid 1001 inumber=20 10313 on /var: filesystem full panic: vm_object_backing_scan: object mismatch KDB: enter: panic [thread pid 22780 tid 100175 ] Stopped at kdb_enter+0x32: leave db> bt Tracing pid 22780 tid 100175 td 0xc8119300 kdb_enter(c06a50b0,c06f9460,c06b9bcd,e9a30978,c8119300) at=20 kdb_enter+0x32 panic(c06b9bcd,0,c06b99b4,604,0) at panic+0x14c vm_object_backing_scan(c7d7dad4,0,c06b99b4,63b,0) at=20 vm_object_backing_scan+0x4e c vm_object_collapse(c9923630,0,c06b99b4,214,c7d7dad4) at=20 vm_object_collapse+0x1b4 vm_object_deallocate(c7d7dad4,0,c06b906f,89e,0) at=20 vm_object_deallocate+0x351 vm_map_delete(c7d16e10,0,bfc00000,c7d16e10,0) at vm_map_delete+0x29d vm_map_remove(c7d16e10,0,bfc00000,c8119300,e9a30a9c) at=20 vm_map_remove+0x55 exec_new_vmspace(e9a30bf0,c06eeec0,2ec,0,0) at exec_new_vmspace+0x243 exec_elf32_imgact(e9a30bf0,0,c06a2586,149,43) at=20 exec_elf32_imgact+0x1bd kern_execve(c8119300,e9a30ca8,0,807b94c,807a000) at kern_execve+0x417 execve(c8119300,e9a30d04,c,41d,3) at execve+0x67 syscall(3b,3b,3b,1,0) at syscall+0x13d Xint0x80_syscall() at Xint0x80_syscall+0x1f =2D-- syscall (59, FreeBSD ELF32, execve), eip =3D 0x805571f, esp =3D=20 0xbfbfd9bc, ebp =3D 0xbfbfd9d8 --- The trace with ps output is here: http://am-productions.biz/docs/bigguy-vm-panic.txt =2D-=20 Anish Mistry --nextPart5518894.zU5UQKIybz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDv1iUxqA5ziudZT0RAjSBAJ9YYzt+pjaOwcKMQ3O1ZojS6Xm87ACgoVRQ F4B3RgrFkxMzeqOq1295+4s= =Dt7r -----END PGP SIGNATURE----- --nextPart5518894.zU5UQKIybz-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 08:20:36 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64B7C16A420 for ; Sat, 7 Jan 2006 08:20:36 +0000 (GMT) (envelope-from sirmoo@cowbert.2y.net) Received: from cowbert.2y.net (d46h180.public.uconn.edu [137.99.46.180]) by mx1.FreeBSD.org (Postfix) with SMTP id C9C1F43D45 for ; Sat, 7 Jan 2006 08:20:33 +0000 (GMT) (envelope-from sirmoo@cowbert.2y.net) Received: (qmail 97232 invoked by uid 1001); 7 Jan 2006 08:20:32 -0000 Date: Sat, 7 Jan 2006 03:20:32 -0500 From: "Peter C. Lai" To: PeterJeremy@optushome.com.au Message-ID: <20060107082032.GU326@cowbert.2y.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Cc: freebsd-stable@FreeBSD.org Subject: Re: NIC card problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 08:20:36 -0000 Peter Jeremy wrote: >Real DEC Tulip cards do this when running Tru64 as well. My guess is that >it's a bug in the NIC. (And it looks like AMDtek have copied it). Peter, Warner, Stefan, et al.: I just found this thread on the mailing list, and am responding to it, a year later :) I also believe the problem is a bug in the NIC as well, since the ADMTek 985 appears to not listen to the "automagic buffer underrun recovery" command. Silby added some patches to mbuf allocation in 2003 after stress testing dc(4), which improves the situation somewhat (ability to sustain the traffic longer) but doesn't solve it. While my system doesn't reboot (panic), it will often hang as a result of this. What happens then is that when the interface tries to transmit, a "No buffer space available" error occurs. If one can access the console, it can be rescued by bringing the interface down and then up again using ifconfig(8). This will reset the card and presumably flush the buffers. I wonder if any work has been done on the driver in -CURRENT (and I am too lazy to look), but in the next few weeks the machine is getting overhauled from 4.11 to 6 (reformat/reinstall) so we shall see if it does anything. -- Peter C. Lai Dept. of Neurobiology Yale University School of Medicine http://cowbert.2y.net/ From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 11:53:17 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FCB216A41F for ; Sat, 7 Jan 2006 11:53:17 +0000 (GMT) (envelope-from hlh@restart.be) Received: from guri.is.scarlet.be (guri.is.scarlet.be [193.74.71.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id D998043D45 for ; Sat, 7 Jan 2006 11:53:15 +0000 (GMT) (envelope-from hlh@restart.be) Received: from (ip-83-134-195-94.dsl.scarlet.be [83.134.195.94]) by guri.is.scarlet.be with ESMTP id k07BrBI30674 for ; Sat, 7 Jan 2006 12:53:12 +0100 Received: from [192.168.24.1] (norquay.restart.bel [192.168.24.1]) (authenticated bits=0) by restart.be (8.13.5/8.13.5) with ESMTP id k07Bqv8l096171 for ; Sat, 7 Jan 2006 12:52:59 +0100 (CET) (envelope-from hlh@restart.be) DomainKey-Signature: a=rsa-sha1; s=norquay; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent: x-accept-language:mime-version:to:subject:content-type: content-transfer-encoding:received-spf:x-spam-status:x-scanned-by; b=VOo+pOn3sknO41JG5IJUOihbx2cD1t4MTecYFtRRbXTbyuqZLmsnKYui2EyYg/8YD fCOYC12ATLGUeRmJb6Csw== Message-ID: <43BFAB99.1030208@restart.be> Date: Sat, 07 Jan 2006 12:52:57 +0100 From: Henri Hennebert Organization: RestartSoft User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051221) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (restart.be: 192.168.24.1 is authenticated by a trusted mechanism) X-Spam-Status: -1.44 (ALL_TRUSTED) X-Scanned-By: MIMEDefang 2.54 on 192.168.24.1 Subject: 6.0-RELEASE freeze repetitively X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 11:53:17 -0000 Hello, I have a production server which freeze from time to time (from 5 hours to 7 days between freeze). I try (in /boot/loader.conf.local): - hint.acpi.0.disabled="1" - debug.mpsafevfs=0 debug.mpsafevm=0 to no avail. I setup a serial console and go into ddb and get: KDB: enter: Line break on console [thread pid 61 tid 100052 ] Stopped at kdb_enter+0x30: leave db> db> bt Tracing pid 61 tid 100052 td 0xc355e300 kdb_enter(c075ddb2,a,9e0a90,417ff9,e69e0aac) at kdb_enter+0x30 siointr1(c3660800,a,2,2,6400) at siointr1+0xe7 siointr(c3660800,257,0,4,c355e300) at siointr+0x78 intr_execute_handlers(c352b090,e69e0aa0,e69e0af8,c06fee23,34) at intr_execute_handlers+0x98 lapic_handle_intr(34) at lapic_handle_intr+0x3a Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc057d1c0, esp = 0xe69e0ae4, ebp = 0xe69e0af8 --- vop_stdlock(c078e260,e69e0b50,e69e0b20,c0721424,e69e0b50) at vop_stdlock ffs_lock(e69e0b50,0,2012,c54db440,e69e0b6c) at ffs_lock+0x19 VOP_LOCK_APV(c078db60,e69e0b50,c3811400,e69e0b4c,c057d232) at VOP_LOCK_APV+0x54 vn_lock(c54db440,2012,c355e300,c079a980,c6029000) at vn_lock+0x13e vget(c54db440,2012,c355e300,c81c1aa0,1) at vget+0xff qsync(c3811400,c3811400,c355e300,c3b64660,0) at qsync+0x1df ffs_sync(c3811400,3,c355e300,c355e300,c355e300) at ffs_sync+0x3fb sync_fsync(e69e0ca0,e69e0cbc,c05876a4,c0782700,e69e0ca0) at sync_fsync+0x21b VOP_FSYNC_APV(c0782700,e69e0ca0,c355e300,0,e69e0cbc) at VOP_FSYNC_APV+0x3e sync_vnode(c39093f0,c355e300,68,c07493b5,0) at sync_vnode+0x1b4 sched_sync(0,e69e0d38,4489e045,458d1424,244489dc) at sched_sync+0x2ef fork_exit(c05877a0,0,e69e0d38) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe69e0d6c, ebp = 0 --- db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 94717 c3e64624 80 94700 94696 0004000 [RUNQ] rrdtool 94703 c3c08624 0 800 800 0000101 [RUNQ] rsync 94702 c3e6c000 80 94698 94698 0004000 [RUNQ] perl 94701 c3e6420c 113 94697 94697 0004001 [RUNQ] perl5.8.7 94700 c5f41a3c 80 94696 94696 0004000 [SLPQ wait 0xc5f41a3c][SLP] perl5.8.7 94698 c35fb418 80 94693 94698 0004000 [SLPQ wait 0xc35fb418][SLP] sh 94697 c3e6c20c 113 94694 94697 0004000 [SLPQ wait 0xc3e6c20c][SLP] sh 94696 c382a20c 80 94692 94696 0004000 [SLPQ wait 0xc382a20c][SLP] sh 94694 c35fb000 0 710 710 0000000 [SLPQ piperd 0xc4adc660][SLP] cron 94693 c8160c48 0 710 710 0000000 [SLPQ piperd 0xc815b4c8][SLP] cron 94692 c5f40624 0 710 710 0000000 [SLPQ piperd 0xc38a9198][SLP] cron 94689 c815f000 0 1 94689 0000100 [SLPQ select 0xc07a7404][SLP] sendmail 94584 c3e6ca3c 60667 678 678 0000100 [SLPQ lockf 0xc5c2ea80][SLP] perl5.8.7 94338 c3c08a3c 60667 678 678 0000100 [SLPQ lockf 0xc5c636c0][SLP] perl5.8.7 94300 c43ab830 8 758 739 0004000 [SLPQ nanslp 0xc07a086c][SLP] sleep 93950 c389f624 60667 678 678 0000100 [SLPQ lockf 0xc5c2e380][SLP] perl5.8.7 93326 c43aaa3c 60667 678 678 0000100 [SLPQ select 0xc07a7404][SLP] perl5.8.7 93248 c3c08830 0 694 694 0000100 [SLPQ select 0xc07a7404][SLP] sendmail 92514 c43ab624 8 754 754 0004000 [SLPQ sbwait 0xc4a43a64][SLP] perl5.8.7 92513 c3c08418 8 754 754 0004000 [SLPQ select 0xc07a7404][SLP] innfeed 88624 c816020c 0 1 88624 0004002 [SLPQ ttyin 0xc3666010][SLP] getty 88573 c3827418 0 1 88573 0004002 [SLPQ ttyin 0xc3666410][SLP] getty 88570 c43a820c 0 1 88570 0004002 [SLPQ ttyin 0xc3665410][SLP] getty 3820 c39ca624 0 1 3820 0004002 [SLPQ ttyin 0xc3664c10][SLP] getty 905 c43ab20c 0 1 905 0000000 [SLPQ select 0xc07a7404][SLP] inetd 896 c3e64c48 0 1 896 0000000 [SLPQ select 0xc07a7404][SLP] moused 872 c389c000 0 1 68 000c082 (threaded) java thread 0xc60c9600 ksegrp 0xc389e1e0 [SLPQ kserel 0xc389e214][SLP] thread 0xc4f56180 ksegrp 0xc389e1e0 [SLPQ sbwait 0xc5e2ae90][SLP] thread 0xc49eda80 ksegrp 0xc389e1e0 [SLPQ sbwait 0xc6191a64][SLP] thread 0xc4f61180 ksegrp 0xc389e1e0 [SLPQ kserel 0xc389e214][SLP] thread 0xc49fb900 ksegrp 0xc389e1e0 [SLPQ sbwait 0xc3a37a64][SLP] thread 0xc4d13a80 ksegrp 0xc389e1e0 [SLPQ sbwait 0xc60d4e90][SLP] thread 0xc5f5c900 ksegrp 0xc389e1e0 [SLPQ accept 0xc3d9ab5a][SLP] thread 0xc4f22d80 ksegrp 0xc389e1e0 [SLPQ sbwait 0xc5eba20c][SLP] thread 0xc622ad80 ksegrp 0xc389e1e0 [SLPQ sbwait 0xc61914d4][SLP] thread 0xc3e65300 ksegrp 0xc389e1e0 [SLPQ accept 0xc3d9a9f6][SLP] thread 0xc3e65000 ksegrp 0xc43a9000 [SLPQ ksesigwait 0xc389c138][SLP] 843 c3c08000 100 841 843 0004000 [SLPQ piperd 0xc39cb4c8][SLP] unlinkd 841 c3e6c830 100 837 837 000c080 (threaded) squid thread 0xc3b70480 ksegrp 0xc3e6b360 [SLPQ kserel 0xc3e6b394][SLP] thread 0xc4f1c180 ksegrp 0xc3e6b360 [SLPQ kserel 0xc3e6b394][SLP] thread 0xc3f65600 ksegrp 0xc3e6b360 [SLPQ select 0xc07a7404][SLP] thread 0xc3e66780 ksegrp 0xc389e2a0 [SLPQ kserel 0xc389e2d4][SLP] thread 0xc3e66900 ksegrp 0xc389e300 [SLPQ kserel 0xc389e334][SLP] thread 0xc3e66a80 ksegrp 0xc389e360 [SLPQ kserel 0xc389e394][SLP] thread 0xc3e66c00 ksegrp 0xc389e3c0 [SLPQ kserel 0xc389e3f4][SLP] thread 0xc3e66d80 ksegrp 0xc389e420 [SLPQ kserel 0xc389e454][SLP] thread 0xc3ea3000 ksegrp 0xc389e480 [SLPQ kserel 0xc389e4b4][SLP] thread 0xc3ea3180 ksegrp 0xc389e4e0 [SLPQ kserel 0xc389e514][SLP] thread 0xc3ea3300 ksegrp 0xc389e540 [SLPQ kserel 0xc389e574][SLP] thread 0xc3ea3480 ksegrp 0xc389e5a0 [SLPQ kserel 0xc389e5d4][SLP] thread 0xc3ea3600 ksegrp 0xc389e600 [SLPQ kserel 0xc389e634][SLP] thread 0xc3ea3780 ksegrp 0xc389e660 [SLPQ kserel 0xc389e694][SLP] thread 0xc3ea3900 ksegrp 0xc389e6c0 [SLPQ kserel 0xc389e6f4][SLP] thread 0xc3ea3a80 ksegrp 0xc389e720 [SLPQ kserel 0xc389e754][SLP] thread 0xc3ea3c00 ksegrp 0xc389e780 [SLPQ kserel 0xc389e7b4][SLP] thread 0xc3ea3d80 ksegrp 0xc389e7e0 [SLPQ kserel 0xc389e814][SLP] thread 0xc3ea7000 ksegrp 0xc389e840 [SLPQ kserel 0xc389e874][SLP] thread 0xc3ea7180 ksegrp 0xc389e8a0 [SLPQ kserel 0xc389e8d4][SLP] thread 0xc3ea7300 ksegrp 0xc389e900 [SLPQ kserel 0xc389e934][SLP] thread 0xc3ea7480 ksegrp 0xc389e960 [SLPQ kserel 0xc389e994][SLP] thread 0xc3ea7600 ksegrp 0xc389e9c0 [SLPQ kserel 0xc389e9f4][SLP] thread 0xc3ea7780 ksegrp 0xc389ea20 [SLPQ kserel 0xc389ea54][SLP] thread 0xc3c85780 ksegrp 0xc389ea80 [SLPQ kserel 0xc389eab4][SLP] thread 0xc3c85d80 ksegrp 0xc389eae0 [SLPQ kserel 0xc389eb14][SLP] thread 0xc3b70180 ksegrp 0xc389eb40 [SLPQ kserel 0xc389eb74][SLP] thread 0xc3829900 ksegrp 0xc389eba0 [SLPQ kserel 0xc389ebd4][SLP] thread 0xc3c7e180 ksegrp 0xc389ec00 [SLPQ kserel 0xc389ec34][SLP] thread 0xc3b70900 ksegrp 0xc389ec60 [SLPQ kserel 0xc389ec94][SLP] thread 0xc3c85600 ksegrp 0xc389ecc0 [SLPQ kserel 0xc389ecf4][SLP] thread 0xc3c7f000 ksegrp 0xc389ed20 [SLPQ kserel 0xc389ed54][SLP] thread 0xc3c7e000 ksegrp 0xc389ed80 [SLPQ kserel 0xc389edb4][SLP] thread 0xc3c85900 ksegrp 0xc389ede0 [SLPQ kserel 0xc389ee14][SLP] thread 0xc3c7f300 ksegrp 0xc389ee40 [SLPQ kserel 0xc389ee74][SLP] thread 0xc3c7f180 ksegrp 0xc389eea0 [SLPQ ksesigwait 0xc3e6c968][SLP] 837 c389f20c 100 1 837 0000000 [SLPQ wait 0xc389f20c][SLP] squid 824 c39cac48 60001 823 823 000c180 (threaded) python2.3 thread 0xc4f51300 ksegrp 0xc354f420 [SLPQ kserel 0xc354f454][SLP] thread 0xc361a600 ksegrp 0xc354f420 [SLPQ select 0xc07a7404][SLP] thread 0xc355ea80 ksegrp 0xc354f420 [SLPQ kserel 0xc354f454][SLP] thread 0xc3f14900 ksegrp 0xc3e6b960 [SLPQ ksesigwait 0xc39cad80][SLP] 823 c382a000 0 1 823 0000000 [SLPQ select 0xc07a7404][SLP] python2.3 817 c39ca830 0 811 811 0000001 [SLPQ lockf 0xc5ce1040][SLP] saslauthd 816 c39caa3c 0 811 811 0000001 [SLPQ accept 0xc3c02e22][SLP] saslauthd 815 c39ca20c 0 811 811 0000001 [SLPQ lockf 0xc61bac80][SLP] saslauthd 814 c389c20c 0 811 811 0000001 [SLPQ lockf 0xc3847580][SLP] saslauthd 811 c39c9000 0 1 811 0000001 [SLPQ lockf 0xc3c86640][SLP] saslauthd 800 c39c9624 0 1 800 0000000 [SLPQ select 0xc07a7404][SLP] rsync 793 c3827a3c 0 1 793 0000000 [SLPQ select 0xc07a7404][SLP] racoon 785 c39ca000 60001 784 784 0004100 [SLPQ select 0xc07a7404][SLP] python2.3 784 c382720c 0 1 784 0000000 [SLPQ select 0xc07a7404][SLP] python2.3 778 c3c07418 80 731 731 0008180 (threaded) httpd thread 0xc4f1c600 ksegrp 0xc354f2a0 [SLPQ kserel 0xc354f2d4][SLP] thread 0xc520cc00 ksegrp 0xc354f2a0 [SLPQ kserel 0xc354f2d4][SLP] thread 0xc5efd000 ksegrp 0xc354f2a0 [SLPQ select 0xc07a7404][SLP] thread 0xc5e10180 ksegrp 0xc354f2a0 [SLPQ lockf 0xc38a7d80][SLP] thread 0xc4abb300 ksegrp 0xc354f2a0 [SLPQ select 0xc07a7404][SLP] thread 0xc3c7ea80 ksegrp 0xc3c09000 [SLPQ ksesigwait 0xc3c07550][SLP] thread 0xc3b6fa80 ksegrp 0xc354f2a0 [SLPQ piperd 0xc38a9b28][SLP] 777 c3c07624 80 731 731 0008180 (threaded) httpd thread 0xc4166900 ksegrp 0xc354f240 [SLPQ kserel 0xc354f274][SLP] thread 0xc60c9300 ksegrp 0xc354f240 [SLPQ select 0xc07a7404][SLP] thread 0xc4f56c00 ksegrp 0xc354f240 [SLPQ kserel 0xc354f274][SLP] thread 0xc60cad80 ksegrp 0xc354f240 [SLPQ lockf 0xc5c2e940][SLP] thread 0xc3c7ed80 ksegrp 0xc3c09060 [SLPQ ksesigwait 0xc3c0775c][SLP] thread 0xc3b6f900 ksegrp 0xc354f240 [SLPQ piperd 0xc38a9b28][SLP] 776 c3c07830 80 731 731 0008180 (threaded) httpd thread 0xc4d14900 ksegrp 0xc354f1e0 [SLPQ kserel 0xc354f214][SLP] thread 0xc60c9c00 ksegrp 0xc354f1e0 [SLPQ select 0xc07a7404][SLP] thread 0xc5efdc00 ksegrp 0xc354f1e0 [SLPQ kserel 0xc354f214][SLP] thread 0xc3c7f600 ksegrp 0xc3c090c0 [SLPQ ksesigwait 0xc3c07968][SLP] thread 0xc3b6f780 ksegrp 0xc354f1e0 [SLPQ piperd 0xc38a9b28][SLP] 775 c3c07a3c 0 731 731 0000000 [SLPQ accept 0xc3c0203a][SLP] httpd 768 c389c624 80 731 731 0000100 [SLPQ accept 0xc3c01b5a][SLP] httpd 759 c39ca418 8 756 739 0004002 [SLPQ nanslp 0xc07a086c][SLP] perl5.8.7 758 c389ca3c 8 755 739 0004002 [SLPQ wait 0xc389ca3c][SLP] sh 756 c38a320c 8 1 739 0000002 [SLPQ wait 0xc38a320c][SLP] sh 755 c38a3a3c 8 1 739 0000002 [SLPQ wait 0xc38a3a3c][SLP] sh 754 c3827830 8 1 754 0000001 [SLPQ select 0xc07a7404][SLP] innd 731 c389f000 0 1 731 0000000 [SLPQ nanslp 0xc07a086c][SLP] httpd 710 c389c830 0 1 710 0000000 [SLPQ nanslp 0xc07a086c][SLP] cron 698 c39c9a3c 25 1 698 0000100 [SLPQ pause 0xc39c9a70][SLP] sendmail 694 c389fc48 0 1 694 0000100 [SLPQ select 0xc07a7404][SLP] sendmail 689 c389f830 60667 1 689 0008080 (threaded) amavis-milter thread 0xc5f5ca80 ksegrp 0xc354fcc0 [SLPQ kserel 0xc354fcf4][SLP] thread 0xc4d19a80 ksegrp 0xc354fcc0 [SLPQ select 0xc07a7404][SLP] thread 0xc49fb180 ksegrp 0xc354fcc0 [SLPQ kserel 0xc354fcf4][SLP] thread 0xc3c88a80 ksegrp 0xc354fcc0 [SLPQ select 0xc07a7404][SLP] thread 0xc3b70600 ksegrp 0xc354f3c0 [SLPQ ksesigwait 0xc389f968][SLP] 678 c3827000 60667 1 678 0000100 [SLPQ nanslp 0xc07a086c][SLP] perl5.8.7 673 c389fa3c 0 1 673 0000100 [SLPQ select 0xc07a7404][SLP] sshd 643 c38a3624 0 1 643 0000000 [SLPQ select 0xc07a7404][SLP] ntpd 628 c39c9c48 0 1 628 0000000 [SLPQ select 0xc07a7404][SLP] lpd 613 c39c9418 0 1 613 0000000 [SLPQ select 0xc07a7404][SLP] timed 534 c38a3418 53 1 534 0000100 [SLPQ select 0xc07a7404][SLP] named 473 c38a3830 0 1 473 0000000 [SLPQ select 0xc07a7404][SLP] syslogd 438 c3827c48 0 1 438 0000000 [SLPQ select 0xc07a7404][SLP] devd 67 c382a624 0 0 0 0000204 [SLPQ - 0xe6c2ecf8][SLP] schedcpu 66 c382a830 0 0 0 0000204 [SLPQ - 0xc07bb92c][SLP] nfsiod 3 65 c382aa3c 0 0 0 0000204 [SLPQ - 0xc07bb928][SLP] nfsiod 2 64 c382ac48 0 0 0 0000204 [SLPQ - 0xc07bb924][SLP] nfsiod 1 63 c355c20c 0 0 0 0000204 [SLPQ - 0xc07bb920][SLP] nfsiod 0 62 c355c418 0 0 0 0000204 [SLPQ vlruwt 0xc355c418][SLP] vnlru 61 c355c624 0 0 0 0000204 [CPU 0] syncer 60 c355c830 0 0 0 0000204 [SLPQ psleep 0xc07a794c][SLP] bufdaemon 59 c355ca3c 0 0 0 000020c [SLPQ pgzero 0xc07c1de4][SLP] pagezero 58 c355cc48 0 0 0 0000204 [SLPQ psleep 0xc07c1934][SLP] vmdaemon 57 c35bc000 0 0 0 0000204 [SLPQ psleep 0xc07c18f0][SLP] pagedaemon 56 c35bc20c 0 0 0 0000204 [IWAIT] swi0: sio 55 c35bc418 0 0 0 0000204 [SLPQ - 0xc352b43c][SLP] fdc0 54 c35bc624 0 0 0 0000204 [SLPQ usbtsk 0xc079d8c4][SLP] usbtask 53 c35bc830 0 0 0 0000204 [SLPQ usbevt 0xc35c0210][SLP] usb0 9 c35bca3c 0 0 0 0000204 [SLPQ - 0xc3563300][SLP] acpi_task2 8 c35bcc48 0 0 0 0000204 [SLPQ - 0xc3563300][SLP] acpi_task1 7 c354d624 0 0 0 0000204 [SLPQ - 0xc3563300][SLP] acpi_task0 6 c354d830 0 0 0 0000204 [SLPQ - 0xc3563380][SLP] thread taskq 52 c354da3c 0 0 0 0000204 [IWAIT] swi6:+ 51 c354dc48 0 0 0 0000204 [IWAIT] swi6: task queue 50 c355b000 0 0 0 0000204 [IWAIT] swi2: cambio 5 c355b20c 0 0 0 0000204 [SLPQ - 0xc3563700][SLP] kqueue taskq 49 c355b418 0 0 0 0000204 [IWAIT] swi5:+ 48 c355b624 0 0 0 0000204 [SLPQ - 0xc079d1c0][SLP] yarrow 4 c355b830 0 0 0 0000204 [SLPQ - 0xc079dd88][SLP] g_down 3 c355ba3c 0 0 0 0000204 [SLPQ - 0xc079dd84][SLP] g_up 2 c355bc48 0 0 0 0000204 [SLPQ - 0xc079dd7c][SLP] g_event 47 c355c000 0 0 0 0000204 [IWAIT] swi3: vm 46 c353ec48 0 0 0 000020c [CPU 1] swi4: clock sio 45 c354c000 0 0 0 0000204 [IWAIT] swi1: net 44 c354c20c 0 0 0 0000204 [IWAIT] irq0: 43 c354c418 0 0 0 0000204 [IWAIT] irq31: 42 c354c624 0 0 0 0000204 [LOCK Giant c8229dc0] irq30: fxp0 41 c354c830 0 0 0 0000204 [LOCK Giant c8229dc0] irq29: sym1 40 c354ca3c 0 0 0 0000204 [IWAIT] irq28: ohci0 39 c354cc48 0 0 0 0000204 [IWAIT] irq27: 38 c354d000 0 0 0 0000204 [IWAIT] irq26: 37 c354d20c 0 0 0 0000204 [IWAIT] irq25: 36 c354d418 0 0 0 0000204 [IWAIT] irq24: 35 c352d624 0 0 0 0000204 [IWAIT] irq23: 34 c352d830 0 0 0 0000204 [IWAIT] irq22: 33 c352da3c 0 0 0 0000204 [IWAIT] irq21: 32 c352dc48 0 0 0 0000204 [IWAIT] irq20: sym0 31 c353e000 0 0 0 0000204 [IWAIT] irq19: 30 c353e20c 0 0 0 0000204 [IWAIT] irq18: 29 c353e418 0 0 0 0000204 [IWAIT] irq17: 28 c353e624 0 0 0 0000204 [IWAIT] irq16: 27 c353e830 0 0 0 0000204 [IWAIT] irq15: ata1 26 c353ea3c 0 0 0 0000204 [IWAIT] irq14: ata0 25 c34de20c 0 0 0 0000204 [IWAIT] irq13: 24 c34de418 0 0 0 0000204 [IWAIT] irq12: psm0 23 c34de624 0 0 0 0000204 [IWAIT] irq11: 22 c34de830 0 0 0 0000204 [IWAIT] irq10: 21 c34dea3c 0 0 0 0000204 [IWAIT] irq9: acpi0 20 c34dec48 0 0 0 0000204 [IWAIT] irq8: 19 c352d000 0 0 0 0000204 [IWAIT] irq7: ppc0 18 c352d20c 0 0 0 0000204 [IWAIT] irq6: fdc0 17 c352d418 0 0 0 0000204 [IWAIT] irq5: 16 c34d9000 0 0 0 0000204 [IWAIT] irq4: sio0 15 c34d920c 0 0 0 0000204 [IWAIT] irq3: sio1 14 c34d9418 0 0 0 0000204 [IWAIT] irq2: 13 c34d9624 0 0 0 0000204 [RUNQ] irq1: atkbd0 12 c34d9830 0 0 0 000020c [Can run] idle: cpu0 11 c34d9a3c 0 0 0 000020c [Can run] idle: cpu1 1 c34d9c48 0 0 1 0004200 [SLPQ wait 0xc34d9c48][SLP] init 10 c34de000 0 0 0 0000204 [SLPQ ktrace 0xc079e7d8][SLP] ktrace 0 c079de80 0 0 0 0000200 [IWAIT] swapper db> show lockedvnods Locked vnodes 0xc43a1770: tag ufs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc3c7e900 (pid 94701) ino 8, on dev da1s1h 0xc3909330: tag syncer, type VNON usecount 1, writecount 0, refcount 2 mountedhere 0 flags () lock type syncer: EXCL (count 1) by thread 0xc355e300 (pid 61) 0xc4c1caa0: tag ufs, type VREG usecount 0, writecount 0, refcount 1 mountedhere 0 flags (VI_DOOMED) lock type ufs: EXCL (count 1) by thread 0xc3c7e900 (pid 94701) ino 69, on dev da1s1h db> show thread 100156 (0xc3c7f480) sched_switch(c3c7f480,c34df900,6,ed1c9c06,6cfa789d) at sched_switch+0x160 100127 (0xc38a5d80) sched_switch(c38a5d80,0,2,8d2becce,ac2bdc7b) at sched_switch+0x160 100160 (0xc3e66000) sched_switch(c3e66000,c34df900,6,59b5b15e,e07064b6) at sched_switch+0x160 100154 (0xc3c7e900) sched_switch(c3c7e900,0,1,2d651c7a,a2790c7f) at sched_switch+0x160 100250 (0xc520c300) sched_switch(c520c300,0,1,75e66fe2,8e60e7df) at sched_switch+0x160 100282 (0xc3c85a80) sched_switch(c3c85a80,0,1,f0b58d3e,e2542b6e) at sched_switch+0x160 100161 (0xc3e65d80) sched_switch(c3e65d80,0,1,92f47c7e,e250531c) at sched_switch+0x160 100071 (0xc3828600) sched_switch(c3828600,0,1,7c42da7e,e10c069a) at sched_switch+0x160 100280 (0xc5210000) sched_switch(c5210000,0,1,ad9b423e,dd6bd755) at sched_switch+0x160 100276 (0xc5e10300) sched_switch(c5e10300,0,1,7d81dcfe,de83f0d4) at sched_switch+0x160 100239 (0xc520fd80) sched_switch(c520fd80,0,1,157f6e1e,dce9b713) at sched_switch+0x160 100241 (0xc3b70a80) sched_switch(c3b70a80,0,1,6e3396d0,9c04a7f9) at sched_switch+0x160 100165 (0xc3e65780) sched_switch(c3e65780,0,1,b52d9ee2,a365ff2) at sched_switch+0x160 100129 (0xc38a5a80) sched_switch(c38a5a80,0,1,6358ee80,5150bbd6) at sched_switch+0x160 100222 (0xc3f13000) sched_switch(c3f13000,0,1,85eb5e3a,6f1af712) at sched_switch+0x160 100087 (0xc3829a80) sched_switch(c3829a80,0,1,f40b7eae,b6727aed) at sched_switch+0x160 100216 (0xc3f14480) sched_switch(c3f14480,0,1,15e3b506,ff812e0c) at sched_switch+0x160 100128 (0xc38a5c00) sched_switch(c38a5c00,0,1,b88a3d28,35446375) at sched_switch+0x160 100221 (0xc3ea7a80) sched_switch(c3ea7a80,0,1,5609055a,536167f1) at sched_switch+0x160 100126 (0xc3b6f000) sched_switch(c3b6f000,0,1,9a807a58,7e920f45) at sched_switch+0x160 100271 (0xc520c180) sched_switch(c520c180,0,1,fea952ea,d5303890) at sched_switch+0x160 100065 (0xc3829000) sched_switch(c3829000,0,1,373a6a6c,70d06376) at sched_switch+0x160 100205 (0xc3f14a80) sched_switch(c3f14a80,0,1,7fdec2b8,10f2540b) at sched_switch+0x160 100108 (0xc38a4180) sched_switch(c38a4180,0,1,f5d8e66e,80e8b786) at sched_switch+0x160 100219 (0xc3ea7900) sched_switch(c3ea7900,0,1,487e208a,6c60d329) at sched_switch+0x160 100159 (0xc3e66180) sched_switch(c3e66180,0,1,6d4069ac,8016b60e) at sched_switch+0x160 100229 (0xc60c9600) sched_switch(c60c9600,0,1,f785468,b78e53fa) at sched_switch+0x160 100164 (0xc4f56180) sched_switch(c4f56180,c60c9600,1,36fa0956,b960c70d) at sched_switch+0x160 100201 (0xc49eda80) sched_switch(c49eda80,c4f56180,1,1ba79ff4,75d77c1c) at sched_switch+0x160 100137 (0xc4f61180) sched_switch(c4f61180,0,1,225731d8,b7881a50) at sched_switch+0x160 100149 (0xc49fb900) sched_switch(c49fb900,c49ed180,1,7df13994,8c50c615) at sched_switch+0x160 100300 (0xc4d13a80) sched_switch(c4d13a80,c49fb900,1,4a89bee0,ff6dc3f3) at sched_switch+0x160 100204 (0xc5f5c900) sched_switch(c5f5c900,c3d64900,1,612c604e,bdef9021) at sched_switch+0x160 100141 (0xc4f22d80) sched_switch(c4f22d80,c3c88c00,1,45b72b8e,590f2e9) at sched_switch+0x160 100277 (0xc622ad80) sched_switch(c622ad80,c5f5da80,1,d3e4acb4,64dadf) at sched_switch+0x160 100228 (0xc3e65300) sched_switch(c3e65300,c3c88300,1,3331449e,ff8b9b1) at sched_switch+0x160 100151 (0xc3e65000) sched_switch(c3e65000,0,1,646bef38,8e2dcf71) at sched_switch+0x160 100124 (0xc3b6f300) sched_switch(c3b6f300,0,1,d1599694,53f5b585) at sched_switch+0x160 100139 (0xc3b70480) sched_switch(c3b70480,0,1,c98fb2fe,6e71793e) at sched_switch+0x160 100088 (0xc4f1c180) sched_switch(c4f1c180,0,1,86f02fde,6dc34218) at sched_switch+0x160 100146 (0xc3f65600) sched_switch(c3f65600,c3b70480,1,6eca6dbe,6e6ba6b3) at sched_switch+0x160 100200 (0xc3e66780) sched_switch(c3e66780,0,1,1ded7970,fd39f1f3) at sched_switch+0x160 100199 (0xc3e66900) sched_switch(c3e66900,0,1,20776480,a49703a6) at sched_switch+0x160 100198 (0xc3e66a80) sched_switch(c3e66a80,0,1,5cd77526,2fbea73) at sched_switch+0x160 100197 (0xc3e66c00) sched_switch(c3e66c00,0,1,aae88704,a5fac4d8) at sched_switch+0x160 100196 (0xc3e66d80) sched_switch(c3e66d80,0,1,c040ba64,5c58ecc3) at sched_switch+0x160 100195 (0xc3ea3000) sched_switch(c3ea3000,0,1,ffc35024,a40d24ae) at sched_switch+0x160 100194 (0xc3ea3180) sched_switch(c3ea3180,0,1,1a310e14,4f11edc6) at sched_switch+0x160 100193 (0xc3ea3300) sched_switch(c3ea3300,0,1,11253b5e,fd508553) at sched_switch+0x160 100192 (0xc3ea3480) sched_switch(c3ea3480,0,1,d037e94e,a5ae9536) at sched_switch+0x160 100191 (0xc3ea3600) sched_switch(c3ea3600,0,1,448973cc,59f2d285) at sched_switch+0x160 100190 (0xc3ea3780) sched_switch(c3ea3780,0,1,544decb2,5ced1aa6) at sched_switch+0x160 100189 (0xc3ea3900) sched_switch(c3ea3900,0,1,6836ae2,98f9ceb9) at sched_switch+0x160 100188 (0xc3ea3a80) sched_switch(c3ea3a80,0,1,1a0dc262,a3f71ded) at sched_switch+0x160 100187 (0xc3ea3c00) sched_switch(c3ea3c00,0,1,444e3da8,a598bd54) at sched_switch+0x160 100186 (0xc3ea3d80) sched_switch(c3ea3d80,0,1,8960b20a,fc23ac48) at sched_switch+0x160 100185 (0xc3ea7000) sched_switch(c3ea7000,0,1,5fa1373a,101f7c5) at sched_switch+0x160 100184 (0xc3ea7180) sched_switch(c3ea7180,0,1,1a4e1f9c,a4d679a5) at sched_switch+0x160 100183 (0xc3ea7300) sched_switch(c3ea7300,0,1,f26f1a50,81eb278a) at sched_switch+0x160 100182 (0xc3ea7480) sched_switch(c3ea7480,0,1,9f3417a2,990bf878) at sched_switch+0x160 100181 (0xc3ea7600) sched_switch(c3ea7600,0,1,860a4b48,a6357828) at sched_switch+0x160 100180 (0xc3ea7780) sched_switch(c3ea7780,0,1,4b9dcb9e,ee3f9b) at sched_switch+0x160 100179 (0xc3c85780) sched_switch(c3c85780,0,1,bfd29fde,a7434c1b) at sched_switch+0x160 100178 (0xc3c85d80) sched_switch(c3c85d80,0,1,f7e31ec8,a327defb) at sched_switch+0x160 100177 (0xc3b70180) sched_switch(c3b70180,0,1,76ab677a,a75766b4) at sched_switch+0x160 100176 (0xc3829900) sched_switch(c3829900,0,1,e1ba2526,30eaa30) at sched_switch+0x160 100175 (0xc3c7e180) sched_switch(c3c7e180,0,1,421e3f9e,5c467355) at sched_switch+0x160 100174 (0xc3b70900) sched_switch(c3b70900,0,1,9687c0ba,f80e7d82) at sched_switch+0x160 100173 (0xc3c85600) sched_switch(c3c85600,0,1,cc2c600a,81cd95a3) at sched_switch+0x160 100172 (0xc3c7f000) sched_switch(c3c7f000,0,1,68be1c46,5a180251) at sched_switch+0x160 100171 (0xc3c7e000) sched_switch(c3c7e000,0,1,78595dde,fc0df9e5) at sched_switch+0x160 100170 (0xc3c85900) sched_switch(c3c85900,0,1,62845a0e,5d06302d) at sched_switch+0x160 100169 (0xc3c7f300) sched_switch(c3c7f300,0,1,74e1a53a,f7f8cfcf) at sched_switch+0x160 100152 (0xc3c7f180) sched_switch(c3c7f180,0,1,aca934fc,81405547) at sched_switch+0x160 100085 (0xc3829d80) sched_switch(c3829d80,0,1,31e7f0ea,27a29388) at sched_switch+0x160 100132 (0xc4f51300) sched_switch(c4f51300,0,1,b379b410,2e284172) at sched_switch+0x160 100113 (0xc361a600) sched_switch(c361a600,c4f51300,1,683ed010,2e1b5da0) at sched_switch+0x160 100077 (0xc355ea80) sched_switch(c355ea80,0,1,356f28d0,2e2a162c) at sched_switch+0x160 100265 (0xc3f14900) sched_switch(c3f14900,0,1,127defba,f008b136) at sched_switch+0x160 100070 (0xc3828780) sched_switch(c3828780,0,1,9d37b56c,6337e43a) at sched_switch+0x160 100109 (0xc38a4000) sched_switch(c38a4000,0,1,a51c72d2,e7e085e0) at sched_switch+0x160 100110 (0xc389dd80) sched_switch(c389dd80,0,1,c6b2775c,e747db78) at sched_switch+0x160 100106 (0xc38a4480) sched_switch(c38a4480,0,1,4affd136,e889ff34) at sched_switch+0x160 100078 (0xc389d900) sched_switch(c389d900,0,1,13c985c4,e809aed1) at sched_switch+0x160 100098 (0xc38a5180) sched_switch(c38a5180,0,1,1ec9f55e,e833b436) at sched_switch+0x160 100101 (0xc38a4c00) sched_switch(c38a4c00,0,1,f4cc778e,25ff41eb) at sched_switch+0x160 100068 (0xc3828a80) sched_switch(c3828a80,0,1,20b9eac,1c043201) at sched_switch+0x160 100105 (0xc38a4600) sched_switch(c38a4600,0,1,4981bd04,39cb983b) at sched_switch+0x160 100064 (0xc355d000) sched_switch(c355d000,0,1,5df6b2c8,d2e7687d) at sched_switch+0x160 100144 (0xc4f1c600) sched_switch(c4f1c600,0,1,83bc94e2,e49a164) at sched_switch+0x160 100116 (0xc520cc00) sched_switch(c520cc00,0,1,b3879762,e29fdd4) at sched_switch+0x160 100168 (0xc5efd000) sched_switch(c5efd000,c4f1c600,1,655752a4,e336263) at sched_switch+0x160 100140 (0xc5e10180) sched_switch(c5e10180,c3d64900,1,ef67a354,67ddc8cb) at sched_switch+0x160 100225 (0xc4abb300) sched_switch(c4abb300,c4f76600,1,1e1680f8,a5e568e0) at sched_switch+0x160 100138 (0xc3c7ea80) sched_switch(c3c7ea80,0,1,e5657842,f23ee64b) at sched_switch+0x160 100119 (0xc3b6fa80) sched_switch(c3b6fa80,c3c7e780,1,61c04e0e,e751b60a) at sched_switch+0x160 100150 (0xc4166900) sched_switch(c4166900,0,1,7e8f7ebc,63e4f0ce) at sched_switch+0x160 100167 (0xc60c9300) sched_switch(c60c9300,c4166900,1,3cde634a,96c2bc1e) at sched_switch+0x160 100237 (0xc4f56c00) sched_switch(c4f56c00,0,1,37303e4c,63dbb66f) at sched_switch+0x160 100142 (0xc60cad80) sched_switch(c60cad80,0,1,35ec0f10,53770376) at sched_switch+0x160 100133 (0xc3c7ed80) sched_switch(c3c7ed80,0,1,1f274368,ed6170bf) at sched_switch+0x160 100120 (0xc3b6f900) sched_switch(c3b6f900,c355ea80,1,df4d25cc,e872a7dd) at sched_switch+0x160 100254 (0xc4d14900) sched_switch(c4d14900,0,1,76a4275a,c83aac05) at sched_switch+0x160 100256 (0xc60c9c00) sched_switch(c60c9c00,c4d14900,1,b0745d6,c833753f) at sched_switch+0x160 100230 (0xc5efdc00) sched_switch(c5efdc00,0,1,b772edf4,c830bad8) at sched_switch+0x160 100131 (0xc3c7f600) sched_switch(c3c7f600,0,1,5a288ba6,5db5ff77) at sched_switch+0x160 100121 (0xc3b6f780) sched_switch(c3b6f780,c3c7f300,1,dbf284d2,e5a7927d) at sched_switch+0x160 100122 (0xc3b6f600) sched_switch(c3b6f600,0,1,fba2ff26,da22fdd9) at sched_switch+0x160 100080 (0xc389d600) sched_switch(c389d600,0,1,32601d56,9f30d031) at sched_switch+0x160 100107 (0xc38a4300) sched_switch(c38a4300,0,1,cc94805e,86634d94) at sched_switch+0x160 100082 (0xc389d300) sched_switch(c389d300,0,1,9967fe14,48feda89) at sched_switch+0x160 100092 (0xc3829300) sched_switch(c3829300,0,1,36b88956,d703a98f) at sched_switch+0x160 100096 (0xc38a5480) sched_switch(c38a5480,0,1,c60c13f0,d705fcd7) at sched_switch+0x160 100067 (0xc3828c00) sched_switch(c3828c00,0,1,ad84418e,567994e8) at sched_switch+0x160 100084 (0xc389d000) sched_switch(c389d000,0,1,2f10b1c4,67c047ab) at sched_switch+0x160 100081 (0xc389d480) sched_switch(c389d480,0,1,4012d430,b6903102) at sched_switch+0x160 100103 (0xc38a4900) sched_switch(c38a4900,0,1,7f46c43c,e3b56dff) at sched_switch+0x160 100090 (0xc3829600) sched_switch(c3829600,0,1,d2f48564,9f586b7) at sched_switch+0x160 100227 (0xc5f5ca80) sched_switch(c5f5ca80,0,1,70b05e4,14e20f23) at sched_switch+0x160 100244 (0xc4d19a80) sched_switch(c4d19a80,c5f5ca80,1,4592fd4c,14de52f0) at sched_switch+0x160 100234 (0xc49fb180) sched_switch(c49fb180,0,1,dc1e8762,14e3cc6c) at sched_switch+0x160 100114 (0xc3c88a80) sched_switch(c3c88a80,c4a86a80,1,1d700794,4cd31a9) at sched_switch+0x160 100112 (0xc3b70600) sched_switch(c3b70600,0,1,a1eecce,4c22e160) at sched_switch+0x160 100063 (0xc355d180) sched_switch(c355d180,0,1,1658f664,d8f64f48) at sched_switch+0x160 100089 (0xc3829780) sched_switch(c3829780,0,1,79b90ec2,5afa0fe4) at sched_switch+0x160 100094 (0xc38a5780) sched_switch(c38a5780,0,1,478ea1de,239904a0) at sched_switch+0x160 100104 (0xc38a4780) sched_switch(c38a4780,0,1,d236590c,bc7d624c) at sched_switch+0x160 100100 (0xc38a4d80) sched_switch(c38a4d80,0,1,8d214e42,141a4219) at sched_switch+0x160 100093 (0xc3829180) sched_switch(c3829180,0,1,2ed3bd8c,8b0d0012) at sched_switch+0x160 100095 (0xc38a5600) sched_switch(c38a5600,0,1,b8fed4e0,31033279) at sched_switch+0x160 100069 (0xc3828900) sched_switch(c3828900,0,1,49e93b8c,c6e7d922) at sched_switch+0x160 100073 (0xc3828300) sched_switch(c3828300,0,1,b7c4904c,469710d8) at sched_switch+0x160 100074 (0xc3828180) sched_switch(c3828180,0,1,3825e9ac,8f7f66d0) at sched_switch+0x160 100075 (0xc3828000) sched_switch(c3828000,0,1,340c7fc,7562a9ce) at sched_switch+0x160 100076 (0xc355ed80) sched_switch(c355ed80,0,1,c3dd6030,64df8a2a) at sched_switch+0x160 100050 (0xc355e600) sched_switch(c355e600,0,1,fb024458,dae27a36) at sched_switch+0x160 100051 (0xc355e480) sched_switch(c355e480,0,1,ba22af90,fc1cb7c6) at sched_switch+0x160 100052 (0xc355e300) kdb_enter(c075ddb2,a,9e0a90,417ff9,e69e0aac) at kdb_enter+0x30 100053 (0xc355e180) sched_switch(c355e180,0,1,ac51fea4,4bc57042) at sched_switch+0x160 100054 (0xc355e000) sched_switch(c355e000,0,1,2d9af1d4,97116f1c) at sched_switch+0x160 100055 (0xc355dd80) sched_switch(c355dd80,0,1,adc0148c,1e62d385) at sched_switch+0x160 100056 (0xc355dc00) sched_switch(c355dc00,0,1,67d0bfd8,e30a8837) at sched_switch+0x160 100057 (0xc355da80) sched_switch(c355da80,0,1,6509ed8c,5917b859) at sched_switch+0x160 100058 (0xc355d900) sched_switch(c355d900,0,1,6db61f60,dd29d36a) at sched_switch+0x160 100059 (0xc355d780) sched_switch(c355d780,0,1,d90f0b8c,59287d9c) at sched_switch+0x160 100060 (0xc355d600) sched_switch(c355d600,0,1,e8ec9c38,37e0919c) at sched_switch+0x160 100061 (0xc355d480) sched_switch(c355d480,0,1,eb10fd8c,592789e3) at sched_switch+0x160 100062 (0xc355d300) sched_switch(c355d300,0,1,3accb40c,59273a36) at sched_switch+0x160 100038 (0xc354ea80) sched_switch(c354ea80,0,1,7e30100c,5926c9b9) at sched_switch+0x160 100039 (0xc354e900) sched_switch(c354e900,0,1,d9d1ed8c,15a7d67b) at sched_switch+0x160 100040 (0xc354e780) fork_trampoline() at fork_trampoline 100041 (0xc354e600) sched_switch(c354e600,0,1,b7f21c8c,c8f6d228) at sched_switch+0x160 100042 (0xc354e480) sched_switch(c354e480,0,1,ae6f8de8,488816e4) at sched_switch+0x160 100043 (0xc354e300) sched_switch(c354e300,0,1,db79368c,5924b818) at sched_switch+0x160 100044 (0xc354e180) fork_trampoline() at fork_trampoline 100045 (0xc354e000) sched_switch(c354e000,0,1,f8537864,508828) at sched_switch+0x160 100046 (0xc353fd80) sched_switch(c353fd80,0,1,d9de21be,bf25ef31) at sched_switch+0x160 100047 (0xc353fc00) sched_switch(c353fc00,0,1,a433e1d2,e3b4ecd0) at sched_switch+0x160 100048 (0xc353fa80) sched_switch(c353fa80,0,1,35d0085e,f026ab20) at sched_switch+0x160 100049 (0xc353f900) fork_trampoline() at fork_trampoline 100027 (0xc353f180) sched_switch(c353f180,c34df900,6,6f1b1704,98026e96) at sched_switch+0x160 100028 (0xc353f000) sched_switch(c353f000,0,1,f7632472,6d3fa016) at sched_switch+0x160 100029 (0xc34dfd80) fork_trampoline() at fork_trampoline 100030 (0xc34dfc00) fork_trampoline() at fork_trampoline 100031 (0xc34dfa80) sched_switch(c34dfa80,0,1,97ed3824,bd4146e6) at sched_switch+0x160 100032 (0xc34df900) sched_switch(c34df900,0,1,c56bd50a,d6c72fa9) at sched_switch+0x160 100033 (0xc34df780) fork_trampoline() at fork_trampoline 100034 (0xc34df600) fork_trampoline() at fork_trampoline 100035 (0xc34df480) fork_trampoline() at fork_trampoline 100036 (0xc354ed80) fork_trampoline() at fork_trampoline 100037 (0xc354ec00) fork_trampoline() at fork_trampoline 100017 (0xc34db900) fork_trampoline() at fork_trampoline 100018 (0xc34db780) fork_trampoline() at fork_trampoline 100019 (0xc34db600) fork_trampoline() at fork_trampoline 100020 (0xc34db480) sched_switch(c34db480,0,1,dfd87026,67b89d1) at sched_switch+0x160 100021 (0xc34db300) fork_trampoline() at fork_trampoline 100022 (0xc34db180) fork_trampoline() at fork_trampoline 100023 (0xc353f780) fork_trampoline() at fork_trampoline 100024 (0xc353f600) fork_trampoline() at fork_trampoline 100025 (0xc353f480) sched_switch(c353f480,0,1,e11d190c,2c827e41) at sched_switch+0x160 100026 (0xc353f300) fork_trampoline() at fork_trampoline 100008 (0xc34da300) fork_trampoline() at fork_trampoline 100009 (0xc34da180) sched_switch(c34da180,0,1,7ea4249a,8d78e619) at sched_switch+0x160 100010 (0xc34da000) fork_trampoline() at fork_trampoline 100011 (0xc34df300) fork_trampoline() at fork_trampoline 100012 (0xc34df180) fork_trampoline() at fork_trampoline 100042 (0xc354e480) sched_switch(c354e480,0,1,ae6f8de8,488816e4) at sched_switch+0x160 100043 (0xc354e300) sched_switch(c354e300,0,1,db79368c,5924b818) at sched_switch+0x160 100044 (0xc354e180) fork_trampoline() at fork_trampoline 100045 (0xc354e000) sched_switch(c354e000,0,1,f8537864,508828) at sched_switch+0x160 100046 (0xc353fd80) sched_switch(c353fd80,0,1,d9de21be,bf25ef31) at sched_switch+0x160 100047 (0xc353fc00) sched_switch(c353fc00,0,1,a433e1d2,e3b4ecd0) at sched_switch+0x160 100048 (0xc353fa80) sched_switch(c353fa80,0,1,35d0085e,f026ab20) at sched_switch+0x160 100049 (0xc353f900) fork_trampoline() at fork_trampoline 100027 (0xc353f180) sched_switch(c353f180,c34df900,6,6f1b1704,98026e96) at sched_switch+0x160 100028 (0xc353f000) sched_switch(c353f000,0,1,f7632472,6d3fa016) at sched_switch+0x160 100029 (0xc34dfd80) fork_trampoline() at fork_trampoline 100030 (0xc34dfc00) fork_trampoline() at fork_trampoline 100031 (0xc34dfa80) sched_switch(c34dfa80,0,1,97ed3824,bd4146e6) at sched_switch+0x160 100032 (0xc34df900) sched_switch(c34df900,0,1,c56bd50a,d6c72fa9) at sched_switch+0x160 100033 (0xc34df780) fork_trampoline() at fork_trampoline 100034 (0xc34df600) fork_trampoline() at fork_trampoline 100035 (0xc34df480) fork_trampoline() at fork_trampoline 100036 (0xc354ed80) fork_trampoline() at fork_trampoline 100037 (0xc354ec00) fork_trampoline() at fork_trampoline 100017 (0xc34db900) fork_trampoline() at fork_trampoline 100018 (0xc34db780) fork_trampoline() at fork_trampoline 100019 (0xc34db600) fork_trampoline() at fork_trampoline 100020 (0xc34db480) sched_switch(c34db480,0,1,dfd87026,67b89d1) at sched_switch+0x160 100021 (0xc34db300) fork_trampoline() at fork_trampoline 100022 (0xc34db180) fork_trampoline() at fork_trampoline 100023 (0xc353f780) fork_trampoline() at fork_trampoline 100024 (0xc353f600) fork_trampoline() at fork_trampoline 100025 (0xc353f480) sched_switch(c353f480,0,1,e11d190c,2c827e41) at sched_switch+0x160 100026 (0xc353f300) fork_trampoline() at fork_trampoline 100008 (0xc34da300) fork_trampoline() at fork_trampoline 100009 (0xc34da180) sched_switch(c34da180,0,1,7ea4249a,8d78e619) at sched_switch+0x160 100010 (0xc34da000) fork_trampoline() at fork_trampoline 100011 (0xc34df300) fork_trampoline() at fork_trampoline 100012 (0xc34df180) fork_trampoline() at fork_trampoline 100013 (0xc34df000) fork_trampoline() at fork_trampoline 100014 (0xc34dbd80) fork_trampoline() at fork_trampoline 100015 (0xc34dbc00) fork_trampoline() at fork_trampoline 100016 (0xc34dba80) fork_trampoline() at fork_trampoline 100000 (0xc34db000) fork_trampoline() at fork_trampoline 100001 (0xc34dad80) fork_trampoline() at fork_trampoline 100002 (0xc34dac00) fork_trampoline() at fork_trampoline 100003 (0xc34daa80) sched_switch(c34daa80,0,1,a928b8f8,b0f056e3) at sched_switch+0x160 100004 (0xc34da900) sched_switch(c34da900,0,1,1ed57904,57a551b2) at sched_switch+0x160 100005 (0xc34da780) sched_switch(c34da780,0,1,acc16ddc,3366968) at sched_switch+0x160 100006 (0xc34da600) sched_switch(c34da600,0,1,8165208,1e4f0201) at sched_switch+0x160 100007 (0xc34da480) sched_switch(c34da480,0,1,80fa0f0c,591aaaf3) at sched_switch+0x160 0 (0xc079e0a0) sched_switch(c079e0a0,0,1,89dc4e8c,26fda0de) at sched_switch+0x160 db> call boot(0) Waiting (max 60 seconds) for system process `vnlru' to stop... And the system freeze again ... Here is the dmesg: Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-RELEASE #0: Thu Dec 22 11:15:36 CET 2005 root@morzine.ciger.be:/usr/obj/usr/src/sys/MORZINE WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) III CPU family 1266MHz (1260.61-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383fbff real memory = 2147483648 (2048 MB) avail memory = 2096680960 (1999 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 3 cpu1 (AP): APIC ID: 0 ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: on acpi0 pci_link1: on acpi0 pci_link2: on acpi0 pci_link3: on acpi0 pci_link4: irq 5 on acpi0 pci_link5: on acpi0 pci_link6: on acpi0 pci_link7: on acpi0 pci_link8: on acpi0 pci_link9: on acpi0 pci_link10: on acpi0 pci_link11: on acpi0 pci_link12: irq 9 on acpi0 pci_link13: irq 10 on acpi0 pci_link14: irq 9 on acpi0 pci_link15: on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xf008-0xf00b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: on acpi0 pci0: on pcib0 pci0: at device 4.0 (no driver attached) fxp0: port 0x1400-0x143f mem 0xfc021000-0xfc021fff,0xfc000000-0xfc0 1ffff irq 30 at device 10.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:30:05:19:9f:a8 fxp0: [GIANT-LOCKED] isab0: port 0xf100-0xf10f at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1800-0x180 f at device 15.1 on pci0 ata0: on atapci0 ata1: on atapci0 ohci0: mem 0xfc022000-0xfc022fff irq 28 at device 15.2 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered pcib1: on acpi0 pci1: on pcib1 sym0: <1010-66> port 0x1c00-0x1cff mem 0xfe004000-0xfe0043ff,0xfe000000-0xfe001fff irq 20 at device 8.0 on pci1 sym0: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: handling phase mismatch from SCRIPTS. sym0: [GIANT-LOCKED] sym1: <1010-66> port 0x2000-0x20ff mem 0xfe004400-0xfe0047ff,0xfe002000-0xfe003fff irq 29 at device 10.0 on pci1 sym1: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking sym1: open drain IRQ line driver, using on-chip SRAM sym1: using LOAD/STORE-based firmware. sym1: handling phase mismatch from SCRIPTS. sym1: [GIANT-LOCKED] pcib2: on acpi0 pci2: on pcib2 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37b irq 7 on acpi0 ppc0: port 0x378-0x37b irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x90 on acpi0 sio0: type 16550A, console sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xccfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <4 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec IPv6 packet filtering initialized, default to accept, logging limited to 100 packets/entry IPsec: Initialized Security Association Processing. ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding enabled, default to deny, logging limited to 100 packets/entry by default acd0: CDROM at ata1-master UDMA33 Waiting 3 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. GEOM_LABEL: Label for provider fd0 is msdosfs/DOS 6_22. (probe22:sym1:0:8:0): phase change 6-7 6@00c7a58c resid=4. sa0 at sym0 bus 0 target 4 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit) pass5 at sym1 bus 0 target 8 lun 0 pass5: Fixed Processor SCSI-2 device pass5: 3.300MB/s transfers da0 at sym1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 62, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da1 at sym1 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 160.000MB/s transfers (80.000MHz, offset 62, 16bit), Tagged Queueing Enabled da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da2 at sym1 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 160.000MB/s transfers (80.000MHz, offset 62, 16bit), Tagged Queueing Enabled da2: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da3 at sym1 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-3 device da3: 160.000MB/s transfers (80.000MHz, offset 62, 16bit), Tagged Queueing Enabled da3: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/da0s1a Any help / advice really appreciated ... Henri From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 12:05:42 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CCE716A41F; Sat, 7 Jan 2006 12:05:42 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B18643D60; Sat, 7 Jan 2006 12:05:35 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 9C0BF20A9; Sat, 7 Jan 2006 13:05:13 +0100 (CET) X-Spam-Tests: AWL,BAYES_00,FORGED_RCVD_HELO X-Spam-Learn: ham X-Spam-Score: -3.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id 7DC8F20A8; Sat, 7 Jan 2006 13:05:13 +0100 (CET) Received: by xps.des.no (Postfix, from userid 1001) id 5833A33C3E; Sat, 7 Jan 2006 13:05:13 +0100 (CET) To: Jo Rhett References: <43A266E5.3080103@samsco.org> <43AB1E65.2030501@mac.com> <20051222221202.GM39174@svcolo.com> <200512231136.12471.doconnor@gsoft.com.au> <20060105092448.GH1358@svcolo.com> <20060105184147.GD69162@funkthat.com> <20060106110318.GF54324@svcolo.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sat, 07 Jan 2006 13:05:13 +0100 In-Reply-To: <20060106110318.GF54324@svcolo.com> (Jo Rhett's message of "Fri, 6 Jan 2006 03:03:18 -0800") Message-ID: <86irsw1bwm.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 12:05:42 -0000 Jo Rhett writes: > On Thu, Jan 05, 2006 at 10:41:47AM -0800, John-Mark Gurney wrote: > > Bottom line: Once code exists, then support can be talked about.. > This is the chicken and egg problem that will kill FreeBSD. So *you're* the AC that keeps predicting the death of *BSD on /.! > I don't bother writing up patches for FreeBSD because every time I > do they sit in a PR and get ignored for several years. Then someone > that does have commit rights makes their own patch (which often is > less useful) but they own it and the best I've ever succeeded at was > convincing them to put some of the ideas from my patch into their > code. Every single time? There are five PRs with your name on in GNATS (assuming you and are one and same) ports/76013 - patch committed after four months ports/76019 - superceded after a month ports/76041 - duplicate of ports/76013 ports/76724 - patch committed after a week docs/87445 - immediately adopted by a committer, being worked on Oh, how we have wronged you! Please let us know how we may correct this grievous injustice! DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 14:16:22 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AA7416A420 for ; Sat, 7 Jan 2006 14:16:22 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-3-1-cust208.cdif.cable.ntl.com [82.31.78.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D36B43D46 for ; Sat, 7 Jan 2006 14:16:21 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EvErk-000Eur-Gn; Sat, 07 Jan 2006 14:16:20 +0000 Date: Sat, 7 Jan 2006 14:16:20 +0000 From: Ceri Davies To: Marius Nuennerich Message-ID: <20060107141620.GO86645@submonkey.net> Mail-Followup-To: Ceri Davies , Marius Nuennerich , freebsd-stable@freebsd.org References: <20060105134133.61aef78f@sol> <20060106151441.GE86645@submonkey.net> <20060107013534.6b1ebdab@sol> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Po3hG7FLjYU3tiSY" Content-Disposition: inline In-Reply-To: <20060107013534.6b1ebdab@sol> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.11 Sender: Ceri Davies Cc: freebsd-stable@freebsd.org Subject: Re: /boot/nextboot.conf not deactivated after one boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 14:16:22 -0000 --Po3hG7FLjYU3tiSY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 07, 2006 at 01:35:34AM +0100, Marius Nuennerich wrote: > On Fri, 6 Jan 2006 15:14:41 +0000 > Ceri Davies wrote: >=20 > > On Thu, Jan 05, 2006 at 01:41:33PM +0100, Marius Nuennerich wrote: > > > Hi folks, > > >=20 > > > it seems like /boot/nextboot.conf is neither deleted nor > > > nextboot_enable set to NO on the first line after a reboot. > > > So it isn't a one shot anymore as the manpage claims. > > >=20 > > > System is 6.0-RELEASE. > >=20 > > I think this is down to a typo in /etc/rc.d/root; at least I can't find > > any other reference to /boot/nextkernel in src/. Patch attached > > (root.diff). > >=20 > > > It would also be fine imo, if the -k option would be optional and the > > > next kernel defaults to "kernel". > >=20 > > I'm not sure if getopts can be persuaded to take an optional argument to > > an option. If not, the attached patch (nextboot.diff) should work for > > you. >=20 > I tested both patches and they work as they should. Please commit :) OK, awaiting mentor approval. Thanks for the report and for testing. Ceri --=20 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Einstein (attrib.) --Po3hG7FLjYU3tiSY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDv800ocfcwTS3JF8RAgpZAJ9YvF7fem0VZJpItp4K3lTS1avoPACfZMAG XuOebXEOq9v1LqrITODB2tM= =MfQW -----END PGP SIGNATURE----- --Po3hG7FLjYU3tiSY-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 14:33:15 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 618A216A420 for ; Sat, 7 Jan 2006 14:33:15 +0000 (GMT) (envelope-from kaasboer@laverenz.de) Received: from natblindhugh.rzone.de (natblindhugh.rzone.de [81.169.145.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8351A43D46 for ; Sat, 7 Jan 2006 14:33:13 +0000 (GMT) (envelope-from kaasboer@laverenz.de) Received: from athena.laverenz.de (p5480FE47.dip.t-dialin.net [84.128.254.71]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id k07EXADO004565 for ; Sat, 7 Jan 2006 15:33:11 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by athena.laverenz.de (Postfix) with ESMTP id BB286E395E21 for ; Sat, 7 Jan 2006 15:33:10 +0100 (CET) Received: from athena.laverenz.de ([127.0.0.1]) by localhost (athena [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11216-02 for ; Sat, 7 Jan 2006 15:33:10 +0100 (CET) Received: from localhost.localdomain (brianna.laverenz.de [192.168.100.88]) by athena.laverenz.de (Postfix) with ESMTP id D1F88E395E20 for ; Sat, 7 Jan 2006 15:33:09 +0100 (CET) Received: by localhost.localdomain (Postfix, from userid 1000) id 0EB425C00F6; Sat, 7 Jan 2006 15:33:09 +0100 (CET) Resent-From: uwe@laverenz.de Resent-Date: Sat, 7 Jan 2006 15:33:09 +0100 Resent-Message-ID: <20060107143309.GA9706@laverenz.de> Resent-To: stable@freebsd.org Date: Fri, 6 Jan 2006 23:00:16 +0100 From: Uwe Laverenz To: stable@freebsd.org Message-ID: <20060106220016.GB25957@laverenz.de> Mail-Followup-To: stable@freebsd.org References: <43BD90E9.3020305@wintek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43BD90E9.3020305@wintek.com> Organization: private site Sender: uwe@laverenz.de User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at laverenz.de Cc: Subject: Re: gdm problem with kernel as of 2005-01-04 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 14:33:15 -0000 On Thu, Jan 05, 2006 at 04:34:33PM -0500, Richard Kuhns wrote: > If anyone has suggestions/wants me to try anything, just say so. Yes, you can solve this problem by changing your /usr/X11R6/etc/gdm/gdm.conf. You have to change the setting for VTAllocation: VTAllocation=true bye, Uwe From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 15:48:46 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3152016A41F for ; Sat, 7 Jan 2006 15:48:46 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.178.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 921E543D46 for ; Sat, 7 Jan 2006 15:48:45 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from [217.185.80.92] (manz-d9b9505c.pool.mediaWays.net [217.185.80.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate1.zdv.Uni-Mainz.DE (Postfix) with ESMTP id E636330001B5; Sat, 7 Jan 2006 16:48:42 +0100 (CET) Message-ID: <43BFE2D9.5050208@mail.uni-mainz.de> Date: Sat, 07 Jan 2006 16:48:41 +0100 From: "O. Hartmann" User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D8ystein_Holmen?= References: <5B4D3B12-8528-4D07-9B03-874D0A7A52B5@holmen.cc> <20060106171840.A49126@cons.org> In-Reply-To: <20060106171840.A49126@cons.org> Content-Type: multipart/mixed; boundary="------------000802020502030806030202" X-Virus-Scanned: by amavisd-new at uni-mainz.de X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Motherboard X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 15:48:46 -0000 This is a multi-part message in MIME format. --------------000802020502030806030202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Martin Cracauer wrote: I use the A8N-SLI Deluxe. >Øystein Holmen wrote on Fri, Jan 06, 2006 at 11:03:18PM +0100: > > >>Hi all! >> >>I'm setting up a new server with FreeBSD 6.0. The motherboard I am >>planning to use is Asus A8N-SLI Premium. Does anyone know if the on- >>board ethernet controller (nve(4)) works? >> >> > >Works for me with the newest 7-current commits, but losing carrier >means temporary machine hang. The other GbE on the board works, too. > > Right, nve(4) sometimes stops working, but it seems to have the best performance to me. sk(4) also works, more reliable, but is bound to PCI32 bus. >Temperature monitoring is also functional. > >Be warned that this board even with the newest BIOS does not correctly >do remapping of the physical memory between 3-4 GB to above 4 GB. > > That's bad to read. I plan to upgrade my box up to 4GB RAM. :-( > > >>Also I'm planning on getting this graphics controller: Gainward >>GeForce 6200 TurboCache, PCI-Express. >> >> I use a MSI NE6600 PCIe board, 256MB video RAM. Don't expect high performance without appropriate drivers! > >Works for me, "nv" driver. No "nvidia" driver for FreeBSD/AMD64. > >Martin > > Oliver --------------000802020502030806030202-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 16:38:28 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8427E16A41F for ; Sat, 7 Jan 2006 16:38:28 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4DF043D45 for ; Sat, 7 Jan 2006 16:38:27 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k07GcQCb028211; Sat, 7 Jan 2006 14:38:27 -0200 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR To: freebsd-stable@freebsd.org Date: Sat, 7 Jan 2006 14:38:28 -0200 User-Agent: KMail/1.8.3 References: <5B4D3B12-8528-4D07-9B03-874D0A7A52B5@holmen.cc> <20060106171840.A49126@cons.org> <43BFE2D9.5050208@mail.uni-mainz.de> In-Reply-To: <43BFE2D9.5050208@mail.uni-mainz.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200601071438.28751.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on msrv.matik.com.br X-Virus-Status: Clean Cc: "O. Hartmann" , =?iso-8859-1?q?=D8ystein_Holmen?= Subject: Re: Motherboard X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 16:38:28 -0000 On Saturday 07 January 2006 13:48, O. Hartmann wrote: > Right, nve(4) sometimes stops working, but it seems to have the best > performance to me. > sk(4) also works, more reliable, but is bound to PCI32 bus. > not exactly ...=20 you can have a look at this PR if you like: kern/91000 but the nve driver on releng_6 seems to work, at least for me since last=20 correction in releng_6, but I have another motherboard with the nvidia-3=20 chipset Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 17:32:42 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFECD16A41F for ; Sat, 7 Jan 2006 17:32:42 +0000 (GMT) (envelope-from neo@timp.be) Received: from lns-bzn-49f-81-56-172-124.adsl.proxad.net (lns-bzn-49f-81-56-172-124.adsl.proxad.net [81.56.172.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4278843D45 for ; Sat, 7 Jan 2006 17:32:41 +0000 (GMT) (envelope-from neo@timp.be) Received: by neo.timp.be (Postfix, from userid 1000) id 0B0E5C136; Thu, 5 Jan 2006 16:02:53 +0100 (CET) Date: Thu, 5 Jan 2006 16:02:53 +0100 From: Neo To: freebsd-stable@freebsd.org Message-ID: <20060105150253.GA67715@neo.timp.be> References: <43BD2794.8020000@cnptia.embrapa.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43BD2794.8020000@cnptia.embrapa.br> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://www.timp.be/key.txt Subject: Re: Postfix and faststart X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 17:32:42 -0000 On Thu, Jan 05, 2006 at 12:05:08PM -0200, Carlos Fernando Assis Paniago wrote: > Hi: after the last cvsup, my FreeBSD 6.0, i386 is not capable to start > postfix. I'm using the link in the /usr/local/etc/rc.d/postfix.sh to > start the postfix program. Looking in the code, I saw that we need to > change this in a file in /usr/local/etc/postfix/postfix-script to have > the "faststart" flag.. Someone else find this problem? > > -- > Paniago > > -- > Carlos F. A. Paniago pan@cnptia.embrapa.br > http://www.cnptia.embrapa.br/ Fone: +55 (19) 3789-5815 Hello, You have probably merged the mailer.conf when you have done a new world. Look at /etc/mail/mailer.conf if its look like the following lines. # # Execute the Postfix sendmail program, named /usr/local/sbin/sendmail # sendmail /usr/local/sbin/sendmail send-mail /usr/local/sbin/sendmail mailq /usr/local/sbin/sendmail newaliases /usr/local/sbin/sendmail By the way, my postfix is started at boot in using rc.conf This starts sendmail with the -bd flag who launch postfix sendmail_enable="YES" sendmail_flags="-bd" These lines disables others sendmail daemons sendmail_submit_enable="NO" sendmail_outbound_enable="NO" sendmail_msp_queue_enable="NO" If you want to start postfix after to be log in, just use "postfix start" I hope that help you. Sincerely yours, Ulrich Blondel From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 19:54:32 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A97816A41F for ; Sat, 7 Jan 2006 19:54:32 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id F23FE43D45 for ; Sat, 7 Jan 2006 19:54:31 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 90396 invoked by uid 399); 7 Jan 2006 19:54:31 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 7 Jan 2006 19:54:31 -0000 Message-ID: <43C01C75.6020504@FreeBSD.org> Date: Sat, 07 Jan 2006 11:54:29 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20051226) MIME-Version: 1.0 To: Carlos Fernando Assis Paniago References: <43BD2794.8020000@cnptia.embrapa.br> In-Reply-To: <43BD2794.8020000@cnptia.embrapa.br> Content-Type: multipart/mixed; boundary="------------030107060302000507010809" Cc: vivek@khera.org, freebsd-stable@freebsd.org Subject: Re: Postfix and faststart X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 19:54:32 -0000 This is a multi-part message in MIME format. --------------030107060302000507010809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Carlos Fernando Assis Paniago wrote: > Hi: after the last cvsup, my FreeBSD 6.0, i386 is not capable to start > postfix. I'm using the link in the /usr/local/etc/rc.d/postfix.sh to > start the postfix program. Looking in the code, I saw that we need to > change this in a file in /usr/local/etc/postfix/postfix-script to have > the "faststart" flag.. Someone else find this problem? The way that it is suggested to start postfix in the pkg-message (by placing a link to /usr/local/sbin/postfix in /usr/local/etc/rc.d) is no longer valid with the new rc.d code in -stable. I've attached a script that works for me to start and stop postfix. Please remove the symlink you have in /usr/local/etc/rc.d now, and put this script in its place. Make sure that the script is executable (chmod 755 /usr/local/etc/rc.d/postfix.sh), then 'echo postfix_enable=yes >> /etc/rc.conf.local' and reboot. Then please let us know for sure that this worked for you. If the maintainer would like help including this in the port, I'd be glad to do so. If you want to create the update yourself, take a look at ports/misc/compat5x to see how to integrate this, or I'd be glad to work on it with you. hth, Doug -- This .signature sanitized for your protection --------------030107060302000507010809 Content-Type: text/plain; name="postfix.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="postfix.sh" #!/bin/sh # # $FreeBSD$ # # PROVIDE: postfix # REQUIRE: DAEMON # KEYWORD: shutdown # # Define these postfix_* variables in one of these files: # /etc/rc.conf # /etc/rc.conf.local # /etc/rc.conf.d/postfix # # DO NOT CHANGE THESE DEFAULT VALUES HERE # postfix_enable="${postfix_enable-NO}" . /etc/rc.subr name=postfix rcvar=`set_rcvar` start_cmd=${name}_start stop_cmd=${name}_stop postfix_start() { /usr/local/sbin/postfix start } postfix_stop() { /usr/local/sbin/postfix stop } load_rc_config ${name} run_rc_command "$1" --------------030107060302000507010809-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 7 23:45:13 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A05A516A41F; Sat, 7 Jan 2006 23:45:13 +0000 (GMT) (envelope-from gpalmer@freebsd.org) Received: from noop.colo.erols.net (noop.colo.erols.net [207.96.1.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48E9443D45; Sat, 7 Jan 2006 23:45:08 +0000 (GMT) (envelope-from gpalmer@freebsd.org) Received: from uucp by noop.colo.erols.net with local-rmail (Exim 4.52 (FreeBSD)) id 1EvNkB-000CfM-FX; Sat, 07 Jan 2006 18:45:07 -0500 Received: from localhost.home.in-addr.com ([127.0.0.1]:49489) by rimmer.home.in-addr.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EvNjt-000BuX-7J; Sat, 07 Jan 2006 23:44:49 +0000 Message-ID: <43C05270.60106@freebsd.org> Date: Sat, 07 Jan 2006 23:44:48 +0000 From: Gary Palmer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051130 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: devd and caseful device ID matching on 6.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 23:45:13 -0000 Hi Warner, I've been playing with devd and noticed that if you do something like: # # Dell TrueMobile 1300 WLAN PC Card # nomatch 10 { match "bus" "pci[0-9]+"; match "vendor" "0x14E4"; match "device" "0x4320"; match "subvendor" "0x1028"; match "subdevice" "0x0002"; action "kldload BCMWL5_SYS"; }; it won't match (at least on 6.0) as the regex that is used is case sensitive. Since these are hex numbers, could the comparison not be case insensitive? I'm not sure what implications just making the regex case insensitive will have on other matching clauses (e.g. for "system"). Thanks, Gary