From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 00:50:35 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9078216A473 for ; Sun, 4 Jun 2006 00:50:35 +0000 (UTC) (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 55F7143D45 for ; Sun, 4 Jun 2006 00:50:35 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 1479772DA5; Sat, 3 Jun 2006 17:49:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 0E75772D9F; Sat, 3 Jun 2006 17:49:08 -0700 (PDT) Date: Sat, 3 Jun 2006 17:49:08 -0700 (PDT) From: Doug White To: Maxim Sobolev In-Reply-To: <447B69EA.20502@sippysoft.com> Message-ID: <20060603174637.M40001@carver.gumbysoft.com> References: <447AB34C.4030509@sippysoft.com> <447B5A43.4000707@samsco.org> <447B69EA.20502@sippysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "current@freebsd.org" Subject: Re: Importing iSCSI target from NetBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 00:50:35 -0000 On Mon, 29 May 2006, Maxim Sobolev wrote: > Scott, > > It seems that you aren't aware that Intel/NetBSD implementation is completely > userland one and it uses any block device/file as backing store (no > interaction with CAM). Therefore, it won't interfere with whatever work you > and others do in the CAM area. For the record, this driver _is_ in-kernel and does attach to CAM, if you want a comparison point: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-16.tar.bz2 I've compiled a prior version of this and it appears to work, but haven't run any sort of test with it. I've wanted to play with iSCSI targets on FreeBSD but have lacked the requisite test equipment. One of these days I'll get the hour or two I need to put together a test rig. > > -Maxim > > Scott Long wrote: >> Maxim Sobolev wrote: >> >>> Hi, >>> >>> I wonder if anybody has any objections to importing iSCSI target daemon >>> from NetBSD (Intel) into the base. >>> >>> -Maxim >> >> Yes. I'm nearing completion of locking CAM, and adding new subsystems is >> not going >> to help that effort at the moment. I'd also like you to talk with Matt >> Jacob and Nate Lawson >> about it since they have quite a bit of current experience with the SCSI >> target side of things. >> So in other words, a drive-by commit is not welcome and will be drive-by >> uncommitted unless >> you work with the people who can provide help and guidance. >> >> Scott >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 00:56:41 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B319116A4DE for ; Sun, 4 Jun 2006 00:56:41 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 918DD43D5D for ; Sun, 4 Jun 2006 00:56:35 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k540uTxe030006; Sat, 3 Jun 2006 18:56:34 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44823080.9030709@samsco.org> Date: Sat, 03 Jun 2006 18:59:44 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug White References: <447AB34C.4030509@sippysoft.com> <447B5A43.4000707@samsco.org> <447B69EA.20502@sippysoft.com> <20060603174637.M40001@carver.gumbysoft.com> In-Reply-To: <20060603174637.M40001@carver.gumbysoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: "current@freebsd.org" , Maxim Sobolev Subject: Re: Importing iSCSI target from NetBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 00:56:42 -0000 Doug White wrote: > On Mon, 29 May 2006, Maxim Sobolev wrote: > >> Scott, >> >> It seems that you aren't aware that Intel/NetBSD implementation is >> completely userland one and it uses any block device/file as backing >> store (no interaction with CAM). Therefore, it won't interfere with >> whatever work you and others do in the CAM area. > > > For the record, this driver _is_ in-kernel and does attach to CAM, if > you want a comparison point: > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-16.tar.bz2 > > I've compiled a prior version of this and it appears to work, but > haven't run any sort of test with it. > > I've wanted to play with iSCSI targets on FreeBSD but have lacked the > requisite test equipment. One of these days I'll get the hour or two I > need to put together a test rig. > Last I knew, this driver was just an initiator. If he's added target support, that's great. Scott From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 01:03:57 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D39B16A49C for ; Sun, 4 Jun 2006 01:03:57 +0000 (UTC) (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 0408543D45 for ; Sun, 4 Jun 2006 01:03:57 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 30A0E72DA5; Sat, 3 Jun 2006 18:02:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 2A5AE72DA2; Sat, 3 Jun 2006 18:02:30 -0700 (PDT) Date: Sat, 3 Jun 2006 18:02:30 -0700 (PDT) From: Doug White To: Scott Long In-Reply-To: <44823080.9030709@samsco.org> Message-ID: <20060603175920.G40001@carver.gumbysoft.com> References: <447AB34C.4030509@sippysoft.com> <447B5A43.4000707@samsco.org> <447B69EA.20502@sippysoft.com> <20060603174637.M40001@carver.gumbysoft.com> <44823080.9030709@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "current@freebsd.org" , Maxim Sobolev Subject: Re: Importing iSCSI target from NetBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 01:03:57 -0000 On Sat, 3 Jun 2006, Scott Long wrote: > Last I knew, this driver was just an initiator. If he's added target > support, that's great. Thats what I get for jumping in a conversation halfway. I didn't notice this was a *target*-mode driver discussion. Danny's driver is still just an initiator. Sorry for the noise. I believe Wasabi is shipping that target driver in some of their storage-appliance software, so they feel confident about it apparently. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Jun 3 20:37:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1335E16A41F; Sat, 3 Jun 2006 20:37:26 +0000 (UTC) (envelope-from mi@aldan.algebra.com) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9467C43D46; Sat, 3 Jun 2006 20:37:25 +0000 (GMT) (envelope-from mi@aldan.algebra.com) Received: from corbulon.video-collage.com ([151.204.231.237]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J0A00CDUX9NSP44@vms042.mailsrvcs.net>; Sat, 03 Jun 2006 15:36:59 -0500 (CDT) Received: from vaio.virtual-estates.net (aldan.algebra.com [216.254.65.224]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k53KaqmP059678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 03 Jun 2006 16:36:53 -0400 (EDT envelope-from mi@aldan.algebra.com) Received: from vaio.virtual-estates.net (localhost [127.0.0.1]) by vaio.virtual-estates.net (8.13.4/8.13.4) with ESMTP id k53KaDlW082134; Sat, 03 Jun 2006 20:36:18 +0000 (envelope-from mi@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by vaio.virtual-estates.net (8.13.6/8.13.4/Submit) id k53KZqLf082133; Sat, 03 Jun 2006 20:35:52 +0000 (envelope-from mi@aldan.algebra.com) Date: Sat, 03 Jun 2006 20:35:50 +0000 From: "Mikhail T." X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli"<=?koi8-r?q?kcG=5EEOVihy+z3/UR=7B6SCQ=0A?= In-reply-to: <200606031009.04640.jhb@freebsd.org> To: John Baldwin Message-id: <200606032035.52075@Misha> MIME-version: 1.0 Content-type: text/plain; charset=koi8-r Content-transfer-encoding: quoted-printable Content-disposition: inline X-Virus-Scanned: ClamAV 0.88/1510/Sat Jun 3 08:07:20 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 References: <200606022121.20535.mi+mx@aldan.algebra.com> <200606031009.04640.jhb@freebsd.org> X-Authentication-warning: vaio.virtual-estates.net: mi set sender to mi@aldan.algebra.com using -f User-Agent: KMail/1.9.1 X-Mailman-Approved-At: Sun, 04 Jun 2006 04:46:12 +0000 Cc: Mikhail Teterin , freebsd-current@freebsd.org Subject: Re: Assembler optimizations for libz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 20:37:26 -0000 =D3=D5=C2=CF=D4=C1 03 =DE=C5=D2=D7=C5=CE=D8 2006 14:09, John Baldwin, =F7= =C9 =CE=C1=D0=C9=D3=C1=CC=C9: =3D Can you expand on the problem you have with inffast.S? There exist both inffast.c and inffast.S. Although the latter is in a directory, that is explicitly listed in the VPATH, the former is picked up. I think, it should be the other way around -- the current directory, that's always in the VPATH implicitly, should be consulted last... =46or this reason, I had to rename inffast.S to _inffast.S. =3D Also, it might read better if the flow of the Makefile is [...] =3D That is, merge the two i386 sections into one section. I'm quite confident, that I will NOT be able to pick the right color for this structure. :-) I'll leave the perfection of the Makefile to whoever commits it -- what's in it now works good enough to demonstrate the benefit of the optimization... Whoever gets to it, though, should add the amd64 implementation too (posted in this thread). It is just the compression for now, I'm still working on the inffast.S... Thanks! Yours, -mi http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/96393 From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 05:13:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B6ED16A41F for ; Sun, 4 Jun 2006 05:13:58 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id A908143D46 for ; Sun, 4 Jun 2006 05:13:57 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.pc (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.6/8.13.6/Debian-1) with ESMTP id k5451AR0006590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 4 Jun 2006 08:01:11 +0300 Received: from gothmog.pc (gothmog [127.0.0.1]) by gothmog.pc (8.13.6/8.13.6) with ESMTP id k5453L3R062239; Sun, 4 Jun 2006 08:03:21 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.pc (8.13.6/8.13.6/Submit) id k5453Ggd062238; Sun, 4 Jun 2006 08:03:16 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 4 Jun 2006 08:03:16 +0300 From: Giorgos Keramidas To: Kris Kennaway Message-ID: <20060604050316.GE61942@gothmog.pc> References: <20060523143013.GA11472@ci0.org> <20060523194106.GA46634@xor.obsecurity.org> <20060524203645.GB13500@gothmog.pc> <20060524203747.GA88742@xor.obsecurity.org> <20060524204617.GA13701@gothmog.pc> <20060601002024.GA1453@gothmog.pc> <20060601210655.GA36389@xor.obsecurity.org> <20060601213527.GA53422@gothmog.pc> <20060602215005.GA43170@nowhere> <20060602220724.GA71883@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060602220724.GA71883@xor.obsecurity.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.409, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.79, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: Craig Boston , freebsd-current@freebsd.org Subject: Re: md /tmp and async mounts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 05:13:58 -0000 On 2006-06-02 18:07, Kris Kennaway wrote: >On Fri, Jun 02, 2006 at 04:50:06PM -0500, Craig Boston wrote: >>On Fri, Jun 02, 2006 at 12:35:27AM +0300, Giorgos Keramidas wrote: >>> Ok, I'll prepare a patch that enables async and disables -M. We >>> should also document the fact that tmpmfs="YES" and varmfs="YES" >>> in rc.conf may require the presence of at least one swap device >>> by default, and point the users to -M with a warning if they run >>> FreeBSD without a swap device but still want to use tmpmfs or >>> varmfs :) >> >> I may be mistaken, but from my (brief) reading of the code it seems >> to me that perhaps "swap-backed" isn't an entirely accurate term. >> More like "VM-backed", with the understanding that VM is (usually) >> backed by swap. >> >> I think if you don't have any swap configured, a swap-backed md >> will be no worse off than a memory-backed one would. > > Yeah, it's kind of a poorly chosen name. Should we still revert the default from using -M for tmpmfs="YES" and varmfs="YES" in rc.conf? - Giorgos From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 05:35:37 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B557B16A477 for ; Sun, 4 Jun 2006 05:35:37 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F12943D46 for ; Sun, 4 Jun 2006 05:35:37 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id k545ZaQW043657 for ; Sat, 3 Jun 2006 22:35:36 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id k545ZaS4043656 for current@freebsd.org; Sat, 3 Jun 2006 22:35:36 -0700 (PDT) (envelope-from david) Date: Sat, 3 Jun 2006 22:35:36 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20060604053536.GH32476@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org References: <20060523194106.GA46634@xor.obsecurity.org> <20060524203645.GB13500@gothmog.pc> <20060524203747.GA88742@xor.obsecurity.org> <20060524204617.GA13701@gothmog.pc> <20060601002024.GA1453@gothmog.pc> <20060601210655.GA36389@xor.obsecurity.org> <20060601213527.GA53422@gothmog.pc> <20060602215005.GA43170@nowhere> <20060602220724.GA71883@xor.obsecurity.org> <20060604050316.GE61942@gothmog.pc> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPDwMsyfds7q4mrK" Content-Disposition: inline In-Reply-To: <20060604050316.GE61942@gothmog.pc> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: md /tmp and async mounts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 05:35:37 -0000 --ZPDwMsyfds7q4mrK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 04, 2006 at 08:03:16AM +0300, Giorgos Keramidas wrote: > ... > >> I think if you don't have any swap configured, a swap-backed md > >> will be no worse off than a memory-backed one would. I'd be rather strongly incline dto agree with that, FWIW. > > Yeah, it's kind of a poorly chosen name. >=20 > Should we still revert the default from using -M for tmpmfs=3D"YES" and > varmfs=3D"YES" in rc.conf? Ever since /usr/src/etc/rc.d/tmp rev. 1.35 (creation of $tmpmfs_flags), I have used the specification to avoid -M. I'd recommend that the default ought not be -M. Since Kris posed his query re: -o async, I changed my $tmpmfs_flags to include it -- both for 6-STABLE and for -CURRENT -- on my laptop, where I track each of those branches every day that there's a change to the corresponding source tree. (Well, save for last weekend, when I was off-Net for a couple of days....) While I haven't seen a noticable performance improvement from -o async, I've certainly not seen any negative impact at all. FWIW, the one other tweak to $tmpmfs_flags I find useful is to adjust the inode density to reflect a larger number of (smaller) files in the /tmp file system. On the laptop, where the daily buildworlds (and occasional builds of mozilla...) tend to be the most strenuous workout it gets, -i4096 seems to be OK. For CVS servers (which the laptop can be at times, though I prefer to use more dedicated resource to that sort of task), I find -i1024 to be preferable. (Recall the behavior of a CVS server when as "cvs update" is requested involves building an isomorphic directory hierarchy in /tmp. I was pleased to see that a CVS server I had set up had no problems doing 9 simultaneous "cvs update" runs against /usr/ports. Absent the -i1024 setting, that would likely have been less-than-satisfactory.) Peace, david --=20 David H. Wolfskill david@catwhisker.org Doing business with spammers only encourages them. Please boycott spammers. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --ZPDwMsyfds7q4mrK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkSCcScACgkQmprOCmdXAD2uhwCfUitjyJF9OvyMItGMGkOE1YEF D1EAn2RpjB6/gmEl+nv22bdL3onol89I =OKrH -----END PGP SIGNATURE----- --ZPDwMsyfds7q4mrK-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 07:54:20 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8CCA16A47A for ; Sun, 4 Jun 2006 07:54:20 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB54543D68 for ; Sun, 4 Jun 2006 07:54:15 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 7147833C93; Sun, 4 Jun 2006 09:54:14 +0200 (SAST) Date: Sun, 4 Jun 2006 09:54:14 +0200 From: John Hay To: current@freebsd.org Message-ID: <20060604075414.GA47483@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: libpthread.so.2 compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 07:54:28 -0000 Hi Guys, Should the -current libpthread.so.2 be compatible with apps of a few months ago? The commit messages made me think that it should, but it isn't. I have a -current machine that was last compiled in January with packages also from that time and things were all working. So I upgraded (compiled from source) the FreeBSD part but did not upgrade my ports/packages. I then found that the ones using libpthread.so.2 was coredumping. Ones that I noticed was ruby18, gnome-session and also the java programs from the diablo-jdk-freebsd6-1.5.0.06.00.tbz package that I just downloaded and installed from the FreeBSD Foundation site. If I just put the January version of libpthread.so.2 back, they all work. They all seem to die in pthread_setcancelstate according to gdb: ################## angel:~ > gdb /usr/local/diablo-jdk1.5.0/bin/javac javac.core 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"...(no debugging symbols found)... Core was generated by `javac'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libz.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.3 Reading symbols from /lib/libpthread.so.2...(no debugging symbols found)...done.Loaded symbols for /lib/libpthread.so.2 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.Loaded symbols for /libexec/ld-elf.so.1 #0 0x280bb46e in pthread_setcancelstate () from /lib/libpthread.so.2 [New LWP 100270] (gdb) bt #0 0x280bb46e in pthread_setcancelstate () from /lib/libpthread.so.2 #1 0x280ac6d8 in pthread_create () from /lib/libpthread.so.2 #2 0x280b82a6 in pthread_join () from /lib/libpthread.so.2 #3 0x280bc1aa in pthread_testcancel () from /lib/libpthread.so.2 #4 0x280bd939 in __error () from /lib/libpthread.so.2 #5 0x280a3c19 in ?? () from /lib/libpthread.so.2 #6 0xbfbfe978 in ?? () #7 0x28078118 in ?? () from /libexec/ld-elf.so.1 #8 0xbfbfe928 in ?? () #9 0x280580d5 in _rtld_error () from /libexec/ld-elf.so.1 #10 0x2805ba93 in _rtld () from /libexec/ld-elf.so.1 #11 0x280578f2 in .rtld_start () from /libexec/ld-elf.so.1 (gdb) ################################ If this is the expected behaviour, that is fine, but otherwise this is just a heads-up that the compatibility isn't working. Version 1.55 of libpthread/Makefile makes one think compatibility was intended. It is not a huge train smash for me. Between recompiling some and using /etc/libmap.conf for others, I'm up and running again. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 08:23:38 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23B1616A46F for ; Sun, 4 Jun 2006 08:23:38 +0000 (UTC) (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 ACF9D43D48 for ; Sun, 4 Jun 2006 08:23:37 +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 B6ACA3E1; Sun, 4 Jun 2006 03:23:36 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 0AC0461C2B; Sun, 4 Jun 2006 03:23:36 -0500 (CDT) Date: Sun, 4 Jun 2006 03:23:35 -0500 From: "Matthew D. Fuller" To: John Hay Message-ID: <20060604082335.GB76919@over-yonder.net> References: <20060604075414.GA47483@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060604075414.GA47483@zibbi.meraka.csir.co.za> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.3 Cc: current@freebsd.org Subject: Re: libpthread.so.2 compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 08:23:38 -0000 On Sun, Jun 04, 2006 at 09:54:14AM +0200 I heard the voice of John Hay, and lo! it spake thus: > > They all seem to die in pthread_setcancelstate according to gdb: FWIW, I just upgraded a system from an early January -CURRENT, and I'm getting the same thing. I've already rebuilt most things, which probably means there'll be a "fix" for this that requires rebuilding them again :p -- 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-current@FreeBSD.ORG Sun Jun 4 08:28:13 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFE7816A47C for ; Sun, 4 Jun 2006 08:28:13 +0000 (UTC) (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 7519743D4C for ; Sun, 4 Jun 2006 08:28:13 +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 2D3263E3 for ; Sun, 4 Jun 2006 03:28:13 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 4183A61C2B; Sun, 4 Jun 2006 03:28:12 -0500 (CDT) Date: Sun, 4 Jun 2006 03:28:12 -0500 From: "Matthew D. Fuller" To: current@freebsd.org Message-ID: <20060604082812.GC76919@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.3 Cc: Subject: unlocking unheld lock with Jun 3 -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 08:28:14 -0000 I just updated one of my -CURRENT machines, and I'm getting a lockmgr message during bootup. ---- ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 lockmgr: thread 0xc07972f8 unlocking unheld lock KDB: stack backtrace: lockmgr(c07a6088,6,c07a60ac,c07972f8,c0c20d3c) at lockmgr+0x452 smb_co_unlock(c07a6080,0,c07972f8,c0c20d48,c061a8dd) at smb_co_unlock+0x1d smb_sm_init(c2fe5400,c0c20d74,c0567d6b,c2fe5400,0) at smb_sm_init+0x30 nsmb_dev_load(c2fe5400,0,0,c0797de0,c071adf3,78) at nsmb_dev_load+0x18 module_register_init(c0778830,c1ec00,c1e000,0,c0448f05) at module_register_init+ 0x50 mi_startup() at mi_startup+0x86 begin() at begin+0x2c netsmb_dev: loaded sequencer 0 created scp 0xc2feae00 acpi0: on motherboard ---- I've not tried using the smbfs stuff (which that seems from) yet, but nothing else seems broken. -- 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-current@FreeBSD.ORG Sun Jun 4 08:37:27 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE50616A477 for ; Sun, 4 Jun 2006 08:37:27 +0000 (UTC) (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 635AE43D45 for ; Sun, 4 Jun 2006 08:37:27 +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 CCA143E3 for ; Sun, 4 Jun 2006 03:37:26 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 2283D61C2B; Sun, 4 Jun 2006 03:37:26 -0500 (CDT) Date: Sun, 4 Jun 2006 03:37:26 -0500 From: "Matthew D. Fuller" To: current@freebsd.org Message-ID: <20060604083725.GD76919@over-yonder.net> References: <20060108070915.GA98507@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060108070915.GA98507@over-yonder.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.3 Cc: Subject: Resolved: nmount() issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 08:37:27 -0000 Update for the record, in case anybody else hits this. [Original message at for those who don't keep mailing lists around so long] On Sun, Jan 08, 2006 at 01:09:15AM -0600 I heard the voice of Matthew D. Fuller, and lo! it spake thus: > > SOME (but not all, and with no pattern I can see) of my filesystems > react poorly to `mount -u`. I keep getting: > > % mount -u /usr/ports > mount: /dev/da0s1e: Bad address I just updated to today's (well, yesterday's) -CURRENT, and still saw this. Nobody responded to the original mail, and nobody else has said anything about it, so I'd assumed it was just a passing thing in the old -CURRENT, but it still happened in the new, so I moved to assuming it was something screwy with my system. And so it was. Strangely, if I unmounted the filesystems that wouldn't mount -u, delete the dir they're mounted over, and recreated it, they picked back up and worked just peachy. Those dirs, as a rule, hadn't been touched since 1999 when I installed this system. And (for instance) the /usr dir that /usr is mounted on hasn't been touched since then either, but is still working just fine without intervention. I still don't know WHY that started happening, but there's how to fix it if anybody else hits it. -- 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-current@FreeBSD.ORG Sun Jun 4 09:27:52 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A76416A4D4 for ; Sun, 4 Jun 2006 09:27:52 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4C3743D46 for ; Sun, 4 Jun 2006 09:27:51 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail12.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k549RnGv016360 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 4 Jun 2006 19:27:50 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k549Rn3C004938; Sun, 4 Jun 2006 19:27:49 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k549RnEL004937; Sun, 4 Jun 2006 19:27:49 +1000 (EST) (envelope-from peter) Date: Sun, 4 Jun 2006 19:27:49 +1000 From: Peter Jeremy To: "Matthew D. Fuller" Message-ID: <20060604092749.GE713@turion.vk2pj.dyndns.org> References: <20060108070915.GA98507@over-yonder.net> <20060604083725.GD76919@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060604083725.GD76919@over-yonder.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: current@freebsd.org Subject: Re: Resolved: nmount() issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 09:27:54 -0000 On Sun, 2006-Jun-04 03:37:26 -0500, Matthew D. Fuller wrote: >And so it was. Strangely, if I unmounted the filesystems that >wouldn't mount -u, delete the dir they're mounted over, and recreated >it, they picked back up and worked just peachy. If the system had been up, I would have suggested that the vnode entry for the covered directory have been corrupted somehow but that wouldn't have survived a reboot. I don't suppose you tried doing an ls on the directory or creating a file in it or fscking the filesystem before deleting it. Do you happen to know if the directories were re-created with the same inode number? Maybe you hit a bug that depends on the inode or block number of the directory. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 09:34:39 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F61016A4CF for ; Sun, 4 Jun 2006 09:34:39 +0000 (UTC) (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 C524543D46 for ; Sun, 4 Jun 2006 09:34:38 +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 12EEA3E1; Sun, 4 Jun 2006 04:34:38 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 46C5C61C32; Sun, 4 Jun 2006 04:34:37 -0500 (CDT) Date: Sun, 4 Jun 2006 04:34:37 -0500 From: "Matthew D. Fuller" To: Peter Jeremy Message-ID: <20060604093437.GE76919@over-yonder.net> References: <20060108070915.GA98507@over-yonder.net> <20060604083725.GD76919@over-yonder.net> <20060604092749.GE713@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060604092749.GE713@turion.vk2pj.dyndns.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.3 Cc: current@freebsd.org Subject: Re: Resolved: nmount() issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 09:34:40 -0000 On Sun, Jun 04, 2006 at 07:27:49PM +1000 I heard the voice of Peter Jeremy, and lo! it spake thus: > > I don't suppose you tried doing an ls on the directory or creating a > file in it or fscking the filesystem before deleting it. I did ls the directory, and it worked. The filesystems all went through numberous full fsck's on both the Jan and Jun -CURRENT's without a hint of trouble. > Do you happen to know if the directories were re-created with the > same inode number? Maybe you hit a bug that depends on the inode or > block number of the directory. That, I don't know, but there were 3 of them on /usr (/usr/src, /usr/obj, and /usr/ports all had the trouble), so I'm a little doubful that three of those inodes/blocks that happened to be mountpoints went wonky. /usr/local kept working just fine, though. It's pretty wacky. At least it's wacky and in the past now; having to unmount and remount all the time instead of just mount -u'ing was driving me battier. 8-} -- 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-current@FreeBSD.ORG Sun Jun 4 09:50:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7255F16A515 for ; Sun, 4 Jun 2006 09:50:29 +0000 (UTC) (envelope-from dirk.meyer@dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D4EC43D49 for ; Sun, 4 Jun 2006 09:50:28 +0000 (GMT) (envelope-from dirk.meyer@dinoex.sub.org) Received: from uucp.dinoex.sub.de (dinoex@uucp.dinoex.sub.de [194.45.71.2] (may be forged)) by uucp.dinoex.sub.de (8.13.6/8.13.5) with ESMTP id k549o1iw067227 for ; Sun, 4 Jun 2006 11:50:01 +0200 (CEST) (envelope-from dirk.meyer@dinoex.sub.org) X-MDaemon-Deliver-To: Received: from build.dinoex.sub.de (dinoex@localhost) by uucp.dinoex.sub.de (8.13.6/8.13.5/Submit) with BSMTP id k549o02C067215 for ; Sun, 4 Jun 2006 11:50:00 +0200 (CEST) (envelope-from dirk.meyer@dinoex.sub.org) To: freebsd-current@freebsd.org Message-ID: From: dirk.meyer@dinoex.sub.org (Dirk Meyer) Organization: privat Date: Sun, 04 Jun 2006 11:45:15 +0200 X-Mailer: Dinoex 1.79 References: <001701c681fc$acddb330$0b0ba8c0@GATEWAY> X-Gateway: ZCONNECT build.dinoex.sub.de [UNIX/Connect 0.94] X-PGP-Fingerprint: 44 16 EC 0A D3 3A 4F 28 8A 8A 47 93 F1 CF 2F 12 X-Copyright: (C) Copyright 2001 by Dirk Meyer -- All rights reserved. X-PGP-Key-Avail: mailto:pgp-public-keys@keys.de.pgp.net Subject:GET 0x331CDA5D X-ZC-VIA: 20060604000000S+2@dinoex.sub.org X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) Subject: Re: namebased VPS using JAIL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 09:50:32 -0000 Hallo Yudai Yamagishi, > I'm trying to serve several VPS for my friends. > But, IP addresses costs too much here in Japan. > So, I only have 1 WAN IP. > For example, I want to create a VPS called vps1. > I'll assign vps1.mydomain.com as VPS's address. > Then all network traffics for vps1.mydomain.com will go to vps1. > Same with other VPSs by the way. > Is this possible using JAIL? No .. each jail need an different IP. You can redirect traffic fro your WAN Ip to diffrent jails, but this solves not your problem. To allow diifrent "named" Services on one WAN IP, you need to do this in the server application. Vsftpd and apache do support "Virtual Hosts" so you can map HTTP and FTP services on the name used by the client to access this IP. kind regards Dirk - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany - [dirk.meyer@dinoex.sub.org],[dirk.meyer@guug.de],[dinoex@FreeBSD.org] http://people.freebsd.org/~dinoex/errorlogs/ From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 14:46:08 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0052F16A4C5 for ; Sun, 4 Jun 2006 14:46:07 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E675943D62 for ; Sun, 4 Jun 2006 14:46:02 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.6/8.13.6/NETPLEX) with ESMTP id k54Ek0pS002213; Sun, 4 Jun 2006 10:46:00 -0400 (EDT) Date: Sun, 4 Jun 2006 10:46:00 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Matthew D. Fuller" In-Reply-To: <20060604082335.GB76919@over-yonder.net> Message-ID: References: <20060604075414.GA47483@zibbi.meraka.csir.co.za> <20060604082335.GB76919@over-yonder.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: John Hay , current@freebsd.org Subject: Re: libpthread.so.2 compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 14:46:08 -0000 On Sun, 4 Jun 2006, Matthew D. Fuller wrote: > On Sun, Jun 04, 2006 at 09:54:14AM +0200 I heard the voice of > John Hay, and lo! it spake thus: >> >> They all seem to die in pthread_setcancelstate according to gdb: > > FWIW, I just upgraded a system from an early January -CURRENT, and I'm > getting the same thing. I've already rebuilt most things, which > probably means there'll be a "fix" for this that requires rebuilding > them again :p There have been no ABI changes in libpthread, so it must be coming from somewhere else. I know that libc had some ABI changes but it's version was bumped to account for that. libpthread did move from /usr/lib to /lib, but I don't know how that would bite you unless you deleted it from /usr/lib in the upgrade process. -- DE From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 15:32:13 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90DF716A56A for ; Sun, 4 Jun 2006 15:32:13 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC08B43D86 for ; Sun, 4 Jun 2006 15:32:12 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 7266833C73; Sun, 4 Jun 2006 17:32:10 +0200 (SAST) Date: Sun, 4 Jun 2006 17:32:10 +0200 From: John Hay To: Daniel Eischen Message-ID: <20060604153210.GA60476@zibbi.meraka.csir.co.za> References: <20060604075414.GA47483@zibbi.meraka.csir.co.za> <20060604082335.GB76919@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: libpthread.so.2 compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 15:32:13 -0000 On Sun, Jun 04, 2006 at 10:46:00AM -0400, Daniel Eischen wrote: > On Sun, 4 Jun 2006, Matthew D. Fuller wrote: > > >On Sun, Jun 04, 2006 at 09:54:14AM +0200 I heard the voice of > >John Hay, and lo! it spake thus: > >> > >>They all seem to die in pthread_setcancelstate according to gdb: > > > >FWIW, I just upgraded a system from an early January -CURRENT, and I'm > >getting the same thing. I've already rebuilt most things, which > >probably means there'll be a "fix" for this that requires rebuilding > >them again :p > > There have been no ABI changes in libpthread, so it must be coming > from somewhere else. I know that libc had some ABI changes but > it's version was bumped to account for that. > > libpthread did move from /usr/lib to /lib, but I don't know how > that would bite you unless you deleted it from /usr/lib in the > upgrade process. Ok, maybe it isn't some ABI change inside libpthread. Can it maybe be that we have two "versions" of libpthread.so.2 now, one that was compiled and like to be linked to libc.so.6 and one that like to be linked to libc.so.7? So if you now try to run an older threaded app (one that was compiled with libc.so.6 and libpthread.so.2, like what would happen in FreeBSD-6) on -current, it would try to use the new libpthread.so.2 that was build against libc.so.7, but try to link it with libc.so.6 and then crash and burn? Maybe when libc gets bumped all other libs have to be bumped too? John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 15:59:45 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF73416A557 for ; Sun, 4 Jun 2006 15:59:45 +0000 (UTC) (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 795E543D48 for ; Sun, 4 Jun 2006 15:59:45 +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.6/8.13.6/NETPLEX) with ESMTP id k54FximE007066; Sun, 4 Jun 2006 11:59:44 -0400 (EDT) Date: Sun, 4 Jun 2006 11:59:44 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Hay In-Reply-To: <20060604153210.GA60476@zibbi.meraka.csir.co.za> Message-ID: References: <20060604075414.GA47483@zibbi.meraka.csir.co.za> <20060604082335.GB76919@over-yonder.net> <20060604153210.GA60476@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: current@freebsd.org Subject: Re: libpthread.so.2 compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 15:59:46 -0000 On Sun, 4 Jun 2006, John Hay wrote: > On Sun, Jun 04, 2006 at 10:46:00AM -0400, Daniel Eischen wrote: >> On Sun, 4 Jun 2006, Matthew D. Fuller wrote: >> >>> On Sun, Jun 04, 2006 at 09:54:14AM +0200 I heard the voice of >>> John Hay, and lo! it spake thus: >>>> >>>> They all seem to die in pthread_setcancelstate according to gdb: >>> >>> FWIW, I just upgraded a system from an early January -CURRENT, and I'm >>> getting the same thing. I've already rebuilt most things, which >>> probably means there'll be a "fix" for this that requires rebuilding >>> them again :p >> >> There have been no ABI changes in libpthread, so it must be coming >> from somewhere else. I know that libc had some ABI changes but >> it's version was bumped to account for that. >> >> libpthread did move from /usr/lib to /lib, but I don't know how >> that would bite you unless you deleted it from /usr/lib in the >> upgrade process. > > Ok, maybe it isn't some ABI change inside libpthread. Can it maybe be > that we have two "versions" of libpthread.so.2 now, one that was > compiled and like to be linked to libc.so.6 and one that like to be > linked to libc.so.7? So if you now try to run an older threaded app > (one that was compiled with libc.so.6 and libpthread.so.2, like what > would happen in FreeBSD-6) on -current, it would try to use the new > libpthread.so.2 that was build against libc.so.7, but try to link it > with libc.so.6 and then crash and burn? Maybe when libc gets bumped > all other libs have to be bumped too? All others have to be bumped anyway (in -current) but I don't know if that is what is causing the problem. ldd or readelf -d are your friends... If there are multiple dependencies on libpthread, then that is probably causing the problem. -- DE From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 17:43:20 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C86516A749; Sun, 4 Jun 2006 17:43:20 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FF0243D45; Sun, 4 Jun 2006 17:43:18 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id EAC5233C8B; Sun, 4 Jun 2006 19:43:15 +0200 (SAST) Date: Sun, 4 Jun 2006 19:43:15 +0200 From: John Hay To: Daniel Eischen Message-ID: <20060604174315.GA64158@zibbi.meraka.csir.co.za> References: <20060604075414.GA47483@zibbi.meraka.csir.co.za> <20060604082335.GB76919@over-yonder.net> <20060604153210.GA60476@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: libpthread.so.2 compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 17:43:21 -0000 > >>>FWIW, I just upgraded a system from an early January -CURRENT, and I'm > >>>getting the same thing. I've already rebuilt most things, which > >>>probably means there'll be a "fix" for this that requires rebuilding > >>>them again :p > >> > >>There have been no ABI changes in libpthread, so it must be coming > >>from somewhere else. I know that libc had some ABI changes but > >>it's version was bumped to account for that. > >> > >>libpthread did move from /usr/lib to /lib, but I don't know how > >>that would bite you unless you deleted it from /usr/lib in the > >>upgrade process. > > > >Ok, maybe it isn't some ABI change inside libpthread. Can it maybe be > >that we have two "versions" of libpthread.so.2 now, one that was > >compiled and like to be linked to libc.so.6 and one that like to be > >linked to libc.so.7? So if you now try to run an older threaded app > >(one that was compiled with libc.so.6 and libpthread.so.2, like what > >would happen in FreeBSD-6) on -current, it would try to use the new > >libpthread.so.2 that was build against libc.so.7, but try to link it > >with libc.so.6 and then crash and burn? Maybe when libc gets bumped > >all other libs have to be bumped too? > > All others have to be bumped anyway (in -current) but I don't know > if that is what is causing the problem. ldd or readelf -d are your > friends... If there are multiple dependencies on libpthread, then > that is probably causing the problem. I have done it, but do not see anything strange. ldd looks like this, with and without the libmap.conf tweak: ######### angel:~ > ldd /usr/local/diablo-jdk1.5.0/bin/javac /usr/local/diablo-jdk1.5.0/bin/javac: libz.so.3 => /lib/libz.so.3 (0x2808e000) libpthread.so.2 => /lib/libpthread.so.2 (0x2809f000) libc.so.6 => /lib/libc.so.6 (0x280c4000) angel:~ > ldd /usr/local/diablo-jdk1.5.0/bin/javac /usr/local/diablo-jdk1.5.0/bin/javac: libz.so.3 => /lib/libz.so.3 (0x2808e000) libpthread.so.2 => /lib/libpthread.old.so.2 (0x2809f000) libc.so.6 => /lib/libc.so.6 (0x280c4000) ######### readelf -d /lib/libpthread.so.2 also doesn't show anything strange... I think: ####### Dynamic segment at offset 0x204dc contains 20 entries: Tag Type Name/Value 0x0000000e (SONAME) Library soname: [libpthread.so.2] 0x0000000c (INIT) 0x4c0c 0x0000000d (FINI) 0x1e944 0x00000004 (HASH) 0x94 0x00000005 (STRTAB) 0x2a88 0x00000006 (SYMTAB) 0xc48 0x0000000a (STRSZ) 4620 (bytes) 0x0000000b (SYMENT) 16 (bytes) 0x00000003 (PLTGOT) 0x205b4 0x00000002 (PLTRELSZ) 912 (bytes) 0x00000014 (PLTREL) REL 0x00000017 (JMPREL) 0x487c 0x00000011 (REL) 0x40cc 0x00000012 (RELSZ) 1968 (bytes) 0x00000013 (RELENT) 8 (bytes) 0x6ffffffc (VERDEF) 0x405c 0x6ffffffd (VERDEFNUM) 4 0x6ffffff0 (VERSYM) 0x3c94 0x6ffffffa (RELCOUNT) 50 0x00000000 (NULL) 0x0 ####### Actually one does not even need a big complex app to see the problem. Just copy /sbin/ggatec from 6.1 or 6.1-stable to a current box and you will see it happen: ####### angel:~ > uname -a FreeBSD angel.cids.org.za 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sun May 28 11:06:16 SAST 2006 jhay@angel.cids.org.za:/usr/src/sys/i386/compile/ANGEL i386 angel:~ > ssh zibbi "uname -a" FreeBSD zibbi.meraka.csir.co.za 6.1-STABLE FreeBSD 6.1-STABLE #4: Thu May 25 06:11:44 SAST 2006 jhay@zibbi.meraka.csir.co.za:/usr/src/sys/i386/compile/ZIBBI i386 angel:~ > scp -p zibbi:/sbin/ggatec /tmp/ ggatec 100% 16KB 8.1KB/s 00:02 angel:~ > /tmp/ggatec Segmentation fault (core dumped) ####### John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 17:50:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E21C16AB62 for ; Sun, 4 Jun 2006 17:50:00 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0621143D49 for ; Sun, 4 Jun 2006 17:50:00 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id D9F791A3C1F; Sun, 4 Jun 2006 10:49:59 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3817151211; Sun, 4 Jun 2006 13:49:59 -0400 (EDT) Date: Sun, 4 Jun 2006 13:49:59 -0400 From: Kris Kennaway To: Giorgos Keramidas Message-ID: <20060604174958.GA34224@xor.obsecurity.org> References: <20060523194106.GA46634@xor.obsecurity.org> <20060524203645.GB13500@gothmog.pc> <20060524203747.GA88742@xor.obsecurity.org> <20060524204617.GA13701@gothmog.pc> <20060601002024.GA1453@gothmog.pc> <20060601210655.GA36389@xor.obsecurity.org> <20060601213527.GA53422@gothmog.pc> <20060602215005.GA43170@nowhere> <20060602220724.GA71883@xor.obsecurity.org> <20060604050316.GE61942@gothmog.pc> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <20060604050316.GE61942@gothmog.pc> User-Agent: Mutt/1.4.2.1i Cc: Craig Boston , freebsd-current@freebsd.org, Kris Kennaway Subject: Re: md /tmp and async mounts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 17:50:30 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 04, 2006 at 08:03:16AM +0300, Giorgos Keramidas wrote: > On 2006-06-02 18:07, Kris Kennaway wrote: > >On Fri, Jun 02, 2006 at 04:50:06PM -0500, Craig Boston wrote: > >>On Fri, Jun 02, 2006 at 12:35:27AM +0300, Giorgos Keramidas wrote: > >>> Ok, I'll prepare a patch that enables async and disables -M. We > >>> should also document the fact that tmpmfs=3D"YES" and varmfs=3D"YES" > >>> in rc.conf may require the presence of at least one swap device > >>> by default, and point the users to -M with a warning if they run > >>> FreeBSD without a swap device but still want to use tmpmfs or > >>> varmfs :) > >> > >> I may be mistaken, but from my (brief) reading of the code it seems > >> to me that perhaps "swap-backed" isn't an entirely accurate term. > >> More like "VM-backed", with the understanding that VM is (usually) > >> backed by swap. > >> > >> I think if you don't have any swap configured, a swap-backed md > >> will be no worse off than a memory-backed one would. > > > > Yeah, it's kind of a poorly chosen name. >=20 > Should we still revert the default from using -M for tmpmfs=3D"YES" and > varmfs=3D"YES" in rc.conf? Someone should test it in a situation without swap configured (including what is the failure mode when you run out of memory - probably a panic again), but it "should" be fine (i.e. behaves the same or better than malloc in all situations). Kris --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEgx1GWry0BWjoQKURAgolAJ0XauOaQf84EoQg4xKKm4pacgl0JACgrnMv 9ZWmSNxK0zhzWu7bEOJPDUk= =PhOg -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 18:26:52 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93CC816A481 for ; Sun, 4 Jun 2006 18:26:52 +0000 (UTC) (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 0DF8043D48 for ; Sun, 4 Jun 2006 18:26:51 +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.6/8.13.6/NETPLEX) with ESMTP id k54IQpoc006435; Sun, 4 Jun 2006 14:26:51 -0400 (EDT) Date: Sun, 4 Jun 2006 14:26:51 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Hay In-Reply-To: <20060604174315.GA64158@zibbi.meraka.csir.co.za> Message-ID: References: <20060604075414.GA47483@zibbi.meraka.csir.co.za> <20060604082335.GB76919@over-yonder.net> <20060604153210.GA60476@zibbi.meraka.csir.co.za> <20060604174315.GA64158@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: current@freebsd.org Subject: Re: libpthread.so.2 compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 18:26:52 -0000 On Sun, 4 Jun 2006, John Hay wrote: >>>>> FWIW, I just upgraded a system from an early January -CURRENT, and I'm >>>>> getting the same thing. I've already rebuilt most things, which >>>>> probably means there'll be a "fix" for this that requires rebuilding >>>>> them again :p >>>> >>>> There have been no ABI changes in libpthread, so it must be coming >>>> from somewhere else. I know that libc had some ABI changes but >>>> it's version was bumped to account for that. >>>> >>>> libpthread did move from /usr/lib to /lib, but I don't know how >>>> that would bite you unless you deleted it from /usr/lib in the >>>> upgrade process. >>> >>> Ok, maybe it isn't some ABI change inside libpthread. Can it maybe be >>> that we have two "versions" of libpthread.so.2 now, one that was >>> compiled and like to be linked to libc.so.6 and one that like to be >>> linked to libc.so.7? So if you now try to run an older threaded app >>> (one that was compiled with libc.so.6 and libpthread.so.2, like what >>> would happen in FreeBSD-6) on -current, it would try to use the new >>> libpthread.so.2 that was build against libc.so.7, but try to link it >>> with libc.so.6 and then crash and burn? Maybe when libc gets bumped >>> all other libs have to be bumped too? >> >> All others have to be bumped anyway (in -current) but I don't know >> if that is what is causing the problem. ldd or readelf -d are your >> friends... If there are multiple dependencies on libpthread, then >> that is probably causing the problem. > > I have done it, but do not see anything strange. ldd looks like this, > with and without the libmap.conf tweak: [ ... ] > Actually one does not even need a big complex app to see the problem. > Just copy /sbin/ggatec from 6.1 or 6.1-stable to a current box and you > will see it happen: > > ####### > angel:~ > uname -a > FreeBSD angel.cids.org.za 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sun May 28 11:06:16 SAST 2006 jhay@angel.cids.org.za:/usr/src/sys/i386/compile/ANGEL i386 > angel:~ > ssh zibbi "uname -a" > FreeBSD zibbi.meraka.csir.co.za 6.1-STABLE FreeBSD 6.1-STABLE #4: Thu May 25 06:11:44 SAST 2006 jhay@zibbi.meraka.csir.co.za:/usr/src/sys/i386/compile/ZIBBI i386 > angel:~ > scp -p zibbi:/sbin/ggatec /tmp/ > ggatec 100% 16KB 8.1KB/s 00:02 > angel:~ > /tmp/ggatec > Segmentation fault (core dumped) > ####### It is probably the networking ABI changes in libc. There was a short period of time when there were ABI changes in libc.so.6 in -current -- before libc was bumped to libc.so.7. What happens when you try moving a -stable libc.so.6 to the -current machine? -- DE From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 19:02:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3AFF16A4D2 for ; Sun, 4 Jun 2006 19:02:00 +0000 (UTC) (envelope-from betogigi@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35F8143D45 for ; Sun, 4 Jun 2006 19:02:00 +0000 (GMT) (envelope-from betogigi@gmail.com) Received: by nz-out-0102.google.com with SMTP id m7so876878nzf for ; Sun, 04 Jun 2006 12:01:59 -0700 (PDT) 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:content-transfer-encoding:content-disposition; b=hCyHRl6B7KbgTSIr2m8gFABvtSUHarmyowrfTa7KAlpK9asV+TNRvIgtEQtmHycUFc2QV+m9biNdzqrkKLYEvOnEVd/FalSV4i3NX84UlwYX/zEjNFVaxDHL/7m41rlxfvhpQahJ1Ip6W4bU5gi0KqpklLRTEothrynlFlzICPg= Received: by 10.37.22.49 with SMTP id z49mr5112865nzi; Sun, 04 Jun 2006 12:01:59 -0700 (PDT) Received: by 10.36.134.11 with HTTP; Sun, 4 Jun 2006 12:01:59 -0700 (PDT) Message-ID: Date: Sun, 4 Jun 2006 16:01:59 -0300 From: "Roberto Lima" To: freebsd-current@freebsd.org, "Mikhail Teterin" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Re: Assembler optimizations for libz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 19:02:00 -0000 Hi, I apply this patch and i have now 20% of compressions performance.. but the problems with this optimization during 'make buildworld' shows this error: cc -O2 -fno-strict-aliasing -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o makewhatis makewhatis.o -lz -legacy /usr/lib/libz.a(inflate.o)(.text+0x17ce): In function `inflate': : undefined reference to `inflate_fast' /usr/lib/libz.a(deflate.o)(.text+0xb44): In function `deflateReset': : undefined reference to `match_init' /usr/lib/libz.a(deflate.o)(.text+0x1339): In function `deflate_fast': : undefined reference to `longest_match' /usr/lib/libz.a(deflate.o)(.text+0x18f4): In function `deflate_slow': : undefined reference to `longest_match' *** Error code 1 Stop in /usr/src/usr.bin/makewhatis. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. you knows how to solve this? Thanks and sorry for my bad english. Roberto. From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 19:10:07 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11D2116A95B; Sun, 4 Jun 2006 19:10:07 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AAB143D6E; Sun, 4 Jun 2006 19:10:01 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 3904133C93; Sun, 4 Jun 2006 21:10:00 +0200 (SAST) Date: Sun, 4 Jun 2006 21:10:00 +0200 From: John Hay To: Daniel Eischen Message-ID: <20060604191000.GA67836@zibbi.meraka.csir.co.za> References: <20060604075414.GA47483@zibbi.meraka.csir.co.za> <20060604082335.GB76919@over-yonder.net> <20060604153210.GA60476@zibbi.meraka.csir.co.za> <20060604174315.GA64158@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: libpthread.so.2 compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 19:10:08 -0000 On Sun, Jun 04, 2006 at 02:26:51PM -0400, Daniel Eischen wrote: > On Sun, 4 Jun 2006, John Hay wrote: > > >>>>>FWIW, I just upgraded a system from an early January -CURRENT, and I'm > >>>>>getting the same thing. I've already rebuilt most things, which > >>>>>probably means there'll be a "fix" for this that requires rebuilding > >>>>>them again :p > >>>> > >>>>There have been no ABI changes in libpthread, so it must be coming > >>>>from somewhere else. I know that libc had some ABI changes but > >>>>it's version was bumped to account for that. > >>>> > >>>>libpthread did move from /usr/lib to /lib, but I don't know how > >>>>that would bite you unless you deleted it from /usr/lib in the > >>>>upgrade process. > >>> > >>>Ok, maybe it isn't some ABI change inside libpthread. Can it maybe be > >>>that we have two "versions" of libpthread.so.2 now, one that was > >>>compiled and like to be linked to libc.so.6 and one that like to be > >>>linked to libc.so.7? So if you now try to run an older threaded app > >>>(one that was compiled with libc.so.6 and libpthread.so.2, like what > >>>would happen in FreeBSD-6) on -current, it would try to use the new > >>>libpthread.so.2 that was build against libc.so.7, but try to link it > >>>with libc.so.6 and then crash and burn? Maybe when libc gets bumped > >>>all other libs have to be bumped too? > >> > >>All others have to be bumped anyway (in -current) but I don't know > >>if that is what is causing the problem. ldd or readelf -d are your > >>friends... If there are multiple dependencies on libpthread, then > >>that is probably causing the problem. > > > >I have done it, but do not see anything strange. ldd looks like this, > >with and without the libmap.conf tweak: > > [ ... ] > > >Actually one does not even need a big complex app to see the problem. > >Just copy /sbin/ggatec from 6.1 or 6.1-stable to a current box and you > >will see it happen: > > > >####### > >angel:~ > uname -a > >FreeBSD angel.cids.org.za 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sun May 28 > >11:06:16 SAST 2006 > >jhay@angel.cids.org.za:/usr/src/sys/i386/compile/ANGEL i386 > >angel:~ > ssh zibbi "uname -a" > >FreeBSD zibbi.meraka.csir.co.za 6.1-STABLE FreeBSD 6.1-STABLE #4: Thu May > >25 06:11:44 SAST 2006 > >jhay@zibbi.meraka.csir.co.za:/usr/src/sys/i386/compile/ZIBBI i386 > >angel:~ > scp -p zibbi:/sbin/ggatec /tmp/ > >ggatec 100% 16KB 8.1KB/s 00:02 > >angel:~ > /tmp/ggatec > >Segmentation fault (core dumped) > >####### > > It is probably the networking ABI changes in libc. There was a short period > of time when there were ABI changes in libc.so.6 in -current -- before libc > was bumped to libc.so.7. What happens when you try moving a -stable > libc.so.6 > to the -current machine? Ok, I did that but it still core dump in pthread_setcancelstate() John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 19:12:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B30E16A9BE for ; Sun, 4 Jun 2006 19:12:26 +0000 (UTC) (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 25FF643D70 for ; Sun, 4 Jun 2006 19:12:11 +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.6) with ESMTP id k54JEodU050651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jun 2006 15:14:56 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: thierry@herbelot.com Date: Sun, 4 Jun 2006 15:12:15 -0400 User-Agent: KMail/1.9.1 References: <200606010042.47193.thierry@herbelot.com> <200605311930.17675.mistry.7@osu.edu> <200606031135.52759.thierry@herbelot.com> In-Reply-To: <200606031135.52759.thierry@herbelot.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10948918.mufkK5ULht"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606041512.32879.mistry.7@osu.edu> X-Spam-Status: No, score=-2.5 required=5.0 tests=ALL_TRUSTED,BAYES_50, J_CHICKENPOX_23,J_CHICKENPOX_63,J_CHICKENPOX_73,J_CHICKENPOX_75, J_CHICKENPOX_91,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.88.2/1511/Sun Jun 4 02:50:01 2006 on mail.united-ware.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: panic while playing with a ugen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 19:12:33 -0000 --nextPart10948918.mufkK5ULht Content-Type: multipart/mixed; boundary="Boundary-01=_QCzgEPRlQhrBUrJ" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_QCzgEPRlQhrBUrJ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 03 June 2006 05:35, Thierry Herbelot wrote: > Le Thursday 1 June 2006 01:30, Anish Mistry a =E9crit : > > On Wednesday 31 May 2006 18:42, Thierry Herbelot wrote: > > > the panic occured when closing one endpoint of a ugen device > > > (the device was disconnecting from the USB bus after being > > > reseted). > > > > I haven't seen this particular panic with ugen before. > > Try the patch in PR: usb/97271. If you've got a test program and > > instructions that can reproduce this panic after applying that > > patch let me know. > > > > Thanks, > > indeed, after applying the patch from usb/97271, the behaviour > seems to be more stable (multiple runs of mytest program, in a > loop, and not one panic so far). Would you try the attached patch? This is modified version that is=20 closer to the version that might be committed. =2D-=20 Anish Mistry --Boundary-01=_QCzgEPRlQhrBUrJ Content-Type: text/x-diff; charset="iso-8859-1"; name="ugen.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ugen.patch" =2D-- ugen.c.orig Sat Jun 3 15:59:24 2006 +++ ugen.c Sun Jun 4 14:55:25 2006 @@ -1,4 +1,4 @@ =2D/* $NetBSD: ugen.c,v 1.59 2002/07/11 21:14:28 augustss Exp $ */ +/* $NetBSD: ugen.c,v 1.79 2006/03/01 12:38:13 yamt Exp $ */ =20 /* Also already merged from NetBSD: * $NetBSD: ugen.c,v 1.61 2002/09/23 05:51:20 simonb Exp $ @@ -284,6 +284,9 @@ ugen_make_devnodes(sc); #endif =20 + usbd_add_drv_event(USB_EVENT_DRIVER_ATTACH, sc->sc_udev, + USBDEV(sc->sc_dev)); + USB_ATTACH_SUCCESS_RETURN; } =20 @@ -322,9 +325,11 @@ Static void ugen_destroy_devnodes(struct ugen_softc *sc) { =2D int endptno; + int endptno, prev_sc_dying; struct cdev *dev; =20 + prev_sc_dying =3D sc->sc_dying; + sc->sc_dying =3D 1; /* destroy all devices for the other (existing) endpoints as well */ for (endptno =3D 1; endptno < USB_MAX_ENDPOINTS; endptno++) { if (sc->sc_endpoints[endptno][IN].sc !=3D NULL || @@ -341,9 +346,16 @@ dev =3D sc->sc_endpoints[endptno][IN].dev; else dev =3D sc->sc_endpoints[endptno][OUT].dev; =2D destroy_dev(dev); + + KASSERT(dev !=3D NULL, ("ugen_destroy_devnodes: NULL dev")); + if(dev !=3D NULL) + destroy_dev(dev); + + sc->sc_endpoints[endptno][IN].sc =3D NULL; + sc->sc_endpoints[endptno][OUT].sc =3D NULL; } } + sc->sc_dying =3D prev_sc_dying; } #endif =20 @@ -378,9 +390,9 @@ return (err); /* store an array of endpoint descriptors to clear if the configuration * change succeeds - these aren't available afterwards */ =2D nendpt_cache =3D malloc(sizeof(u_int8_t) * niface, M_TEMP, M_WAITOK); + nendpt_cache =3D malloc(sizeof(u_int8_t) * niface, M_TEMP, M_WAITOK|M_ZER= O); sce_cache_arr =3D malloc(sizeof(struct ugen_endpoint **) * niface, M_TEMP, =2D M_WAITOK); + M_WAITOK|M_ZERO); niface_cache =3D niface; =20 for (ifaceno =3D 0; ifaceno < niface; ifaceno++) { @@ -727,13 +739,12 @@ sce->state |=3D UGEN_ASLP; DPRINTFN(5, ("ugenread: sleep on %p\n", sce)); error =3D tsleep(sce, PZERO | PCATCH, "ugenri", 0); + sce->state &=3D ~UGEN_ASLP; DPRINTFN(5, ("ugenread: woke, error=3D%d\n", error)); if (sc->sc_dying) error =3D EIO; =2D if (error) { =2D sce->state &=3D ~UGEN_ASLP; + if (error) break; =2D } } splx(s); =20 @@ -791,13 +802,12 @@ sce->state |=3D UGEN_ASLP; DPRINTFN(5, ("ugenread: sleep on %p\n", sce)); error =3D tsleep(sce, PZERO | PCATCH, "ugenri", 0); + sce->state &=3D ~UGEN_ASLP; DPRINTFN(5, ("ugenread: woke, error=3D%d\n", error)); if (sc->sc_dying) error =3D EIO; =2D if (error) { =2D sce->state &=3D ~UGEN_ASLP; + if (error) break; =2D } } =20 while (sce->cur !=3D sce->fill && uio->uio_resid > 0 && !error) { @@ -835,6 +845,9 @@ =20 USB_GET_SC(ugen, UGENUNIT(dev), sc); =20 + if (sc->sc_dying) + return (EIO); + UGEN_DEV_REF(dev, sc); error =3D ugen_do_read(sc, endpt, uio, flag); UGEN_DEV_RELE(dev, sc); @@ -933,6 +946,9 @@ =20 USB_GET_SC(ugen, UGENUNIT(dev), sc); =20 + if (sc->sc_dying) + return (EIO); + UGEN_DEV_REF(dev, sc); error =3D ugen_do_write(sc, endpt, uio, flag); UGEN_DEV_RELE(dev, sc); @@ -971,6 +987,20 @@ sce =3D &sc->sc_endpoints[endpt][IN]; if (sce->pipeh) usbd_abort_pipe(sce->pipeh); + if (sce->state & UGEN_ASLP) { + DPRINTFN(5, ("ugenpurge: waking %p\n", sce)); + wakeup(sce); + } + selwakeuppri(&sce->rsel, PZERO); + + sce =3D &sc->sc_endpoints[endpt][OUT]; + if (sce->pipeh) + usbd_abort_pipe(sce->pipeh); + if (sce->state & UGEN_ASLP) { + DPRINTFN(5, ("ugenpurge: waking %p\n", sce)); + wakeup(sce); + } + selwakeuppri(&sce->rsel, PZERO); } #endif =20 @@ -996,6 +1026,7 @@ sce =3D &sc->sc_endpoints[i][dir]; if (sce->pipeh) usbd_abort_pipe(sce->pipeh); + selwakeuppri(&sce->rsel, PZERO); } } =20 @@ -1035,6 +1066,9 @@ destroy_dev(sc->dev); #endif =20 + usbd_add_drv_event(USB_EVENT_DRIVER_DETACH, sc->sc_udev, + USBDEV(sc->sc_dev)); + return (0); } =20 @@ -1333,7 +1367,7 @@ switch (err) { case USBD_NORMAL_COMPLETION: #if defined(__FreeBSD__) =2D ugen_make_devnodes(sc); + ugen_make_devnodes(sc); #endif break; case USBD_IN_USE: @@ -1542,6 +1576,9 @@ =20 USB_GET_SC(ugen, UGENUNIT(dev), sc); =20 + if (sc->sc_dying) + return (EIO); + UGEN_DEV_REF(dev, sc); error =3D ugen_do_ioctl(sc, endpt, cmd, addr, flag, p); UGEN_DEV_RELE(dev, sc); @@ -1552,43 +1589,57 @@ ugenpoll(struct cdev *dev, int events, usb_proc_ptr p) { struct ugen_softc *sc; =2D struct ugen_endpoint *sce; + struct ugen_endpoint *sce_in, *sce_out; + usb_endpoint_descriptor_t *edesc; int revents =3D 0; int s; =20 USB_GET_SC(ugen, UGENUNIT(dev), sc); =20 if (sc->sc_dying) =2D return (EIO); + return ((events & (POLLIN | POLLOUT | POLLRDNORM | + POLLWRNORM)) | POLLHUP); + /* Do not allow to poll a control endpoint */ + if (UGENENDPOINT(dev) =3D=3D USB_CONTROL_ENDPOINT) + return (0); + + sce_in =3D &sc->sc_endpoints[UGENENDPOINT(dev)][IN]; + sce_out =3D &sc->sc_endpoints[UGENENDPOINT(dev)][OUT]; + edesc =3D (sce_in->edesc !=3D NULL) ? sce_in->edesc : sce_out->edesc; + KASSERT(edesc !=3D NULL, ("ugenpoll: NULL edesc")); + if (sce_in->edesc =3D=3D NULL || sce_in->pipeh =3D=3D NULL) + sce_in =3D NULL; + if (sce_out->edesc =3D=3D NULL || sce_out->pipeh =3D=3D NULL) + sce_out =3D NULL; =20 =2D /* XXX always IN */ =2D sce =3D &sc->sc_endpoints[UGENENDPOINT(dev)][IN]; =2D#ifdef DIAGNOSTIC =2D if (!sce->edesc) { =2D printf("ugenpoll: no edesc\n"); =2D return (EIO); =2D } =2D if (!sce->pipeh) { =2D printf("ugenpoll: no pipe\n"); =2D return (EIO); =2D } =2D#endif s =3D splusb(); =2D switch (sce->edesc->bmAttributes & UE_XFERTYPE) { + switch (edesc->bmAttributes & UE_XFERTYPE) { case UE_INTERRUPT: =2D if (events & (POLLIN | POLLRDNORM)) { =2D if (sce->q.c_cc > 0) + if (sce_in !=3D NULL && (events & (POLLIN | POLLRDNORM))) { + if (sce_in->q.c_cc > 0) revents |=3D events & (POLLIN | POLLRDNORM); else =2D selrecord(p, &sce->rsel); + selrecord(p, &sce_in->rsel); + } + if (sce_out !=3D NULL && (events & (POLLOUT | POLLWRNORM))) { + if (sce_out->q.c_cc > 0) + revents |=3D events & (POLLIN | POLLRDNORM); + else + selrecord(p, &sce_out->rsel); } break; case UE_ISOCHRONOUS: =2D if (events & (POLLIN | POLLRDNORM)) { =2D if (sce->cur !=3D sce->fill) + if (sce_in !=3D NULL && (events & (POLLIN | POLLRDNORM))) { + if (sce_in->cur !=3D sce_in->fill) + revents |=3D events & (POLLIN | POLLRDNORM); + else + selrecord(p, &sce_in->rsel); + } + if (sce_out !=3D NULL && (events & (POLLOUT | POLLWRNORM))) { + if (sce_out->cur !=3D sce_out->fill) revents |=3D events & (POLLIN | POLLRDNORM); else =2D selrecord(p, &sce->rsel); + selrecord(p, &sce_out->rsel); } break; case UE_BULK: --Boundary-01=_QCzgEPRlQhrBUrJ-- --nextPart10948918.mufkK5ULht Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQBEgzCgxqA5ziudZT0RAi7VAKDUAf2Bykk051sNJm/PnJh36MCe4QCeOakt jFr2KiUV772qfQ3/Z121MPQ= =nkYA -----END PGP SIGNATURE----- --nextPart10948918.mufkK5ULht-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 21:06:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C405716AFF4 for ; Sun, 4 Jun 2006 21:06:25 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8A3343D60 for ; Sun, 4 Jun 2006 21:06:24 +0000 (GMT) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.13.6/jtpda-5.4) with ESMTP id k54L6NP9045303 for ; Sun, 4 Jun 2006 23:06:23 +0200 (CEST) X-Ids: 166 Received: from heho.labo (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id k54L6MRZ026393 for ; Sun, 4 Jun 2006 23:06:22 +0200 (MEST) Received: (from arno@localhost) by heho.labo (8.13.3/8.13.1/Submit) id k54L6Lhs026390; Sun, 4 Jun 2006 23:06:21 +0200 (MEST) (envelope-from arno) Sender: arno@heho.snv.jussieu.fr To: freebsd-current@freebsd.org From: "Arno J. Klaassen" Date: 04 Jun 2006 23:06:21 +0200 Message-ID: Lines: 80 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (shiva.jussieu.fr [134.157.0.166]); Sun, 04 Jun 2006 23:06:23 +0200 (CEST) X-Virus-Scanned: ClamAV 0.88.2/1512/Sun Jun 4 11:58:49 2006 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at shiva.jussieu.fr with ID 44834B4F.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Subject: indefinite wait buffer take-II X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 21:06:26 -0000 --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, I don't know if this is the right medium, the diff is against releng-6. In my spare-time I try, still in vain, to find a reproducable configuration for the 6.1 desired feature "swap_pager warnings when swapfiles are in use" to produce a panic rather than deadlock (on amd64). The first part of the attached diff has as goal to verify that, till now, no (logged) "wait buffer timeout" ever is "indefinite", the second part to disable a panic when rebooting after a test which did not produce deadlock. I test on a notebook with 1G RAM, 1G swap-slice and 3G pagingfile, using the attached simple program to force insane swapping. Without the second part of the diff, it panics as follows : Unread portion of the kernel message buffer: <118>May 29 00:46:12 demo syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 done All buffers synced. Swap device ad0s3b removed. swap_pager: I/O error - pagein failed; blkno 268319,size 4096, error 5 panic: swap_pager_force_pagein: read from swap failed (I do not have the corresponding kernel any longer but the trace is something like : (kgdb) where #0 doadump () at pcpu.h:172 #1 0x0000000000000004 in ?? () #2 0xffffffff8029a093 in boot (howto=260) at /files/bsd/src6/sys/kern/kern_shutdown.c:409 #3 0xffffffff8029a696 in panic (fmt=0xffffff00177d5be0 "@ãª\022") at /files/bsd/src6/sys/kern/kern_shutdown.c:565 #4 0xffffffff803f1cac in swapoff_one (sp=0xffffff002f9d2880, td=0xffffffff80628200) at /files/bsd/src6/sys/vm/swap_pager.c:1614 #5 0xffffffff803f1fc4 in swapoff_all () at /files/bsd/src6/sys/vm/swap_pager.c:2233 #6 0xffffffff8029a2ba in boot (howto=0) at /files/bsd/src6/sys/kern/kern_shutdown.c:393 #7 0xffffffff8029a427 in reboot (td=0x0, uap=0xffffffffa81ecbc0) at /files/bsd/src6/sys/kern/kern_shutdown.c:169 #8 0xffffffff80427b41 in syscall (frame= {tf_rdi = 0, tf_rsi = 9, tf_rdx = -1, tf_rcx = 3, tf_r8 = -1099117536288, tf_r9 = 140737488350440, tf_rax = 55, tf_rbx = 2, tf_rbp = 232662, tf_r10 = -2140997928, tf_r11 = 518, tf_r12 = 0, tf_r13 = 0, tf_r14 = 0, tf_r15 = 0, tf_trapno = 12, tf_addr = 34367711392, tf_flags = 0, tf_err = 2, tf_rip = 34367517868, tf_cs = 43, tf_rflags = 514, tf_rsp = 140737488350440, tf_ss = 35}) at /files/bsd/src6/sys/amd64/amd64/trap.c:792 #9 0xffffffff80415648 in Xfast_syscall () at /files/bsd/src6/sys/amd64/amd64/exception.S:270 ) Maybe this gives a glue to someone; apart from the kernel message I have no indication of a "real" I/O error (and VM_PAGER_FAIL and VM_PAGER_ERROR seem valid return values for swap_pager_getpages() anyway). Thanks very much. Arno --=-=-= Content-Type: application/octet-stream Content-Disposition: attachment; filename=testswap_pager.c #include #include #include #include #define M_SIZE (1*1024*1024) int main (int argc, char **argv) { unsigned long maxpage; int *base1, *base2, *ptr1, *ptr2; unsigned int iter = 1; time_t clock; _malloc_options = "AJ"; maxpage = strtol (argv[1], (char **) NULL, 10) * M_SIZE; fprintf (stderr, "Allocing %ld Bytes\n", maxpage); base1 = (int *) (malloc (maxpage / 2)); base2 = (int *) (malloc (maxpage / 2)); if (base1 == NULL) { fprintf (stderr, "Jammer 1\n"); exit (1); } if (base2 == NULL) { fprintf (stderr, "Jammer 1\n"); exit (1); } while (0 == 0) { unsigned int i; fprintf (stderr, "Starting loop <%d>\n filling reference base ...", iter); clock = time(NULL); fprintf (stderr, "%s ", ctime(&clock)); fflush (stderr); ptr1 = base1; for (i = 0; i < maxpage / 2 / sizeof (int); i++) { *(ptr1++) += i; } fprintf (stderr, " done\n filling control base ..."); clock = time(NULL); fprintf (stderr, "%s ", ctime(&clock)); fflush (stderr); ptr2 = base2; for (i = 0; i < maxpage / 2 / sizeof (int); i++) { *(ptr2++) += i; } fprintf (stderr, " done\n starting comparison ..."); clock = time(NULL); fprintf (stderr, "%s ", ctime(&clock)); fflush (stderr); ptr1 = base1; ptr2 = base2; for (i = 0; i < maxpage / 2 / sizeof (int); i++) { if (*ptr1 != *ptr2) { fprintf (stderr, "\n index <%d> differ : <%d> <%d>", iter, *ptr1, *ptr2); fflush (stderr); } ptr1++; ptr2++; } fprintf (stderr, " done (%d integer comparisons)\n\n",i); clock = time(NULL); fprintf (stderr, "%s ", ctime(&clock)); iter++; } exit (0); // never reached } --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=swap_pager.diff Index: sys/vm/swap_pager.c =================================================================== RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v retrieving revision 1.273.2.2 diff -u -r1.273.2.2 swap_pager.c --- sys/vm/swap_pager.c 10 May 2006 07:00:08 -0000 1.273.2.2 +++ sys/vm/swap_pager.c 2 Jun 2006 21:20:01 -0000 @@ -972,6 +972,9 @@ vm_page_t mreq; int i; int j; + int retry = 0; +#define TIMO_CHUNK 1 + static int timo_secs = 20; /* set low to force quick first timeout */ daddr_t blk; mreq = m[reqpage]; @@ -1099,13 +1102,23 @@ */ vm_page_lock_queues(); while ((mreq->flags & PG_SWAPINPROG) != 0) { - vm_page_flag_set(mreq, PG_WANTED | PG_REFERENCED); - cnt.v_intrans++; - if (msleep(mreq, &vm_page_queue_mtx, PSWP, "swread", hz*20)) { - printf( -"swap_pager: indefinite wait buffer: bufobj: %p, blkno: %jd, size: %ld\n", - bp->b_bufobj, (intmax_t)bp->b_blkno, bp->b_bcount); + if (retry == 0) { + vm_page_flag_set(mreq, PG_WANTED | PG_REFERENCED); + cnt.v_intrans++; } + if (msleep(mreq, &vm_page_queue_mtx, PSWP, "swread", hz*timo_secs)) { + printf( +"swap_pager: wait buffer timeout %d (%d secs): bufobj: %p, blkno: %jd, size: %ld\n", + ++retry, timo_secs, bp->b_bufobj, (intmax_t)bp->b_blkno, bp->b_bcount); + if ( retry+TIMO_CHUNK > timo_secs) { + timo_secs = retry+TIMO_CHUNK; + } + } else { + if (retry > 0) { + printf( +"swap_pager: wait buffer completed (%d retry): bufobj: %p, blkno: %jd, size: %ld\n", + retry, bp->b_bufobj, (intmax_t)bp->b_blkno, bp->b_bcount); + }} } vm_page_unlock_queues(); @@ -1584,6 +1597,7 @@ swp_pager_force_pagein(vm_object_t object, vm_pindex_t pindex) { vm_page_t m; + int ret; vm_object_pip_add(object, 1); m = vm_page_grab(object, pindex, VM_ALLOC_NORMAL|VM_ALLOC_RETRY); @@ -1598,8 +1612,18 @@ return; } - if (swap_pager_getpages(object, &m, 1, 0) != VM_PAGER_OK) - panic("swap_pager_force_pagein: read from swap failed");/*XXX*/ + if ((ret=swap_pager_getpages(object, &m, 1, 0)) != VM_PAGER_OK) { + if (ret == VM_PAGER_FAIL) { + printf("swp_pager_force_pagein: VM_PAGER_FAIL\n"); + } + else { + if (ret == VM_PAGER_ERROR) { + printf("swp_pager_force_pagein: VM_PAGER_ERROR\n"); + } + else + panic("swap_pager_force_pagein: read from swap failed");/*XXX*/ + } + } vm_object_pip_subtract(object, 1); vm_page_lock_queues(); vm_page_dirty(m); --=-=-= -- Arno J. Klaassen SCITO S.A. 8 rue des Haies F-75020 Paris, France http://scito.com --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 21:29:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5146C16A925 for ; Sun, 4 Jun 2006 21:29:34 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id B705743D6A for ; Sun, 4 Jun 2006 21:29:27 +0000 (GMT) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.13.6/jtpda-5.4) with ESMTP id k54LTQDb026552 for ; Sun, 4 Jun 2006 23:29:26 +0200 (CEST) X-Ids: 164 Received: from heho.labo (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id k54LTPTi026453 for ; Sun, 4 Jun 2006 23:29:25 +0200 (MEST) Received: (from arno@localhost) by heho.labo (8.13.3/8.13.1/Submit) id k54LTP7t026450; Sun, 4 Jun 2006 23:29:25 +0200 (MEST) (envelope-from arno) Sender: arno@heho.snv.jussieu.fr To: freebsd-current@freebsd.org References: From: "Arno J. Klaassen" Date: 04 Jun 2006 23:29:25 +0200 In-Reply-To: Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (shiva.jussieu.fr [134.157.0.164]); Sun, 04 Jun 2006 23:29:26 +0200 (CEST) X-Virus-Scanned: ClamAV 0.88.2/1512/Sun Jun 4 11:58:49 2006 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at shiva.jussieu.fr with ID 448350B6.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Subject: Re: indefinite wait buffer take-II X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 21:29:34 -0000 grr, followup to myself .. the part if ( retry+TIMO_CHUNK > timo_secs) { timo_secs = retry+TIMO_CHUNK; } should be read as : if ( retry*TIMO_CHUNK > timo_secs) { timo_secs = retry*TIMO_CHUNK; } (I tested it this way, initialising timo_secs=1; sorry) -- Arno J. Klaassen SCITO S.A. 8 rue des Haies F-75020 Paris, France http://scito.com From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 23:05:14 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B044316ABC5 for ; Sun, 4 Jun 2006 23:05:14 +0000 (UTC) (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 7324443D60 for ; Sun, 4 Jun 2006 23:05:05 +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.6/8.13.6/NETPLEX) with ESMTP id k54N53OC003865; Sun, 4 Jun 2006 19:05:04 -0400 (EDT) Date: Sun, 4 Jun 2006 19:05:03 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Hay In-Reply-To: <20060604191000.GA67836@zibbi.meraka.csir.co.za> Message-ID: References: <20060604075414.GA47483@zibbi.meraka.csir.co.za> <20060604082335.GB76919@over-yonder.net> <20060604153210.GA60476@zibbi.meraka.csir.co.za> <20060604174315.GA64158@zibbi.meraka.csir.co.za> <20060604191000.GA67836@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: current@freebsd.org Subject: Re: libpthread.so.2 compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 23:05:14 -0000 On Sun, 4 Jun 2006, John Hay wrote: > On Sun, Jun 04, 2006 at 02:26:51PM -0400, Daniel Eischen wrote: >> On Sun, 4 Jun 2006, John Hay wrote: >> >>> Actually one does not even need a big complex app to see the problem. >>> Just copy /sbin/ggatec from 6.1 or 6.1-stable to a current box and you >>> will see it happen: >>> >>> ####### >>> angel:~ > uname -a >>> FreeBSD angel.cids.org.za 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sun May 28 >>> 11:06:16 SAST 2006 >>> jhay@angel.cids.org.za:/usr/src/sys/i386/compile/ANGEL i386 >>> angel:~ > ssh zibbi "uname -a" >>> FreeBSD zibbi.meraka.csir.co.za 6.1-STABLE FreeBSD 6.1-STABLE #4: Thu May >>> 25 06:11:44 SAST 2006 >>> jhay@zibbi.meraka.csir.co.za:/usr/src/sys/i386/compile/ZIBBI i386 >>> angel:~ > scp -p zibbi:/sbin/ggatec /tmp/ >>> ggatec 100% 16KB 8.1KB/s 00:02 >>> angel:~ > /tmp/ggatec >>> Segmentation fault (core dumped) >>> ####### >> >> It is probably the networking ABI changes in libc. There was a short period >> of time when there were ABI changes in libc.so.6 in -current -- before libc >> was bumped to libc.so.7. What happens when you try moving a -stable >> libc.so.6 >> to the -current machine? > > Ok, I did that but it still core dump in pthread_setcancelstate() I don't know then. If recompiling it fixes the problem, then something in /usr/include changed. All the pthread_foo_t types are pointers to things allocated by the library, and I don't think any of them changed anyways. -- DE From owner-freebsd-current@FreeBSD.ORG Sun Jun 4 23:21:51 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AE9816A763 for ; Sun, 4 Jun 2006 23:21:51 +0000 (UTC) (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 7C16643D46 for ; Sun, 4 Jun 2006 23:21:50 +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.6/8.13.6/NETPLEX) with ESMTP id k54NLnQ1014148; Sun, 4 Jun 2006 19:21:49 -0400 (EDT) Date: Sun, 4 Jun 2006 19:21:49 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Hay In-Reply-To: Message-ID: References: <20060604075414.GA47483@zibbi.meraka.csir.co.za> <20060604082335.GB76919@over-yonder.net> <20060604153210.GA60476@zibbi.meraka.csir.co.za> <20060604174315.GA64158@zibbi.meraka.csir.co.za> <20060604191000.GA67836@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: current@freebsd.org Subject: Re: libpthread.so.2 compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 23:21:52 -0000 On Sun, 4 Jun 2006, Daniel Eischen wrote: > On Sun, 4 Jun 2006, John Hay wrote: > >> On Sun, Jun 04, 2006 at 02:26:51PM -0400, Daniel Eischen wrote: >>> On Sun, 4 Jun 2006, John Hay wrote: >>> >>>> Actually one does not even need a big complex app to see the problem. >>>> Just copy /sbin/ggatec from 6.1 or 6.1-stable to a current box and you >>>> will see it happen: >>>> >>>> ####### >>>> angel:~ > uname -a >>>> FreeBSD angel.cids.org.za 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sun May 28 >>>> 11:06:16 SAST 2006 >>>> jhay@angel.cids.org.za:/usr/src/sys/i386/compile/ANGEL i386 >>>> angel:~ > ssh zibbi "uname -a" >>>> FreeBSD zibbi.meraka.csir.co.za 6.1-STABLE FreeBSD 6.1-STABLE #4: Thu May >>>> 25 06:11:44 SAST 2006 >>>> jhay@zibbi.meraka.csir.co.za:/usr/src/sys/i386/compile/ZIBBI i386 >>>> angel:~ > scp -p zibbi:/sbin/ggatec /tmp/ >>>> ggatec 100% 16KB 8.1KB/s >>>> 00:02 >>>> angel:~ > /tmp/ggatec >>>> Segmentation fault (core dumped) >>>> ####### >>> >>> It is probably the networking ABI changes in libc. There was a short >>> period >>> of time when there were ABI changes in libc.so.6 in -current -- before >>> libc >>> was bumped to libc.so.7. What happens when you try moving a -stable >>> libc.so.6 >>> to the -current machine? >> >> Ok, I did that but it still core dump in pthread_setcancelstate() > > I don't know then. If recompiling it fixes the problem, then > something in /usr/include changed. All the pthread_foo_t types > are pointers to things allocated by the library, and I don't > think any of them changed anyways. How old was your system when you upgraded to -current? There were changes to malloc() in libc.so.6 which have been in -current for a while, and libpthread is dependent on some internal locks in libc. If you are using a libc.so.6 before jasone's malloc() changes and a newer libpthread, then that won't work. When you recompile, your binaries will be linked to libc.so.7, and libpthread.so.2 will find the correct locks. If you don't find the following: $ readelf -s /lib/libc.so.6 | grep _malloc 275: 0005f65c 139 FUNC GLOBAL DEFAULT 8 _malloc_postfork 299: 000e96d0 4 OBJECT GLOBAL DEFAULT 19 _malloc_options 870: 0005f5d0 139 FUNC GLOBAL DEFAULT 8 _malloc_prefork 2486: 000d1fd8 4 OBJECT GLOBAL DEFAULT 11 _malloc_message _malloc_postfork and _malloc_prefork in libc.so.6, then that is probably why libpthread is failing. -- DE From owner-freebsd-current@FreeBSD.ORG Mon Jun 5 03:04:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4263C16A581 for ; Mon, 5 Jun 2006 03:04:43 +0000 (UTC) (envelope-from netsick@iinet.net.au) Received: from customer-domains.icp-qv1-irony1.iinet.net.au (customer-domains.icp-qv1-irony1.iinet.net.au [203.59.1.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id E178C43D53 for ; Mon, 5 Jun 2006 03:04:41 +0000 (GMT) (envelope-from netsick@iinet.net.au) Received: from per-qv1-webmail-01.iinet.net.au (HELO mail.iinet.net.au) ([203.59.3.55]) by customer-domains.icp-qv1-irony1.iinet.net.au with SMTP; 05 Jun 2006 11:04:39 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,207,1146412800"; d="scan'208"; a="511631068:sNHT24601364" Received: (qmail 31653 invoked by uid 33); 5 Jun 2006 03:04:39 -0000 Received: from mail-placeholder.iinet.net.au (mail-placeholder.iinet.net.au [203.59.1.180]) by mail.iinet.net.au (IMP) with HTTP for ; Mon, 5 Jun 2006 11:04:39 +0800 Message-ID: <1149476679.44839f4740950@mail.iinet.net.au> Date: Mon, 5 Jun 2006 11:04:39 +0800 From: netsick@iinet.net.au To: freebsd-hardware@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 203.59.1.180 Cc: freebsd-current@freebsd.org Subject: NO AGPGART - i945 ICH7 - 7.0 Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 03:04:43 -0000 device agp in my kernel no /dev/agpgart Can we get this supported please ? From owner-freebsd-current@FreeBSD.ORG Mon Jun 5 06:04:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EA8816A47C; Mon, 5 Jun 2006 06:04:40 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEA4943D45; Mon, 5 Jun 2006 06:04:39 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-71-233-168-2.hsd1.ma.comcast.net ([71.233.168.2]) by comcast.net (rwcrmhc13) with ESMTP id <20060605060438m1300g8gcpe>; Mon, 5 Jun 2006 06:04:38 +0000 Received: from c-71-233-168-2.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k5564bKo031650; Mon, 5 Jun 2006 02:04:37 -0400 (EDT) (envelope-from rodrigc@c-71-233-168-2.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k5564adO031649; Mon, 5 Jun 2006 02:04:36 -0400 (EDT) (envelope-from rodrigc) Date: Mon, 5 Jun 2006 02:04:36 -0400 From: Craig Rodrigues To: netsick@iinet.net.au Message-ID: <20060605060436.GA31638@crodrigues.org> References: <1149476679.44839f4740950@mail.iinet.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1149476679.44839f4740950@mail.iinet.net.au> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: NO AGPGART - i945 ICH7 - 7.0 Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 06:04:40 -0000 On Mon, Jun 05, 2006 at 11:04:39AM +0800, netsick@iinet.net.au wrote: > > device agp in my kernel > > no /dev/agpgart > > Can we get this supported please ? Can you try this patch? Index: pci_cfgreg.c =================================================================== RCS file: /home/ncvs/src/sys/i386/pci/pci_cfgreg.c,v retrieving revision 1.123 diff -u -u -r1.123 pci_cfgreg.c --- pci_cfgreg.c 8 Dec 2005 18:55:15 -0000 1.123 +++ pci_cfgreg.c 5 Jun 2006 06:02:33 -0000 @@ -167,8 +167,8 @@ /* Intel 7520 or 7320 */ pciebar = pci_cfgregread(0, 0, 0, 0xce, 2) << 16; pciereg_cfgopen(); - } else if (did == 0x2580 || did == 0x2584) { - /* Intel 915 or 925 */ + } else if (did == 0x2580 || did == 0x2584 || did == 0x2770) { + /* Intel 915, 925, or 945 */ pciebar = pci_cfgregread(0, 0, 0, 0x48, 4); pciereg_cfgopen(); } -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Mon Jun 5 07:55:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1068416A482 for ; Mon, 5 Jun 2006 07:55:06 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from rune.pobox.com (rune.pobox.com [208.210.124.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9572343D49 for ; Mon, 5 Jun 2006 07:55:06 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id AEBB07898A; Mon, 5 Jun 2006 03:55:27 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 6E8F011A55; Mon, 5 Jun 2006 03:55:25 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1Fn9vR-000MCh-P0; Mon, 05 Jun 2006 08:55:01 +0100 Date: Mon, 5 Jun 2006 08:55:01 +0100 From: Brian Candler To: Dirk Meyer Message-ID: <20060605075501.GA85278@uk.tiscali.com> References: <001701c681fc$acddb330$0b0ba8c0@GATEWAY> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: namebased VPS using JAIL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 07:55:07 -0000 On Sun, Jun 04, 2006 at 11:45:15AM +0200, Dirk Meyer wrote: > To allow diifrent "named" Services on one WAN IP, > you need to do this in the server application. > > Vsftpd and apache do support "Virtual Hosts" > so you can map HTTP and FTP services on > the name used by the client to access this IP. You can of run a single httpd on your main IP, and use this to proxy different virtual hosts to different (private) IPs which are in the jails, if you want each client to run their own http daemon. However, this means that the jail httpd's will see all incoming requests coming from your own IP. In order for logs and access controls to work properly, install mod_extract_forwarded on the clients' httpd servers, and AddAcceptForwarder x.x.x.x where x.x.x.x is the main server's IP. This is just for httpd though. There are many other services which can't be virtualised in this way, such ftp and ssh. If you want your clients to have these services, but sharing a single IP, then you can either run a single instance of the daemon which uses the login username to distinguish between them, or you can run multiple instances of the daemon on different ports. You can use redirection (e.g. with pf) to redirect, say, x.x.x.x:10022 to 192.168.0.1:22 HTH, Brian. From owner-freebsd-current@FreeBSD.ORG Mon Jun 5 10:23:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F2EE16A41F for ; Mon, 5 Jun 2006 10:23:13 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DE4443D4C for ; Mon, 5 Jun 2006 10:23:11 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k55AN3E0021806; Mon, 5 Jun 2006 14:23:03 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k55AN2da021804; Mon, 5 Jun 2006 14:23:02 +0400 (MSD) (envelope-from yar) Date: Mon, 5 Jun 2006 14:23:01 +0400 From: Yar Tikhiy To: Nate Lawson Message-ID: <20060605102301.GA21102@comp.chem.msu.su> References: <20060528142039.GA80613@comp.chem.msu.su> <447B551F.8000904@root.org> <20060531073145.GA30802@comp.chem.msu.su> <447DB684.7060503@root.org> <20060601102014.GA58143@comp.chem.msu.su> <4481A680.1070608@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4481A680.1070608@root.org> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: Freeze due to performance_cx_lowest=LOW X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 10:23:13 -0000 On Sat, Jun 03, 2006 at 08:10:56AM -0700, Nate Lawson wrote: > Yar Tikhiy wrote: > >On Wed, May 31, 2006 at 08:30:12AM -0700, Nate Lawson wrote: > >>Yar Tikhiy wrote: > >>>As I reported in <20060529085723.GA98288@comp.chem.msu.su>, this > >>>way of disabling apic didn't work in my case for some reason although > >>>I had triple checked the line in device.hints. The only mention > >>>of apic in the output from sysctl -a was there irrespective of the > >>>setting in device.hints: "hw.apic.enable_extint: 0". Perhaps my > >>>system has no apic at all? > >>> > >>>Nevertheless, removing "device apic" from the kernel changed things > >>>in a way, but C3 still was unusable and the system would go to C2 > >>>after detecting too many short sleeps by cpu0, which was described > >>>in the said message, too. > >>It appears that may be a different problem. On systems with the lapic > >>issue, it seems both C2/C3 are unusable. However, it seems C3 is > >>unusable on some other systems for a different reason. If you could > >>look into the datasheet errata for your chipset, you might find > >>something about this. I already have specially called out a few > >>chipsets in acpi_cpu.c to not use C3. > > > >Alas, I've failed to find the errata. My m/b is Epox EP-8K3AE, > >based on VIA KT333: > > > >http://www.epox.nl/products/view.php?product_id=388 > > Not pointing fingers, but I've had a lot of C3 problems on VIA > southbridges. I don't know if it's something we're doing wrong or they are. It's rather probable that there are quirks and bugs in the VIA chip on my m/b. From observing the recent development of our drivers as complex as ACPI or ATA I've got an impression that modern chip manufacturers rarely want to, or have enough time to, pay attention to the quality of their silicon designs, prefering to work around h/w issues in their Windows drivers. Supporting such h/w in a free OS may be a real hell, as the manufacturers release a new chip with a different bug set each quarter for their marketing people to have something to brag of. I've just had a couple of funny experiences on the ATA side, one of them with VIA, too. The point of my original posting was mostly to see if other folks experienced similar problems. Now I seem to see the complexity of the issue. > >>Oh and do you have usb compiled in? C3 won't be used on systems that > >>have usb compiled in due to the constant bus master activity when usb > >>polls ports. Anyone interested in helping with this? It basically > >>involves adding a timeout to usb to run every 1 second or so that pokes > >>usb to check for new devices and then disables it again. (global > >>suspend function I think). > > > >FWIW, my system backs off from C3 to C2 even with no usb stuff in > >the kernel. Here I mean the case of no apic in the kernel either, > >when my system can survive setting cx_lowest to C3 without freeze. > > It prints the "c3 unusable, backing off" message? That means that the > system idle thread looped too many times immediately instead of pausing > when C3 was used. I'm not sure there's anything we can do about th If it could clarify anything, the message from the kernel read, "cpu0: too many short sleeps, backing off to C2". Nate, thank you for your efforts to tame the ACPI beast :-) -- Yar From owner-freebsd-current@FreeBSD.ORG Mon Jun 5 11:55:13 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D06916A835 for ; Mon, 5 Jun 2006 11:55:13 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF4A443D45 for ; Mon, 5 Jun 2006 11:55:12 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 786741FFACC for ; Mon, 5 Jun 2006 13:55:10 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 0B1121FFACB; Mon, 5 Jun 2006 13:55:07 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 420FE4448D6 for ; Mon, 5 Jun 2006 11:51:12 +0000 (UTC) Date: Mon, 5 Jun 2006 11:51:12 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: <20060605114900.M79180@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: Subject: panic: ffs_freefile: freeing free inode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 11:55:20 -0000 Hi, this is with a kernel from late May (I'll have to check when I had synced the sources once I get it booting again...). The machine crashed with a new kernel with the next boot I got: ... properly dismounted dev = ad8s2d, ino = 329734, fs = /var panic: ffs_freefile: freeing free inode cpuid = 1 KDB: enter: panic [thread pid 129 tid 100038 ] Stopped at kdb_enter+0x31: leave db> where Tracing pid 129 tid 100038 td 0xffffff007b8b32b0 kdb_enter() at kdb_enter+0x31 panic() at panic+0x1e6 ffs_freefile() at ffs_freefile+0x231 ffs_vfree() at ffs_vfree+0x3d ufs_inactive() at ufs_inactive+0x29b VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xc5 vinactive() at vinactive+0x97 vput() at vput+0x20d kern_unlink() at kern_unlink+0x21c unlink() at unlink+0x11 syscall() at syscall+0x340 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (10, FreeBSD ELF64, unlink), rip = 0x8007080bc, rsp = 0x7fffffffed18, rbp = 0 --- db> show alllocks db> -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Mon Jun 5 14:21:52 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21C0C16B635 for ; Mon, 5 Jun 2006 14:21:47 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13BD543D88 for ; Mon, 5 Jun 2006 14:21:32 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 356701A4D80; Mon, 5 Jun 2006 07:21:31 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 363E8512A6; Mon, 5 Jun 2006 10:21:28 -0400 (EDT) Date: Mon, 5 Jun 2006 10:21:28 -0400 From: Kris Kennaway To: "Bjoern A. Zeeb" Message-ID: <20060605142128.GB66078@xor.obsecurity.org> References: <20060605114900.M79180@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0ntfKIWw70PvrIHh" Content-Disposition: inline In-Reply-To: <20060605114900.M79180@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD current mailing list Subject: Re: panic: ffs_freefile: freeing free inode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 14:22:05 -0000 --0ntfKIWw70PvrIHh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 05, 2006 at 11:51:12AM +0000, Bjoern A. Zeeb wrote: > Hi, >=20 > this is with a kernel from late May (I'll have to check when I had > synced the sources once I get it booting again...). > The machine crashed with a new kernel with the next boot I got: >=20 > ... > properly dismounted i.e. you previously panicked and then ran bg fsck? This can cause further panics until you force a fg fsck, since your filesystem had damage that was not safe to run with. Just say no to bg fsck! Kris --0ntfKIWw70PvrIHh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEhD3nWry0BWjoQKURAj+TAKCb4eHEW7xSxt+tepMjfiyb84DfvgCeKz1k RB8TFg4moW4EhaVHDkojOpE= =cgar -----END PGP SIGNATURE----- --0ntfKIWw70PvrIHh-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 5 16:01:05 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 311B016A551; Mon, 5 Jun 2006 16:01:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7BB143D53; Mon, 5 Jun 2006 16:01:04 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id D1C8646C4D; Mon, 5 Jun 2006 12:01:03 -0400 (EDT) Date: Mon, 5 Jun 2006 17:01:04 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20060605165946.L61202@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: trustedbsd-audit@TrustedBSD.org Subject: Heads up: OpenBSM 1.0a6, per-auditpipe preselection imported to CVS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 16:01:16 -0000 This is a heads up to current@ users regarding two moderate sized sets of changes that entered FreeBSD CVS today: (1) I imported OpenBSM 1.0 alpha 6. (2) I imported support for per-auditpipe preselection. Detailed commit messages are below. Robert N M Watson ---------- Forwarded message ---------- Date: Mon, 5 Jun 2006 10:52:14 +0000 (UTC) From: Robert Watson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/contrib/openbsm - Imported sources rwatson 2006-06-05 10:52:14 UTC FreeBSD src repository src/contrib/openbsm - Imported sources Update of /home/ncvs/src/contrib/openbsm In directory repoman.freebsd.org:/tmp/cvs-serv59860 Log Message: Vendor branch import of TrustedBSD OpenBSM 1.0 alpha 6: - Use AU_TO_WRITE and AU_NO_TO_WRITE for the 'keep' argument to au_close(); previously we used hard-coded 0 and 1 values. - Add man page for au_open(), au_write(), au_close(), and au_close_buffer(). - Support a more complete range of data types for the arbitrary data token: add AUR_CHAR (alias to AUR_BYTE), remove AUR_LONG, add AUR_INT32 (alias to AUR_INT), add AUR_INT64. - Add au_close_token(), which allows writing a single token_t to a memory buffer. Not likely to be used much by applications, but useful for writing test tools. - Modify au_to_file() so that it accepts a timeval in user space, not just kernel -- this is not a Solaris BSM API so can be modified without causing compatibility issues. - Define a new API, au_to_header32_tm(), which adds a struct timeval argument to the ordinary au_to_header32(), which is now implemented by wrapping au_to_header32_tm() and calling gettimeofday(). #ifndef KERNEL the APIs that invoke gettimeofday(), rather than having a variable definition. Don't try to retrieve time zone information using gettimeofday(), as it's not needed, and introduces possible failure modes. - Don't perform byte order transformations on the addr/machine fields of the terminal ID that appears in the process32/subject32 tokens. These are assumed to be IP addresses, and as such, to be in network byte order. - Universally, APIs now assume that IP addresses and ports are provided in network byte order. APIs now generally provide these types in network byte order when decoding. - Beginnings of an OpenBSM test framework can now be found in openbsm/test. This code is not built or installed by default. - auditd now assigns more appropriate syslog levels to its debugging and error information. - Support for audit filters introduced: audit filters are dynamically loaded shared objects that run in the context of a new daemon, auditfilterd. The daemon reads from an audit pipe and feeds both BSM and parsed versions of records to shared objects using a module API. This will provide a framework for the writing of intrusion detection services. - New utility API, audit_submit(), added to capture common elements of audit record submission for many applications. Obtained from: TrustedBSD Project Status: Vendor Tag: TrustedBSD Release Tags: OPENBSM_1_0_ALPHA_6 U src/contrib/openbsm/HISTORY U src/contrib/openbsm/LICENSE U src/contrib/openbsm/Makefile.am U src/contrib/openbsm/Makefile.in U src/contrib/openbsm/README U src/contrib/openbsm/TODO U src/contrib/openbsm/VERSION U src/contrib/openbsm/aclocal.m4 U src/contrib/openbsm/autogen.sh U src/contrib/openbsm/configure U src/contrib/openbsm/configure.ac U src/contrib/openbsm/bin/Makefile.am U src/contrib/openbsm/bin/Makefile.in U src/contrib/openbsm/bin/audit/Makefile.am U src/contrib/openbsm/bin/audit/Makefile.in U src/contrib/openbsm/bin/audit/audit.8 U src/contrib/openbsm/bin/audit/audit.c U src/contrib/openbsm/bin/auditd/Makefile.am U src/contrib/openbsm/bin/auditd/Makefile.in U src/contrib/openbsm/bin/auditd/audit_warn.c U src/contrib/openbsm/bin/auditd/auditd.8 U src/contrib/openbsm/bin/auditd/auditd.c U src/contrib/openbsm/bin/auditd/auditd.h N src/contrib/openbsm/bin/auditfilterd/Makefile.am N src/contrib/openbsm/bin/auditfilterd/Makefile.in N src/contrib/openbsm/bin/auditfilterd/auditfilterd.8 N src/contrib/openbsm/bin/auditfilterd/auditfilterd.c N src/contrib/openbsm/bin/auditfilterd/auditfilterd.h N src/contrib/openbsm/bin/auditfilterd/auditfilterd_conf.c U src/contrib/openbsm/bin/auditreduce/Makefile.am U src/contrib/openbsm/bin/auditreduce/Makefile.in U src/contrib/openbsm/bin/auditreduce/auditreduce.1 U src/contrib/openbsm/bin/auditreduce/auditreduce.c U src/contrib/openbsm/bin/auditreduce/auditreduce.h U src/contrib/openbsm/bin/praudit/Makefile.am U src/contrib/openbsm/bin/praudit/Makefile.in U src/contrib/openbsm/bin/praudit/praudit.1 U src/contrib/openbsm/bin/praudit/praudit.c U src/contrib/openbsm/bsm/Makefile.am U src/contrib/openbsm/bsm/Makefile.in U src/contrib/openbsm/bsm/audit.h N src/contrib/openbsm/bsm/audit_filter.h U src/contrib/openbsm/bsm/audit_internal.h U src/contrib/openbsm/bsm/audit_kevents.h U src/contrib/openbsm/bsm/audit_record.h U src/contrib/openbsm/bsm/audit_uevents.h U src/contrib/openbsm/bsm/libbsm.h U src/contrib/openbsm/compat/endian.h U src/contrib/openbsm/compat/queue.h U src/contrib/openbsm/config/config.guess U src/contrib/openbsm/config/config.h.in U src/contrib/openbsm/config/config.sub U src/contrib/openbsm/config/depcomp U src/contrib/openbsm/config/install-sh U src/contrib/openbsm/config/ltmain.sh U src/contrib/openbsm/config/missing U src/contrib/openbsm/etc/audit_class U src/contrib/openbsm/etc/audit_control U src/contrib/openbsm/etc/audit_event N src/contrib/openbsm/etc/audit_filter U src/contrib/openbsm/etc/audit_user U src/contrib/openbsm/etc/audit_warn U src/contrib/openbsm/libbsm/Makefile.am U src/contrib/openbsm/libbsm/Makefile.in U src/contrib/openbsm/libbsm/au_class.3 U src/contrib/openbsm/libbsm/au_control.3 U src/contrib/openbsm/libbsm/au_event.3 U src/contrib/openbsm/libbsm/au_free_token.3 U src/contrib/openbsm/libbsm/au_io.3 U src/contrib/openbsm/libbsm/au_mask.3 N src/contrib/openbsm/libbsm/au_open.3 U src/contrib/openbsm/libbsm/au_token.3 U src/contrib/openbsm/libbsm/au_user.3 N src/contrib/openbsm/libbsm/audit_submit.3 U src/contrib/openbsm/libbsm/bsm_audit.c U src/contrib/openbsm/libbsm/bsm_class.c U src/contrib/openbsm/libbsm/bsm_control.c U src/contrib/openbsm/libbsm/bsm_event.c U src/contrib/openbsm/libbsm/bsm_flags.c U src/contrib/openbsm/libbsm/bsm_io.c U src/contrib/openbsm/libbsm/bsm_mask.c U src/contrib/openbsm/libbsm/bsm_notify.c U src/contrib/openbsm/libbsm/bsm_token.c U src/contrib/openbsm/libbsm/bsm_user.c U src/contrib/openbsm/libbsm/libbsm.3 U src/contrib/openbsm/libbsm/bsm_wrappers.c U src/contrib/openbsm/man/Makefile.am U src/contrib/openbsm/man/Makefile.in U src/contrib/openbsm/man/audit.2 U src/contrib/openbsm/man/audit.log.5 U src/contrib/openbsm/man/audit_class.5 U src/contrib/openbsm/man/audit_control.5 U src/contrib/openbsm/man/audit_event.5 U src/contrib/openbsm/man/audit_user.5 U src/contrib/openbsm/man/audit_warn.5 U src/contrib/openbsm/man/auditctl.2 U src/contrib/openbsm/man/auditon.2 U src/contrib/openbsm/man/getaudit.2 U src/contrib/openbsm/man/getauid.2 U src/contrib/openbsm/man/setaudit.2 U src/contrib/openbsm/man/setauid.2 N src/contrib/openbsm/modules/Makefile.am N src/contrib/openbsm/modules/Makefile.in N src/contrib/openbsm/modules/auditfilter_noop/Makefile.am N src/contrib/openbsm/modules/auditfilter_noop/Makefile.in N src/contrib/openbsm/modules/auditfilter_noop/auditfilter_noop.c N src/contrib/openbsm/test/Makefile.am N src/contrib/openbsm/test/Makefile.in N src/contrib/openbsm/test/bsm/Makefile.am N src/contrib/openbsm/test/bsm/Makefile.in N src/contrib/openbsm/test/bsm/generate.c U src/contrib/openbsm/tools/Makefile.am U src/contrib/openbsm/tools/Makefile.in U src/contrib/openbsm/tools/audump.c No conflicts created by this import ---------- Forwarded message ---------- Date: Mon, 5 Jun 2006 14:48:17 +0000 (UTC) From: Robert Watson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/security/audit audit.c audit_bsm_klib.c audit_ioctl.h audit_pipe.c audit_private.h audit_worker.c rwatson 2006-06-05 14:48:17 UTC FreeBSD src repository Modified files: sys/security/audit audit.c audit_bsm_klib.c audit_ioctl.h audit_pipe.c audit_private.h audit_worker.c Log: Introduce support for per-audit pipe preselection independent from the global audit trail configuration. This allows applications consuming audit trails to specify parameters for which audit records are of interest, including selecting records not required by the global trail. Allowing application interest specification without changing the global configuration allows intrusion detection systems to run without interfering with global auditing or each other (if multiple are present). To implement this: - Kernel audit records now carry a flag to indicate whether they have been selected by the global trail or by the audit pipe subsystem, set during record commit, so that this information is available after BSM conversion when delivering the BSM to the trail and audit pipes in the audit worker thread asynchronously. Preselection by either record target will cause the record to be kept. - Similar changes to preselection when the audit record is created when the system call is entering: consult both the global trail and pipes. - au_preselect() now accepts the class in order to avoid repeatedly looking up the mask for each preselection test. - Define a series of ioctls that allow applications to specify whether they want to track the global trail, or program their own preselection parameters: they may specify their own flags and naflags masks, similar to the global masks of the same name, as well as a set of per-auid masks. They also set a per-pipe mode specifying whether they track the global trail, or user their own -- the door is left open for future additional modes. A new ioctl is defined to allow a user process to flush the current audit pipe queue, which can be used after reprogramming pre-selection to make sure that only records of interest are received in future reads. - Audit pipe data structures are extended to hold the additional fields necessary to support preselection. By default, audit pipes track the global trail, so "praudit /dev/auditpipe" will track the global audit trail even though praudit doesn't program the audit pipe selection model. - Comment about the complexities of potentially adding partial read support to audit pipes. By using a set of ioctls, applications can select which records are of interest, and toggle the preselection mode. Obtained from: TrustedBSD Project Revision Changes Path 1.15 +28 -16 src/sys/security/audit/audit.c 1.4 +3 -6 src/sys/security/audit/audit_bsm_klib.c 1.3 +32 -0 src/sys/security/audit/audit_ioctl.h 1.7 +393 -13 src/sys/security/audit/audit_pipe.c 1.9 +13 -3 src/sys/security/audit/audit_private.h 1.8 +49 -27 src/sys/security/audit/audit_worker.c From owner-freebsd-current@FreeBSD.ORG Mon Jun 5 15:22:27 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC21D16BB03; Mon, 5 Jun 2006 15:22:27 +0000 (UTC) (envelope-from erob@cpan.org) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B7F543D46; Mon, 5 Jun 2006 15:22:24 +0000 (GMT) (envelope-from erob@cpan.org) Received: from sparklslap:) ([70.83.244.138]) by VL-MO-MR003.ip.videotron.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J0E00MN181B4D60@VL-MO-MR003.ip.videotron.ca>; Mon, 05 Jun 2006 11:22:24 -0400 (EDT) Date: Mon, 05 Jun 2006 11:37:32 -0400 From: Etienne Robillard To: FreeBSD gnats submit MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. X-send-pr-version: gtk-send-pr 0.4.7 X-GNATS-Notify: Message-Id: <20060605152224.0B7F543D46@mx1.FreeBSD.org> X-Mailman-Approved-At: Mon, 05 Jun 2006 16:20:30 +0000 Cc: FreeBSD current mailing list Subject: devel/subversion: build/linking problem on 7-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 15:22:29 -0000 >Submitter-Id: current-users >Originator: Etienne Robillard >Organization: >Confidential: no >Synopsis: devel/subversion: build/linking problem on 7-current >Severity: critical >Priority: medium >Category: ports >Class: sw-bug >Release: FreeBSD 7.0-CURRENT i386 >Environment: System: FreeBSD 7.0-CURRENT #1: Sat Jun 3 18:32:25 EDT 2006 root@sparklslap:):/usr/obj/usr/src/sys/GENERIC >Description: ===> Building for subversion-1.3.1_1 cd subversion/clients/cmdline && /usr/local/bin/libtool --tag=CC --silent --mode=link cc -O2 -fno-strict-aliasing -pipe -g -O2 -L/usr/local/lib/db42 -L/usr/local/lib -rpath /usr/local/lib -o svn add-cmd.o blame-cmd.o cat-cmd.o checkout-cmd.o cleanup-cmd.o commit-cmd.o copy-cmd.o delete-cmd.o diff-cmd.o export-cmd.o help-cmd.o import-cmd.o info-cmd.o lock-cmd.o log-cmd.o ls-cmd.o main.o merge-cmd.o mkdir-cmd.o move-cmd.o notify.o prompt.o propdel-cmd.o propedit-cmd.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o resolved-cmd.o revert-cmd.o status-cmd.o status.o switch-cmd.o unlock-cmd.o update-cmd.o util.o ../../../subversion/libsvn_client/libsvn_client-1.la ../../../subversion/libsvn_wc/libsvn_wc-1.la ../../../subversion/libsvn_ra/libsvn_ra-1.la ../../../subversion/libsvn_delta/libsvn_delta-1.la ../../../subversion/libsvn_subr/libsvn_subr-1.la /usr/local/lib/libaprutil-1.la -ldb-4.2 -lexpat -liconv /usr/local/lib/libapr-1.la -lcrypt -lpthread -L/usr/local/lib -rp ath=/usr /usr/lib/libroken.so: undefined reference to `_(long double,...)(short)' *** Error code 1 Stop in /usr/ports/devel/subversion/work/subversion-1.3.1. *** Error code 1 Stop in /usr/ports/devel/subversion. >How-To-Repeat: $ cd /ports/devel/subversion $ sudo make build >Fix: From owner-freebsd-current@FreeBSD.ORG Mon Jun 5 16:47:25 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2872D16BD22; Mon, 5 Jun 2006 16:47:25 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BABA43D6A; Mon, 5 Jun 2006 16:47:13 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id DBFAC33C99; Mon, 5 Jun 2006 18:47:11 +0200 (SAST) Date: Mon, 5 Jun 2006 18:47:11 +0200 From: John Hay To: Daniel Eischen Message-ID: <20060605164711.GA8065@zibbi.meraka.csir.co.za> References: <20060604075414.GA47483@zibbi.meraka.csir.co.za> <20060604082335.GB76919@over-yonder.net> <20060604153210.GA60476@zibbi.meraka.csir.co.za> <20060604174315.GA64158@zibbi.meraka.csir.co.za> <20060604191000.GA67836@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: libpthread.so.2 compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 16:47:35 -0000 > >>> > >>>>Actually one does not even need a big complex app to see the problem. > >>>>Just copy /sbin/ggatec from 6.1 or 6.1-stable to a current box and you > >>>>will see it happen: > >>>> > >>>>####### > >>>>angel:~ > uname -a > >>>>FreeBSD angel.cids.org.za 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sun May 28 > >>>>11:06:16 SAST 2006 > >>>>jhay@angel.cids.org.za:/usr/src/sys/i386/compile/ANGEL i386 > >>>>angel:~ > ssh zibbi "uname -a" > >>>>FreeBSD zibbi.meraka.csir.co.za 6.1-STABLE FreeBSD 6.1-STABLE #4: Thu > >>>>May > >>>>25 06:11:44 SAST 2006 > >>>>jhay@zibbi.meraka.csir.co.za:/usr/src/sys/i386/compile/ZIBBI i386 > >>>>angel:~ > scp -p zibbi:/sbin/ggatec /tmp/ > >>>>ggatec 100% 16KB 8.1KB/s > >>>>00:02 > >>>>angel:~ > /tmp/ggatec > >>>>Segmentation fault (core dumped) > >>>>####### > >>> > >>>It is probably the networking ABI changes in libc. There was a short > >>>period > >>>of time when there were ABI changes in libc.so.6 in -current -- before > >>>libc > >>>was bumped to libc.so.7. What happens when you try moving a -stable > >>>libc.so.6 > >>>to the -current machine? > >> > >>Ok, I did that but it still core dump in pthread_setcancelstate() > > > >I don't know then. If recompiling it fixes the problem, then > >something in /usr/include changed. All the pthread_foo_t types > >are pointers to things allocated by the library, and I don't > >think any of them changed anyways. > > How old was your system when you upgraded to -current? There > were changes to malloc() in libc.so.6 which have been in -current > for a while, and libpthread is dependent on some internal locks > in libc. If you are using a libc.so.6 before jasone's malloc() > changes and a newer libpthread, then that won't work. When you > recompile, your binaries will be linked to libc.so.7, and > libpthread.so.2 will find the correct locks. If you don't > find the following: > > $ readelf -s /lib/libc.so.6 | grep _malloc > 275: 0005f65c 139 FUNC GLOBAL DEFAULT 8 _malloc_postfork > 299: 000e96d0 4 OBJECT GLOBAL DEFAULT 19 _malloc_options > 870: 0005f5d0 139 FUNC GLOBAL DEFAULT 8 _malloc_prefork > 2486: 000d1fd8 4 OBJECT GLOBAL DEFAULT 11 _malloc_message > > _malloc_postfork and _malloc_prefork in libc.so.6, then that is > probably why libpthread is failing. The libc.so.6 I copied from the -stable box does not have it: # readelf -s /lib/libc.so.6 | grep _malloc 281: 000d78b4 4 OBJECT GLOBAL DEFAULT 18 _malloc_options 1705: 000c0e30 4 OBJECT GLOBAL DEFAULT 11 __malloc_lock 2351: 000c0e2c 4 OBJECT GLOBAL DEFAULT 11 _malloc_message But the one from the -current box has it: # readelf -s /lib/libc.so.6.old | grep _malloc 274: 0005fcd4 113 FUNC GLOBAL DEFAULT 8 _malloc_postfork 297: 000e25d4 4 OBJECT GLOBAL DEFAULT 19 _malloc_options 852: 0005fc60 113 FUNC GLOBAL DEFAULT 8 _malloc_prefork 2424: 000cae38 4 OBJECT GLOBAL DEFAULT 11 _malloc_message Does it work for you? Can you take a 6-stable libpthread app and run it on current? John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jun 5 17:01:12 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5CE216B30D for ; Mon, 5 Jun 2006 17:01:12 +0000 (UTC) (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 3051B43D6D for ; Mon, 5 Jun 2006 17:01:12 +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.6/8.13.6/NETPLEX) with ESMTP id k55H1BlN007681; Mon, 5 Jun 2006 13:01:11 -0400 (EDT) Date: Mon, 5 Jun 2006 13:01:11 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Hay In-Reply-To: <20060605164711.GA8065@zibbi.meraka.csir.co.za> Message-ID: References: <20060604075414.GA47483@zibbi.meraka.csir.co.za> <20060604082335.GB76919@over-yonder.net> <20060604153210.GA60476@zibbi.meraka.csir.co.za> <20060604174315.GA64158@zibbi.meraka.csir.co.za> <20060604191000.GA67836@zibbi.meraka.csir.co.za> <20060605164711.GA8065@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: current@freebsd.org Subject: Re: libpthread.so.2 compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 17:01:24 -0000 On Mon, 5 Jun 2006, John Hay wrote: >> >> How old was your system when you upgraded to -current? There >> were changes to malloc() in libc.so.6 which have been in -current >> for a while, and libpthread is dependent on some internal locks >> in libc. If you are using a libc.so.6 before jasone's malloc() >> changes and a newer libpthread, then that won't work. When you >> recompile, your binaries will be linked to libc.so.7, and >> libpthread.so.2 will find the correct locks. If you don't >> find the following: >> >> $ readelf -s /lib/libc.so.6 | grep _malloc >> 275: 0005f65c 139 FUNC GLOBAL DEFAULT 8 _malloc_postfork >> 299: 000e96d0 4 OBJECT GLOBAL DEFAULT 19 _malloc_options >> 870: 0005f5d0 139 FUNC GLOBAL DEFAULT 8 _malloc_prefork >> 2486: 000d1fd8 4 OBJECT GLOBAL DEFAULT 11 _malloc_message >> >> _malloc_postfork and _malloc_prefork in libc.so.6, then that is >> probably why libpthread is failing. > > The libc.so.6 I copied from the -stable box does not have it: > > # readelf -s /lib/libc.so.6 | grep _malloc > 281: 000d78b4 4 OBJECT GLOBAL DEFAULT 18 _malloc_options > 1705: 000c0e30 4 OBJECT GLOBAL DEFAULT 11 __malloc_lock > 2351: 000c0e2c 4 OBJECT GLOBAL DEFAULT 11 _malloc_message > > But the one from the -current box has it: > > # readelf -s /lib/libc.so.6.old | grep _malloc > 274: 0005fcd4 113 FUNC GLOBAL DEFAULT 8 _malloc_postfork > 297: 000e25d4 4 OBJECT GLOBAL DEFAULT 19 _malloc_options > 852: 0005fc60 113 FUNC GLOBAL DEFAULT 8 _malloc_prefork > 2424: 000cae38 4 OBJECT GLOBAL DEFAULT 11 _malloc_message > > Does it work for you? Can you take a 6-stable libpthread app and run > it on current? No, you can't make a 6-stable libpthread and have it work on -current. Both libc and libpthread have to match. There were also other changes in libc that libpthread relies on (__thr_jtable changed in size). When you upgraded to -current, you got a different libpthread that is reliant on -current's libc. But since libc's version was bumped, you never got a -current libc.so.6 that was compatible with libpthread. The only way to get around this is to go back a couple of weeks to before the resolver changes and libc bump were committed -- rebuild libc.so.6 from those older sources. -- DE From owner-freebsd-current@FreeBSD.ORG Mon Jun 5 17:14:19 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9753416B721; Mon, 5 Jun 2006 17:14:19 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70D4843D60; Mon, 5 Jun 2006 17:14:18 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 1474B33C93; Mon, 5 Jun 2006 19:14:14 +0200 (SAST) Date: Mon, 5 Jun 2006 19:14:14 +0200 From: John Hay To: Daniel Eischen Message-ID: <20060605171414.GA9032@zibbi.meraka.csir.co.za> References: <20060604153210.GA60476@zibbi.meraka.csir.co.za> <20060604174315.GA64158@zibbi.meraka.csir.co.za> <20060604191000.GA67836@zibbi.meraka.csir.co.za> <20060605164711.GA8065@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: libpthread.so.2 compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 17:14:28 -0000 On Mon, Jun 05, 2006 at 01:01:11PM -0400, Daniel Eischen wrote: > On Mon, 5 Jun 2006, John Hay wrote: > >> > >>How old was your system when you upgraded to -current? There > >>were changes to malloc() in libc.so.6 which have been in -current > >>for a while, and libpthread is dependent on some internal locks > >>in libc. If you are using a libc.so.6 before jasone's malloc() > >>changes and a newer libpthread, then that won't work. When you > >>recompile, your binaries will be linked to libc.so.7, and > >>libpthread.so.2 will find the correct locks. If you don't > >>find the following: > >> > >> $ readelf -s /lib/libc.so.6 | grep _malloc > >> 275: 0005f65c 139 FUNC GLOBAL DEFAULT 8 _malloc_postfork > >> 299: 000e96d0 4 OBJECT GLOBAL DEFAULT 19 _malloc_options > >> 870: 0005f5d0 139 FUNC GLOBAL DEFAULT 8 _malloc_prefork > >> 2486: 000d1fd8 4 OBJECT GLOBAL DEFAULT 11 _malloc_message > >> > >>_malloc_postfork and _malloc_prefork in libc.so.6, then that is > >>probably why libpthread is failing. > > > >The libc.so.6 I copied from the -stable box does not have it: > > > ># readelf -s /lib/libc.so.6 | grep _malloc > > 281: 000d78b4 4 OBJECT GLOBAL DEFAULT 18 _malloc_options > > 1705: 000c0e30 4 OBJECT GLOBAL DEFAULT 11 __malloc_lock > > 2351: 000c0e2c 4 OBJECT GLOBAL DEFAULT 11 _malloc_message > > > >But the one from the -current box has it: > > > ># readelf -s /lib/libc.so.6.old | grep _malloc > > 274: 0005fcd4 113 FUNC GLOBAL DEFAULT 8 _malloc_postfork > > 297: 000e25d4 4 OBJECT GLOBAL DEFAULT 19 _malloc_options > > 852: 0005fc60 113 FUNC GLOBAL DEFAULT 8 _malloc_prefork > > 2424: 000cae38 4 OBJECT GLOBAL DEFAULT 11 _malloc_message > > > >Does it work for you? Can you take a 6-stable libpthread app and run > >it on current? > > No, you can't make a 6-stable libpthread and have it work > on -current. Both libc and libpthread have to match. There > were also other changes in libc that libpthread relies on > (__thr_jtable changed in size). > > When you upgraded to -current, you got a different libpthread > that is reliant on -current's libc. But since libc's version > was bumped, you never got a -current libc.so.6 that was > compatible with libpthread. The only way to get around this > is to go back a couple of weeks to before the resolver > changes and libc bump were committed -- rebuild libc.so.6 > from those older sources. Not sure if I understand you wrong. I didn't mean that one should take a 6-stable libpthread. I meant an app that use libpthread. Or is that what you mean? That one cannot use an app on -current that use libpthread, but was compiled on 6-stable? If that was so, I will accept it, although the commit message in libpthread/Makefile ver 1.55 make it sound as if it should work. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jun 5 17:33:16 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8507216A73B for ; Mon, 5 Jun 2006 17:33:16 +0000 (UTC) (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 214CC43D55 for ; Mon, 5 Jun 2006 17:33:13 +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.6/8.13.6/NETPLEX) with ESMTP id k55HXDww012862; Mon, 5 Jun 2006 13:33:13 -0400 (EDT) Date: Mon, 5 Jun 2006 13:33:13 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Hay In-Reply-To: <20060605171414.GA9032@zibbi.meraka.csir.co.za> Message-ID: References: <20060604153210.GA60476@zibbi.meraka.csir.co.za> <20060604174315.GA64158@zibbi.meraka.csir.co.za> <20060604191000.GA67836@zibbi.meraka.csir.co.za> <20060605164711.GA8065@zibbi.meraka.csir.co.za> <20060605171414.GA9032@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: current@freebsd.org Subject: Re: libpthread.so.2 compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 17:33:22 -0000 On Mon, 5 Jun 2006, John Hay wrote: > On Mon, Jun 05, 2006 at 01:01:11PM -0400, Daniel Eischen wrote: >> On Mon, 5 Jun 2006, John Hay wrote: >>>> >>>> How old was your system when you upgraded to -current? There >>>> were changes to malloc() in libc.so.6 which have been in -current >>>> for a while, and libpthread is dependent on some internal locks >>>> in libc. If you are using a libc.so.6 before jasone's malloc() >>>> changes and a newer libpthread, then that won't work. When you >>>> recompile, your binaries will be linked to libc.so.7, and >>>> libpthread.so.2 will find the correct locks. If you don't >>>> find the following: >>>> >>>> $ readelf -s /lib/libc.so.6 | grep _malloc >>>> 275: 0005f65c 139 FUNC GLOBAL DEFAULT 8 _malloc_postfork >>>> 299: 000e96d0 4 OBJECT GLOBAL DEFAULT 19 _malloc_options >>>> 870: 0005f5d0 139 FUNC GLOBAL DEFAULT 8 _malloc_prefork >>>> 2486: 000d1fd8 4 OBJECT GLOBAL DEFAULT 11 _malloc_message >>>> >>>> _malloc_postfork and _malloc_prefork in libc.so.6, then that is >>>> probably why libpthread is failing. >>> >>> The libc.so.6 I copied from the -stable box does not have it: >>> >>> # readelf -s /lib/libc.so.6 | grep _malloc >>> 281: 000d78b4 4 OBJECT GLOBAL DEFAULT 18 _malloc_options >>> 1705: 000c0e30 4 OBJECT GLOBAL DEFAULT 11 __malloc_lock >>> 2351: 000c0e2c 4 OBJECT GLOBAL DEFAULT 11 _malloc_message >>> >>> But the one from the -current box has it: >>> >>> # readelf -s /lib/libc.so.6.old | grep _malloc >>> 274: 0005fcd4 113 FUNC GLOBAL DEFAULT 8 _malloc_postfork >>> 297: 000e25d4 4 OBJECT GLOBAL DEFAULT 19 _malloc_options >>> 852: 0005fc60 113 FUNC GLOBAL DEFAULT 8 _malloc_prefork >>> 2424: 000cae38 4 OBJECT GLOBAL DEFAULT 11 _malloc_message >>> >>> Does it work for you? Can you take a 6-stable libpthread app and run >>> it on current? >> >> No, you can't make a 6-stable libpthread and have it work >> on -current. Both libc and libpthread have to match. There >> were also other changes in libc that libpthread relies on >> (__thr_jtable changed in size). >> >> When you upgraded to -current, you got a different libpthread >> that is reliant on -current's libc. But since libc's version >> was bumped, you never got a -current libc.so.6 that was >> compatible with libpthread. The only way to get around this >> is to go back a couple of weeks to before the resolver >> changes and libc bump were committed -- rebuild libc.so.6 >> from those older sources. > > Not sure if I understand you wrong. I didn't mean that one should > take a 6-stable libpthread. I meant an app that use libpthread. Or > is that what you mean? That one cannot use an app on -current that > use libpthread, but was compiled on 6-stable? If that was so, I > will accept it, although the commit message in libpthread/Makefile > ver 1.55 make it sound as if it should work. No, you can't use that app unless you somehow build it so that it doesn't use libc. The problem is that you don't have a libc.so.6 that matches libpthread.so.2. You -stable app depends on libc.so.6, not libc.so.7. When you upgrade from -stable to -current, you bypass the changes that went into libc.so.6 before it became libc.so.7. The -current libpthread.so.2 changed to stay in sync with those changes. Bottom line: -stable libc.so.6 != -current libc.so.6 -stable libpthread.so.2 != -current libpthread.so.2 Both libpthread.so.2 and libc.so.6 (and .so.7) have to be in sync (built from same-dated sources). -- DE From owner-freebsd-current@FreeBSD.ORG Mon Jun 5 18:04:49 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4155A16C28D; Mon, 5 Jun 2006 18:04:49 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80E2143D53; Mon, 5 Jun 2006 18:04:47 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id A664E33C99; Mon, 5 Jun 2006 20:04:45 +0200 (SAST) Date: Mon, 5 Jun 2006 20:04:45 +0200 From: John Hay To: Daniel Eischen Message-ID: <20060605180445.GA10089@zibbi.meraka.csir.co.za> References: <20060604174315.GA64158@zibbi.meraka.csir.co.za> <20060604191000.GA67836@zibbi.meraka.csir.co.za> <20060605164711.GA8065@zibbi.meraka.csir.co.za> <20060605171414.GA9032@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: libpthread.so.2 compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 18:04:52 -0000 On Mon, Jun 05, 2006 at 01:33:13PM -0400, Daniel Eischen wrote: > > No, you can't use that app unless you somehow build it so that > it doesn't use libc. The problem is that you don't have a > libc.so.6 that matches libpthread.so.2. You -stable app depends > on libc.so.6, not libc.so.7. When you upgrade from -stable > to -current, you bypass the changes that went into libc.so.6 > before it became libc.so.7. The -current libpthread.so.2 > changed to stay in sync with those changes. > > Bottom line: -stable libc.so.6 != -current libc.so.6 > -stable libpthread.so.2 != -current libpthread.so.2 > > Both libpthread.so.2 and libc.so.6 (and .so.7) have to be > in sync (built from same-dated sources). Ok, hopefully this is just a temporary thing until somebody can work up the courage to bump libpthread.so.2. It is pretty silly to have two files with the same name but different contents. Even the compat libs cannot help with that. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jun 5 19:41:06 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2861B16B37E for ; Mon, 5 Jun 2006 19:41:06 +0000 (UTC) (envelope-from granted14@yahoo.com) Received: from web55614.mail.re4.yahoo.com (web55614.mail.re4.yahoo.com [206.190.58.238]) by mx1.FreeBSD.org (Postfix) with SMTP id A36D543D88 for ; Mon, 5 Jun 2006 19:41:04 +0000 (GMT) (envelope-from granted14@yahoo.com) Received: (qmail 34175 invoked by uid 60001); 5 Jun 2006 19:41:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tVRU8lNUwB/KaXV0jUXFxCf/G31hvno9q7EtllDlJBfvn11NSnFQ9vo1LQIeV0DRyYs0eBpmlKqzM8jFPv/ZzvXFQouIFzo/64sUsWH9g9bMumoUKD82GB6mllyQEyMjYhHGAVup7JCZUmGoVR3iICPMlEQPuu9WYepAwpV5+Bk= ; Message-ID: <20060605194104.34173.qmail@web55614.mail.re4.yahoo.com> Received: from [70.83.244.138] by web55614.mail.re4.yahoo.com via HTTP; Mon, 05 Jun 2006 15:41:03 EDT Date: Mon, 5 Jun 2006 15:41:03 -0400 (EDT) From: Etienne Robillard To: freebsd-current@FreeBSD.org In-Reply-To: <20060605152224.0B7F543D46@mx1.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: devel/subversion: build/linking problem on 7-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 19:41:14 -0000 --- Etienne Robillard wrote: > > >Submitter-Id: current-users > >Originator: Etienne Robillard > >Organization: > >Confidential: no > >Synopsis: devel/subversion: build/linking problem > on 7-current > >Severity: critical > >Priority: medium > >Category: ports > >Class: sw-bug > >Release: FreeBSD 7.0-CURRENT i386 > >Environment: > > > System: FreeBSD 7.0-CURRENT #1: Sat Jun 3 18:32:25 > EDT 2006 > root@sparklslap:):/usr/obj/usr/src/sys/GENERIC > > > > >Description: > > > ===> Building for subversion-1.3.1_1 > cd subversion/clients/cmdline && > /usr/local/bin/libtool --tag=CC --silent --mode=link > cc -O2 -fno-strict-aliasing -pipe -g -O2 > -L/usr/local/lib/db42 -L/usr/local/lib -rpath > /usr/local/lib -o svn add-cmd.o blame-cmd.o > cat-cmd.o checkout-cmd.o cleanup-cmd.o commit-cmd.o > copy-cmd.o delete-cmd.o diff-cmd.o export-cmd.o > help-cmd.o import-cmd.o info-cmd.o lock-cmd.o > log-cmd.o ls-cmd.o main.o merge-cmd.o mkdir-cmd.o > move-cmd.o notify.o prompt.o propdel-cmd.o > propedit-cmd.o propget-cmd.o proplist-cmd.o props.o > propset-cmd.o resolved-cmd.o revert-cmd.o > status-cmd.o status.o switch-cmd.o unlock-cmd.o > update-cmd.o util.o > ../../../subversion/libsvn_client/libsvn_client-1.la > ../../../subversion/libsvn_wc/libsvn_wc-1.la > ../../../subversion/libsvn_ra/libsvn_ra-1.la > ../../../subversion/libsvn_delta/libsvn_delta-1.la > ../../../subversion/libsvn_subr/libsvn_subr-1.la > /usr/local/lib/libaprutil-1.la -ldb-4.2 -lexpat > -liconv /usr/local/lib/libapr-1.la -lcrypt > -lpthread -L/usr/local/lib -rp > ath=/usr > /usr/lib/libroken.so: undefined reference to `_(long > double,...)(short)' > *** Error code 1 > > Stop in > /usr/ports/devel/subversion/work/subversion-1.3.1. > *** Error code 1 > > Stop in /usr/ports/devel/subversion. > > > > >How-To-Repeat: > > > $ cd /ports/devel/subversion > $ sudo make build > > > > > >Fix: Download subversion-1.3.2.tar.gz and build a stable release. Perhaps the port just need to be updated to 1.3.2 ? -- Etienne Robillard JID: incidah AT njs.netlab.cz YMS/MSN: granted14 AT yahoo.com TEL: +1 514.962.7703 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Mon Jun 5 22:43:39 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97BDC16CE9C for ; Mon, 5 Jun 2006 22:13:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from Gate5-sandiego.nmci.navy.mil (gate5-sandiego.nmci.navy.mil [138.163.0.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5320C43D62 for ; Mon, 5 Jun 2006 22:12:47 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from nawesdnims03.nmci.navy.mil by Gate5-sandiego.nmci.navy.mil via smtpd (for mx1.freebsd.org [216.136.204.125]) with ESMTP; Mon, 5 Jun 2006 22:12:47 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: from mail pickup service by nawesdnieb01.nadsuswe.nads.navy.mil with Microsoft SMTPSVC; Mon, 5 Jun 2006 15:11:52 -0700 Received: from nawesdnieg04.nadsuswe.nads.navy.mil ([10.0.10.59]) by nawesdnieb01.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Jun 2006 09:17:33 -0700 Received: from nawesdnifw06.nmci.navy.mil ([10.0.0.38]) by nawesdnieg04.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Jun 2006 09:17:31 -0700 Received: from Nawesdnims02.nmci.navy.mil by nawesdnifw06.nmci.navy.mil via smtpd (for Insidesmtp.navy.mil [10.0.10.59]) with ESMTP; Mon, 5 Jun 2006 16:17:31 +0000 Received: from nawesdnifw02c.nmci.navy.mil (nawesdnifw02c.nmci.navy.mil [10.0.0.162] (may be forged)) by nawesdnims02.nadsuswe.nads.navy.mil (Switch-3.1.8/Switch-3.1.7) with ESMTP id k55FrUN7021925 for ; Mon, 5 Jun 2006 15:54:39 GMT Received: from [138.163.0.138] by nawesdnifw02c.nmci.navy.mil via smtpd (for [10.0.0.166]) with ESMTP; Mon, 5 Jun 2006 16:17:31 +0000 Received: from mx1.spawar.navy.mil (128.49.251.6) by navysdniio02.nmci.navy.mil with ESMTP; 05 Jun 2006 09:06:18 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by mx1.spawar.navy.mil (8.13.1/8.13.1) with ESMTP id k55G2ZHA028997 for ; Mon, 5 Jun 2006 09:02:41 -0700 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 95C9963E9C; Mon, 5 Jun 2006 16:01:44 +0000 (GMT) (envelope-from owner-trustedbsd-audit@FreeBSD.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 8931E16A990; Mon, 5 Jun 2006 16:01:39 +0000 (UTC) (envelope-from owner-trustedbsd-audit@FreeBSD.org) X-Original-To: trustedbsd-audit@freebsd.org Delivered-To: trustedbsd-audit@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 311B016A551; Mon, 5 Jun 2006 16:01:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7BB143D53; Mon, 5 Jun 2006 16:01:04 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id D1C8646C4D; Mon, 5 Jun 2006 12:01:03 -0400 (EDT) Date: Mon, 5 Jun 2006 17:01:04 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20060605165946.L61202@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: trustedbsd-audit@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-trustedbsd-audit@FreeBSD.org Errors-To: owner-trustedbsd-audit@FreeBSD.org X-SPAWAR-MailScanner: Found to be clean X-SPAWAR-MailScanner-SpamCheck: not spam, SpamAssassin (score=0, required 3.5, autolearn=disabled) X-SPAWAR-MailScanner-From: owner-trustedbsd-audit@freebsd.org X-Spam-Status: No X-OriginalArrivalTime: 05 Jun 2006 16:17:32.0102 (UTC) FILETIME=[8C510660:01C688BB] Cc: trustedbsd-audit@TrustedBSD.org Subject: Heads up: OpenBSM 1.0a6, per-auditpipe preselection imported to CVS X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 22:43:40 -0000 This is a heads up to current@ users regarding two moderate sized sets of changes that entered FreeBSD CVS today: (1) I imported OpenBSM 1.0 alpha 6. (2) I imported support for per-auditpipe preselection. Detailed commit messages are below. Robert N M Watson ---------- Forwarded message ---------- Date: Mon, 5 Jun 2006 10:52:14 +0000 (UTC) From: Robert Watson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/contrib/openbsm - Imported sources rwatson 2006-06-05 10:52:14 UTC FreeBSD src repository src/contrib/openbsm - Imported sources Update of /home/ncvs/src/contrib/openbsm In directory repoman.freebsd.org:/tmp/cvs-serv59860 Log Message: Vendor branch import of TrustedBSD OpenBSM 1.0 alpha 6: - Use AU_TO_WRITE and AU_NO_TO_WRITE for the 'keep' argument to au_close(); previously we used hard-coded 0 and 1 values. - Add man page for au_open(), au_write(), au_close(), and au_close_buffer(). - Support a more complete range of data types for the arbitrary data token: add AUR_CHAR (alias to AUR_BYTE), remove AUR_LONG, add AUR_INT32 (alias to AUR_INT), add AUR_INT64. - Add au_close_token(), which allows writing a single token_t to a memory buffer. Not likely to be used much by applications, but useful for writing test tools. - Modify au_to_file() so that it accepts a timeval in user space, not just kernel -- this is not a Solaris BSM API so can be modified without causing compatibility issues. - Define a new API, au_to_header32_tm(), which adds a struct timeval argument to the ordinary au_to_header32(), which is now implemented by wrapping au_to_header32_tm() and calling gettimeofday(). #ifndef KERNEL the APIs that invoke gettimeofday(), rather than having a variable definition. Don't try to retrieve time zone information using gettimeofday(), as it's not needed, and introduces possible failure modes. - Don't perform byte order transformations on the addr/machine fields of the terminal ID that appears in the process32/subject32 tokens. These are assumed to be IP addresses, and as such, to be in network byte order. - Universally, APIs now assume that IP addresses and ports are provided in network byte order. APIs now generally provide these types in network byte order when decoding. - Beginnings of an OpenBSM test framework can now be found in openbsm/test. This code is not built or installed by default. - auditd now assigns more appropriate syslog levels to its debugging and error information. - Support for audit filters introduced: audit filters are dynamically loaded shared objects that run in the context of a new daemon, auditfilterd. The daemon reads from an audit pipe and feeds both BSM and parsed versions of records to shared objects using a module API. This will provide a framework for the writing of intrusion detection services. - New utility API, audit_submit(), added to capture common elements of audit record submission for many applications. Obtained from: TrustedBSD Project Status: Vendor Tag: TrustedBSD Release Tags: OPENBSM_1_0_ALPHA_6 U src/contrib/openbsm/HISTORY U src/contrib/openbsm/LICENSE U src/contrib/openbsm/Makefile.am U src/contrib/openbsm/Makefile.in U src/contrib/openbsm/README U src/contrib/openbsm/TODO U src/contrib/openbsm/VERSION U src/contrib/openbsm/aclocal.m4 U src/contrib/openbsm/autogen.sh U src/contrib/openbsm/configure U src/contrib/openbsm/configure.ac U src/contrib/openbsm/bin/Makefile.am U src/contrib/openbsm/bin/Makefile.in U src/contrib/openbsm/bin/audit/Makefile.am U src/contrib/openbsm/bin/audit/Makefile.in U src/contrib/openbsm/bin/audit/audit.8 U src/contrib/openbsm/bin/audit/audit.c U src/contrib/openbsm/bin/auditd/Makefile.am U src/contrib/openbsm/bin/auditd/Makefile.in U src/contrib/openbsm/bin/auditd/audit_warn.c U src/contrib/openbsm/bin/auditd/auditd.8 U src/contrib/openbsm/bin/auditd/auditd.c U src/contrib/openbsm/bin/auditd/auditd.h N src/contrib/openbsm/bin/auditfilterd/Makefile.am N src/contrib/openbsm/bin/auditfilterd/Makefile.in N src/contrib/openbsm/bin/auditfilterd/auditfilterd.8 N src/contrib/openbsm/bin/auditfilterd/auditfilterd.c N src/contrib/openbsm/bin/auditfilterd/auditfilterd.h N src/contrib/openbsm/bin/auditfilterd/auditfilterd_conf.c U src/contrib/openbsm/bin/auditreduce/Makefile.am U src/contrib/openbsm/bin/auditreduce/Makefile.in U src/contrib/openbsm/bin/auditreduce/auditreduce.1 U src/contrib/openbsm/bin/auditreduce/auditreduce.c U src/contrib/openbsm/bin/auditreduce/auditreduce.h U src/contrib/openbsm/bin/praudit/Makefile.am U src/contrib/openbsm/bin/praudit/Makefile.in U src/contrib/openbsm/bin/praudit/praudit.1 U src/contrib/openbsm/bin/praudit/praudit.c U src/contrib/openbsm/bsm/Makefile.am U src/contrib/openbsm/bsm/Makefile.in U src/contrib/openbsm/bsm/audit.h N src/contrib/openbsm/bsm/audit_filter.h U src/contrib/openbsm/bsm/audit_internal.h U src/contrib/openbsm/bsm/audit_kevents.h U src/contrib/openbsm/bsm/audit_record.h U src/contrib/openbsm/bsm/audit_uevents.h U src/contrib/openbsm/bsm/libbsm.h U src/contrib/openbsm/compat/endian.h U src/contrib/openbsm/compat/queue.h U src/contrib/openbsm/config/config.guess U src/contrib/openbsm/config/config.h.in U src/contrib/openbsm/config/config.sub U src/contrib/openbsm/config/depcomp U src/contrib/openbsm/config/install-sh U src/contrib/openbsm/config/ltmain.sh U src/contrib/openbsm/config/missing U src/contrib/openbsm/etc/audit_class U src/contrib/openbsm/etc/audit_control U src/contrib/openbsm/etc/audit_event N src/contrib/openbsm/etc/audit_filter U src/contrib/openbsm/etc/audit_user U src/contrib/openbsm/etc/audit_warn U src/contrib/openbsm/libbsm/Makefile.am U src/contrib/openbsm/libbsm/Makefile.in U src/contrib/openbsm/libbsm/au_class.3 U src/contrib/openbsm/libbsm/au_control.3 U src/contrib/openbsm/libbsm/au_event.3 U src/contrib/openbsm/libbsm/au_free_token.3 U src/contrib/openbsm/libbsm/au_io.3 U src/contrib/openbsm/libbsm/au_mask.3 N src/contrib/openbsm/libbsm/au_open.3 U src/contrib/openbsm/libbsm/au_token.3 U src/contrib/openbsm/libbsm/au_user.3 N src/contrib/openbsm/libbsm/audit_submit.3 U src/contrib/openbsm/libbsm/bsm_audit.c U src/contrib/openbsm/libbsm/bsm_class.c U src/contrib/openbsm/libbsm/bsm_control.c U src/contrib/openbsm/libbsm/bsm_event.c U src/contrib/openbsm/libbsm/bsm_flags.c U src/contrib/openbsm/libbsm/bsm_io.c U src/contrib/openbsm/libbsm/bsm_mask.c U src/contrib/openbsm/libbsm/bsm_notify.c U src/contrib/openbsm/libbsm/bsm_token.c U src/contrib/openbsm/libbsm/bsm_user.c U src/contrib/openbsm/libbsm/libbsm.3 U src/contrib/openbsm/libbsm/bsm_wrappers.c U src/contrib/openbsm/man/Makefile.am U src/contrib/openbsm/man/Makefile.in U src/contrib/openbsm/man/audit.2 U src/contrib/openbsm/man/audit.log.5 U src/contrib/openbsm/man/audit_class.5 U src/contrib/openbsm/man/audit_control.5 U src/contrib/openbsm/man/audit_event.5 U src/contrib/openbsm/man/audit_user.5 U src/contrib/openbsm/man/audit_warn.5 U src/contrib/openbsm/man/auditctl.2 U src/contrib/openbsm/man/auditon.2 U src/contrib/openbsm/man/getaudit.2 U src/contrib/openbsm/man/getauid.2 U src/contrib/openbsm/man/setaudit.2 U src/contrib/openbsm/man/setauid.2 N src/contrib/openbsm/modules/Makefile.am N src/contrib/openbsm/modules/Makefile.in N src/contrib/openbsm/modules/auditfilter_noop/Makefile.am N src/contrib/openbsm/modules/auditfilter_noop/Makefile.in N src/contrib/openbsm/modules/auditfilter_noop/auditfilter_noop.c N src/contrib/openbsm/test/Makefile.am N src/contrib/openbsm/test/Makefile.in N src/contrib/openbsm/test/bsm/Makefile.am N src/contrib/openbsm/test/bsm/Makefile.in N src/contrib/openbsm/test/bsm/generate.c U src/contrib/openbsm/tools/Makefile.am U src/contrib/openbsm/tools/Makefile.in U src/contrib/openbsm/tools/audump.c No conflicts created by this import ---------- Forwarded message ---------- Date: Mon, 5 Jun 2006 14:48:17 +0000 (UTC) From: Robert Watson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/security/audit audit.c audit_bsm_klib.c audit_ioctl.h audit_pipe.c audit_private.h audit_worker.c rwatson 2006-06-05 14:48:17 UTC FreeBSD src repository Modified files: sys/security/audit audit.c audit_bsm_klib.c audit_ioctl.h audit_pipe.c audit_private.h audit_worker.c Log: Introduce support for per-audit pipe preselection independent from the global audit trail configuration. This allows applications consuming audit trails to specify parameters for which audit records are of interest, including selecting records not required by the global trail. Allowing application interest specification without changing the global configuration allows intrusion detection systems to run without interfering with global auditing or each other (if multiple are present). To implement this: - Kernel audit records now carry a flag to indicate whether they have been selected by the global trail or by the audit pipe subsystem, set during record commit, so that this information is available after BSM conversion when delivering the BSM to the trail and audit pipes in the audit worker thread asynchronously. Preselection by either record target will cause the record to be kept. - Similar changes to preselection when the audit record is created when the system call is entering: consult both the global trail and pipes. - au_preselect() now accepts the class in order to avoid repeatedly looking up the mask for each preselection test. - Define a series of ioctls that allow applications to specify whether they want to track the global trail, or program their own preselection parameters: they may specify their own flags and naflags masks, similar to the global masks of the same name, as well as a set of per-auid masks. They also set a per-pipe mode specifying whether they track the global trail, or user their own -- the door is left open for future additional modes. A new ioctl is defined to allow a user process to flush the current audit pipe queue, which can be used after reprogramming pre-selection to make sure that only records of interest are received in future reads. - Audit pipe data structures are extended to hold the additional fields necessary to support preselection. By default, audit pipes track the global trail, so "praudit /dev/auditpipe" will track the global audit trail even though praudit doesn't program the audit pipe selection model. - Comment about the complexities of potentially adding partial read support to audit pipes. By using a set of ioctls, applications can select which records are of interest, and toggle the preselection mode. Obtained from: TrustedBSD Project Revision Changes Path 1.15 +28 -16 src/sys/security/audit/audit.c 1.4 +3 -6 src/sys/security/audit/audit_bsm_klib.c 1.3 +32 -0 src/sys/security/audit/audit_ioctl.h 1.7 +393 -13 src/sys/security/audit/audit_pipe.c 1.9 +13 -3 src/sys/security/audit/audit_private.h 1.8 +49 -27 src/sys/security/audit/audit_worker.c _______________________________________________ trustedbsd-audit@FreeBSD.org mailing list http://lists.freebsd.org/mailman/listinfo/trustedbsd-audit To unsubscribe, send any mail to "trustedbsd-audit-unsubscribe@FreeBSD.org" From owner-freebsd-current@FreeBSD.ORG Tue Jun 6 00:54:33 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 937DD16D598; Mon, 5 Jun 2006 23:54:35 +0000 (UTC) (envelope-from davidn@datalinktech.com.au) Received: from customer-domains.icp-qv1-irony8.iinet.net.au (customer-domains.icp-qv1-irony8.iinet.net.au [203.59.1.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EE5243D46; Mon, 5 Jun 2006 23:54:33 +0000 (GMT) (envelope-from davidn@datalinktech.com.au) Received: from 203-206-162-119.perm.iinet.net.au (HELO mail.datalinktech.com.au) ([203.206.162.119]) by customer-domains.icp-qv1-irony8.iinet.net.au with ESMTP; 06 Jun 2006 07:54:33 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,212,1146412800"; d="scan'208"; a="335606921:sNHT12760380" Received: from [192.168.4.232] ([192.168.4.232]) by mail.datalinktech.com.au with esmtp; Tue, 06 Jun 2006 09:54:31 +1000 id 0018D962.4484C437.00016BB8 Message-ID: <4484C42C.90107@datalinktech.com.au> Date: Tue, 06 Jun 2006 09:54:20 +1000 From: David Nugent User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: John Hay References: <20060604174315.GA64158@zibbi.meraka.csir.co.za> <20060604191000.GA67836@zibbi.meraka.csir.co.za> <20060605164711.GA8065@zibbi.meraka.csir.co.za> <20060605171414.GA9032@zibbi.meraka.csir.co.za> <20060605180445.GA10089@zibbi.meraka.csir.co.za> In-Reply-To: <20060605180445.GA10089@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , current@freebsd.org Subject: Re: libpthread.so.2 compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 00:54:41 -0000 John Hay wrote: >> Both libpthread.so.2 and libc.so.6 (and .so.7) have to be >> in sync (built from same-dated sources). >> > > Ok, hopefully this is just a temporary thing until somebody can work > up the courage to bump libpthread.so.2. It is pretty silly to have > two files with the same name but different contents. Even the > compat libs cannot help with that. > It would therefore make a lot of sense to simultaneously bump libraries with ABI dependancies, until this becomes a non-issue. From owner-freebsd-current@FreeBSD.ORG Tue Jun 6 01:14:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2408516CF2F for ; Tue, 6 Jun 2006 00:33:13 +0000 (UTC) (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 C29E043D46 for ; Tue, 6 Jun 2006 00:33:12 +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.62 (FreeBSD)) (envelope-from ) id 1FnPVQ-000FT9-8N for freebsd-current@freebsd.org; Tue, 06 Jun 2006 00:33:12 +0000 Received: from localhost.nanog.merit.net ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1FnPVP-000GnR-Uw for freebsd-current@freebsd.org; Mon, 05 Jun 2006 17:33:12 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17540.52551.487480.920472@roam.psg.com> Date: Mon, 5 Jun 2006 17:33:11 -0700 To: FreeBSD Current Subject: kernel build failure - don't know how to make bsd.README X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 01:14:23 -0000 very very -current i386 been going on for days kernel conf below --- ld -d -warn-common -r -d -o geom_md.kld md.o touch export_syms awk -f /usr/src/sys/modules/md/../../conf/kmod_syms.awk geom_md.kld export_syms | xargs -J% objcopy % geom_md.kld ld -Bshareable -d -warn-common -o geom_md.ko.debug geom_md.kld objcopy --only-keep-debug geom_md.ko.debug geom_md.ko.symbols objcopy --strip-debug --add-gnu-debuglink=geom_md.ko.symbols geom_md.ko.debug geom_md.ko ===> mem (all) cc -O2 -fno-strict-aliasing -pipe -march=pentiumpro -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/ROAM/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/ROAM -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -std=c99 -c /usr/src/sys/modules/mem/../../dev/mem/memdev.c cc -O2 -fno-strict-aliasing -pipe -march=pentiumpro -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/ROAM/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/ROAM -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -std=c99 -c /usr/src/sys/modules/mem/../../i386/i386/mem.c cc -O2 -fno-strict-aliasing -pipe -march=pentiumpro -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/ROAM/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/ROAM -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -std=c99 -c /usr/src/sys/modules/mem/../../dev/mem/memutil.c cc -O2 -fno-strict-aliasing -pipe -march=pentiumpro -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/ROAM/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/ROAM -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -std=c99 -c /usr/src/sys/modules/mem/../../i386/i386/i686_mem.c cc -O2 -fno-strict-aliasing -pipe -march=pentiumpro -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/ROAM/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/ROAM -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -std=c99 -c /usr/src/sys/modules/mem/../../i386/i386/k6_mem.c ld -d -warn-common -r -d -o mem.kld memdev.o mem.o memutil.o i686_mem.o k6_mem.o touch export_syms awk -f /usr/src/sys/modules/mem/../../conf/kmod_syms.awk mem.kld export_syms | xargs -J% objcopy % mem.kld ld -Bshareable -d -warn-common -o mem.ko.debug mem.kld objcopy --only-keep-debug mem.ko.debug mem.ko.symbols objcopy --strip-debug --add-gnu-debuglink=mem.ko.symbols mem.ko.debug mem.ko ===> mfi (all) make: don't know how to make bsd.README. Stop *** Error code 2 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/ROAM. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. --- cpu I686_CPU ident ROAM makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options INCLUDE_CONFIG_FILE # Include this file in kernel options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big directories 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_43TTY # BSD 4.3 TTY compat [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 ADAPTIVE_GIANT # Giant mutex is adaptive. options IPDIVERT # divert sockets options IPFIREWALL # firewall options IPFIREWALL_VERBOSE # enable logging to syslogd(8) options GEOM_LABEL # Providers labelization. options GEOM_MBR # DOS/MBR partitioning options KDB # Enable kernel debugger support. options DDB # Support DDB. device pci device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support device sc device agp # support several AGP chipsets device pmtimer device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus device ppc device ppbus # Parallel port bus (required) device lpt # Printer device em # Intel PRO/1000 adapter Gigabit Ethernet Card device wlan # 802.11 support device wlan_wep # 802.11 WEP support device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device bpf # Berkeley packet filter device uhci # UHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device uscanner # Scanners -30- From owner-freebsd-current@FreeBSD.ORG Tue Jun 6 03:39:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5405F16AD9D for ; Tue, 6 Jun 2006 02:57:06 +0000 (UTC) (envelope-from netsick@iinet.net.au) Received: from customer-domains.icp-qv1-irony1.iinet.net.au (customer-domains.icp-qv1-irony1.iinet.net.au [203.59.1.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 197C543D46 for ; Tue, 6 Jun 2006 02:57:04 +0000 (GMT) (envelope-from netsick@iinet.net.au) Received: from per-qv1-webmail-01.iinet.net.au (HELO mail.iinet.net.au) ([203.59.3.55]) by customer-domains.icp-qv1-irony1.iinet.net.au with SMTP; 06 Jun 2006 10:57:01 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,213,1146412800"; d="scan'208"; a="513309688:sNHT29228488" Received: (qmail 20105 invoked by uid 33); 6 Jun 2006 02:57:01 -0000 Received: from mail-placeholder.iinet.net.au (mail-placeholder.iinet.net.au [203.59.1.180]) by mail.iinet.net.au (IMP) with HTTP for ; Tue, 6 Jun 2006 10:57:01 +0800 Message-ID: <1149562621.4484eefd725ff@mail.iinet.net.au> Date: Tue, 6 Jun 2006 10:57:01 +0800 From: netsick@iinet.net.au To: Craig Rodrigues References: <1149476679.44839f4740950@mail.iinet.net.au> <20060605060436.GA31638@crodrigues.org> In-Reply-To: <20060605060436.GA31638@crodrigues.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 203.59.1.180 Cc: freebsd-current@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: NO AGPGART - i945 ICH7 - 7.0 Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 03:40:03 -0000 Hi Craig, Patched pci_cfgreg.c as supplied. Rebuilt kernel. Rebooted. The patch broke the boot up sequence. I ended up at a mountroot> prompt due to no SATA support. (worked previously) atapci0: port 0x1f0-0x1f7,0x3f6,0x170- 0x177,0x376,0xffa0-0xffaf irq 16 at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0xfe00-0xfe07,0xfe10- 0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfea0-0xfeaf irq 20 at device 31.2 on pci0 atapci1: failed to enable memory mapping! ata2: on atapci1 ata3: on atapci1 Making things difficult to get a log of the boot process as the HDD will not mount. Taking a look at the changes in the patch you have a "did" of 0x2700 for 945 support. Should this be looking for the Memory controller or the PCI-E controller? 0x2700 is the Memory Controller and 0x2701 is the PCI-e. Will try to get a better log, any suggestions considering the HDD will not mount? I can still see fd0. Thanks for you help. Kris hostb0@pci0:0:0: class=0x060000 card=0x01ad1028 chip=0x27708086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82945 Series Memory Controller Hub (MCH)' class = bridge subclass = HOST-PCI pcib1@pci0:1:0: class=0x060400 card=0x00000088 chip=0x27718086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = 'PCI Express Graphics Port' class = bridge subclass = PCI-PCI vgapci0@pci0:2:0: class=0x030000 card=0x01ad1028 chip=0x27728086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Integrated Graphics Controller' class = display subclass = VGA vgapci1@pci0:2:1: class=0x038000 card=0x01ad1028 chip=0x27768086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Integrated Graphics Controller' class = display pcib2@pci0:28:0: class=0x060400 card=0x00000040 chip=0x27d08086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCI Express Root Port' class = bridge subclass = PCI-PCI pcib3@pci0:28:1: class=0x060400 card=0x00000040 chip=0x27d28086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCI Express Root Port' class = bridge subclass = PCI-PCI uhci0@pci0:29:0: class=0x0c0300 card=0x01ad1028 chip=0x27c88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci1@pci0:29:1: class=0x0c0300 card=0x01ad1028 chip=0x27c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci2@pci0:29:2: class=0x0c0300 card=0x01ad1028 chip=0x27ca8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci3@pci0:29:3: class=0x0c0300 card=0x01ad1028 chip=0x27cb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB ehci0@pci0:29:7: class=0x0c0320 card=0x01ad1028 chip=0x27cc8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB pcib4@pci0:30:0: class=0x060401 card=0x00000050 chip=0x244e8086 rev=0xe1 hdr=0x01 vendor = 'Intel Corporation' device = '82801BA/CA/DB/DBL/EB/ER/FB (ICH2/3/4/4/5/5/6), 6300ESB Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI pcm0@pci0:30:2: class=0x040100 card=0x01ad1028 chip=0x27de8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB I/O Controller Hub AC'97 Audio' class = multimedia subclass = audio isab0@pci0:31:0: class=0x060100 card=0x00000000 chip=0x27b88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB/GR (ICH7 Family) LPC Interface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:31:1: class=0x01018a card=0x01ad1028 chip=0x27df8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) Ultra ATA Storage Controller' class = mass storage subclass = ATA atapci1@pci0:31:2: class=0x01018f card=0x01ad1028 chip=0x27c08086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller' class = mass storage subclass = ATA none0@pci0:31:3: class=0x0c0500 card=0x01ad1028 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus bge0@pci2:0:0: class=0x020000 card=0x01ad1028 chip=0x167714e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express' class = network subclass = ethernet Quoting Craig Rodrigues : > On Mon, Jun 05, 2006 at 11:04:39AM +0800, netsick@iinet.net.au wrote: > > > > device agp in my kernel > > > > no /dev/agpgart > > > > Can we get this supported please ? > > Can you try this patch? > > > Index: pci_cfgreg.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/pci/pci_cfgreg.c,v > retrieving revision 1.123 > diff -u -u -r1.123 pci_cfgreg.c > --- pci_cfgreg.c 8 Dec 2005 18:55:15 -0000 1.123 > +++ pci_cfgreg.c 5 Jun 2006 06:02:33 -0000 > @@ -167,8 +167,8 @@ > /* Intel 7520 or 7320 */ > pciebar = pci_cfgregread(0, 0, 0, 0xce, 2) << 16; > pciereg_cfgopen(); > - } else if (did == 0x2580 || did == 0x2584) { > - /* Intel 915 or 925 */ > + } else if (did == 0x2580 || did == 0x2584 || did == 0x2770) { > + /* Intel 915, 925, or 945 */ > pciebar = pci_cfgregread(0, 0, 0, 0x48, 4); > pciereg_cfgopen(); > } > > > -- > Craig Rodrigues > rodrigc@crodrigues.org > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Jun 6 04:02:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7CEC16AEF4 for ; Tue, 6 Jun 2006 03:23:42 +0000 (UTC) (envelope-from bhuvan.kumarmital@wipro.com) Received: from wip-cdctls-mx1.wipro.com (wip-cdctls-mx1.wipro.com [203.91.201.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AAFC43D4C for ; Tue, 6 Jun 2006 03:23:40 +0000 (GMT) (envelope-from bhuvan.kumarmital@wipro.com) Received: from wip-cdctls-mx1.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 611713C40B2 for ; Tue, 6 Jun 2006 08:44:44 +0530 (IST) Received: from chn-snr-bh1.wipro.com (chn-snr-bh1.wipro.com [10.145.50.91]) by wip-cdctls-mx1.wipro.com (Postfix) with ESMTP id 554E03C40A6 for ; Tue, 6 Jun 2006 08:44:44 +0530 (IST) Received: from PNE-HJN-MBX01.wipro.com ([10.111.50.182]) by chn-snr-bh1.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 08:53:38 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 08:53:01 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: libmemstat(3) - Library for monitoring kernel memory use Thread-Index: AcaJGIPySHC+pbMRSCO5emq8cHXafA== From: To: X-OriginalArrivalTime: 06 Jun 2006 03:23:38.0060 (UTC) FILETIME=[99E240C0:01C68918] X-Mailman-Approved-At: Tue, 06 Jun 2006 04:44:16 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: libmemstat(3) - Library for monitoring kernel memory use X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 04:02:25 -0000 Hi Robert Watson, Saw your tool (memtop) for monitoring kernel memory. I'd like to use a similar tool for linux, i believe your tool is bsd based. Could you tell me a similar tool, or perhaps another version of memtop built for linux.=0D I'd really appreciate you help. Please reply on my email address. =0D Regards =0D Bhuvan Mital Project Engineer,=0D Wipro Technologies Pune +91-20-39101609 +91-9890360586 =0D The information contained in this electronic message and any attachments to= this message are intended for the exclusive use of the addressee(s) and= may contain proprietary, confidential or privileged information. If you= are not the intended recipient, you should not disseminate, distribute or= copy this e-mail. Please notify the sender immediately and destroy all= copies of this message and any attachments.=0D WARNING: Computer viruses can be transmitted via email. The recipient= should check this email and any attachments for the presence of viruses.= The company accepts no liability for any damage caused by any virus= transmitted by this email. =0D www.wipro.com From owner-freebsd-current@FreeBSD.ORG Tue Jun 6 06:28:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9BDA16AC9F for ; Tue, 6 Jun 2006 06:20:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8327E43D48 for ; Tue, 6 Jun 2006 06:20:39 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1F27E46BAF; Tue, 6 Jun 2006 02:20:39 -0400 (EDT) Date: Tue, 6 Jun 2006 07:20:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: bhuvan.kumarmital@wipro.com In-Reply-To: Message-ID: <20060606071736.J68996@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: libmemstat(3) - Library for monitoring kernel memory use X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 06:28:02 -0000 On Tue, 6 Jun 2006 bhuvan.kumarmital@wipro.com wrote: > Saw your tool (memtop) for monitoring kernel memory. I'd like to use a > similar tool for linux, i believe your tool is bsd based. Could you tell me > a similar tool, or perhaps another version of memtop built for linux. I'd > really appreciate you help. Please reply on my email address. Bhuvan, You are correct that libmemstat and derived tools currently rely on features present in the FreeBSD kernel. The library provides a general monitoring abstraction over a set of specific kernel memory allocators -- specifically, the FreeBSD malloc(9) and uma(9) allocators. It is relatively straight forward to implement that abstraction for other memory allocators, such as user space allocators or kernel allocators from other platforms, but that work has not been done (as far as I know). I'm not aware of specific monitoring tools for the Linux operating system that are able to perform this type of profiling/monitoring, although I presume some sort of kernel memory profiling tool does exist. Thanks, Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Tue Jun 6 07:21:06 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E243D16BFA6 for ; Tue, 6 Jun 2006 07:11:02 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B70DF43D6D for ; Tue, 6 Jun 2006 07:11:01 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 87D2846C01; Tue, 6 Jun 2006 03:11:00 -0400 (EDT) Date: Tue, 6 Jun 2006 08:11:00 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Derek Tattersall In-Reply-To: <200605311911.k4VJBdr0080562@sukey.arm.org> Message-ID: <20060606080615.G66414@fledge.watson.org> References: <200605311911.k4VJBdr0080562@sukey.arm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: Use of the audit subsystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 07:21:08 -0000 On Wed, 31 May 2006, Derek Tattersall wrote: > I recently installed the audit code on my current system. It comes up and > works fine, the logs rotate properly and all is copacetic. Now I would like > to develop audit policies for a few typical installations. > > 1) Departmental server. Serves files, mail, web proxies and > application proxies. What are the appropriate events to audit to > enhance the IT security in an environment that probably doesn't > have an IT staff. > 2) Workstation. Used as an application client, with e-mail, web and > network services. Probably has access to printers and file > servers. Is potentially exposed to spam and malware. > 3) Routers and infrastructure servers. Provide network services, > DHCP, network address translation, routing, PXE, proxies etc. > How best to audit this box. > > For each of these types of IT provider, we need to monitor activity for > security purposes first, and perhaps also for cost accounting. The audit > daemon provides records with varying degrees of importance. How should we > separate and report so as to achieve the timeliness that we need. > > I'm trying to put together a white paper on the use of auditing to > complement the excellent installation and operation information in the > Handbook. All suggestions are welcome. Hmm. I enthusiastically support the above activities, but unfortunately don't have a lot of information likely to be appropriate to the above environments. For workstations and servers, the general starting point will be the logging of authentication events and exec events, since those provide moderate insight into the security context. Right now, only a limited number of user applications generate application-layer audit records -- most records are generated by the kernel, and offer accurate but very fine-grained views onto the behavior of the application, which can make it hard to see the big picture. For example, the kernel can audit the system calls performed by the login command, but what you really want is for login to tell you who logged in. We've modified login and a number of critical system management tools to do this, but you may find that other tools, such as Samba, require similar modifications. In many cases, Sun, Apple, or other organizations have already added BSM support to applications -- our support in SSH is, in fact, the Sun support, which we just turned on, so it may be a question of starting to compile ports or packages with audit support that already exists. An important part of your best practices documentation may be audit reduction -- you may find that for a week, you want to keep all file accesses, but after one week, you want only to keep login information. This can be done using the auditreduce command line tool, and right now there's not really any practice documentation on using it effectively. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Tue Jun 6 07:53:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12D1416B24A for ; Tue, 6 Jun 2006 07:43:11 +0000 (UTC) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89E6D43D46 for ; Tue, 6 Jun 2006 07:43:08 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw501.dsto.defence.gov.au (ednmsw501.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id k567fBGN028033 for ; Tue, 6 Jun 2006 17:11:11 +0930 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw501.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Tue, 6 Jun 2006 17:13:02 +0930 Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au [131.185.2.170]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id k567Za721386 for ; Tue, 6 Jun 2006 17:05:36 +0930 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC (6.0.3790.1830); Tue, 6 Jun 2006 17:05:36 +0930 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.13.3/8.13.3) with ESMTP id k567YbFu029780 for ; Tue, 6 Jun 2006 17:04:37 +0930 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.13.3/8.13.3/Submit) id k567Yb9x029779 for freebsd-current@freebsd.org; Tue, 6 Jun 2006 17:04:37 +0930 (CST) (envelope-from wilkinsa) Date: Tue, 6 Jun 2006 17:04:37 +0930 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20060606073436.GK27880@squash.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20060606071736.J68996@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20060606071736.J68996@fledge.watson.org> User-Agent: Mutt/1.5.11 X-OriginalArrivalTime: 06 Jun 2006 07:35:36.0144 (UTC) FILETIME=[CCF6CD00:01C6893B] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-3.52.1006-14488.003 X-TM-AS-Result: No--2.990000-0.000000-31 Subject: Re: libmemstat(3) - Library for monitoring kernel memory use X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 07:54:02 -0000 0n Tue, Jun 06, 2006 at 07:20:39AM +0100, Robert Watson wrote: > >On Tue, 6 Jun 2006 bhuvan.kumarmital@wipro.com wrote: > >> Saw your tool (memtop) for monitoring kernel memory. I'd like to use a >>similar tool for linux, i believe your tool is bsd based. Could you tell >>me a similar tool, or perhaps another version of memtop built for linux. >>I'd really appreciate you help. Please reply on my email address. > >Bhuvan, > >You are correct that libmemstat and derived tools currently rely on >features present in the FreeBSD kernel. The library provides a general >monitoring abstraction over a set of specific kernel memory allocators -- >specifically, the FreeBSD malloc(9) and uma(9) allocators. It is >relatively straight forward to implement that abstraction for other memory >allocators, such as user space allocators or kernel allocators from other >platforms, but that work has not been done (as far as I know). I'm not >aware of specific monitoring tools for the Linux operating system that are >able to perform this type of profiling/monitoring, although I presume some >sort of kernel memory profiling tool does exist. Erm, Robert, where does memtop live ? I can find it in ports nor base system. -aW From owner-freebsd-current@FreeBSD.ORG Tue Jun 6 08:18:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5D6316AC24 for ; Tue, 6 Jun 2006 08:11:11 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E65D43D46 for ; Tue, 6 Jun 2006 08:11:11 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 993CF46C1D; Tue, 6 Jun 2006 04:11:10 -0400 (EDT) Date: Tue, 6 Jun 2006 09:11:10 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Wilkinson, Alex" In-Reply-To: <20060606073436.GK27880@squash.dsto.defence.gov.au> Message-ID: <20060606090919.U68996@fledge.watson.org> References: <20060606071736.J68996@fledge.watson.org> <20060606073436.GK27880@squash.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: libmemstat(3) - Library for monitoring kernel memory use X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 08:18:37 -0000 On Tue, 6 Jun 2006, Wilkinson, Alex wrote: > 0n Tue, Jun 06, 2006 at 07:20:39AM +0100, Robert Watson wrote: > > > > >On Tue, 6 Jun 2006 bhuvan.kumarmital@wipro.com wrote: > > > >> Saw your tool (memtop) for monitoring kernel memory. I'd like to use a > >>similar tool for linux, i believe your tool is bsd based. Could you tell > >>me a similar tool, or perhaps another version of memtop built for linux. > >>I'd really appreciate you help. Please reply on my email address. > > > >You are correct that libmemstat and derived tools currently rely on > >features present in the FreeBSD kernel. The library provides a general > >monitoring abstraction over a set of specific kernel memory allocators -- > >specifically, the FreeBSD malloc(9) and uma(9) allocators. It is > >relatively straight forward to implement that abstraction for other memory > >allocators, such as user space allocators or kernel allocators from other > >platforms, but that work has not been done (as far as I know). I'm not > >aware of specific monitoring tools for the Linux operating system that are > >able to perform this type of profiling/monitoring, although I presume some > >sort of kernel memory profiling tool does exist. > > Erm, Robert, where does memtop live ? I can find it in ports nor base > system. memtop is an experimental monitoring tool based on libmemstat, you can find the source here: http://www.watson.org/~robert/freebsd/libmemstat/ Possibly something like this could be integrated into systat, but my ncurses knowledge is a bit weak, and I've not had a chance to investigate further. As with vmstat, the interpretation of the output requires a moderate amount of insight into how the kernel works, so I've been a bit reluctant to push it as a debugging tool without some more refinement. I think it would be neat if someone picked it up and did something useful with it, though :-). Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Tue Jun 6 09:24:34 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B2CC16B533 for ; Tue, 6 Jun 2006 09:20:24 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3DAC43D49 for ; Tue, 6 Jun 2006 09:20:23 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1FnXja-0006OZ-4t; Tue, 06 Jun 2006 12:20:22 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Doug White In-reply-to: <20060603175920.G40001@carver.gumbysoft.com> References: <447AB34C.4030509@sippysoft.com> <447B5A43.4000707@samsco.org> <447B69EA.20502@sippysoft.com> <20060603174637.M40001@carver.gumbysoft.com> <44823080.9030709@samsco.org> <20060603175920.G40001@carver.gumbysoft.com> Comments: In-reply-to Doug White message dated "Sat, 03 Jun 2006 18:02:30 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Jun 2006 12:20:22 +0300 From: Danny Braniss Message-ID: Cc: "current@freebsd.org" , Maxim Sobolev Subject: Re: Importing iSCSI target from NetBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 09:24:42 -0000 > On Sat, 3 Jun 2006, Scott Long wrote: > > > Last I knew, this driver was just an initiator. If he's added target > > support, that's great. > > Thats what I get for jumping in a conversation halfway. I didn't notice > this was a *target*-mode driver discussion. Danny's driver is still just > an initiator. Sorry for the noise. > he, "just an initiator", I hope you ment this as an uderstatement :-) > I believe Wasabi is shipping that target driver in some of their > storage-appliance software, so they feel confident about it apparently. are you sure it's the same one? danny From owner-freebsd-current@FreeBSD.ORG Tue Jun 6 17:27:08 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1F9316C4A7 for ; Tue, 6 Jun 2006 17:27:08 +0000 (UTC) (envelope-from schwabe@uni-paderborn.de) Received: from dagobah.rfc1149.org (dagobah.rfc1149.org [217.160.170.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25B8F43D5A for ; Tue, 6 Jun 2006 17:27:06 +0000 (GMT) (envelope-from schwabe@uni-paderborn.de) Received: from dslb-084-061-132-118.pools.arcor-ip.net ([84.61.132.118] helo=[192.168.0.199]) by dagobah.rfc1149.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1FnfKW-000IfS-M4; Tue, 06 Jun 2006 19:27:03 +0200 Message-ID: <4485BAB0.9010806@uni-paderborn.de> Date: Tue, 06 Jun 2006 19:26:08 +0200 From: Arne Schwabe User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Andrew Turner References: <4467E117.8070301@fubar.geek.nz> In-Reply-To: <4467E117.8070301@fubar.geek.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RFC-Spam-Score: -3.8 (---) X-Mailman-Approved-At: Tue, 06 Jun 2006 17:50:08 +0000 Cc: freebsd-current@freebsd.org Subject: Re: BSDInstaller snapshot (test on Tohsiba M400) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 17:27:11 -0000 Andrew Turner schrieb: > I am pleased to announce the third public beta of the BSDInstaller on > FreeBSD. > I thought I would give BSDInstaller ai shot on my shiny new M400 > Major changes in this release are: > > - Lua and required libraries are now installed from packages > - Allow the installation of kernels other than GENERIC > > The ISO image is available from > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/bsdinstaller/7.0-20060512-BSDINSTALLER-i386-disc1.iso > or your local mirror. > Installation works well but I ran in to a few iusses: The parition editor does not accept a parition table that does not end in a cylinder :( It asked whether I would like to shrink or expand the parition where my windows (with ntfs) is installed on. I prefer to leave my windows parition alone. If you have a FreeBSD slice that does not end at a cylinder boundary the label editor won't work correctly if one entry is "*". dhclient did not work: On a console I got: # dhclient em0 chroot exiting. # A strange sidemark: If I am booting from the installer cd em0 is working, If booting from harddisk (even with the installer cd kernel) em0 complains about checksum errors. :/ > As with the previous Beta release there are three virtual consoles > available: > * ttyv0: The front end > * ttyv1: The back end > * ttyv2: A standard login screen to login as root with no password Would be nice to have either more ttys with root shell or "screen" on the cd so I could that for more shells (starting logins on other screens works but is uncomfortable). Arne From owner-freebsd-current@FreeBSD.ORG Tue Jun 6 18:16:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC6F816CC34 for ; Tue, 6 Jun 2006 18:15:31 +0000 (UTC) (envelope-from ggajic@afrodita.rcub.bg.ac.yu) Received: from afrodita.rcub.bg.ac.yu (afrodita.rcub.bg.ac.yu [147.91.1.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6840543D49 for ; Tue, 6 Jun 2006 18:15:29 +0000 (GMT) (envelope-from ggajic@afrodita.rcub.bg.ac.yu) Received: from afrodita.rcub.bg.ac.yu (localhost.localdomain [127.0.0.1]) by afrodita.rcub.bg.ac.yu (8.13.6/8.13.4) with ESMTP id k56IFMZf003593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Jun 2006 20:15:23 +0200 Received: from localhost (ggajic@localhost) by afrodita.rcub.bg.ac.yu (8.13.6/8.13.6/Submit) with ESMTP id k56IFMiI003590 for ; Tue, 6 Jun 2006 20:15:22 +0200 Date: Tue, 6 Jun 2006 20:15:22 +0200 (CEST) From: Goran Gajic To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-RCUB-MailScanner-Information: Please contact the RCUB if you have problem with mail X-RCUB-MailScanner: Found to be clean X-RCUB-MailScanner-From: ggajic@afrodita.rcub.bg.ac.yu X-Mailman-Approved-At: Tue, 06 Jun 2006 18:24:54 +0000 Subject: scroll lock causes panic on latest 7.0 current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 18:16:43 -0000 Hi, I have noticed that if I press scroll lock during boot somwhere after VGA detected and mounting of file systems kernel will panic and drop into debugger. It is strange that keyboard is also locked so I can't type anything. Regards, gg. From owner-freebsd-current@FreeBSD.ORG Tue Jun 6 20:02:23 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5892E16C85E for ; Tue, 6 Jun 2006 20:00:17 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id A340D43D46 for ; Tue, 6 Jun 2006 20:00:16 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 97F70170DE for ; Tue, 6 Jun 2006 20:00:14 +0000 (UTC) To: current@freebsd.org From: Poul-Henning Kamp Date: Tue, 06 Jun 2006 20:00:14 +0000 Message-ID: <1625.1149624014@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: -current/rc.mumble/devfs(8) problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 20:02:30 -0000 Something is wrong in /etc/rc.d land in -current right now, /dev/null gets hidden or whatever during /etc/rc processing and the system is generally hosed by the time it gets to multi-user. In single user everything is fine. Moving /sbin/devfs away results in some whinage during boot, but a usable system. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Jun 6 19:06:39 2006 Return-Path: X-Original-To: freebsd-current@www.freebsd.org Delivered-To: freebsd-current@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9CEB16AA8E for ; Tue, 6 Jun 2006 19:05:00 +0000 (UTC) (envelope-from ggajic@tesla.rcub.bg.ac.yu) Received: from tesla.rcub.bg.ac.yu (tesla.rcub.bg.ac.yu [147.91.1.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DC3E43D49 for ; Tue, 6 Jun 2006 19:05:00 +0000 (GMT) (envelope-from ggajic@tesla.rcub.bg.ac.yu) Received: by tesla.rcub.bg.ac.yu (Postfix, from userid 2055) id 64D0D2403E; Tue, 6 Jun 2006 20:03:09 +0200 (CEST), Found to be clean Received: from localhost (localhost [127.0.0.1]) by tesla.rcub.bg.ac.yu (Postfix) with ESMTP id 61BDA2403B for ; Tue, 6 Jun 2006 20:03:09 +0200 (CEST) Date: Tue, 6 Jun 2006 20:03:09 +0200 (CEST) From: Goran Gajic To: freebsd-current@www.freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 06 Jun 2006 21:12:43 +0000 Cc: Subject: 7.0-CURRENT panics if scroll lock is pressed during boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 19:06:47 -0000 Hi, I have noticed that if I press scroll lock during boot somwhere after VGA detected and mounting of file systems kernel will panic and drop into debugger. It is strange that keyboard is also locked so I can't type anything. Regards, gg. From owner-freebsd-current@FreeBSD.ORG Tue Jun 6 21:30:48 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AFA516CA7F for ; Tue, 6 Jun 2006 21:21:46 +0000 (UTC) (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 18A1043D46 for ; Tue, 6 Jun 2006 21:21:45 +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 218C33E1; Tue, 6 Jun 2006 16:21:45 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 6FB9D61C2B; Tue, 6 Jun 2006 16:21:44 -0500 (CDT) Date: Tue, 6 Jun 2006 16:21:44 -0500 From: "Matthew D. Fuller" To: Poul-Henning Kamp Message-ID: <20060606212144.GM76919@over-yonder.net> References: <1625.1149624014@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1625.1149624014@critter.freebsd.dk> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.3 Cc: current@freebsd.org Subject: Re: -current/rc.mumble/devfs(8) problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 21:30:55 -0000 On Tue, Jun 06, 2006 at 08:00:14PM +0000 I heard the voice of Poul-Henning Kamp, and lo! it spake thus: > > Something is wrong in /etc/rc.d land in -current right now, > /dev/null gets hidden or whatever during /etc/rc processing and the > system is generally hosed by the time it gets to multi-user. I don't see this in FreeBSD 7.0-CURRENT #2: Sat Jun 3 08:19:50 CDT 2006 -- 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-current@FreeBSD.ORG Wed Jun 7 08:32:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68DC716BED6; Wed, 7 Jun 2006 08:20:14 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id B181543D4C; Wed, 7 Jun 2006 08:20:11 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id CED351FF903; Wed, 7 Jun 2006 10:20:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 4A6731FF905; Wed, 7 Jun 2006 10:20:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1DB944448D6; Wed, 7 Jun 2006 08:15:58 +0000 (UTC) Date: Wed, 7 Jun 2006 08:15:57 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Konstantin Belousov In-Reply-To: <20060529082951.GU54541@deviant.kiev.zoral.com.ua> Message-ID: <20060607081522.T79180@maildrop.int.zabbadoz.net> References: <447A1F94.7020809@sh.cvut.cz> <20060529082951.GU54541@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de X-Mailman-Approved-At: Wed, 07 Jun 2006 11:45:07 +0000 Cc: V??clav Haisman , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: LOR in vnode interlock and system map X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 08:32:48 -0000 On Mon, 29 May 2006, Konstantin Belousov wrote: > lock order reversal: > 1st 0xc1a018f0 vnode interlock (vnode interlock) @ /usr/home/kostik/work/b= > sd/sys/kern/vfs_subr.c:2449 > 2nd 0xc0c43144 system map (system map) @ /usr/home/kostik/work/bsd/sys/vm/= > vm_kern.c:295 added with LOR ID 189: http://sources.zabbadoz.net/freebsd/lor.html#189 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Wed Jun 7 20:32:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEA9B16D1B5 for ; Wed, 7 Jun 2006 18:47:58 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 4BB2D43D62 for ; Wed, 7 Jun 2006 18:47:54 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 17834 invoked by uid 399); 7 Jun 2006 18:47:54 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 7 Jun 2006 18:47:54 -0000 Message-ID: <44871F58.4070707@FreeBSD.org> Date: Wed, 07 Jun 2006 11:47:52 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.4 (X11/20060604) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Problem with nvidia drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 20:32:47 -0000 With the latest -current and the nvidia drivers, either xorg or wdm dump core on a semi-regular basis. Is this expected? I've already tried disabling witness and invariants in my kernel config. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Jun 7 22:32:04 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C83916EE12 for ; Wed, 7 Jun 2006 20:09:05 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4DD643D5A for ; Wed, 7 Jun 2006 20:08:52 +0000 (GMT) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id c31so202017nfb for ; Wed, 07 Jun 2006 13:08:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition; b=uK4wVr6z7lEUW5lD3x5wzN6pYnYkxh+eZXif75jNlgeP0uV5Iid3kJz0Q1MsE/NQXH6lna+L9Vpj/8quuEAc8JOAQ3iCrFWdt+aM+tKnRM0BQ2hKH51aOiYsR5PT/LdrDbLqUA7FMLdRnraiyWcDmQvvqJcBZ/c9kNRBkn0KmbM= Received: by 10.49.93.15 with SMTP id v15mr827826nfl; Wed, 07 Jun 2006 13:08:51 -0700 (PDT) Received: from roadrunner.q.local ( [217.185.119.143]) by mx.gmail.com with ESMTP id z73sm1081512nfb.2006.06.07.13.08.38; Wed, 07 Jun 2006 13:08:51 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.6/8.13.6) with ESMTP id k57K8Oxa003678 for ; Wed, 7 Jun 2006 22:08:24 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.6/8.13.6/Submit) id k57Jr4XA003438 for current@freebsd.org; Wed, 7 Jun 2006 21:53:04 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Wed, 7 Jun 2006 21:53:03 +0200 From: Ulrich Spoerlein To: current@freebsd.org Message-ID: <20060607195303.GA3225@roadrunner.q.local> Mail-Followup-To: current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jq0ap7NbKX2Kqbes" Content-Disposition: inline Cc: Subject: [PATCH] Call for bfe(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 22:32:06 -0000 --jq0ap7NbKX2Kqbes Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I investigated a bug/missing feature in the bfe(4) driver, which makes it not see any LINK DOWN events unless you happen to invoke ifconfig. If you are running bfe hardware, *please* test the following (NO PATCHING OR REBOOTING REQUIRED) 1. Plug in ethernet cable 2. Watch dmesg/syslogd for the LINK UP message 3. Remove the cable 4. Do you see a LINK DOWN message? Does it appear after you issue 'ifconfig'? Please run these simple steps and report back to me, if you get the LINK DOWN message or not and which hardware you are running. For reference, mine is a BCM4401, card=3D0x81271028 chip=3D0x440114e4 rev=3D0x01. If you want to give the patch a try, you are of course encouraged to do so. Ulrich Spoerlein --=20 PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Description: if_bfe.c.diff Content-Disposition: attachment; filename="if_bfe.patch3" Content-Transfer-Encoding: quoted-printable --- if_bfe.c.orig Wed Jun 7 21:34:49 2006 +++ if_bfe.c Wed Jun 7 21:37:07 2006 @@ -1552,17 +1552,21 @@ bfe_tick(void *xsc) mii =3D device_get_softc(sc->bfe_miibus); =20 bfe_stats_update(sc); - sc->bfe_stat_ch =3D timeout(bfe_tick, sc, hz); =20 - if(sc->bfe_link) { - BFE_UNLOCK(sc); - return; + if (sc->bfe_miibus !=3D NULL) + mii_tick(mii); + + if (!sc->bfe_link) { + if (mii->mii_media_status & IFM_ACTIVE) + sc->bfe_link++; + } else { + mii_pollstat(mii); + + if (!(mii->mii_media_status & IFM_ACTIVE)) + sc->bfe_link =3D 0; } =20 - mii_tick(mii); - if (!sc->bfe_link && mii->mii_media_status & IFM_ACTIVE && - IFM_SUBTYPE(mii->mii_media_active) !=3D IFM_NONE) - sc->bfe_link++; + sc->bfe_stat_ch =3D timeout(bfe_tick, sc, hz); =20 BFE_UNLOCK(sc); } --tKW2IUtsqtDRztdT-- --jq0ap7NbKX2Kqbes Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEhy6f524iJyD+6d0RAsAZAKCcCQ0wJT+fxNzS9Fzu9mMHa//DQwCfZLaP csgmDqxYyHAta/lRZ1hEzPo= =W3P5 -----END PGP SIGNATURE----- --jq0ap7NbKX2Kqbes-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 7 23:25:54 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29D0C16B765 for ; Wed, 7 Jun 2006 22:27:38 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id A54E743D49 for ; Wed, 7 Jun 2006 22:27:37 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k57MRZZA023502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Jun 2006 18:27:36 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k57MRTwD083268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Jun 2006 18:27:30 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: current@freebsd.org Date: Wed, 7 Jun 2006 18:27:24 -0400 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606071827.24207.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88/1519/Wed Jun 7 15:17:46 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Wed, 07 Jun 2006 23:43:53 +0000 Cc: Subject: getrusage() -- negative ru_maxrss?! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 23:26:01 -0000 Hello! I have a program, which uses getrusage() to report its own performance before exiting. I noticed recently, that the ru_maxrss field is sometimes reported negative -- I don't think, I ever saw this last year, for example... Is the field considered usable and (semi-)accurate, or did FreeBSD abandon it (as Solaris did)? I currently print it as: fprintf(..., "... used %ld Kb ...", ... ru.ru_maxrss*getpagesize()/1024... ); What's the right way to do it? -mi From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 00:30:07 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AA1516E8B2; Wed, 7 Jun 2006 21:57:23 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0BD643D46; Wed, 7 Jun 2006 21:57:21 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.13.4/8.13.3) with ESMTP id k57LvKLR054417; Thu, 8 Jun 2006 01:57:20 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Thu, 8 Jun 2006 01:57:20 +0400 (MSD) From: Maxim Konovalov To: current@freebsd.org Message-ID: <20060608015022.Y52876@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: dougb@freebsd.org Subject: named recursive queries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 00:30:08 -0000 [ Bikeshed zone ] I think we need to stop spread misconfigured named's too. Any objections? Index: named.conf =================================================================== RCS file: /home/ncvs/src/etc/namedb/named.conf,v retrieving revision 1.22 diff -u -p -r1.22 named.conf --- named.conf 5 Sep 2005 13:42:22 -0000 1.22 +++ named.conf 7 Jun 2006 21:56:26 -0000 @@ -30,6 +30,13 @@ options { // // forward only; +// Prevent external networks from using us to query domains we are not +// authoritative for. +// + allow-recursion { + localhost; + }; + // If you've got a DNS server around at your upstream provider, enter // its IP address here, and enable the line below. This will make you // benefit from its cache, thus reduce overall DNS traffic in the Internet. -- Maxim Konovalov ---------- Forwarded message ---------- Date: Wed, 17 May 2006 07:25:47 -0700 (PDT) From: Sascha Wildner To: commits@crater.dragonflybsd.org Subject: cvs commit: src/etc/namedb named.conf swildner 2006/05/17 07:25:47 PDT DragonFly src repository Modified files: etc/namedb named.conf Log: Per default, restrict recursive queries to 127.0.0.1. Submitted-by: Gary OK-by: corecode, joerg Revision Changes Path 1.4 +9 -1 src/etc/namedb/named.conf http://www.dragonflybsd.org/cvsweb/src/etc/namedb/named.conf.diff?r1=1.3&r2=1.4&f=u From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 02:49:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C17A916C6C5 for ; Thu, 8 Jun 2006 00:32:51 +0000 (UTC) (envelope-from fierykylin@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53E5043D45 for ; Thu, 8 Jun 2006 00:32:51 +0000 (GMT) (envelope-from fierykylin@gmail.com) Received: by wx-out-0102.google.com with SMTP id i31so228710wxd for ; Wed, 07 Jun 2006 17:32:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=gdgRsu5fOOnekfwmrQJ+M5hDjxD1Uk5XwFzyd9IpSXgOV0xeA1gzcoWit/svin0eIjHCT6PLyhBJJIv49E+Kn5ELS+/wqCfN78M8KcI9dgO5vLEpTyHOHvBelBBhtHbs5Rql/UZlF+hq8mfvluG0I6Nw9ktcduOp9uTkk58Qu+0= Received: by 10.70.39.19 with SMTP id m19mr1416980wxm; Wed, 07 Jun 2006 17:32:50 -0700 (PDT) Received: by 10.70.17.16 with HTTP; Wed, 7 Jun 2006 17:32:48 -0700 (PDT) Message-ID: <87ab37ab0606071732o72d4145cs821f6305ead626a7@mail.gmail.com> Date: Thu, 8 Jun 2006 08:32:50 +0800 From: "william wallace" Sender: fierykylin@gmail.com To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: c80cf15c0cf46d02 Subject: how to get current from CVS by tortoiseCVS on windows X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 02:49:54 -0000 what module does current in ? i only see the src module .....,help me out ,thank u! -- we who r about to die,salute u! From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 03:04:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D4D516C792; Thu, 8 Jun 2006 01:04:46 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAB5B43D48; Thu, 8 Jun 2006 01:04:45 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.22] (andersonbox2.centtech.com [192.168.42.22]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id k5814iu3055827; Wed, 7 Jun 2006 20:04:44 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <448777B5.8040100@centtech.com> Date: Wed, 07 Jun 2006 20:04:53 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.2 (X11/20060506) MIME-Version: 1.0 To: Doug Barton References: <44871F58.4070707@FreeBSD.org> In-Reply-To: <44871F58.4070707@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1520/Wed Jun 7 16:47:18 2006 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: Problem with nvidia drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 03:04:47 -0000 Doug Barton wrote: > With the latest -current and the nvidia drivers, either xorg or wdm dump > core on a semi-regular basis. Is this expected? I've already tried disabling > witness and invariants in my kernel config. > > Doug > Try the one from their website, not the one in ports. It gave me better stability, but I ended up moving to the nv driver anyhow. You could search the lists for my posts to see the trials and tribulations if you'd like (if you can't find it, let me know). Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 05:06:39 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0382216BABF for ; Thu, 8 Jun 2006 02:28:50 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EE2D43D48 for ; Thu, 8 Jun 2006 02:28:47 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.pc (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.6/8.13.6/Debian-1) with ESMTP id k582Ssm6010929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Jun 2006 05:28:56 +0300 Received: from gothmog.pc (gothmog [127.0.0.1]) by gothmog.pc (8.13.6/8.13.6) with ESMTP id k582UR0C002006; Thu, 8 Jun 2006 05:30:27 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.pc (8.13.6/8.13.6/Submit) id k582URVG002005; Thu, 8 Jun 2006 05:30:27 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Thu, 8 Jun 2006 05:30:27 +0300 From: Giorgos Keramidas To: Mikhail Teterin Message-ID: <20060608023027.GA1891@gothmog.pc> References: <200606071827.24207.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200606071827.24207.mi+mx@aldan.algebra.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-0.876, required 5, autolearn=not spam, ALL_TRUSTED -1.44, AWL 0.24, PLING_QUERY 0.33) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: current@freebsd.org Subject: Re: getrusage() -- negative ru_maxrss?! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 05:06:40 -0000 On 2006-06-07 18:27, Mikhail Teterin wrote: > Hello! > I have a program, which uses getrusage() to report its own > performance before exiting. > > I noticed recently, that the ru_maxrss field is sometimes > reported negative -- I don't think, I ever saw this last year, > for example... Is the field considered usable and > (semi-)accurate, or did FreeBSD abandon it (as Solaris did)? ru_maxrss _is_ updated by the kernel, AFAICT. What you see is probably an overflow because of a large size and the multiplication below. > I currently print it as: > > fprintf(..., "... used %ld Kb ...", > ... ru.ru_maxrss*getpagesize()/1024... ); > > What's the right way to do it? You probably want to split this in more parts, and check that no overflow can occur: int pagesize; long kb, rss; pagesize = getpagesize(); if (LONG_MAX / pagesize < ru.ru_maxrss) rss = ru.ru_maxrss * (pagesize / 1024); else rss = (ru.ru_maxrss * pagesize) / 1024; fprintf(..., "... used %ld Kb ...", ... rss ...); It may even be more sensible to just use the first way of calculating `rss' all the time: fprintf(..., "... used %ld Kb ...", ... ru.ru_maxrss * (getpagesize() / 1024) ...); You can check if this is an overflow by printing LONG_MAX and the value of ru.ru_maxrss and going over the numbers yourself to make sure that what you see is not an overflow. - Giorgos From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 05:35:21 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 549E316DCA2 for ; Thu, 8 Jun 2006 02:56:26 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id D873343D6A for ; Thu, 8 Jun 2006 02:56:25 +0000 (GMT) (envelope-from lyndon@orthanc.ca) Received: from [192.168.15.2] (d154-5-28-131.bchsia.telus.net [154.5.28.131]) (authenticated bits=0) by orthanc.ca (8.13.4/8.13.4) with ESMTP id k582uMbp077460; Wed, 7 Jun 2006 20:56:22 -0600 (MDT) (envelope-from lyndon@orthanc.ca) In-Reply-To: <20060608015022.Y52876@mp2.macomnet.net> References: <20060608015022.Y52876@mp2.macomnet.net> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6F58AE0B-7A48-4675-96C3-92899A4DF8AD@orthanc.ca> Content-Transfer-Encoding: 7bit From: Lyndon Nerenberg Date: Wed, 7 Jun 2006 19:56:20 -0700 To: Maxim Konovalov X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on orthanc.ca Cc: current@freebsd.org Subject: Re: named recursive queries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 05:35:21 -0000 > I think we need to stop spread misconfigured named's too. Any > objections? I like OpenBSD's way a bit better: acl clients { localnets; ::1; 127.0.0.1; }; options { allow-recursion { clients; }; }; It's the same as you propose, but also allows hosts on directly connected networks to query. From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 06:08:44 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02B5F16C427; Thu, 8 Jun 2006 03:30:09 +0000 (UTC) (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 8C3E743D46; Thu, 8 Jun 2006 03:30:09 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id EB98B5D3A; Wed, 7 Jun 2006 23:30:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com 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 QTczDCLfjFUE; Wed, 7 Jun 2006 23:30:08 -0400 (EDT) Received: from [192.168.1.251] (pool-68-160-201-170.ny325.east.verizon.net [68.160.201.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id B65D45D25; Wed, 7 Jun 2006 23:30:07 -0400 (EDT) Message-ID: <448799B6.8080709@mac.com> Date: Wed, 07 Jun 2006 23:29:58 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Maxim Konovalov References: <20060608015022.Y52876@mp2.macomnet.net> In-Reply-To: <20060608015022.Y52876@mp2.macomnet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dougb@freebsd.org, current@freebsd.org Subject: Re: named recursive queries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 06:08:47 -0000 Maxim Konovalov wrote: > [ Bikeshed zone ] > > I think we need to stop spread misconfigured named's too. > Any objections? It seems clear that people who want to run a recursive nameserver will be able to change this if your proposed change is made. However, which problem that you are trying to solve with it? Yes, people can send queries with a spoofed sender to perform a DoS, and yes, permitting recursive queries lets the attacker choose a large response from any zone rather than having to tailor the attack to each nameserver. But querying each individual nameserver for the SOA record of it's domain would do just about as well for a DoS, and besides, you can construct a DoS attack using spoofed traffic via any open service, from chargen to HTTP.... The right solution to that problem is egress filtering of spoofed traffic at the ISP-level. [1] I'd be happier if named grew a mechanism to rate-limit queries made by foreign networks (or local ones, for that matter), rather than this change. [2] -- -Chuck [1]: http://www.mit.edu/~rbeverly/papers/spoofer-sruti05.html [2]: serial-query-rate exists, but isn't really what's needed. Perhaps no change in BIND is going to solve the broader problem that 25% of the netblocks out there permit spoofing-- a more generalized solution in the network stack (similar to net.inet.icmp.icmplimit) rather than in a specific application might do, or perhaps at the firewall level via dummynet or equivalent. > Index: named.conf > =================================================================== > RCS file: /home/ncvs/src/etc/namedb/named.conf,v > retrieving revision 1.22 > diff -u -p -r1.22 named.conf > --- named.conf 5 Sep 2005 13:42:22 -0000 1.22 > +++ named.conf 7 Jun 2006 21:56:26 -0000 > @@ -30,6 +30,13 @@ options { > // > // forward only; > > +// Prevent external networks from using us to query domains we are not > +// authoritative for. > +// > + allow-recursion { > + localhost; Surely this should be localnets...? > + }; > + > // If you've got a DNS server around at your upstream provider, enter > // its IP address here, and enable the line below. This will make you > // benefit from its cache, thus reduce overall DNS traffic in the Internet. > From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 06:10:06 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 235A616D0F0 for ; Thu, 8 Jun 2006 03:30:57 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 736B843D49 for ; Thu, 8 Jun 2006 03:30:56 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.13.4/8.13.3) with ESMTP id k583UsRo006283; Thu, 8 Jun 2006 07:30:54 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Thu, 8 Jun 2006 07:30:54 +0400 (MSD) From: Maxim Konovalov To: Lyndon Nerenberg In-Reply-To: <6F58AE0B-7A48-4675-96C3-92899A4DF8AD@orthanc.ca> Message-ID: <20060608072636.C6097@mp2.macomnet.net> References: <20060608015022.Y52876@mp2.macomnet.net> <6F58AE0B-7A48-4675-96C3-92899A4DF8AD@orthanc.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: current@freebsd.org Subject: Re: named recursive queries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 06:10:06 -0000 On Wed, 7 Jun 2006, 19:56-0700, Lyndon Nerenberg wrote: > >I think we need to stop spread misconfigured named's too. Any > >objections? > > I like OpenBSD's way a bit better: > > acl clients { > localnets; > : :1; 127.0.0.1; > }; > > options { > allow-recursion { clients; }; > }; > > It's the same as you propose, but also allows hosts on directly connected > networks to query. Yep, agreed. NetBSD's allow-recursion { localhost; localnets; }; looks like a good compromise. -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 06:50:04 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 267E116D66F; Thu, 8 Jun 2006 04:15:43 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 209BA43D5A; Thu, 8 Jun 2006 04:15:41 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.13.4/8.13.3) with ESMTP id k584FeEC006791; Thu, 8 Jun 2006 08:15:40 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Thu, 8 Jun 2006 08:15:40 +0400 (MSD) From: Maxim Konovalov To: Chuck Swiger In-Reply-To: <448799B6.8080709@mac.com> Message-ID: <20060608074705.Q6097@mp2.macomnet.net> References: <20060608015022.Y52876@mp2.macomnet.net> <448799B6.8080709@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: dougb@freebsd.org, current@freebsd.org Subject: Re: named recursive queries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 06:50:04 -0000 On Wed, 7 Jun 2006, 23:29-0400, Chuck Swiger wrote: > Maxim Konovalov wrote: > > [ Bikeshed zone ] > > > > I think we need to stop spread misconfigured named's too. > > Any objections? > > It seems clear that people who want to run a recursive nameserver > will be able to change this if your proposed change is made. > However, which problem that you are trying to solve with it? > > Yes, people can send queries with a spoofed sender to perform a DoS, > and yes, permitting recursive queries lets the attacker choose a > large response from any zone rather than having to tailor the attack > to each nameserver. > > But querying each individual nameserver for the SOA record of it's domain By default there are master zones (hence SOA records) for 0.0.127.IN-ADDR.ARPA and ipv6 localhost ARPA in our named.conf. Queries to them should be limited by the same ACL. > would do just about as well for a DoS, and besides, you can construct a DoS > attack using spoofed traffic via any open service, from chargen to HTTP.... That's why we don't have chargen turned on by default. For HTTP an amplification is ~1 and personally I don't know a way to construct an effective DoS. > The right solution to that problem is egress filtering of spoofed > traffic at the ISP-level. [1] I'd be happier if named grew a > mechanism to rate-limit queries made by foreign networks (or local > ones, for that matter), rather than this change. [2] I agreed that the problem in general should be solved by complete TCP/IP and Internet redesign :-) but personally I just want we stop to spread an incorrect named config and make people to think a minute and to learn a bit _before_ they run an authorized or recursive name server based on our example config. It's just a question of being a good netizens. A lemming argument - all *BSD already doing that. -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 07:15:59 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAD3B16BD5B for ; Thu, 8 Jun 2006 04:43:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 307D443D69 for ; Thu, 8 Jun 2006 04:43:18 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 25408 invoked by uid 399); 8 Jun 2006 04:43:18 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 8 Jun 2006 04:43:18 -0000 Message-ID: <4487AAE4.6020209@FreeBSD.org> Date: Wed, 07 Jun 2006 21:43:16 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.4 (X11/20060604) MIME-Version: 1.0 To: Maxim Konovalov References: <20060608015022.Y52876@mp2.macomnet.net> In-Reply-To: <20060608015022.Y52876@mp2.macomnet.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: named recursive queries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 07:16:01 -0000 Maxim Konovalov wrote: > [ Bikeshed zone ] > > I think we need to stop spread misconfigured named's too. Any > objections? Yes. :) The default named.conf already has the following: listen-on { 127.0.0.1; }; Which is a more effective solution to the problem. (Although you're not the first person to suggest this, so don't feel bad.) :) That said, BIND 9.4 is going to have a default for allow-recursion of "localhost; localnets;" which might be a good thing for us to make explicit now, so our users have a chance to get used to the idea. Comments? Doug > Index: named.conf > =================================================================== > RCS file: /home/ncvs/src/etc/namedb/named.conf,v > retrieving revision 1.22 > diff -u -p -r1.22 named.conf > --- named.conf 5 Sep 2005 13:42:22 -0000 1.22 > +++ named.conf 7 Jun 2006 21:56:26 -0000 > @@ -30,6 +30,13 @@ options { > // > // forward only; > > +// Prevent external networks from using us to query domains we are not > +// authoritative for. > +// > + allow-recursion { > + localhost; > + }; > + > // If you've got a DNS server around at your upstream provider, enter > // its IP address here, and enable the line below. This will make you > // benefit from its cache, thus reduce overall DNS traffic in the Internet. > -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 07:29:12 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4275616D51F; Thu, 8 Jun 2006 05:19:28 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93C1143D48; Thu, 8 Jun 2006 05:19:27 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.13.4/8.13.3) with ESMTP id k585JLEF008216; Thu, 8 Jun 2006 09:19:25 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Thu, 8 Jun 2006 09:19:21 +0400 (MSD) From: Maxim Konovalov To: Doug Barton In-Reply-To: <4487AAE4.6020209@FreeBSD.org> Message-ID: <20060608091735.V7007@mp2.macomnet.net> References: <20060608015022.Y52876@mp2.macomnet.net> <4487AAE4.6020209@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: current@FreeBSD.org Subject: Re: named recursive queries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 07:29:18 -0000 On Wed, 7 Jun 2006, 21:43-0700, Doug Barton wrote: > Maxim Konovalov wrote: > > [ Bikeshed zone ] > > > > I think we need to stop spread misconfigured named's too. Any > > objections? > > Yes. :) The default named.conf already has the following: > > listen-on { 127.0.0.1; }; > > Which is a more effective solution to the problem. (Although you're > not the first person to suggest this, so don't feel bad.) :) Just had my breakfast and feel quite good :-) > That said, BIND 9.4 is going to have a default for allow-recursion > of "localhost; localnets;" which might be a good thing for us to > make explicit now, so our users have a chance to get used to the > idea. Comments? I'm all for that. Thanks! -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 07:53:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F00016B1BD for ; Thu, 8 Jun 2006 05:24:01 +0000 (UTC) (envelope-from davidn@datalinktech.com.au) Received: from mail-ihug.icp-qv1-irony4.iinet.net.au (ihug-mail.icp-qv1-irony4.iinet.net.au [203.59.1.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9041F43D45 for ; Thu, 8 Jun 2006 05:23:59 +0000 (GMT) (envelope-from davidn@datalinktech.com.au) Received: from 203-206-162-119.perm.iinet.net.au (HELO mail.datalinktech.com.au) ([203.206.162.119]) by mail-ihug.icp-qv1-irony4.iinet.net.au with ESMTP; 08 Jun 2006 13:23:57 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,218,1146412800"; d="scan'208"; a="767220677:sNHT18434176" Received: from [192.168.4.232] ([192.168.4.232]) by mail.datalinktech.com.au with esmtp; Thu, 08 Jun 2006 15:23:54 +1000 id 0018D94B.4487B46A.00009930 Message-ID: <4487B45B.10601@datalinktech.com.au> Date: Thu, 08 Jun 2006 15:23:39 +1000 From: David Nugent User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: william wallace References: <87ab37ab0606071732o72d4145cs821f6305ead626a7@mail.gmail.com> In-Reply-To: <87ab37ab0606071732o72d4145cs821f6305ead626a7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: how to get current from CVS by tortoiseCVS on windows X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 07:53:56 -0000 william wallace wrote: > what module does current in ? > i only see the src module .....,help me out ,thank u! > "current" is not a module, it is a branch of src (but not really a branch as such, it is the trunk or "main" branch). An extract/checkout from src will be -current unless you specify an alternative branch like RELENG_6 for 6-stable or use a tag (which is, in effect, a snapshot). If you do not understand this or are confused by the terms used, then you may find http://cvsbook.red-bean.com/cvsbook.html#Branches useful. From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 09:10:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8244E16A913 for ; Thu, 8 Jun 2006 07:01:46 +0000 (UTC) (envelope-from bkoenig@cs.tu-berlin.de) Received: from efacilitas.de (smtp.efacilitas.de [85.10.196.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1300943D49 for ; Thu, 8 Jun 2006 07:01:43 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from eurystheus.local (port-212-202-39-242.dynamic.qsc.de [212.202.39.242]) by efacilitas.de (Postfix) with ESMTP id 142434C8B5; Thu, 8 Jun 2006 09:02:02 +0200 (CEST) Received: from [192.168.1.2] (muhkuh.local [192.168.1.2]) by eurystheus.local (Postfix) with ESMTP id 001E45285B; Thu, 8 Jun 2006 08:59:39 +0200 (CEST) Message-ID: <4487CB4B.2020706@cs.tu-berlin.de> Date: Thu, 08 Jun 2006 09:01:31 +0200 From: =?ISO-8859-1?Q?Bj=F6rn_K=F6nig?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-AT; rv:1.7.13) Gecko/20060519 X-Accept-Language: de, en MIME-Version: 1.0 To: danial_thom@yahoo.com References: <20060607122229.12701.qmail@web33304.mail.mud.yahoo.com> In-Reply-To: <20060607122229.12701.qmail@web33304.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: generic kernel doesn't boot without ppc? (was: Generic Kernel suggestion) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: danial_thom@yahoo.com, freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 09:10:14 -0000 Danial Thom schrieb: > It seems that Freebsd 6.1 (and likely others > versions as well) will hang when booted on a > machine with no parallel port. Since many newer > MBs are leaving the PP off due to lack of > interest, it might be a good idea to fix this, > since the point of a GENERIC kernel is that its a > superset of what's needed in most cases. I think you mean a missing parallel port controller (ppc) instead of missing parallel ports, because I deactivated my parallel ports and it works without problems (ppc0: parallel port not found.). This might be an interesting issue that need further investigation. I think it will get lost at questions@ thus I posted it to current@. Björn From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 09:38:34 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6456F16ED2B for ; Thu, 8 Jun 2006 07:38:26 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2483043D48 for ; Thu, 8 Jun 2006 07:38:26 +0000 (GMT) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id AF80778C1D; Thu, 8 Jun 2006 07:38:23 +0000 (GMT) Date: Thu, 8 Jun 2006 07:38:23 +0000 From: John Birrell To: current@freebsd.org Message-ID: <20060608073823.GA34193@what-creek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: DTrace for FreeBSD- source snapshots X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 09:38:36 -0000 Since the Slashdot article and my last status update here, I've had numerous requests for access to the development sources for the DTrace port to FreeBSD. I had hoped to get the DTrace P4 project exported to CVS and then to a CVSup server, but that doesn't seem to be possible. The FreeBSD P4 admins who can set this up haven't responded to my emails. Sulk. The best that I can do at the moment is to make a tar-ball containing the entire FreeBSD-current source tree available for download. You can get it from There is also a link on that page to a diff of the changed files and another tar-ball of the added files in case you want to just look. You should regard this as pre-alpha quality. It's still a work-in-progress. It can crash your system and/or ruin your day. Don't ask me how I know. 8-) The source tree will build on an i386 RELENG_6 machine (or a current one) using a standard 'buildworld'. The 'buildkernel' step will need to be: 'make NO_CTF=1 buildkernel' at the moment due to the fact that the buildkernel phase doesn't seem to use the bootstrapped tools. That's a problem that someone could work on. Hint. 8-) If there is someone with a bit of spare time on their hands, I'd like an install ISO to be built using 'make release'. And someone else might care to work on producing a live CD using FreeSBIE . That would be useful too. One final note: If you want to help out, please don't tell me you don't have much spare time. I'm looking for people who can put a bit of effort in. DTrace isn't a trivial project. It touches every part of the operating system. -- John Birrell From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 07:50:12 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8762B16B329 for ; Thu, 8 Jun 2006 05:18:45 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.digifonica.com (mail.digifonica.com [69.90.104.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2618C43D4C for ; Thu, 8 Jun 2006 05:18:44 +0000 (GMT) (envelope-from sobomax@sippysoft.com) Received: from localhost (localhost.digifonica.com [127.0.0.1]) by mail.digifonica.com (Postfix) with ESMTP id 3B45D5C3C; Wed, 7 Jun 2006 22:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at digifonica.com Received: from mail.digifonica.com ([127.0.0.1]) by localhost (mail.digifonica.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7J9H3xwA8As8; Wed, 7 Jun 2006 22:18:43 -0700 (PDT) Received: from [192.168.1.5] (S0106000f3d63befd.vs.shawcable.net [70.71.19.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digifonica.com (Postfix) with ESMTP id 897245C33; Wed, 7 Jun 2006 22:18:43 -0700 (PDT) Message-ID: <4487B334.60203@sippysoft.com> Date: Wed, 07 Jun 2006 22:18:44 -0700 From: Maksym Sobolyev User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Mikhail Teterin References: <200606071827.24207.mi+mx@aldan.algebra.com> In-Reply-To: <200606071827.24207.mi+mx@aldan.algebra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 08 Jun 2006 11:49:35 +0000 Cc: current@FreeBSD.ORG Subject: Re: getrusage() -- negative ru_maxrss?! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 07:50:14 -0000 Looks like you are just overflowing long, which is 32bits on i386. You are multiplying size in kilobytes by 4K, in 32 bit math, which as it can be easily seen will overflow 2^^31 limit and therefore go negative when maxrss is more than 512K. -Maxim Mikhail Teterin wrote: > Hello! > > I have a program, which uses getrusage() to report its own performance before > exiting. > > I noticed recently, that the ru_maxrss field is sometimes reported negative -- > I don't think, I ever saw this last year, for example... Is the field > considered usable and (semi-)accurate, or did FreeBSD abandon it (as Solaris > did)? > > I currently print it as: > > fprintf(..., "... used %ld Kb ...", ... ru.ru_maxrss*getpagesize()/1024... ); > > What's the right way to do it? > > -mi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 13:05:26 2006 Return-Path: X-Original-To: freebsd-current@www.freebsd.org Delivered-To: freebsd-current@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3197616F844 for ; Thu, 8 Jun 2006 11:01:12 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BF5B43D49 for ; Thu, 8 Jun 2006 11:01:08 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k58B0n8g071055; Thu, 8 Jun 2006 15:00:49 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k58B0k4j071054; Thu, 8 Jun 2006 15:00:46 +0400 (MSD) (envelope-from yar) Date: Thu, 8 Jun 2006 15:00:46 +0400 From: Yar Tikhiy To: Goran Gajic Message-ID: <20060608110046.GD69869@comp.chem.msu.su> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: freebsd-current@www.freebsd.org Subject: Re: 7.0-CURRENT panics if scroll lock is pressed during boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 13:05:27 -0000 On Tue, Jun 06, 2006 at 08:03:09PM +0200, Goran Gajic wrote: > > Hi, > > > I have noticed that if I press scroll lock during boot > somwhere after VGA detected and mounting of file systems > kernel will panic and drop into debugger. It is strange > that keyboard is also locked so I can't type anything. It might be another issue in kbdmux, as keyboard not working in the debugger apparently is. You can try hitting Scroll Lock with kbdmux disabled in device.hints or not compiled into the kernel in order to see if it's the case. Should the system still panic, you'll at least have the keyboard working in the debugger. -- Yar From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 15:14:10 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0457B16D4E0 for ; Thu, 8 Jun 2006 13:23:25 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 649F343D46 for ; Thu, 8 Jun 2006 13:23:21 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C8C275133B; Thu, 8 Jun 2006 15:23:20 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 6F67850E96; Thu, 8 Jun 2006 15:23:14 +0200 (CEST) Date: Thu, 8 Jun 2006 15:20:49 +0200 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20060608132048.GD86198@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IMjqdzrDRly81ofr" Content-Disposition: inline X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Subject: Data authentication for geli(8) committed to HEAD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 15:14:17 -0000 --IMjqdzrDRly81ofr Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. geli(8) from FreeBSD-CURRENT is not able to perform data integrity verification (data authentication) using one of the following algorithms: - HMAC/MD5 - HMAC/SHA1 - HMAC/RIPEMD160 - HMAC/SHA256 - HMAC/SHA384 - HMAC/SHA512 One of the main design goals was to make it reliable and resistant to power failures or system crashes. This was very important to commit both data update and HMAC update as an atomic operation to the disk, so users don't have to fight with false positives. Even with data authentication enabled, geli(8) should still be fast - to provide the reliability I'm talking on internal journal or other complex mechanisms are used. It is still sector-to-sector encryption. If someone is interested in the data layout itself, it is described in the sys/geom/eli/g_eli_integrity.c file. Before you use this feature, please read "DATA AUTHENTICATION" section in the geli(8) manual page, to learn against which kind of attacks geli(8) can protect your data and against which it can not. While working on this, I improved crypto(9) framework a bit and various drivers. At this point, all crypto accelerators, which we support should work with geli(8) (ubsec(4), hifn(4), safe(4), padlock(4)), also with data authentication functionality. Enjoy! The work was sponsored by Wheel LTD. [http://www.wheel.pl], creator of authentication system - CERB - which allows to use mobile phone/device in two-factor authentication process. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --IMjqdzrDRly81ofr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEiCQwForvXbEpPzQRAitiAJ0XeEyyaHSoDMvgzgVRFQ+0xOwSAACgoRz/ oFh2yYG9R05eBwa/yNCFjFY= =9x8V -----END PGP SIGNATURE----- --IMjqdzrDRly81ofr-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 15:22:33 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D25C16B73D for ; Thu, 8 Jun 2006 13:41:27 +0000 (UTC) (envelope-from tyler@tamu.edu) Received: from sr-2-int.cis.tamu.edu (smtp-relay.tamu.edu [165.91.22.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0133843D49 for ; Thu, 8 Jun 2006 13:41:25 +0000 (GMT) (envelope-from tyler@tamu.edu) Received: from localhost (localhost [127.0.0.1]) by sr-2-int.cis.tamu.edu (Postfix) with ESMTP id 2D1C4EE5A; Thu, 8 Jun 2006 08:41:25 -0500 (CDT) Received: from [192.168.250.100] (24-240-212-120.dhcp.sprn.tx.charter.com [24.240.212.120]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by sr-2-int.cis.tamu.edu (Postfix) with ESMTP id 2046FE79D; Thu, 8 Jun 2006 08:41:22 -0500 (CDT) In-Reply-To: <20060608073823.GA34193@what-creek.com> References: <20060608073823.GA34193@what-creek.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "R. Tyler Ballance" Date: Thu, 8 Jun 2006 08:41:17 -0500 To: John Birrell X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) X-Virus-Scanned: amavisd-new at tamu.edu Cc: current@freebsd.org Subject: Re: DTrace for FreeBSD- source snapshots X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 15:22:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Presumably since it's from Sun, it'll run on the FreeBSD/sparc64 machines as well? ;) Unfortunately, I don't have anything but i386 machines here (not counting a Powerbook), but how portable is this code? Can anybody verify it'll work on FreeBSD/amd64? mips? arm? leg? I'm definitely interested in the prospects of being able to use this while working on L4::BSD, since dtrace seems almost perfect for debugging kernel and other low level processes without all the magic and pixie dust I hear jhb and phk use... ;) Cheers, - -R. Tyler Ballance On Jun 8, 2006, at 2:38 AM, John Birrell wrote: > Since the Slashdot article 06/05/29/1144234.shtml> > and my last status update here, I've had numerous requests for > access to the > development sources for the DTrace port to FreeBSD. > > I had hoped to get the DTrace P4 project exported to CVS and then > to a CVSup > server, but that doesn't seem to be possible. The FreeBSD P4 admins > who can set > this up haven't responded to my emails. Sulk. > > The best that I can do at the moment is to make a tar-ball > containing the > entire FreeBSD-current source tree available for download. You can > get it from > > > There is also a link on that page to a diff of the changed files > and another > tar-ball of the added files in case you want to just look. > > You should regard this as pre-alpha quality. It's still a work-in- > progress. > It can crash your system and/or ruin your day. Don't ask me how I > know. 8-) > > The source tree will build on an i386 RELENG_6 machine (or a > current one) using a > standard 'buildworld'. The 'buildkernel' step will need to be: > 'make NO_CTF=1 buildkernel' at the moment due to the fact that the > buildkernel > phase doesn't seem to use the bootstrapped tools. That's a problem > that someone > could work on. Hint. 8-) > > If there is someone with a bit of spare time on their hands, I'd > like an install > ISO to be built using 'make release'. And someone else might care > to work on > producing a live CD using FreeSBIE . That would > be useful > too. > > One final note: If you want to help out, please don't tell me you > don't have > much spare time. I'm looking for people who can put a bit of effort > in. DTrace > isn't a trivial project. It touches every part of the operating > system. > > -- > John Birrell > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFEiCkAqO6nEJfroRsRAi7rAJwP1ArHZKsl5T2LIKW1hWqbR/R5RgCeNWE1 1FHD6WuD0aAbMZF+E8Jv9L4= =2s6B -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 16:28:16 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E4CE16C1C4 for ; Thu, 8 Jun 2006 14:53:34 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56E7D43D48 for ; Thu, 8 Jun 2006 14:53:33 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k58ErUim055102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Jun 2006 18:53:31 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k58ErUTB055101 for current@FreeBSD.org; Thu, 8 Jun 2006 18:53:30 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 8 Jun 2006 18:53:30 +0400 From: Gleb Smirnoff To: current@FreeBSD.org Message-ID: <20060608145330.GI46285@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline User-Agent: Mutt/1.5.6i Cc: Subject: [TEST] bge patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 16:28:17 -0000 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Dear colleagues, here is a patch, that I'd like to commit to HEAD. It is mostly a merge from OpenBSD. The changes are the following: - Add more device IDs, ASIC revisions and chip IDs. - Rewrite a bit code that picks the description for device. - Introduce several macros to match shorten quirks for bugs and features. - Use some magic values, that OpenBSD has successfully possessed from Linux (Broadcom supplied) driver. The patch is going to: - Add support for new NICs from this family. - Do not break supported NICs. I'd appreciate if you test this patch, assuming you have a bge(4) NIC. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="bge.diff" Index: if_bge.c =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.131 diff -u -r1.131 if_bge.c --- if_bge.c 8 Jun 2006 10:19:16 -0000 1.131 +++ if_bge.c 8 Jun 2006 14:34:29 -0000 @@ -126,72 +126,258 @@ * ID burned into it, though it will always be overriden by the vendor * ID in the EEPROM. Just to be safe, we cover all possibilities. */ -#define BGE_DEVDESC_MAX 64 /* Maximum device description length */ - static struct bge_type bge_devs[] = { - { ALT_VENDORID, ALT_DEVICEID_BCM5700, - "Broadcom BCM5700 Gigabit Ethernet" }, - { ALT_VENDORID, ALT_DEVICEID_BCM5701, - "Broadcom BCM5701 Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5700, - "Broadcom BCM5700 Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5701, - "Broadcom BCM5701 Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5702, - "Broadcom BCM5702 Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5702X, - "Broadcom BCM5702X Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5703, - "Broadcom BCM5703 Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5703X, - "Broadcom BCM5703X Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5704C, - "Broadcom BCM5704C Dual Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5704S, - "Broadcom BCM5704S Dual Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5705, - "Broadcom BCM5705 Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5705K, - "Broadcom BCM5705K Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5705M, - "Broadcom BCM5705M Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5705M_ALT, - "Broadcom BCM5705M Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5714C, - "Broadcom BCM5714C Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5721, - "Broadcom BCM5721 Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5750, - "Broadcom BCM5750 Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5750M, - "Broadcom BCM5750M Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5751, - "Broadcom BCM5751 Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5751M, - "Broadcom BCM5751M Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5752, - "Broadcom BCM5752 Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5782, - "Broadcom BCM5782 Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5788, - "Broadcom BCM5788 Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5789, - "Broadcom BCM5789 Gigabit Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5901, - "Broadcom BCM5901 Fast Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM5901A2, - "Broadcom BCM5901A2 Fast Ethernet" }, - { SK_VENDORID, SK_DEVICEID_ALTIMA, - "SysKonnect Gigabit Ethernet" }, - { ALTIMA_VENDORID, ALTIMA_DEVICE_AC1000, - "Altima AC1000 Gigabit Ethernet" }, - { ALTIMA_VENDORID, ALTIMA_DEVICE_AC1002, - "Altima AC1002 Gigabit Ethernet" }, - { ALTIMA_VENDORID, ALTIMA_DEVICE_AC9100, - "Altima AC9100 Gigabit Ethernet" }, - { 0, 0, NULL } + { ALTEON_VENDORID, ALTEON_DEVICEID_BCM5700 }, + { ALTEON_VENDORID, ALTEON_DEVICEID_BCM5701 }, + + { ALTIMA_VENDORID, ALTIMA_DEVICE_AC1000 }, + { ALTIMA_VENDORID, ALTIMA_DEVICE_AC1002 }, + { ALTIMA_VENDORID, ALTIMA_DEVICE_AC9100 }, + + { APPLE_VENDORID, APPLE_DEVICE_BCM5701 }, + + { BCOM_VENDORID, BCOM_DEVICEID_BCM5700 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5701 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5702 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5702_ALT }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5702X }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5703 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5703_ALT }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5703X }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5704C }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5704S }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5704S_ALT }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5705 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5705F }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5705K }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5705M }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5705M_ALT }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5714C }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5714S }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5715 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5715S }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5720 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5721 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5750 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5750M }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5751 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5751F }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5751M }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5752 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5752M }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5753 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5753F }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5753M }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5780 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5780S }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5781 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5782 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5788 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5789 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5901 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5901A2 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5903M }, + + { SK_VENDORID, SK_DEVICEID_ALTIMA }, + + { TC_VENDORID, TC_DEVICEID_3C985 }, + { TC_VENDORID, TC_DEVICEID_3C996 }, + + { 0, 0 } }; +#define BGE_IS_5705_OR_BEYOND(sc) \ + ((sc)->bge_asicrev == BGE_ASICREV_BCM5705 || \ + (sc)->bge_asicrev == BGE_ASICREV_BCM5750 || \ + (sc)->bge_asicrev == BGE_ASICREV_BCM5714_A0 || \ + (sc)->bge_asicrev == BGE_ASICREV_BCM5780 || \ + (sc)->bge_asicrev == BGE_ASICREV_BCM5714 || \ + (sc)->bge_asicrev == BGE_ASICREV_BCM5752) + +#define BGE_IS_575X_PLUS(sc) \ + ((sc)->bge_asicrev == BGE_ASICREV_BCM5750 || \ + (sc)->bge_asicrev == BGE_ASICREV_BCM5714_A0 || \ + (sc)->bge_asicrev == BGE_ASICREV_BCM5780 || \ + (sc)->bge_asicrev == BGE_ASICREV_BCM5714 || \ + (sc)->bge_asicrev == BGE_ASICREV_BCM5752) + +#define BGE_IS_5714_FAMILY(sc) \ + ((sc)->bge_asicrev == BGE_ASICREV_BCM5714_A0 || \ + (sc)->bge_asicrev == BGE_ASICREV_BCM5780 || \ + (sc)->bge_asicrev == BGE_ASICREV_BCM5714) + +#define BGE_IS_JUMBO_CAPABLE(sc) \ + ((sc)->bge_asicrev != BGE_ASICREV_BCM5705 && \ + (sc)->bge_asicrev != BGE_ASICREV_BCM5750) + +static const struct bge_revision { + uint32_t br_chipid; + const char *br_name; +} bge_revisions[] = { + { BGE_CHIPID_BCM5700_A0, + "BCM5700 A0" }, + + { BGE_CHIPID_BCM5700_A1, + "BCM5700 A1" }, + + { BGE_CHIPID_BCM5700_B0, + "BCM5700 B0" }, + + { BGE_CHIPID_BCM5700_B1, + "BCM5700 B1" }, + + { BGE_CHIPID_BCM5700_B2, + "BCM5700 B2" }, + + { BGE_CHIPID_BCM5700_B3, + "BCM5700 B3" }, + + /* This is treated like a BCM5700 Bx */ + { BGE_CHIPID_BCM5700_ALTIMA, + "BCM5700 Altima" }, + + { BGE_CHIPID_BCM5700_C0, + "BCM5700 C0" }, + + { BGE_CHIPID_BCM5701_A0, + "BCM5701 A0" }, + + { BGE_CHIPID_BCM5701_B0, + "BCM5701 B0" }, + + { BGE_CHIPID_BCM5701_B2, + "BCM5701 B2" }, + + { BGE_CHIPID_BCM5701_B5, + "BCM5701 B5" }, + + { BGE_CHIPID_BCM5703_A0, + "BCM5703 A0" }, + + { BGE_CHIPID_BCM5703_A1, + "BCM5703 A1" }, + + { BGE_CHIPID_BCM5703_A2, + "BCM5703 A2" }, + + { BGE_CHIPID_BCM5703_A3, + "BCM5703 A3" }, + + { BGE_CHIPID_BCM5704_A0, + "BCM5704 A0" }, + + { BGE_CHIPID_BCM5704_A1, + "BCM5704 A1" }, + + { BGE_CHIPID_BCM5704_A2, + "BCM5704 A2" }, + + { BGE_CHIPID_BCM5704_A3, + "BCM5704 A3" }, + + { BGE_CHIPID_BCM5704_B0, + "BCM5704 B0" }, + + { BGE_CHIPID_BCM5705_A0, + "BCM5705 A0" }, + + { BGE_CHIPID_BCM5705_A1, + "BCM5705 A1" }, + + { BGE_CHIPID_BCM5705_A2, + "BCM5705 A2" }, + + { BGE_CHIPID_BCM5705_A3, + "BCM5705 A3" }, + + { BGE_CHIPID_BCM5750_A0, + "BCM5750 A0" }, + + { BGE_CHIPID_BCM5750_A1, + "BCM5750 A1" }, + + { BGE_CHIPID_BCM5750_A3, + "BCM5750 A3" }, + + { BGE_CHIPID_BCM5750_B0, + "BCM5750 B0" }, + + { BGE_CHIPID_BCM5750_B1, + "BCM5750 B1" }, + + { BGE_CHIPID_BCM5750_C0, + "BCM5750 C0" }, + + { BGE_CHIPID_BCM5750_C1, + "BCM5750 C1" }, + + { BGE_CHIPID_BCM5714_A0, + "BCM5714 A0" }, + + { BGE_CHIPID_BCM5752_A0, + "BCM5752 A0" }, + + { BGE_CHIPID_BCM5752_A1, + "BCM5752 A1" }, + + { BGE_CHIPID_BCM5752_A2, + "BCM5752 A2" }, + + { BGE_CHIPID_BCM5714_B0, + "BCM5714 B0" }, + + { BGE_CHIPID_BCM5714_B3, + "BCM5714 B3" }, + + { BGE_CHIPID_BCM5715_A0, + "BCM5715 A0" }, + + { BGE_CHIPID_BCM5715_A1, + "BCM5715 A1" }, + + { 0, + NULL } +}; + +/* + * Some defaults for major revisions, so that newer steppings + * that we don't know about have a shot at working. + */ +static const struct bge_revision bge_majorrevs[] = { + { BGE_ASICREV_BCM5700, + "unknown BCM5700" }, + + { BGE_ASICREV_BCM5701, + "unknown BCM5701" }, + + { BGE_ASICREV_BCM5703, + "unknown BCM5703" }, + + { BGE_ASICREV_BCM5704, + "unknown BCM5704" }, + + { BGE_ASICREV_BCM5705, + "unknown BCM5705" }, + + { BGE_ASICREV_BCM5750, + "unknown BCM5750" }, + + { BGE_ASICREV_BCM5714_A0, + "unknown BCM5714" }, + + { BGE_ASICREV_BCM5752, + "unknown BCM5752" }, + + { BGE_ASICREV_BCM5780, + "unknown BCM5780" }, + + { BGE_ASICREV_BCM5714, + "unknown BCM5714" }, + + { 0, NULL } +}; + +const struct bge_revision * bge_lookup_rev(uint32_t); static int bge_probe(device_t); static int bge_attach(device_t); static int bge_detach(device_t); @@ -973,23 +1159,27 @@ /* Set up the PCI DMA control register. */ if (sc->bge_pcie) { + /* PCI Express bus */ dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD | (0xf << BGE_PCIDMARWCTL_RD_WAT_SHIFT) | (0x2 << BGE_PCIDMARWCTL_WR_WAT_SHIFT); - } else if (pci_read_config(sc->bge_dev, BGE_PCI_PCISTATE, 4) & - BGE_PCISTATE_PCI_BUSMODE) { - /* Conventional PCI bus */ - dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD | - (0x7 << BGE_PCIDMARWCTL_RD_WAT_SHIFT) | - (0x7 << BGE_PCIDMARWCTL_WR_WAT_SHIFT) | - (0x0F); - } else { + } else if (sc->bge_pcix) { /* PCI-X bus */ - /* - * The 5704 uses a different encoding of read/write - * watermarks. - */ - if (sc->bge_asicrev == BGE_ASICREV_BCM5704) + if (BGE_IS_5714_FAMILY(sc)) { + dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD; + dma_rw_ctl &= ~BGE_PCIDMARWCTL_ONEDMA_ATONCE; /* XXX */ + /* XXX magic values, Broadcom-supplied Linux driver */ + if (sc->bge_asicrev == BGE_ASICREV_BCM5780) + dma_rw_ctl |= (1 << 20) | (1 << 18) | + BGE_PCIDMARWCTL_ONEDMA_ATONCE; + else + dma_rw_ctl |= (1 << 20) | (1 << 18) | (1 << 15); + + } else if (sc->bge_asicrev == BGE_ASICREV_BCM5704) + /* + * The 5704 uses a different encoding of read/write + * watermarks. + */ dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD | (0x7 << BGE_PCIDMARWCTL_RD_WAT_SHIFT) | (0x3 << BGE_PCIDMARWCTL_WR_WAT_SHIFT); @@ -1011,12 +1201,16 @@ if (tmp == 0x6 || tmp == 0x7) dma_rw_ctl |= BGE_PCIDMARWCTL_ONEDMA_ATONCE; } - } + } else + /* Conventional PCI bus */ + dma_rw_ctl = BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD | + (0x7 << BGE_PCIDMARWCTL_RD_WAT_SHIFT) | + (0x7 << BGE_PCIDMARWCTL_WR_WAT_SHIFT) | + (0x0F); if (sc->bge_asicrev == BGE_ASICREV_BCM5703 || sc->bge_asicrev == BGE_ASICREV_BCM5704 || - sc->bge_asicrev == BGE_ASICREV_BCM5705 || - sc->bge_asicrev == BGE_ASICREV_BCM5750) + sc->bge_asicrev == BGE_ASICREV_BCM5705) dma_rw_ctl &= ~BGE_PCIDMARWCTL_MINDMA; pci_write_config(sc->bge_dev, BGE_PCI_DMA_RW_CTL, dma_rw_ctl, 4); @@ -1068,8 +1262,7 @@ /* Note: the BCM5704 has a smaller mbuf space than other chips. */ - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) { + if (!(BGE_IS_5705_OR_BEYOND(sc))) { /* Configure mbuf memory pool */ if (sc->bge_extram) { CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_BASEADDR, @@ -1094,8 +1287,7 @@ } /* Configure mbuf pool watermarks */ - if (sc->bge_asicrev == BGE_ASICREV_BCM5705 || - sc->bge_asicrev == BGE_ASICREV_BCM5750) { + if (!(BGE_IS_5705_OR_BEYOND(sc))) { CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0); CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x10); } else { @@ -1109,8 +1301,7 @@ CSR_WRITE_4(sc, BGE_BMAN_DMA_DESCPOOL_HIWAT, 10); /* Enable buffer manager */ - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) { + if (!(BGE_IS_5705_OR_BEYOND(sc))) { CSR_WRITE_4(sc, BGE_BMAN_MODE, BGE_BMANMODE_ENABLE|BGE_BMANMODE_LOMBUF_ATTN); @@ -1152,8 +1343,7 @@ BGE_ADDR_HI(sc->bge_ldata.bge_rx_std_ring_paddr); bus_dmamap_sync(sc->bge_cdata.bge_rx_std_ring_tag, sc->bge_cdata.bge_rx_std_ring_map, BUS_DMASYNC_PREREAD); - if (sc->bge_asicrev == BGE_ASICREV_BCM5705 || - sc->bge_asicrev == BGE_ASICREV_BCM5750) + if (BGE_IS_5705_OR_BEYOND(sc)) rcb->bge_maxlen_flags = BGE_RCB_MAXLEN_FLAGS(512, 0); else rcb->bge_maxlen_flags = @@ -1175,8 +1365,7 @@ * using this ring (i.e. once we set the MTU * high enough to require it). */ - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) { + if (BGE_IS_JUMBO_CAPABLE(sc)) { rcb = &sc->bge_ldata.bge_info.bge_jumbo_rx_rcb; rcb->bge_hostaddr.bge_addr_lo = @@ -1237,8 +1426,7 @@ RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_lo, taddr.bge_addr_lo); RCB_WRITE_4(sc, vrcb, bge_nicaddr, BGE_NIC_TXRING_ADDR(0, BGE_TX_RING_CNT)); - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) + if (!(BGE_IS_5705_OR_BEYOND(sc))) RCB_WRITE_4(sc, vrcb, bge_maxlen_flags, BGE_RCB_MAXLEN_FLAGS(BGE_TX_RING_CNT, 0)); @@ -1322,8 +1510,7 @@ CSR_WRITE_4(sc, BGE_HCC_TX_COAL_TICKS, sc->bge_tx_coal_ticks); CSR_WRITE_4(sc, BGE_HCC_RX_MAX_COAL_BDS, sc->bge_rx_max_coal_bds); CSR_WRITE_4(sc, BGE_HCC_TX_MAX_COAL_BDS, sc->bge_tx_max_coal_bds); - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) { + if (!(BGE_IS_5705_OR_BEYOND(sc))) { CSR_WRITE_4(sc, BGE_HCC_RX_COAL_TICKS_INT, 0); CSR_WRITE_4(sc, BGE_HCC_TX_COAL_TICKS_INT, 0); } @@ -1331,8 +1518,7 @@ CSR_WRITE_4(sc, BGE_HCC_TX_MAX_COAL_BDS_INT, 0); /* Set up address of statistics block */ - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) { + if (!(BGE_IS_5705_OR_BEYOND(sc))) { CSR_WRITE_4(sc, BGE_HCC_STATS_ADDR_HI, BGE_ADDR_HI(sc->bge_ldata.bge_stats_paddr)); CSR_WRITE_4(sc, BGE_HCC_STATS_ADDR_LO, @@ -1361,8 +1547,7 @@ CSR_WRITE_4(sc, BGE_RXLP_MODE, BGE_RXLPMODE_ENABLE); /* Turn on RX list selector state machine. */ - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) + if (!(BGE_IS_5705_OR_BEYOND(sc))) CSR_WRITE_4(sc, BGE_RXLS_MODE, BGE_RXLSMODE_ENABLE); /* Turn on DMA, clear stats */ @@ -1384,8 +1569,7 @@ #endif /* Turn on DMA completion state machine */ - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) + if (!(BGE_IS_5705_OR_BEYOND(sc))) CSR_WRITE_4(sc, BGE_DMAC_MODE, BGE_DMACMODE_ENABLE); /* Turn on write DMA state machine */ @@ -1406,8 +1590,7 @@ CSR_WRITE_4(sc, BGE_RDBDI_MODE, BGE_RDBDIMODE_ENABLE); /* Turn on Mbuf cluster free state machine */ - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) + if (!(BGE_IS_5705_OR_BEYOND(sc))) CSR_WRITE_4(sc, BGE_MBCF_MODE, BGE_MBCFMODE_ENABLE); /* Turn on send BD completion state machine */ @@ -1441,7 +1624,7 @@ } else { BGE_SETBIT(sc, BGE_MI_MODE, BGE_MIMODE_AUTOPOLL|10<<16); if (sc->bge_asicrev == BGE_ASICREV_BCM5700 && - sc->bge_chipid != BGE_CHIPID_BCM5700_B1) + sc->bge_chipid != BGE_CHIPID_BCM5700_B2) CSR_WRITE_4(sc, BGE_MAC_EVT_ENB, BGE_EVTENB_MI_INTERRUPT); } @@ -1463,6 +1646,24 @@ return (0); } +const struct bge_revision * +bge_lookup_rev(uint32_t chipid) +{ + const struct bge_revision *br; + + for (br = bge_revisions; br->br_name != NULL; br++) { + if (br->br_chipid == chipid) + return (br); + } + + for (br = bge_majorrevs; br->br_name != NULL; br++) { + if (br->br_chipid == BGE_ASICREV(chipid)) + return (br); + } + + return (NULL); +} + /* * Probe for a Broadcom chip. Check the PCI vendor and device IDs * against our list and return its name if we find a match. Note @@ -1474,33 +1675,35 @@ static int bge_probe(device_t dev) { - struct bge_type *t; - struct bge_softc *sc; - char *descbuf; + struct bge_type *t = bge_devs; + struct bge_softc *sc = device_get_softc(dev); - t = bge_devs; - - sc = device_get_softc(dev); bzero(sc, sizeof(struct bge_softc)); sc->bge_dev = dev; - while(t->bge_name != NULL) { + while(t->bge_vid != 0) { if ((pci_get_vendor(dev) == t->bge_vid) && (pci_get_device(dev) == t->bge_did)) { + char buf[64]; + const struct bge_revision *br; + uint32_t id; + #ifdef notdef bge_vpd_read(sc); device_set_desc(dev, sc->bge_vpd_prodname); #endif - descbuf = malloc(BGE_DEVDESC_MAX, M_TEMP, M_NOWAIT); - if (descbuf == NULL) - return (ENOMEM); - snprintf(descbuf, BGE_DEVDESC_MAX, - "%s, ASIC rev. %#04x", t->bge_name, - pci_read_config(dev, BGE_PCI_MISC_CTL, 4) >> 16); - device_set_desc_copy(dev, descbuf); + id = pci_read_config(dev, BGE_PCI_MISC_CTL, 4) & + BGE_PCIMISCCTL_ASICREV; + br = bge_lookup_rev(id); + id >>= 16; + if (br == NULL) + snprintf(buf, 64, "unknown ASIC (%#04x)", id); + else + snprintf(buf, 64, "%s, ASIC rev. %#04x", + br->br_name, id); + device_set_desc_copy(dev, buf); if (pci_get_subvendor(dev) == DELL_VENDORID) sc->bge_no_3_led = 1; - free(descbuf, M_TEMP); return (0); } t++; @@ -1721,8 +1924,7 @@ sc->bge_ldata.bge_rx_std_ring_paddr = ctx.bge_busaddr; /* Create tags for jumbo mbufs. */ - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) { + if (BGE_IS_JUMBO_CAPABLE(sc)) { error = bus_dma_tag_create(sc->bge_cdata.bge_parent_tag, 1, 0, BUS_SPACE_MAXADDR, BUS_SPACE_MAXADDR, NULL, NULL, MJUM9BYTES, BGE_NSEG_JUMBO, PAGE_SIZE, @@ -1971,18 +2173,10 @@ sc->bge_chiprev = BGE_CHIPREV(sc->bge_chipid); /* - * Treat the 5714 and the 5752 like the 5750 until we have more info - * on this chip. - */ - if (sc->bge_asicrev == BGE_ASICREV_BCM5714 || - sc->bge_asicrev == BGE_ASICREV_BCM5752) - sc->bge_asicrev = BGE_ASICREV_BCM5750; - - /* * XXX: Broadcom Linux driver. Not in specs or eratta. * PCI-Express? */ - if (sc->bge_asicrev == BGE_ASICREV_BCM5750) { + if (BGE_IS_5705_OR_BEYOND(sc)) { uint32_t v; v = pci_read_config(dev, BGE_PCI_MSI_CAPID, 4); @@ -1993,6 +2187,13 @@ } } + /* + * PCI-X ? + */ + if ((pci_read_config(sc->bge_dev, BGE_PCI_PCISTATE, 4) & + BGE_PCISTATE_PCI_BUSMODE) == 0) + sc->bge_pcix = 1; + /* Try to reset the chip. */ bge_reset(sc); @@ -2024,8 +2225,7 @@ } /* 5705 limits RX return ring to 512 entries. */ - if (sc->bge_asicrev == BGE_ASICREV_BCM5705 || - sc->bge_asicrev == BGE_ASICREV_BCM5750) + if (BGE_IS_5705_OR_BEYOND(sc)) sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT_5705; else sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT; @@ -2141,18 +2341,8 @@ * which do not support unaligned accesses, we will realign the * payloads by copying the received packets. */ - switch (sc->bge_chipid) { - case BGE_CHIPID_BCM5701_A0: - case BGE_CHIPID_BCM5701_B0: - case BGE_CHIPID_BCM5701_B2: - case BGE_CHIPID_BCM5701_B5: - /* If in PCI-X mode, work around the alignment bug. */ - if ((pci_read_config(dev, BGE_PCI_PCISTATE, 4) & - (BGE_PCISTATE_PCI_BUSMODE | BGE_PCISTATE_PCI_BUSSPEED)) == - BGE_PCISTATE_PCI_BUSSPEED) - sc->bge_rx_alignment_bug = 1; - break; - } + if (sc->bge_asicrev == BGE_ASICREV_BCM5701 && sc->bge_pcix) + sc->bge_rx_alignment_bug = 1; /* * Call MI attach routine. @@ -2298,8 +2488,12 @@ bge_writereg_ind(sc, BGE_MISC_CFG, (65 << 1)); /* Enable memory arbiter. */ - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) + if (BGE_IS_5714_FAMILY(sc)) { + uint32_t val; + + val = CSR_READ_4(sc, BGE_MARB_MODE); + CSR_WRITE_4(sc, BGE_MARB_MODE, BGE_MARBMODE_ENABLE | val); + } else CSR_WRITE_4(sc, BGE_MARB_MODE, BGE_MARBMODE_ENABLE); /* @@ -2395,12 +2589,9 @@ sc->bge_cdata.bge_rx_return_ring_map, BUS_DMASYNC_POSTREAD); bus_dmamap_sync(sc->bge_cdata.bge_rx_std_ring_tag, sc->bge_cdata.bge_rx_std_ring_map, BUS_DMASYNC_POSTREAD); - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) { + if (BGE_IS_JUMBO_CAPABLE(sc)) bus_dmamap_sync(sc->bge_cdata.bge_rx_jumbo_ring_tag, - sc->bge_cdata.bge_rx_jumbo_ring_map, - BUS_DMASYNC_POSTREAD); - } + sc->bge_cdata.bge_rx_jumbo_ring_map, BUS_DMASYNC_POSTREAD); while(sc->bge_rx_saved_considx != sc->bge_ldata.bge_status_block->bge_idx[0].bge_rx_prod_idx) { @@ -2521,13 +2712,10 @@ if (stdcnt > 0) bus_dmamap_sync(sc->bge_cdata.bge_rx_std_ring_tag, sc->bge_cdata.bge_rx_std_ring_map, BUS_DMASYNC_PREWRITE); - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) { - if (jumbocnt > 0) - bus_dmamap_sync(sc->bge_cdata.bge_rx_jumbo_ring_tag, - sc->bge_cdata.bge_rx_jumbo_ring_map, - BUS_DMASYNC_PREWRITE); - } + + if (BGE_IS_JUMBO_CAPABLE(sc) && jumbocnt > 0) + bus_dmamap_sync(sc->bge_cdata.bge_rx_jumbo_ring_tag, + sc->bge_cdata.bge_rx_jumbo_ring_map, BUS_DMASYNC_PREWRITE); CSR_WRITE_4(sc, BGE_MBX_RX_CONS0_LO, sc->bge_rx_saved_considx); if (stdcnt) @@ -2612,7 +2800,7 @@ if (cmd == POLL_AND_CHECK_STATUS) if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && - sc->bge_chipid != BGE_CHIPID_BCM5700_B1) || + sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || sc->bge_link_evt || sc->bge_tbi) bge_link_upd(sc); @@ -2661,7 +2849,7 @@ sc->bge_cdata.bge_status_map, BUS_DMASYNC_PREREAD); if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && - sc->bge_chipid != BGE_CHIPID_BCM5700_B1) || + sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || statusword || sc->bge_link_evt) bge_link_upd(sc); @@ -2690,8 +2878,7 @@ BGE_LOCK_ASSERT(sc); - if (sc->bge_asicrev == BGE_ASICREV_BCM5705 || - sc->bge_asicrev == BGE_ASICREV_BCM5750) + if (BGE_IS_5705_OR_BEYOND(sc)) bge_stats_update_regs(sc); else bge_stats_update(sc); @@ -3244,6 +3431,10 @@ if (CSR_READ_4(sc, BGE_MAC_STS) & BGE_MACSTAT_TBI_PCS_SYNCHED) ifmr->ifm_status |= IFM_ACTIVE; + else { + ifmr->ifm_active |= IFM_NONE; + return; + } ifmr->ifm_active |= IFM_1000_SX; if (CSR_READ_4(sc, BGE_MAC_MODE) & BGE_MACMODE_HALF_DUPLEX) ifmr->ifm_active |= IFM_HDX; @@ -3268,12 +3459,13 @@ switch (command) { case SIOCSIFMTU: - /* Disallow jumbo frames on 5705. */ - if (((sc->bge_asicrev == BGE_ASICREV_BCM5705 || - sc->bge_asicrev == BGE_ASICREV_BCM5750) && - ifr->ifr_mtu > ETHERMTU) || ifr->ifr_mtu > BGE_JUMBO_MTU) + if (ifr->ifr_mtu < ETHERMIN || + ((BGE_IS_JUMBO_CAPABLE(sc)) && + ifr->ifr_mtu > BGE_JUMBO_MTU) || + ((!BGE_IS_JUMBO_CAPABLE(sc)) && + ifr->ifr_mtu > ETHERMTU)) error = EINVAL; - else { + else if (ifp->if_mtu != ifr->ifr_mtu) { ifp->if_mtu = ifr->ifr_mtu; ifp->if_drv_flags &= ~IFF_DRV_RUNNING; bge_init(sc); @@ -3424,8 +3616,7 @@ BGE_CLRBIT(sc, BGE_RX_MODE, BGE_RXMODE_ENABLE); BGE_CLRBIT(sc, BGE_RBDI_MODE, BGE_RBDIMODE_ENABLE); BGE_CLRBIT(sc, BGE_RXLP_MODE, BGE_RXLPMODE_ENABLE); - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) + if (!(BGE_IS_5705_OR_BEYOND(sc))) BGE_CLRBIT(sc, BGE_RXLS_MODE, BGE_RXLSMODE_ENABLE); BGE_CLRBIT(sc, BGE_RDBDI_MODE, BGE_RBDIMODE_ENABLE); BGE_CLRBIT(sc, BGE_RDC_MODE, BGE_RDCMODE_ENABLE); @@ -3439,8 +3630,7 @@ BGE_CLRBIT(sc, BGE_SDI_MODE, BGE_SDIMODE_ENABLE); BGE_CLRBIT(sc, BGE_RDMA_MODE, BGE_RDMAMODE_ENABLE); BGE_CLRBIT(sc, BGE_SDC_MODE, BGE_SDCMODE_ENABLE); - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) + if (!(BGE_IS_5705_OR_BEYOND(sc))) BGE_CLRBIT(sc, BGE_DMAC_MODE, BGE_DMACMODE_ENABLE); BGE_CLRBIT(sc, BGE_SBDC_MODE, BGE_SBDCMODE_ENABLE); @@ -3450,13 +3640,11 @@ */ BGE_CLRBIT(sc, BGE_HCC_MODE, BGE_HCCMODE_ENABLE); BGE_CLRBIT(sc, BGE_WDMA_MODE, BGE_WDMAMODE_ENABLE); - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) + if (!(BGE_IS_5705_OR_BEYOND(sc))) BGE_CLRBIT(sc, BGE_MBCF_MODE, BGE_MBCFMODE_ENABLE); CSR_WRITE_4(sc, BGE_FTQ_RESET, 0xFFFFFFFF); CSR_WRITE_4(sc, BGE_FTQ_RESET, 0); - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) { + if (!(BGE_IS_5705_OR_BEYOND(sc))) { BGE_CLRBIT(sc, BGE_BMAN_MODE, BGE_BMANMODE_ENABLE); BGE_CLRBIT(sc, BGE_MARB_MODE, BGE_MARBMODE_ENABLE); } @@ -3474,8 +3662,7 @@ bge_free_rx_ring_std(sc); /* Free jumbo RX list. */ - if (sc->bge_asicrev != BGE_ASICREV_BCM5705 && - sc->bge_asicrev != BGE_ASICREV_BCM5750) + if (BGE_IS_JUMBO_CAPABLE(sc)) bge_free_rx_ring_jumbo(sc); /* Free TX buffers. */ @@ -3589,11 +3776,11 @@ * the interrupt handler. * * XXX: perhaps link state detection procedure used for - * BGE_CHIPID_BCM5700_B1 can be used for others BCM5700 revisions. + * BGE_CHIPID_BCM5700_B2 can be used for others BCM5700 revisions. */ if (sc->bge_asicrev == BGE_ASICREV_BCM5700 && - sc->bge_chipid != BGE_CHIPID_BCM5700_B1) { + sc->bge_chipid != BGE_CHIPID_BCM5700_B2) { status = CSR_READ_4(sc, BGE_MAC_STS); if (status & BGE_MACSTAT_MI_INTERRUPT) { callout_stop(&sc->bge_stat_ch); Index: if_bgereg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v retrieving revision 1.48 diff -u -r1.48 if_bgereg.h --- if_bgereg.h 8 Jun 2006 09:35:02 -0000 1.48 +++ if_bgereg.h 8 Jun 2006 14:34:56 -0000 @@ -224,9 +224,12 @@ #define BGE_CHIPID_TIGON_I 0x40000000 #define BGE_CHIPID_TIGON_II 0x60000000 +#define BGE_CHIPID_BCM5700_A0 0x70000000 +#define BGE_CHIPID_BCM5700_A1 0x70010000 #define BGE_CHIPID_BCM5700_B0 0x71000000 -#define BGE_CHIPID_BCM5700_B1 0x71020000 -#define BGE_CHIPID_BCM5700_B2 0x71030000 +#define BGE_CHIPID_BCM5700_B1 0x71010000 +#define BGE_CHIPID_BCM5700_B2 0x71020000 +#define BGE_CHIPID_BCM5700_B3 0x71030000 #define BGE_CHIPID_BCM5700_ALTIMA 0x71040000 #define BGE_CHIPID_BCM5700_C0 0x72000000 #define BGE_CHIPID_BCM5701_A0 0x00000000 /* grrrr */ @@ -236,27 +239,44 @@ #define BGE_CHIPID_BCM5703_A0 0x10000000 #define BGE_CHIPID_BCM5703_A1 0x10010000 #define BGE_CHIPID_BCM5703_A2 0x10020000 +#define BGE_CHIPID_BCM5703_A3 0x10030000 #define BGE_CHIPID_BCM5704_A0 0x20000000 #define BGE_CHIPID_BCM5704_A1 0x20010000 #define BGE_CHIPID_BCM5704_A2 0x20020000 +#define BGE_CHIPID_BCM5704_A3 0x20030000 +#define BGE_CHIPID_BCM5704_B0 0x21000000 #define BGE_CHIPID_BCM5705_A0 0x30000000 #define BGE_CHIPID_BCM5705_A1 0x30010000 #define BGE_CHIPID_BCM5705_A2 0x30020000 #define BGE_CHIPID_BCM5705_A3 0x30030000 #define BGE_CHIPID_BCM5750_A0 0x40000000 #define BGE_CHIPID_BCM5750_A1 0x40010000 +#define BGE_CHIPID_BCM5750_A3 0x40030000 +#define BGE_CHIPID_BCM5750_B0 0x40100000 +#define BGE_CHIPID_BCM5750_B1 0x41010000 +#define BGE_CHIPID_BCM5750_C0 0x42000000 +#define BGE_CHIPID_BCM5750_C1 0x42010000 #define BGE_CHIPID_BCM5714_A0 0x50000000 +#define BGE_CHIPID_BCM5752_A0 0x60000000 +#define BGE_CHIPID_BCM5752_A1 0x60010000 +#define BGE_CHIPID_BCM5752_A2 0x60020000 +#define BGE_CHIPID_BCM5714_B0 0x80000000 +#define BGE_CHIPID_BCM5714_B3 0x80030000 +#define BGE_CHIPID_BCM5715_A0 0x90000000 +#define BGE_CHIPID_BCM5715_A1 0x90010000 /* shorthand one */ #define BGE_ASICREV(x) ((x) >> 28) -#define BGE_ASICREV_BCM5700 0x07 #define BGE_ASICREV_BCM5701 0x00 #define BGE_ASICREV_BCM5703 0x01 #define BGE_ASICREV_BCM5704 0x02 #define BGE_ASICREV_BCM5705 0x03 #define BGE_ASICREV_BCM5750 0x04 -#define BGE_ASICREV_BCM5714 0x05 +#define BGE_ASICREV_BCM5714_A0 0x05 #define BGE_ASICREV_BCM5752 0x06 +#define BGE_ASICREV_BCM5700 0x07 +#define BGE_ASICREV_BCM5780 0x08 +#define BGE_ASICREV_BCM5714 0x09 /* chip revisions */ #define BGE_CHIPREV(x) ((x) >> 24) @@ -1939,37 +1959,54 @@ #define BCOM_VENDORID 0x14E4 #define BCOM_DEVICEID_BCM5700 0x1644 #define BCOM_DEVICEID_BCM5701 0x1645 -#define BCOM_DEVICEID_BCM5702 0x16A6 -#define BCOM_DEVICEID_BCM5702X 0x16C6 -#define BCOM_DEVICEID_BCM5703 0x16A7 -#define BCOM_DEVICEID_BCM5703X 0x16C7 +#define BCOM_DEVICEID_BCM5702 0x1646 +#define BCOM_DEVICEID_BCM5702X 0x16A6 +#define BCOM_DEVICEID_BCM5702_ALT 0x16C6 +#define BCOM_DEVICEID_BCM5703 0x1647 +#define BCOM_DEVICEID_BCM5703X 0x16A7 +#define BCOM_DEVICEID_BCM5703_ALT 0x16C7 #define BCOM_DEVICEID_BCM5704C 0x1648 #define BCOM_DEVICEID_BCM5704S 0x16A8 +#define BCOM_DEVICEID_BCM5704S_ALT 0x1649 #define BCOM_DEVICEID_BCM5705 0x1653 #define BCOM_DEVICEID_BCM5705K 0x1654 -#define BCOM_DEVICEID_BCM5721 0x1659 +#define BCOM_DEVICEID_BCM5705F 0x166E #define BCOM_DEVICEID_BCM5705M 0x165D #define BCOM_DEVICEID_BCM5705M_ALT 0x165E #define BCOM_DEVICEID_BCM5714C 0x1668 +#define BCOM_DEVICEID_BCM5714S 0x1669 +#define BCOM_DEVICEID_BCM5715 0x1678 +#define BCOM_DEVICEID_BCM5715S 0x1679 +#define BCOM_DEVICEID_BCM5720 0x1658 +#define BCOM_DEVICEID_BCM5721 0x1659 #define BCOM_DEVICEID_BCM5750 0x1676 #define BCOM_DEVICEID_BCM5750M 0x167C #define BCOM_DEVICEID_BCM5751 0x1677 +#define BCOM_DEVICEID_BCM5751F 0x167E #define BCOM_DEVICEID_BCM5751M 0x167D #define BCOM_DEVICEID_BCM5752 0x1600 +#define BCOM_DEVICEID_BCM5752M 0x1601 +#define BCOM_DEVICEID_BCM5753 0x16F7 +#define BCOM_DEVICEID_BCM5753F 0x16FE +#define BCOM_DEVICEID_BCM5753M 0x16FD +#define BCOM_DEVICEID_BCM5780 0x166A +#define BCOM_DEVICEID_BCM5780S 0x166B +#define BCOM_DEVICEID_BCM5781 0x16DD #define BCOM_DEVICEID_BCM5782 0x1696 #define BCOM_DEVICEID_BCM5788 0x169C #define BCOM_DEVICEID_BCM5789 0x169D #define BCOM_DEVICEID_BCM5901 0x170D #define BCOM_DEVICEID_BCM5901A2 0x170E +#define BCOM_DEVICEID_BCM5903M 0x16FF /* * Alteon AceNIC PCI vendor/device ID. */ -#define ALT_VENDORID 0x12AE -#define ALT_DEVICEID_ACENIC 0x0001 -#define ALT_DEVICEID_ACENIC_COPPER 0x0002 -#define ALT_DEVICEID_BCM5700 0x0003 -#define ALT_DEVICEID_BCM5701 0x0004 +#define ALTEON_VENDORID 0x12AE +#define ALTEON_DEVICEID_ACENIC 0x0001 +#define ALTEON_DEVICEID_ACENIC_COPPER 0x0002 +#define ALTEON_DEVICEID_BCM5700 0x0003 +#define ALTEON_DEVICEID_BCM5701 0x0004 /* * 3Com 3c985 PCI vendor/device ID. @@ -2001,6 +2038,12 @@ #define DELL_VENDORID 0x1028 /* + * Apple PCI vendor ID. + */ +#define APPLE_VENDORID 0x106b +#define APPLE_DEVICE_BCM5701 0x1645 + +/* * Offset of MAC address inside EEPROM. */ #define BGE_EE_MAC_OFFSET 0x7C @@ -2372,7 +2415,6 @@ struct bge_type { uint16_t bge_vid; uint16_t bge_did; - char *bge_name; }; #define BGE_HWREV_TIGON 0x01 @@ -2404,6 +2446,7 @@ uint8_t bge_chiprev; uint8_t bge_no_3_led; uint8_t bge_pcie; + uint8_t bge_pcix; struct bge_ring_data bge_ldata; /* rings */ struct bge_chain_data bge_cdata; /* mbufs */ uint16_t bge_tx_saved_considx; --EVF5PPMfhYS0aIcm-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 21:29:32 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6032C16A4FD for ; Thu, 8 Jun 2006 17:53:07 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7446243D5D for ; Thu, 8 Jun 2006 17:52:55 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 06EC15133B; Thu, 8 Jun 2006 19:52:53 +0200 (CEST) Received: from localhost (dll43.neoplus.adsl.tpnet.pl [83.24.41.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 318F05131F for ; Thu, 8 Jun 2006 19:52:32 +0200 (CEST) Date: Thu, 8 Jun 2006 19:50:15 +0200 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20060608175015.GB89516@garage.freebsd.pl> References: <20060608132048.GD86198@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DKU6Jbt7q3WqK7+M" Content-Disposition: inline In-Reply-To: <20060608132048.GD86198@garage.freebsd.pl> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: *** X-Spam-Status: Yes, score=3.3 required=3.0 tests=BAYES_00,RCVD_IN_DSBL, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 X-Spam-Report: * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] * 2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [83.24.41.43 listed in dnsbl.sorbs.net] * 3.8 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org * [] * 0.1 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP * [83.24.41.43 listed in combined.njabl.org] Cc: Subject: Re: Data authentication for geli(8) committed to HEAD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 21:29:32 -0000 --DKU6Jbt7q3WqK7+M Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 08, 2006 at 03:20:49PM +0200, Pawel Jakub Dawidek wrote: +> Hi. +>=20 +> geli(8) from FreeBSD-CURRENT is not able to perform data integrity This should be: "...is NOW able to..." --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEiGNXForvXbEpPzQRAufCAJ4+94yKwWCjsqi5KUGQDlE6JiCYYwCeKdEC DbXiK6xOvHle4euUB1eRWpc= =Vmwv -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 21:29:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F45A16A76B; Thu, 8 Jun 2006 18:37:00 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04F5D43D45; Thu, 8 Jun 2006 18:36:59 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr7.xs4all.nl (8.13.6/8.13.6) with ESMTP id k58Iawn2024099; Thu, 8 Jun 2006 20:36:58 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.6/8.13.3) with ESMTP id k58IavCr026979; Thu, 8 Jun 2006 20:36:57 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.6/8.13.6/Submit) id k58IavTa026978; Thu, 8 Jun 2006 20:36:57 +0200 (CEST) (envelope-from wb) Date: Thu, 8 Jun 2006 20:36:57 +0200 From: Wilko Bulte To: Pawel Jakub Dawidek Message-ID: <20060608183657.GA26963@freebie.xs4all.nl> References: <20060608132048.GD86198@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060608132048.GD86198@garage.freebsd.pl> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@freebsd.org Subject: Re: Data authentication for geli(8) committed to HEAD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 21:29:58 -0000 On Thu, Jun 08, 2006 at 03:20:49PM +0200, Pawel Jakub Dawidek wrote.. > Hi. > > geli(8) from FreeBSD-CURRENT is not able to perform data integrity s/not/now/ :) > verification (data authentication) using one of the following > algorithms: > > - HMAC/MD5 > - HMAC/SHA1 > - HMAC/RIPEMD160 > - HMAC/SHA256 > - HMAC/SHA384 > - HMAC/SHA512 > -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 21:31:09 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D865316ABAC for ; Thu, 8 Jun 2006 17:11:04 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAB6043D7B for ; Thu, 8 Jun 2006 17:11:03 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by wx-out-0102.google.com with SMTP id i31so371302wxd for ; Thu, 08 Jun 2006 10:11:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S7lH1ETFoU6raN6aDQY2kBo7XZBFA8toxFO1R/JacGJFpDi2GUpRklJPDDE0c92NHPE7kgiMoVSyWDUYua1FOxnTKiIVYR1jgHebpr82qIBr8QXU1RsKhFAbATkpJGlQlLdpcpkVQrBIdbJVWPloDi6hFFQrvCmQsWzo4GwWxRs= Received: by 10.70.109.5 with SMTP id h5mr2288324wxc; Thu, 08 Jun 2006 10:11:02 -0700 (PDT) Received: by 10.70.36.8 with HTTP; Thu, 8 Jun 2006 10:11:02 -0700 (PDT) Message-ID: <47d0403c0606081011y5f610eb3h8eb8ac32f1a6bee0@mail.gmail.com> Date: Thu, 8 Jun 2006 17:11:02 +0000 From: "Ben Kaduk" To: current@freebsd.org In-Reply-To: <20060607195303.GA3225@roadrunner.q.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060607195303.GA3225@roadrunner.q.local> Cc: Subject: Re: [PATCH] Call for bfe(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 21:31:09 -0000 On 6/7/06, Ulrich Spoerlein wrote: > Hi, > > I investigated a bug/missing feature in the bfe(4) driver, which makes > it not see any LINK DOWN events unless you happen to invoke ifconfig. > > If you are running bfe hardware, *please* test the following (NO > PATCHING OR REBOOTING REQUIRED) > > 1. Plug in ethernet cable > 2. Watch dmesg/syslogd for the LINK UP message > 3. Remove the cable > 4. Do you see a LINK DOWN message? Does it appear after you issue > 'ifconfig'? > > Please run these simple steps and report back to me, if you get the LINK > DOWN message or not and which hardware you are running. For reference, > mine is a BCM4401, card=0x81271028 chip=0x440114e4 rev=0x01. > > If you want to give the patch a try, you are of course encouraged to do > so. > > Ulrich Spoerlein > -- > PGP Key ID: 20FEE9DD Encrypted mail welcome! > Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD > Which is worse: ignorance or apathy? > Don't know. Don't care. > > > Hi Ulrich, It appears that I have the same card as you, but I performed the simple test anyways (kernel recompile will have to wait until my ~5 hour computation finishes). The link up message appears automatically, but the link down message does not appear until I issue an ``ifconfig" command. pciconf -lv: bfe0@pci2:0:0: class=0x020000 card=0x81271028 chip=0x440114e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4401 10/100 Integrated Ethernet Controller' class = network subclass = ethernet I will hopefully give the patch a try in the next couple of days. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 21:31:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7603016AAF9 for ; Thu, 8 Jun 2006 18:15:09 +0000 (UTC) (envelope-from garyj@jennejohn.org) Received: from mail08a.verio.de (mail08a.verio.de [213.198.55.73]) by mx1.FreeBSD.org (Postfix) with SMTP id D511E43D58 for ; Thu, 8 Jun 2006 18:15:07 +0000 (GMT) (envelope-from garyj@jennejohn.org) Received: from mx32.stngva01.us.mxservers.net (204.202.242.10) by mail08a.verio.de (RS ver 1.0.95vs) with SMTP id 2-019655502; Thu, 8 Jun 2006 20:15:05 +0200 (CEST) Received: from www.jennejohn.org [213.198.5.174] (EHLO peedub.jennejohn.org) by mx32.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 62968844.21525.168.mx32.stngva01.us.mxservers.net; Thu, 08 Jun 2006 14:15:02 -0400 (EDT) Received: from jennejohn.org (localhost [127.0.0.1]) by peedub.jennejohn.org (8.13.4/8.11.6) with ESMTP id k58IF0sE007832; Thu, 8 Jun 2006 20:15:00 +0200 (CEST) (envelope-from garyj@jennejohn.org) Message-Id: <200606081815.k58IF0sE007832@peedub.jennejohn.org> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: Pawel Jakub Dawidek In-Reply-To: Message from Pawel Jakub Dawidek of "Thu, 08 Jun 2006 15:20:49 +0200." <20060608132048.GD86198@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Jun 2006 20:15:00 +0200 From: Gary Jennejohn X-Spam: [F=0.3844947881; heur=0.500(-19800); stat=0.384; spamtraq-heur=0.500(2006060714)] X-MAIL-FROM: X-SOURCE-IP: [213.198.5.174] X-Loop-Detect: 1 X-DistLoop-Detect: 1 Cc: freebsd-current@FreeBSD.org Subject: Re: Data authentication for geli(8) committed to HEAD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 21:31:39 -0000 Pawel Jakub Dawidek writes: > geli(8) from FreeBSD-CURRENT is not able to perform data integrity ^^^ you obviously meant to write "now" > verification (data authentication) using one of the following > algorithms: > [snip] --- Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg garyjATdenxDOTde From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 21:32:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5C7616DCF2 for ; Thu, 8 Jun 2006 18:10:29 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADEA043D4C for ; Thu, 8 Jun 2006 18:10:26 +0000 (GMT) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id c31so384836nfb for ; Thu, 08 Jun 2006 11:10:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=Cf8DQExhnIKIpPecm7rYaFUT4EIfM4Im+Yq2wql+XreVcxaiYzf5VyYAaTcmZtsA3MOccL6PEM4X/NQ2UJJr0xPxarEYaWnC9pl2IXItmAcDm86rODqvXipo5h6oTi7cVpBsUofo6LbfcBy+GgEQKpZuVyLtG9Z93riQ7im3rYQ= Received: by 10.49.7.1 with SMTP id k1mr1587281nfi; Thu, 08 Jun 2006 11:10:23 -0700 (PDT) Received: from roadrunner.q.local ( [217.185.114.19]) by mx.gmail.com with ESMTP id p45sm2350999nfa.2006.06.08.11.10.17; Thu, 08 Jun 2006 11:10:22 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.6/8.13.6) with ESMTP id k58IALrN003592; Thu, 8 Jun 2006 20:10:21 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.6/8.13.6/Submit) id k58HfDKR003156; Thu, 8 Jun 2006 19:41:13 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Thu, 8 Jun 2006 19:41:13 +0200 From: Ulrich Spoerlein To: Pawel Jakub Dawidek Message-ID: <20060608174113.GC1075@roadrunner.q.local> Mail-Followup-To: Pawel Jakub Dawidek , freebsd-current@FreeBSD.org References: <20060608132048.GD86198@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8NvZYKFJsRX2Djef" Content-Disposition: inline In-Reply-To: <20060608132048.GD86198@garage.freebsd.pl> Cc: freebsd-current@FreeBSD.org Subject: Re: Data authentication for geli(8) committed to HEAD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 21:32:12 -0000 --8NvZYKFJsRX2Djef Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Pawel Jakub Dawidek wrote: > One of the main design goals was to make it reliable and resistant to > power failures or system crashes. This was very important to commit both > data update and HMAC update as an atomic operation to the disk, so users > don't have to fight with false positives. Great stuff. I take this opportunity to hijack this thread and ask I question that has been bothering me a long time now. I have an external HDD that I initially attached via Firewire, but I've since switched to USB, as our firewire subsystem is less than rock solid. When configuring geli encryption on the drive, I made the folly of using 4kB sectors, as this should improve performance. But, it has a disastrous impact on data integrity if your system crashes. Now, I don't know if I'm right with the following thoughts, so please correct me if I'm wrong. Consider an mtime or atime update. You need to update 4 bytes on the disk, which will be accomplished by writes of 512 bytes. If the system crashes in between (I'm not talking about power failures), the disk has either updated the 512 bytes, or not. No harm done. With 4096 byte sectors and unencrypted data, the hard disk will have written/updated 512 or 1024, ... or the whole 4096 bytes. Since only 4 bytes needed to be changed, you either got these changes or not. No harm done. Now consider encryption with 4096 byte sectors. Whenever you twiddle one bit, the whole 4096 byte sector changes completely. To leave the disk in a consistent state, you always have to make sure, that the whole 8 512-byte blocks are written to disk. If only a single 512-byte block is not updated (due to kernel crashing because of that !@#^#$@ firewire), the whole 4096 are useless. SoL. The question really is, are 512 byte disk writes considered to be some kind of "atomic" as it is the smallest disk block size? What does the ATA subsystem do with writes of 4096? Are they completed atomically too, or not? Due to various kernel panics (no power failures involved!) I lost several blocks of inodes on a 4096 byte sector geli mount. It's really no fun, if fsck tells you that inodes 102340 - 109329 are lost. Please note that I'm not asking any action from you, I'd simply appreciated it, if someone could confirm or dispute my claims. Thanks. Ulrich Spoerlein --=20 PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. --8NvZYKFJsRX2Djef Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEiGE4524iJyD+6d0RAnDSAJ93ssmz6IU/ReSzpA8YHS2XcV9P9gCfZC76 HNFrXDfLTN5IUh7NSYp3L1k= =9NE1 -----END PGP SIGNATURE----- --8NvZYKFJsRX2Djef-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 21:53:33 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8F5616A8C9 for ; Thu, 8 Jun 2006 21:53:33 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.FreeBSD.org (Postfix) with SMTP id E29C7441C9 for ; Thu, 8 Jun 2006 19:05:25 +0000 (GMT) (envelope-from ale@FreeBSD.org) Received: (qmail 361 invoked from network); 8 Jun 2006 19:05:08 -0000 Received: from unknown (HELO ?192.168.178.2?) (a.premoli@andxor.it@81.174.31.42) by andxor.it with SMTP; 8 Jun 2006 19:05:08 -0000 Message-ID: <448874E4.6080806@FreeBSD.org> Date: Thu, 08 Jun 2006 21:05:08 +0200 From: Alex Dupre User-Agent: Mozilla Thunderbird 1.5.0.4 (X11/20060605) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20060608132048.GD86198@garage.freebsd.pl> In-Reply-To: <20060608132048.GD86198@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Data authentication for geli(8) committed to HEAD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 21:53:34 -0000 Pawel Jakub Dawidek ha scritto: > geli(8) from FreeBSD-CURRENT is not able to perform data integrity __________________________________^^^ 'now' should be more correct ;-) -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 22:09:36 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B87BE16A521 for ; Thu, 8 Jun 2006 22:09:36 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 426C943D48 for ; Thu, 8 Jun 2006 22:09:36 +0000 (GMT) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 7B09078C1D; Thu, 8 Jun 2006 20:52:54 +0000 (GMT) Date: Thu, 8 Jun 2006 20:52:54 +0000 From: John Birrell To: "R. Tyler Ballance" Message-ID: <20060608205254.GB38400@what-creek.com> References: <20060608073823.GA34193@what-creek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: DTrace for FreeBSD- source snapshots X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 22:09:36 -0000 On Thu, Jun 08, 2006 at 08:41:17AM -0500, R. Tyler Ballance wrote: > Presumably since it's from Sun, it'll run on the FreeBSD/sparc64 > machines as well? ;) I don't have access to anything other than single processor i386 machines at the moment. That is about to change. I'll say more about that soon. 8-) > Unfortunately, I don't have anything but i386 machines here (not > counting a Powerbook), but how portable is this code? Can anybody > verify it'll work on FreeBSD/amd64? mips? arm? leg? Sun's code has amd64 support in it. I haven't ported that because I don't have a machine that I can test on. And since the port involves crashing the OS a LOT, I need to be able to have a serial console and the ability to power the machine down many times per hour. -- John Birrell From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 22:14:49 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 212C716A41F for ; Thu, 8 Jun 2006 22:14:49 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.FreeBSD.org (Postfix) with SMTP id A600A43D4C for ; Thu, 8 Jun 2006 22:14:47 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 15700 invoked by uid 399); 8 Jun 2006 21:14:47 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 8 Jun 2006 21:14:47 -0000 Message-ID: <44889345.8030800@FreeBSD.org> Date: Thu, 08 Jun 2006 14:14:45 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.4 (X11/20060604) MIME-Version: 1.0 To: Eric Anderson References: <44871F58.4070707@FreeBSD.org> <448777B5.8040100@centtech.com> In-Reply-To: <448777B5.8040100@centtech.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problem with nvidia drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 22:14:49 -0000 Eric Anderson wrote: > Doug Barton wrote: >> With the latest -current and the nvidia drivers, either xorg or wdm dump >> core on a semi-regular basis. Is this expected? I've already tried >> disabling >> witness and invariants in my kernel config. >> >> Doug >> > > > Try the one from their website, not the one in ports. Do you mean the latest version from their web site? I have that installed through ports (which was recently updated) now. Or do you mean install it without using ports? > It gave me better > stability, but I ended up moving to the nv driver anyhow. You could > search the lists for my posts to see the trials and tribulations if > you'd like (if you can't find it, let me know). Ok, thanks. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 22:22:50 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 688F616A827 for ; Thu, 8 Jun 2006 22:22:50 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.FreeBSD.org (Postfix) with SMTP id A70A143D4C for ; Thu, 8 Jun 2006 22:22:49 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 22347 invoked by uid 399); 8 Jun 2006 21:22:47 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 8 Jun 2006 21:22:47 -0000 Message-ID: <44889524.3030600@FreeBSD.org> Date: Thu, 08 Jun 2006 14:22:44 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.4 (X11/20060604) MIME-Version: 1.0 To: Chuck Swiger References: <20060608015022.Y52876@mp2.macomnet.net> <448799B6.8080709@mac.com> In-Reply-To: <448799B6.8080709@mac.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: named recursive queries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 22:22:50 -0000 Chuck Swiger wrote: > It seems clear that people who want to run a recursive nameserver will > be able to change this if your proposed change is made. However, which > problem that you are trying to solve with it? Well, having a wide open anything on the network is pretty much a bad idea nowadays. While the current press surrounding the open resolver DDoS problem is drawing attention to this particular part of the issue, it's bad for us to start what is supposed to be a local resolver in wide open mode in any case. (Which, as I pointed out already, is not what we are doing.) > Yes, people can send queries with a spoofed sender to perform a DoS, and > yes, permitting recursive queries lets the attacker choose a large > response from any zone rather than having to tailor the attack to each > nameserver. Yes, that is one variant of the attack that we're trying to mitigate. > The right solution to that problem is egress filtering of spoofed > traffic at the ISP-level. Yes, but long years of history (not to mention the obvious economic incentive) have shown that this will not happen. Therefore we need to attack this problem directly, using available mechanisms. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 23:53:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C90F16A4AC for ; Thu, 8 Jun 2006 23:53:52 +0000 (UTC) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E06843D70 for ; Thu, 8 Jun 2006 23:53:29 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw501.dsto.defence.gov.au (ednmsw501.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id k58NpUMQ000923 for ; Fri, 9 Jun 2006 09:21:30 +0930 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw501.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Fri, 9 Jun 2006 09:23:21 +0930 Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au [131.185.2.170]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id k58NnC712631 for ; Fri, 9 Jun 2006 09:19:12 +0930 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC (6.0.3790.1830); Fri, 9 Jun 2006 09:19:12 +0930 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.13.3/8.13.3) with ESMTP id k58Nm5vF057408 for ; Fri, 9 Jun 2006 09:18:05 +0930 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.13.3/8.13.3/Submit) id k58Nm5nZ057407 for freebsd-current@freebsd.org; Fri, 9 Jun 2006 09:18:05 +0930 (CST) (envelope-from wilkinsa) Date: Fri, 9 Jun 2006 09:18:05 +0930 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20060608234805.GM40068@squash.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20060606071736.J68996@fledge.watson.org> <20060606073436.GK27880@squash.dsto.defence.gov.au> <20060606090919.U68996@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20060606090919.U68996@fledge.watson.org> User-Agent: Mutt/1.5.11 X-OriginalArrivalTime: 08 Jun 2006 23:49:12.0214 (UTC) FILETIME=[247B3360:01C68B56] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-3.52.1006-14494.003 X-TM-AS-Result: No--2.890000-0.000000-31 Subject: Re: libmemstat(3) - Library for monitoring kernel memory use X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 23:53:52 -0000 0n Tue, Jun 06, 2006 at 09:11:10AM +0100, Robert Watson wrote: > >On Tue, 6 Jun 2006, Wilkinson, Alex wrote: > >> 0n Tue, Jun 06, 2006 at 07:20:39AM +0100, Robert Watson wrote: >> >> > >> >On Tue, 6 Jun 2006 bhuvan.kumarmital@wipro.com wrote: >> > >> >> Saw your tool (memtop) for monitoring kernel memory. I'd like to >> use a >> >>similar tool for linux, i believe your tool is bsd based. Could you >> tell >> >>me a similar tool, or perhaps another version of memtop built for >> linux. >> >>I'd really appreciate you help. Please reply on my email address. >> > >> >You are correct that libmemstat and derived tools currently rely on >> >features present in the FreeBSD kernel. The library provides a general >> >monitoring abstraction over a set of specific kernel memory allocators >> -- >> >specifically, the FreeBSD malloc(9) and uma(9) allocators. It is >> >relatively straight forward to implement that abstraction for other >> memory >> >allocators, such as user space allocators or kernel allocators from >> other >> >platforms, but that work has not been done (as far as I know). I'm not >> >aware of specific monitoring tools for the Linux operating system that >> are >> >able to perform this type of profiling/monitoring, although I presume >> some >> >sort of kernel memory profiling tool does exist. >> >>Erm, Robert, where does memtop live ? I can find it in ports nor base >>system. > >memtop is an experimental monitoring tool based on libmemstat, you can find >the source here: > > http://www.watson.org/~robert/freebsd/libmemstat/ > >Possibly something like this could be integrated into systat, but my >ncurses knowledge is a bit weak, and I've not had a chance to investigate >further. As with vmstat, the interpretation of the output requires a >moderate amount of insight into how the kernel works, so I've been a bit >reluctant to push it as a debugging tool without some more refinement. I >think it would be neat if someone picked it up and did something useful >with it, though :-). I assume this only works with -CURRENT ? -aW From owner-freebsd-current@FreeBSD.ORG Thu Jun 8 23:52:24 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD29A16A4C9 for ; Thu, 8 Jun 2006 23:52:24 +0000 (UTC) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D7E343DA5 for ; Thu, 8 Jun 2006 23:51:44 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id B2E0CF280E for ; Thu, 8 Jun 2006 16:51:32 -0700 (PDT) X-Virus-Scanned: by amavisd-new at mcneil.com Received: from mail.mcneil.com ([127.0.0.1]) by localhost (triton.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9AnO3d5TSuN for ; Thu, 8 Jun 2006 16:51:31 -0700 (PDT) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 12885F1AF9 for ; Thu, 8 Jun 2006 16:51:31 -0700 (PDT) From: Sean McNeil To: current@freebsd.org Content-Type: text/plain Date: Thu, 08 Jun 2006 16:51:30 -0700 Message-Id: <1149810690.2642.11.camel@triton.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 09 Jun 2006 00:02:29 +0000 Cc: Subject: bugus rc.conf.d locations recently committed to -STABLE? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2006 23:52:24 -0000 I am now having difficulty with bringup on my -STABLE system. I get what looks like bogus warnings: root: /etc/rc: WARNING: Warning: /etc/rc.conf.d/ntpdate is deprecated, please use /etc/rc/etc/rc.conf.d/ntpdate instead. and root: /etc/rc: WARNING: Warning: /etc/rc.conf.d/sendmail is deprecated, please use /etc/rc/etc/rc.conf.d/sendmail instead. but this doesn't make sense and is impossible as /etc/rc is a regular file, not a directory. There were warnings for /usr/local and /usr/X11R6 to go into /usr/local/etc/rc.conf.d and /usr/X11R6/etc/rc.conf.d. These make sense. They correspond to /etc/rc.d and /etc/rc.conf.d. Also, I have port cyrus-imapd-2.2.13_2 and it installs /usr/local/etc/rc.d/imap. This script has an internal name of "cyrus_imap", but instead of wanting /usr/local/etc/rc.conf.d/cyrus_imap as would be the completely logical place for it, I have to place it in /usr/local/cyrus/etc/rc.conf.d/cyrus_imapd. Seems like it bases the location upon where the binary is as opposed to where the rc script is. Same thing happens with slapd. I told it to put the rc script in /etc/rc.d/slapd when I configured the port. But it warns me that it wants the rc.conf.d in /usr/local/libexec/slapd/etc/rc.conf.d/slapd. This is very counter intuitive to me. What is the logic behind this and why was it MFCd in a non-working condition? Like I said, many of my daemons did not start even though I could start them by running the script by hand. So I'm guessing that maybe rcorder isn't working with this new configuration. From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 00:31:16 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AA4F16A418 for ; Fri, 9 Jun 2006 00:31:16 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED26343D45 for ; Fri, 9 Jun 2006 00:31:15 +0000 (GMT) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id 1D89233C03; Fri, 9 Jun 2006 02:31:14 +0200 (CEST) Date: Fri, 9 Jun 2006 02:31:14 +0200 From: Lars Engels To: current@freebsd.org Message-ID: <20060609003113.GD61348@e.0x20.net> References: <20060607195303.GA3225@roadrunner.q.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K/NRh952CO+2tg14" Content-Disposition: inline In-Reply-To: <20060607195303.GA3225@roadrunner.q.local> X-Editor: VIM - Vi IMproved 6.4 User-Agent: Mutt/1.5.11 X-Mailman-Approved-At: Fri, 09 Jun 2006 00:57:38 +0000 Cc: Subject: Re: [PATCH] Call for bfe(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 00:31:16 -0000 --K/NRh952CO+2tg14 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Ulrich, On Wed, Jun 07, 2006 at 09:53:03PM +0200, Ulrich Spoerlein wrote: > Hi, >=20 > I investigated a bug/missing feature in the bfe(4) driver, which makes > it not see any LINK DOWN events unless you happen to invoke ifconfig. I do not have this problem with my bfe NIC and it always worked here. > If you are running bfe hardware, *please* test the following (NO > PATCHING OR REBOOTING REQUIRED) >=20 > 1. Plug in ethernet cable > 2. Watch dmesg/syslogd for the LINK UP message > 3. Remove the cable > 4. Do you see a LINK DOWN message? Does it appear after you issue > 'ifconfig'? Jun 9 01:49:11 bart kernel: bfe0: link state changed to DOWN Jun 9 01:49:14 bart kernel: bfe0: link state changed to UP > Please run these simple steps and report back to me, if you get the LINK > DOWN message or not and which hardware you are running. For reference, > mine is a BCM4401, card=3D0x81271028 chip=3D0x440114e4 rev=3D0x01. bfe0@pci2:5:0: class=3D0x020000 card=3D0x108217c0 chip=3D0x440114e4 rev=3D= 0x01 hdr=3D0x00 vendor =3D 'Broadcom Corporation' device =3D 'BCM4401 10/100 Integrated Ethernet Controller' So it is a different card but the same chip and revision. The system is a FreeBSD 7.0-CURRENT with sources from last weekend. I just applied your patch and it does still work for me, so if the patch wo= rks=20 for you, we can both be happy :) Lars --K/NRh952CO+2tg14 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEiMFRKc512sD3afgRAvphAJ0XyMBvjCTI/vP2ehlP/4JLSKEC8gCeJkTO GRWPjMS/7NZIvLTMQZQ/MNM= =zpH1 -----END PGP SIGNATURE----- --K/NRh952CO+2tg14-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 01:20:59 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C15A16A419; Fri, 9 Jun 2006 01:20:59 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53D4B43DA8; Fri, 9 Jun 2006 01:20:33 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.80] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.6/8.13.6) with ESMTP id k591KUTQ044693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jun 2006 18:20:32 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <4488CCC7.4040500@FreeBSD.org> Date: Thu, 08 Jun 2006 18:20:07 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Pawel Jakub Dawidek , freebsd-current@FreeBSD.org References: <20060608132048.GD86198@garage.freebsd.pl> <20060608174113.GC1075@roadrunner.q.local> In-Reply-To: <20060608174113.GC1075@roadrunner.q.local> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Data authentication for geli(8) committed to HEAD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 01:20:59 -0000 That's kinda of hard problem with any software-based disk block data encryption. Higher layers (UFS for example) expect one-sector writes to be atomic, so that there are basically 3 possibilities: 1. Stick with 512-bytes encrypted sector size. Not very good for performance reasons and possibly security reasons. Is not even possible in the cases when each write of one encrypted sector must also update some metadata (e.g. geom). 2. Live with the possibility that an unexpected system crash can leave the filesystem system in the unrecoverable state. My own experience with geom, which exploits this approach, however suggests that the chance is pretty slim even when actively used filesystem (PostgreSQL DB in my case) is placed on top of encrypted disk. 3. Implement some kind of sector-level journaling, again the performance is likely to suffer a great deal due to seeks. -Maxim Ulrich Spoerlein wrote: > Pawel Jakub Dawidek wrote: >> One of the main design goals was to make it reliable and resistant to >> power failures or system crashes. This was very important to commit both >> data update and HMAC update as an atomic operation to the disk, so users >> don't have to fight with false positives. > > Great stuff. I take this opportunity to hijack this thread and ask I > question that has been bothering me a long time now. > > I have an external HDD that I initially attached via Firewire, but I've > since switched to USB, as our firewire subsystem is less than rock > solid. When configuring geli encryption on the drive, I made the folly > of using 4kB sectors, as this should improve performance. But, it has a > disastrous impact on data integrity if your system crashes. > > Now, I don't know if I'm right with the following thoughts, so please > correct me if I'm wrong. > > Consider an mtime or atime update. You need to update 4 bytes on the > disk, which will be accomplished by writes of 512 bytes. If the system > crashes in between (I'm not talking about power failures), the disk has > either updated the 512 bytes, or not. No harm done. > > With 4096 byte sectors and unencrypted data, the hard disk will have > written/updated 512 or 1024, ... or the whole 4096 bytes. Since only 4 > bytes needed to be changed, you either got these changes or not. No harm > done. > > Now consider encryption with 4096 byte sectors. Whenever you twiddle one > bit, the whole 4096 byte sector changes completely. To leave the disk in > a consistent state, you always have to make sure, that the whole 8 > 512-byte blocks are written to disk. If only a single 512-byte block is > not updated (due to kernel crashing because of that !@#^#$@ firewire), > the whole 4096 are useless. SoL. > > The question really is, are 512 byte disk writes considered to be some > kind of "atomic" as it is the smallest disk block size? What does the > ATA subsystem do with writes of 4096? Are they completed atomically too, > or not? > > Due to various kernel panics (no power failures involved!) I lost > several blocks of inodes on a 4096 byte sector geli mount. It's really > no fun, if fsck tells you that inodes 102340 - 109329 are lost. > > Please note that I'm not asking any action from you, I'd simply > appreciated it, if someone could confirm or dispute my claims. Thanks. > > Ulrich Spoerlein From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 02:18:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BABB16A494; Fri, 9 Jun 2006 02:18:19 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from groat.ugcs.caltech.edu (groat.ugcs.caltech.edu [131.215.176.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id E619543D8B; Fri, 9 Jun 2006 02:18:18 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by groat.ugcs.caltech.edu (Postfix, from userid 3640) id 398945880B; Thu, 8 Jun 2006 19:18:18 -0700 (PDT) Date: Thu, 8 Jun 2006 19:18:18 -0700 From: Paul Allen To: Maxim Sobolev Message-ID: <20060609021818.GH28128@groat.ugcs.caltech.edu> References: <20060608132048.GD86198@garage.freebsd.pl> <20060608174113.GC1075@roadrunner.q.local> <4488CCC7.4040500@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4488CCC7.4040500@FreeBSD.org> Sender: jd@ugcs.caltech.edu Cc: freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: Data authentication for geli(8) committed to HEAD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 02:18:19 -0000 >From Maxim Sobolev , Thu, Jun 08, 2006 at 06:20:07PM -0700: > 3. Implement some kind of sector-level journaling, again the performance > is likely to suffer a great deal due to seeks. Right. This is certainly a case where background fsck is useless and much of the theory of softupdates generally is wrong. Just one more nail to seal the fate of softupdates. Paul From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 02:45:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CF7516A41A; Fri, 9 Jun 2006 02:45:57 +0000 (UTC) (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 9A19C43D92; Fri, 9 Jun 2006 02:45:55 +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 k592jgCe095913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jun 2006 12:15:43 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Fri, 9 Jun 2006 12:15:33 +0930 User-Agent: KMail/1.9.3 References: <20060608132048.GD86198@garage.freebsd.pl> <20060608174113.GC1075@roadrunner.q.local> In-Reply-To: <20060608174113.GC1075@roadrunner.q.local> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1722409.6Rlg8ajgsb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606091215.41787.doconnor@gsoft.com.au> X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 203.31.81.10 Cc: Pawel Jakub Dawidek Subject: Re: Data authentication for geli(8) committed to HEAD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 02:45:57 -0000 --nextPart1722409.6Rlg8ajgsb Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 09 June 2006 03:11, Ulrich Spoerlein wrote: > I have an external HDD that I initially attached via Firewire, but I've > since switched to USB, as our firewire subsystem is less than rock Interesting. I find the reverse :) Then again I started using Firewire in 4.x where USB2.0 didn't exist and th= e=20 USB 1 code was kind of dodgy. > The question really is, are 512 byte disk writes considered to be some > kind of "atomic" as it is the smallest disk block size? What does the > ATA subsystem do with writes of 4096? Are they completed atomically too, > or not? I think that in reality with a modern high capacity disk you don't get atom= ic=20 writes at all because they all re-write whole tracks. Yes this violates the assumption soft updates makes, I believe the only way= =20 around it is to buy SCSI drives (not because they're SCSI per se, but becau= se=20 they're smaller capacity so they don't do this) =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 --nextPart1722409.6Rlg8ajgsb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEiODV5ZPcIHs/zowRAvnRAKCdbFsjpBtt0pzvmA2F6VZyQb7ElQCcDk6v K+pSiJ69ThtEBj5EcWABh9U= =KYEN -----END PGP SIGNATURE----- --nextPart1722409.6Rlg8ajgsb-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 03:21:44 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A05D816A41B for ; Fri, 9 Jun 2006 03:21:44 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94AD743D7B for ; Fri, 9 Jun 2006 03:21:41 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1132488ugc for ; Thu, 08 Jun 2006 20:21:40 -0700 (PDT) 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=IUXdg7xAz0HfXnu0aUpOj4D+JdT9Xlhh6eqC/tH5AKLoRbNXuqYKNy/LZNeq9A09zTbwFE5e3/jgiAzC+R0z7n9YDv2gJ1Wdr3jAZXGliV1P8mavpgfrzYO8uPu77t0MSfVHcsMsnxsBi2HSC/pxlBv4jw7fskesDEB93E+XFzo= Received: by 10.78.23.16 with SMTP id 16mr752052huw; Thu, 08 Jun 2006 20:15:32 -0700 (PDT) Received: by 10.78.71.19 with HTTP; Thu, 8 Jun 2006 20:15:31 -0700 (PDT) Message-ID: <84dead720606082015i3631f179v4da9ea76b7e0712@mail.gmail.com> Date: Fri, 9 Jun 2006 08:45:31 +0530 From: "Joseph Koshy" To: "Sean McNeil" In-Reply-To: <1149810690.2642.11.camel@triton.mcneil.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149810690.2642.11.camel@triton.mcneil.com> Cc: current@freebsd.org Subject: Re: bugus rc.conf.d locations recently committed to -STABLE? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 03:21:44 -0000 > I am now having difficulty with bringup on my -STABLE system. > I get what looks like bogus warnings: Which -STABLE? Which architecture? -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 04:29:35 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6814D16A41A for ; Fri, 9 Jun 2006 04:29:35 +0000 (UTC) (envelope-from boris@brooknet.com.au) Received: from jay.exetel.com.au (jay.exetel.com.au [220.233.0.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E3ED43D73 for ; Fri, 9 Jun 2006 04:29:33 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: (qmail 9551 invoked by uid 507); 9 Jun 2006 14:29:32 +1000 Received: from 180.205.233.220.exetel.com.au (HELO ?192.168.0.157?) (220.233.205.180) by jay.exetel.com.au with SMTP; 9 Jun 2006 14:29:32 +1000 Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <20060608073823.GA34193@what-creek.com> References: <20060608073823.GA34193@what-creek.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1903E996-3617-419E-8BA9-A3F0F9F3AFD1@brooknet.com.au> Content-Transfer-Encoding: 7bit From: Sam Lawrance Date: Fri, 9 Jun 2006 14:29:25 +1000 To: John Birrell , current@freebsd.org X-Mailer: Apple Mail (2.750) Cc: Subject: FreeBSD-current installer ISO with DTrace (was: Re: DTrace for FreeBSD- source snapshots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 04:29:35 -0000 On 08/06/2006, at 5:38 PM, John Birrell wrote: > Since the Slashdot article 06/05/29/1144234.shtml> > and my last status update here, I've had numerous requests for > access to the > development sources for the DTrace port to FreeBSD. > > I had hoped to get the DTrace P4 project exported to CVS and then > to a CVSup > server, but that doesn't seem to be possible. The FreeBSD P4 admins > who can set > this up haven't responded to my emails. Sulk. > > The best that I can do at the moment is to make a tar-ball > containing the > entire FreeBSD-current source tree available for download. You can > get it from > > > There is also a link on that page to a diff of the changed files > and another > tar-ball of the added files in case you want to just look. > > You should regard this as pre-alpha quality. It's still a work-in- > progress. > It can crash your system and/or ruin your day. Don't ask me how I > know. 8-) > > The source tree will build on an i386 RELENG_6 machine (or a > current one) using a > standard 'buildworld'. The 'buildkernel' step will need to be: > 'make NO_CTF=1 buildkernel' at the moment due to the fact that the > buildkernel > phase doesn't seem to use the bootstrapped tools. That's a problem > that someone > could work on. Hint. 8-) > > If there is someone with a bit of spare time on their hands, I'd > like an install > ISO to be built using 'make release'. And someone else might care > to work on > producing a live CD using FreeSBIE . That would > be useful > too. An installer ISO for FreeBSD-current (June 8) with John's DTrace work is available here: http://people.freebsd.org/~lawrance/7-CURRENT-jb-dtrace-i386- disc1.iso.bz2 If you are curious to try it but don't want to install -current, you may be able to try it from the Fixit shell. For example: Fixit# kldconfig /dist/boot/kernel Fixit# kldload dtrace systrace profile fbt Fixit# dtrace -n 'open:entry{@[copyinstr(arg0)] = count()}' & Fixit# kill `jobid %1` From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 04:38:11 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE68116A418 for ; Fri, 9 Jun 2006 04:38:11 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id A65FE43D70 for ; Fri, 9 Jun 2006 04:38:11 +0000 (GMT) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 4537878C1D; Fri, 9 Jun 2006 04:38:09 +0000 (GMT) Date: Fri, 9 Jun 2006 04:38:08 +0000 From: John Birrell To: Sam Lawrance Message-ID: <20060609043808.GA42333@what-creek.com> References: <20060608073823.GA34193@what-creek.com> <1903E996-3617-419E-8BA9-A3F0F9F3AFD1@brooknet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1903E996-3617-419E-8BA9-A3F0F9F3AFD1@brooknet.com.au> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: FreeBSD-current installer ISO with DTrace (was: Re: DTrace for FreeBSD- source snapshots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 04:38:12 -0000 On Fri, Jun 09, 2006 at 02:29:25PM +1000, Sam Lawrance wrote: > Fixit# kldload dtrace systrace profile fbt kldload cyclic dtrace systrace profile fbt The 'dtrace' module depends on 'cyclic'. The next update wil have a boot loader menu item to load the modules in the right order. -- John Birrell From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 04:43:23 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FD4B16A418 for ; Fri, 9 Jun 2006 04:43:23 +0000 (UTC) (envelope-from boris@brooknet.com.au) Received: from jay.exetel.com.au (jay.exetel.com.au [220.233.0.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEAD643D72 for ; Fri, 9 Jun 2006 04:43:22 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: (qmail 15682 invoked by uid 507); 9 Jun 2006 14:43:21 +1000 Received: from 180.205.233.220.exetel.com.au (HELO ?192.168.0.157?) (220.233.205.180) by jay.exetel.com.au with SMTP; 9 Jun 2006 14:43:21 +1000 In-Reply-To: <20060609043808.GA42333@what-creek.com> References: <20060608073823.GA34193@what-creek.com> <1903E996-3617-419E-8BA9-A3F0F9F3AFD1@brooknet.com.au> <20060609043808.GA42333@what-creek.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sam Lawrance Date: Fri, 9 Jun 2006 14:43:14 +1000 To: John Birrell X-Mailer: Apple Mail (2.750) Cc: current@freebsd.org Subject: Re: FreeBSD-current installer ISO with DTrace (was: Re: DTrace for FreeBSD- source snapshots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 04:43:23 -0000 On 09/06/2006, at 2:38 PM, John Birrell wrote: > On Fri, Jun 09, 2006 at 02:29:25PM +1000, Sam Lawrance wrote: >> Fixit# kldload dtrace systrace profile fbt > > kldload cyclic dtrace systrace profile fbt > > The 'dtrace' module depends on 'cyclic'. > > The next update wil have a boot loader menu item to load the modules > in the right order. cyclic was loaded automagically when I tested it. From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 04:08:46 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C48616A418 for ; Fri, 9 Jun 2006 04:08:46 +0000 (UTC) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0098143D72 for ; Fri, 9 Jun 2006 04:08:45 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 97240F287F; Thu, 8 Jun 2006 21:08:45 -0700 (PDT) X-Virus-Scanned: by amavisd-new at mcneil.com Received: from mail.mcneil.com ([127.0.0.1]) by localhost (triton.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDDEDWy8vmaL; Thu, 8 Jun 2006 21:08:44 -0700 (PDT) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id C6AB7F1AF9; Thu, 8 Jun 2006 21:08:44 -0700 (PDT) From: Sean McNeil To: Joseph Koshy In-Reply-To: <84dead720606082015i3631f179v4da9ea76b7e0712@mail.gmail.com> References: <1149810690.2642.11.camel@triton.mcneil.com> <84dead720606082015i3631f179v4da9ea76b7e0712@mail.gmail.com> Content-Type: text/plain Date: Thu, 08 Jun 2006 21:08:44 -0700 Message-Id: <1149826124.3548.1.camel@triton.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 09 Jun 2006 04:47:04 +0000 Cc: current@freebsd.org Subject: Re: bugus rc.conf.d locations recently committed to -STABLE? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 04:08:46 -0000 On Fri, 2006-06-09 at 08:45 +0530, Joseph Koshy wrote: > > I am now having difficulty with bringup on my -STABLE system. > > I get what looks like bogus warnings: > > Which -STABLE? Which architecture? > FreeBSD triton.mcneil.com 6.1-STABLE FreeBSD 6.1-STABLE #17: Thu Jun 8 13:18:19 PDT 2006 root@triton.mcneil.com:/usr/obj/usr/src/sys/TRITON amd64 From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 04:53:42 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9329816A41F for ; Fri, 9 Jun 2006 04:53:42 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DBFC43D8E for ; Fri, 9 Jun 2006 04:53:37 +0000 (GMT) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id B154778C1D; Fri, 9 Jun 2006 04:53:35 +0000 (GMT) Date: Fri, 9 Jun 2006 04:53:35 +0000 From: John Birrell To: Sam Lawrance Message-ID: <20060609045335.GA42431@what-creek.com> References: <20060608073823.GA34193@what-creek.com> <1903E996-3617-419E-8BA9-A3F0F9F3AFD1@brooknet.com.au> <20060609043808.GA42333@what-creek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: FreeBSD-current installer ISO with DTrace (was: Re: DTrace for FreeBSD- source snapshots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 04:53:42 -0000 On Fri, Jun 09, 2006 at 02:43:14PM +1000, Sam Lawrance wrote: > > On 09/06/2006, at 2:38 PM, John Birrell wrote: > > >On Fri, Jun 09, 2006 at 02:29:25PM +1000, Sam Lawrance wrote: > >>Fixit# kldload dtrace systrace profile fbt > > > >kldload cyclic dtrace systrace profile fbt > > > >The 'dtrace' module depends on 'cyclic'. > > > >The next update wil have a boot loader menu item to load the modules > >in the right order. > > cyclic was loaded automagically when I tested it. Does that mean you can just: kldload systrace (for example) and cyclic and dtrace get loaded because of the module dependencies? The dependencies are: kernel (built with KDTRACE option) | +-> cyclic | +-> dtrace | +-> systrace | +-> profile | +-> fbttrace : +-> (other providers) -- John Birrell From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 04:57:51 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2E5F16A418 for ; Fri, 9 Jun 2006 04:57:51 +0000 (UTC) (envelope-from boris@brooknet.com.au) Received: from jay.exetel.com.au (jay.exetel.com.au [220.233.0.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id DACF843D70 for ; Fri, 9 Jun 2006 04:57:50 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: (qmail 23032 invoked by uid 507); 9 Jun 2006 14:57:49 +1000 Received: from 180.205.233.220.exetel.com.au (HELO ?192.168.0.157?) (220.233.205.180) by jay.exetel.com.au with SMTP; 9 Jun 2006 14:57:49 +1000 In-Reply-To: <20060609045335.GA42431@what-creek.com> References: <20060608073823.GA34193@what-creek.com> <1903E996-3617-419E-8BA9-A3F0F9F3AFD1@brooknet.com.au> <20060609043808.GA42333@what-creek.com> <20060609045335.GA42431@what-creek.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sam Lawrance Date: Fri, 9 Jun 2006 14:57:38 +1000 To: John Birrell X-Mailer: Apple Mail (2.750) Cc: current@freebsd.org Subject: Re: FreeBSD-current installer ISO with DTrace (was: Re: DTrace for FreeBSD- source snapshots) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 04:57:51 -0000 On 09/06/2006, at 2:53 PM, John Birrell wrote: > On Fri, Jun 09, 2006 at 02:43:14PM +1000, Sam Lawrance wrote: >> >> On 09/06/2006, at 2:38 PM, John Birrell wrote: >> >>> On Fri, Jun 09, 2006 at 02:29:25PM +1000, Sam Lawrance wrote: >>>> Fixit# kldload dtrace systrace profile fbt >>> >>> kldload cyclic dtrace systrace profile fbt >>> >>> The 'dtrace' module depends on 'cyclic'. >>> >>> The next update wil have a boot loader menu item to load the modules >>> in the right order. >> >> cyclic was loaded automagically when I tested it. > > Does that mean you can just: > > kldload systrace > > (for example) > > and cyclic and dtrace get loaded because of the module dependencies? > > The dependencies are: > > kernel (built with KDTRACE option) > | > +-> cyclic > | > +-> dtrace > | > +-> systrace > | > +-> profile > | > +-> fbttrace > : > +-> (other providers) > Heh, yes. I didn't think about that. gis2# kldstat Id Refs Address Size Name 1 4 0xc0400000 788134 kernel 2 1 0xc0b89000 5aaa0 acpi.ko 3 1 0xc398c000 30000 pf.ko gis2# kldload systrace gis2# kldstat Id Refs Address Size Name 1 7 0xc0400000 788134 kernel 2 1 0xc0b89000 5aaa0 acpi.ko 3 1 0xc398c000 30000 pf.ko 10 1 0xc3c39000 6000 systrace.ko 11 1 0xc3f00000 26000 dtrace.ko 12 1 0xc3c49000 4000 cyclic.ko gis2# From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 06:53:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7048916A41A; Fri, 9 Jun 2006 06:53:26 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr16.xs4all.nl (smtp-vbr16.xs4all.nl [194.109.24.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CD6043D78; Fri, 9 Jun 2006 06:53:25 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr16.xs4all.nl (8.13.6/8.13.6) with ESMTP id k596rCDD005120; Fri, 9 Jun 2006 08:53:20 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.6/8.13.3) with ESMTP id k596rCVl004346; Fri, 9 Jun 2006 08:53:12 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.6/8.13.6/Submit) id k596rBCX004345; Fri, 9 Jun 2006 08:53:11 +0200 (CEST) (envelope-from wb) Date: Fri, 9 Jun 2006 08:53:11 +0200 From: Wilko Bulte To: "Daniel O'Connor" Message-ID: <20060609065311.GB4251@freebie.xs4all.nl> References: <20060608132048.GD86198@garage.freebsd.pl> <20060608174113.GC1075@roadrunner.q.local> <200606091215.41787.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200606091215.41787.doconnor@gsoft.com.au> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: Data authentication for geli(8) committed to HEAD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 06:53:26 -0000 On Fri, Jun 09, 2006 at 12:15:33PM +0930, Daniel O'Connor wrote.. > On Friday 09 June 2006 03:11, Ulrich Spoerlein wrote: > > I have an external HDD that I initially attached via Firewire, but I've > > since switched to USB, as our firewire subsystem is less than rock > > Interesting. I find the reverse :) > Then again I started using Firewire in 4.x where USB2.0 didn't exist and the > USB 1 code was kind of dodgy. > > > The question really is, are 512 byte disk writes considered to be some > > kind of "atomic" as it is the smallest disk block size? What does the > > ATA subsystem do with writes of 4096? Are they completed atomically too, > > or not? > > I think that in reality with a modern high capacity disk you don't get atomic > writes at all because they all re-write whole tracks. > > Yes this violates the assumption soft updates makes, I believe the only way > around it is to buy SCSI drives (not because they're SCSI per se, but because > they're smaller capacity so they don't do this) Don't tell my 300GB SCSI disks (at work) that they are 'small'. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 07:01:15 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8B5B16A41A; Fri, 9 Jun 2006 07:01:15 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0962043D73; Fri, 9 Jun 2006 07:01:14 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr5.xs4all.nl (8.13.6/8.13.6) with ESMTP id k5970uH0094381; Fri, 9 Jun 2006 09:00:56 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.6/8.13.3) with ESMTP id k5970uGV004468; Fri, 9 Jun 2006 09:00:56 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.6/8.13.6/Submit) id k5970uv8004467; Fri, 9 Jun 2006 09:00:56 +0200 (CEST) (envelope-from wb) Date: Fri, 9 Jun 2006 09:00:56 +0200 From: Wilko Bulte To: Rink Springer Message-ID: <20060609070056.GA4435@freebie.xs4all.nl> References: <20060608132048.GD86198@garage.freebsd.pl> <20060608174113.GC1075@roadrunner.q.local> <200606091215.41787.doconnor@gsoft.com.au> <20060609065311.GB4251@freebie.xs4all.nl> <20060609065706.GA42376@rink.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060609065706.GA42376@rink.nu> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@FreeBSD.ORG, Pawel Jakub Dawidek Subject: Re: Data authentication for geli(8) committed to HEAD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 07:01:15 -0000 On Fri, Jun 09, 2006 at 08:57:07AM +0200, Rink Springer wrote.. > > Don't tell my 300GB SCSI disks (at work) that they are 'small'. > > I'd expect them to be 3.5" just like every other disk... Is that small > enough for you? ;-) For me it is. For SAS SFF drives I have sofar not seen > 72GB, but that does not mean much. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 08:33:52 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0E6516A41A for ; Fri, 9 Jun 2006 08:33:52 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id C102343D73 for ; Fri, 9 Jun 2006 08:33:51 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id DE8FB51388; Fri, 9 Jun 2006 10:33:48 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id E153E51307 for ; Fri, 9 Jun 2006 10:33:39 +0200 (CEST) Date: Fri, 9 Jun 2006 10:31:21 +0200 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20060609083121.GA95774@garage.freebsd.pl> References: <20060608132048.GD86198@garage.freebsd.pl> <20060608174113.GC1075@roadrunner.q.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <20060608174113.GC1075@roadrunner.q.local> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Subject: Re: Data authentication for geli(8) committed to HEAD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 08:33:52 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 08, 2006 at 07:41:13PM +0200, Ulrich Spoerlein wrote: +> Pawel Jakub Dawidek wrote: +> > One of the main design goals was to make it reliable and resistant to +> > power failures or system crashes. This was very important to commit bo= th +> > data update and HMAC update as an atomic operation to the disk, so use= rs +> > don't have to fight with false positives. +>=20 +> Great stuff. I take this opportunity to hijack this thread and ask I +> question that has been bothering me a long time now. +>=20 +> I have an external HDD that I initially attached via Firewire, but I've +> since switched to USB, as our firewire subsystem is less than rock +> solid. When configuring geli encryption on the drive, I made the folly +> of using 4kB sectors, as this should improve performance. But, it has a +> disastrous impact on data integrity if your system crashes. +>=20 +> Now, I don't know if I'm right with the following thoughts, so please +> correct me if I'm wrong. +>=20 +> Consider an mtime or atime update. You need to update 4 bytes on the +> disk, which will be accomplished by writes of 512 bytes. If the system +> crashes in between (I'm not talking about power failures), the disk has +> either updated the 512 bytes, or not. No harm done. +>=20 +> With 4096 byte sectors and unencrypted data, the hard disk will have +> written/updated 512 or 1024, ... or the whole 4096 bytes. Since only 4 +> bytes needed to be changed, you either got these changes or not. No harm +> done. +>=20 +> Now consider encryption with 4096 byte sectors. Whenever you twiddle one +> bit, the whole 4096 byte sector changes completely. To leave the disk in +> a consistent state, you always have to make sure, that the whole 8 +> 512-byte blocks are written to disk. If only a single 512-byte block is +> not updated (due to kernel crashing because of that !@#^#$@ firewire), +> the whole 4096 are useless. SoL. +>=20 +> The question really is, are 512 byte disk writes considered to be some +> kind of "atomic" as it is the smallest disk block size? What does the +> ATA subsystem do with writes of 4096? Are they completed atomically too, +> or not? +>=20 +> Due to various kernel panics (no power failures involved!) I lost +> several blocks of inodes on a 4096 byte sector geli mount. It's really +> no fun, if fsck tells you that inodes 102340 - 109329 are lost. +>=20 +> Please note that I'm not asking any action from you, I'd simply +> appreciated it, if someone could confirm or dispute my claims. Thanks. Unfortunately, you're right. This is because how CBC chaining works. When you specify to use larger sector size, geli(8) will generate one IV for every 4kB of data and will encrypt the whole 4kB together. If geli(8) will only have chance to encrypt first 512 bytes and those 512 have changed, the following 3584 bytes will not be readable. I should mention it in the manual page for sure. When geli(8) is used with authentication there is no such problem, because every single 512-bytes sector has its own IV. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEiTHZForvXbEpPzQRAhzyAKCX4XsVVWMJxTfDnr5Ec/74ivGmoQCfcM2N ZWNYbkw16IV0XKbNj77nMrQ= =ln5H -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 08:46:59 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CBAB16A418 for ; Fri, 9 Jun 2006 08:46:59 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 516F843D70 for ; Fri, 9 Jun 2006 08:46:59 +0000 (GMT) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 1BD0678C1D; Fri, 9 Jun 2006 08:46:57 +0000 (GMT) Date: Fri, 9 Jun 2006 08:46:57 +0000 From: John Birrell To: current@freebsd.org Message-ID: <20060609084656.GA43591@what-creek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Loader forth X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 08:46:59 -0000 Gobbldy-gook! Yuk. I need help. All I want to do is add another menu option that will do the equivalent of: cyclic_load="YES" dtrace_load="YES" etc and then boot. Adding the menu option was simple. But it seems that the loader code does the module loading *before* the menu is displayed and simply doing the setenvs when the key press is detected is too late -- they get ignored. Doing the setenv and then a boot-conf resets everything to what was read from the config files. Grumble. I see that the acpi implementation cheats and that module gets loaded from the C-code. Is that because the design of the loader forth doesn't allow this? This is probably really simple for a forth programmer. Which I'm not. Can anyone tell me how to do it? -- John Birrell From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 09:57:33 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2645016A41B; Fri, 9 Jun 2006 09:57:33 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC9A643D73; Fri, 9 Jun 2006 09:57:32 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp6-g19.free.fr (Postfix) with ESMTP id 1A4FC22591; Fri, 9 Jun 2006 11:57:31 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 3D1359C3F4; Fri, 9 Jun 2006 09:57:51 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 28B04405B; Fri, 9 Jun 2006 11:57:51 +0200 (CEST) Date: Fri, 9 Jun 2006 11:57:51 +0200 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org, freebsd-security@FreeBSD.org Message-ID: <20060609095751.GI1273@obiwan.tataz.chchile.org> References: <20060526153422.GB25953@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060526153422.GB25953@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.11 Cc: Subject: Re: [fbsd] Integrating ProPolice/SSP into FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 09:57:33 -0000 Hi list, I haven't got much feedback so far. I would be glad if any people who have been using this patch told be if they have been faced with some problems. Thank you Regards, Jeremie On Fri, May 26, 2006 at 05:34:22PM +0200, Jeremie Le Hen wrote: > Hi, > > first sorry for cross-posting but I thought this patch might interest > -CURRENT users as well as people concerned by security. > > I wrote a patch that integrates ProPolice/SSP into FreeBSD, one step > further than it has been realized so far. > > It is available here : > http://tataz.chchile.org/~tataz/FreeBSD/SSP/ > > Everything is explained on the web page, but I will repeat some > informations here. The patchset is splitted in two parts to ease the > review of the patch. The -propolice patch is only the original > ProPolice patch for GCC 3.4.4 applied on FreeBSD source tree. The > -freebsd patch contains the glue I have written to make things neat. > > The patch exists in both for CURRENT and RELENG_6. Both introduce a > new make.conf(5) (and src.conf(5)) knob to enable stack protection > on a per Makefile basis. It if of course possible to compile your > world with it. Please refer to the web page for more informations. > > The patch has been tested and works pretty well. My laptop and my > workstation at work are compiled with SSP : world, kernel and ports, > including X.org. > > I hope you will enjoy it. > Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 09:59:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 139FA16A41B for ; Fri, 9 Jun 2006 09:59:58 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEFCF43D95 for ; Fri, 9 Jun 2006 09:59:29 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail06.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k599xOdH013699 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 9 Jun 2006 19:59:26 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k599xOov019625; Fri, 9 Jun 2006 19:59:24 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k599xNmE019624; Fri, 9 Jun 2006 19:59:23 +1000 (EST) (envelope-from peter) Date: Fri, 9 Jun 2006 19:59:23 +1000 From: Peter Jeremy To: "Daniel O'Connor" Message-ID: <20060609095923.GB739@turion.vk2pj.dyndns.org> References: <20060608132048.GD86198@garage.freebsd.pl> <20060608174113.GC1075@roadrunner.q.local> <200606091215.41787.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3lcZGd9BuhuYXNfi" Content-Disposition: inline In-Reply-To: <200606091215.41787.doconnor@gsoft.com.au> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: Data authentication for geli(8) committed to HEAD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 09:59:58 -0000 --3lcZGd9BuhuYXNfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 2006-Jun-09 12:15:33 +0930, Daniel O'Connor wrote: >I think that in reality with a modern high capacity disk you don't get ato= mic=20 >writes at all because they all re-write whole tracks. AFAIK, this applies to _all_ modern disks, whether they're SATA, PATA or SC= SI. >Yes this violates the assumption soft updates makes, I believe the only wa= y=20 >around it is to buy SCSI drives (not because they're SCSI per se, but beca= use=20 >they're smaller capacity so they don't do this) Not totally. Soft updates requires that the device driver inform the filesystem when a write has been committed to non-volatile media. The device driver can only do this if the underlying device reports this. All SCSI devices do but few ATA devices support tagged queueing so the device driver can only tell that the data has been written to the disk cache, not that the data has been committed. You can work around this (at the cost of reducing write performance by about an order of magnitude) by disabling write caching. --=20 Peter Jeremy --3lcZGd9BuhuYXNfi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEiUZ3/opHv/APuIcRAlDXAJ92h716J2xAq23+Qf7qz2kjY2UMnACffmC0 kikRsuEcBVIehGCqechqXHM= =BdHB -----END PGP SIGNATURE----- --3lcZGd9BuhuYXNfi-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 10:32:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 677F916A419 for ; Fri, 9 Jun 2006 10:32:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id C218643D79 for ; Fri, 9 Jun 2006 10:32:40 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5933F46B06; Fri, 9 Jun 2006 06:32:40 -0400 (EDT) Date: Fri, 9 Jun 2006 11:32:40 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Wilkinson, Alex" In-Reply-To: <20060608234805.GM40068@squash.dsto.defence.gov.au> Message-ID: <20060609113101.W70317@fledge.watson.org> References: <20060606071736.J68996@fledge.watson.org> <20060606073436.GK27880@squash.dsto.defence.gov.au> <20060606090919.U68996@fledge.watson.org> <20060608234805.GM40068@squash.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: libmemstat(3) - Library for monitoring kernel memory use X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 10:32:41 -0000 On Fri, 9 Jun 2006, Wilkinson, Alex wrote: > >>Erm, Robert, where does memtop live ? I can find it in ports nor base > >>system. > > > >memtop is an experimental monitoring tool based on libmemstat, you can > find > >the source here: > > > > http://www.watson.org/~robert/freebsd/libmemstat/ > > > >Possibly something like this could be integrated into systat, but my > >ncurses knowledge is a bit weak, and I've not had a chance to > investigate > >further. As with vmstat, the interpretation of the output requires a > >moderate amount of insight into how the kernel works, so I've been a bit > >reluctant to push it as a debugging tool without some more refinement. > I > >think it would be neat if someone picked it up and did something useful > >with it, though :-). > > I assume this only works with -CURRENT ? It should build and run on 6.1 forwards also, as libmemstat was MFC'd in as part of fixing mbuf allocator statistics on SMP. I'm able to build and run memtop on 6-STABLE dated March 12. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 06:57:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0042E16A4FD; Fri, 9 Jun 2006 06:57:05 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx0.rink.nu (thunderstone.rink.nu [80.112.228.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8408743D77; Fri, 9 Jun 2006 06:57:05 +0000 (GMT) (envelope-from rink@rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx0.rink.nu (Postfix) with ESMTP id E8D8C170BF; Fri, 9 Jun 2006 08:57:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx0.rink.nu ([127.0.0.1]) by localhost (thunderstone.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLTE4QWLY3AJ; Fri, 9 Jun 2006 08:57:07 +0200 (CEST) Received: by mx0.rink.nu (Postfix, from userid 1678) id 11DB3170BD; Fri, 9 Jun 2006 08:57:07 +0200 (CEST) Date: Fri, 9 Jun 2006 08:57:07 +0200 From: Rink Springer To: Wilko Bulte Message-ID: <20060609065706.GA42376@rink.nu> References: <20060608132048.GD86198@garage.freebsd.pl> <20060608174113.GC1075@roadrunner.q.local> <200606091215.41787.doconnor@gsoft.com.au> <20060609065311.GB4251@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060609065311.GB4251@freebie.xs4all.nl> User-Agent: Mutt/1.5.11 X-Mailman-Approved-At: Fri, 09 Jun 2006 11:30:00 +0000 Cc: freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: Data authentication for geli(8) committed to HEAD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 06:57:06 -0000 > Don't tell my 300GB SCSI disks (at work) that they are 'small'. I'd expect them to be 3.5" just like every other disk... Is that small enough for you? ;-) -- Rink P.W. Springer - http://rink.nu "Richter: Tribute? You steal men's souls, and make them your slaves! Dracula: Perhaps the same could be said of all religions." - Castlevania: Symphony of the Night From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 12:24:27 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A7A316A46F; Fri, 9 Jun 2006 12:24:27 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id F342643D72; Fri, 9 Jun 2006 12:24:26 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k59COQ0E072738; Fri, 9 Jun 2006 07:24:26 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <44896883.3070203@centtech.com> Date: Fri, 09 Jun 2006 07:24:35 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.2 (X11/20060506) MIME-Version: 1.0 To: Doug Barton References: <44871F58.4070707@FreeBSD.org> <448777B5.8040100@centtech.com> <44889345.8030800@FreeBSD.org> In-Reply-To: <44889345.8030800@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1523/Fri Jun 9 02:10:10 2006 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org Subject: Re: Problem with nvidia drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 12:24:27 -0000 Doug Barton wrote: > Eric Anderson wrote: >> Doug Barton wrote: >>> With the latest -current and the nvidia drivers, either xorg or wdm dump >>> core on a semi-regular basis. Is this expected? I've already tried >>> disabling >>> witness and invariants in my kernel config. >>> >>> Doug >>> >> >> Try the one from their website, not the one in ports. > > Do you mean the latest version from their web site? I have that installed > through ports (which was recently updated) now. Or do you mean install it > without using ports? I did, however I didn't know the port had recently been updated. >> It gave me better >> stability, but I ended up moving to the nv driver anyhow. You could >> search the lists for my posts to see the trials and tribulations if >> you'd like (if you can't find it, let me know). > > Ok, thanks. Also make sure acpi_video is not loaded. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 14:10:35 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A073316A473 for ; Fri, 9 Jun 2006 14:10:35 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id F106843D70 for ; Fri, 9 Jun 2006 14:10:34 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so1392979ugf for ; Fri, 09 Jun 2006 07:10:30 -0700 (PDT) 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=ubXWQF2mbckOIHcSrA4nwS/egEvuQj9n2A3Ed8sMfLsb2Y0lDV3I/5tnxCGxlhYwiSSjYBN8TyfIBWLsb9+4/fjywDCRHgFe5gRVipnD6D3vNEhosVh5tlGY6KTxO7UsfDJeUXYqI3xmbQZCq9DHKxzM2XoisfEc1t+9NF6aiQM= Received: by 10.78.51.16 with SMTP id y16mr884531huy; Fri, 09 Jun 2006 07:03:17 -0700 (PDT) Received: by 10.78.71.19 with HTTP; Fri, 9 Jun 2006 07:03:17 -0700 (PDT) Message-ID: <84dead720606090703l13f11e15t1ac87b52d6014bf6@mail.gmail.com> Date: Fri, 9 Jun 2006 19:33:17 +0530 From: "Joseph Koshy" To: "Sean McNeil" In-Reply-To: <1149826124.3548.1.camel@triton.mcneil.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1149810690.2642.11.camel@triton.mcneil.com> <84dead720606082015i3631f179v4da9ea76b7e0712@mail.gmail.com> <1149826124.3548.1.camel@triton.mcneil.com> Cc: current@freebsd.org Subject: Re: bugus rc.conf.d locations recently committed to -STABLE? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 14:10:35 -0000 sm> I get what looks like bogus warnings: sm> root: /etc/rc: WARNING: Warning: /etc/rc.conf.d/ntpdate is deprecated, sm> please use /etc/rc/etc/rc.conf.d/ntpdate instead. jk> Which -STABLE? Which architecture? sm> FreeBSD triton.mcneil.com 6.1-STABLE FreeBSD 6.1-STABLE \ sm> #17: Thu Jun 8 13:18:19 PDT 2006 \ sm> root@triton.mcneil.com:/usr/obj/usr/src/sys/TRITON amd64 I updated a system to today's (i.e., Jun 9th) RELENG_6 without problems. FreeBSD slbf 6.1-STABLE FreeBSD 6.1-STABLE #9: \ Fri Jun 9 13:17:51 IST 2006 \ root@slbf:/home/obj/home/src-6x/sys/SLBF amd64 You might want to run `mergemaster` and check whether your /etc is upto-date. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 15:52:40 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4092D16A419 for ; Fri, 9 Jun 2006 15:52:40 +0000 (UTC) (envelope-from cbh-freebsd-current@groups.chrishedley.com) Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78EF943D72 for ; Fri, 9 Jun 2006 15:52:39 +0000 (GMT) (envelope-from cbh-freebsd-current@groups.chrishedley.com) Received: from 53-233.adsl.zetnet.co.uk ([194.247.53.233] helo=mail.chrishedley.com country=GB ident=postmaster*pop3#chrishedley^com) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.218) id 4489993b.730b.3f9 for current@freebsd.org; Fri, 9 Jun 2006 16:52:27 +0100 (envelope-sender ) Received: from localhost (localhost [127.0.0.1]) by mail.chrishedley.com (Postfix) with ESMTP id 99146C57A for ; Fri, 9 Jun 2006 16:52:26 +0100 (BST) X-Virus-Scanned: amavisd-new at chrishedley.com Received: from mail.chrishedley.com ([127.0.0.1]) by localhost (mail.chrishedley.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ua8BHxEPbrXV for ; Fri, 9 Jun 2006 16:52:24 +0100 (BST) Received: from aga.cbhnet (aga.cbhnet [192.168.1.16]) by mail.chrishedley.com (Postfix) with ESMTP id 9CB48C579 for ; Fri, 9 Jun 2006 16:52:24 +0100 (BST) Date: Fri, 9 Jun 2006 16:52:24 +0100 (BST) From: Chris Hedley X-X-Sender: cbh@aga.cbhnet To: current@freebsd.org Message-ID: <20060609163735.D829@aga.cbhnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: aac0: COMMAND 0xffffffffxxxxxxxx TIMEOUT AFTER xx SECONDS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 15:52:40 -0000 I've been receiving this message quite a lot lately if I put my Adaptec 2410SA aac controller under really heavy load. A quick look at the archives suggests that it used to be a problem a couple of years ago, but was apparently fixed. Personally I've had no bother with it until a few months ago when I upgraded my version of -CURRENT, at which point it started misbehaving. The process which seems pretty much guaranteed to cause it aggravation is Hercules, when I use it to IPL VM/370 the aac filesystems hang (and it eventually brings down ahc and fxp too, with complaints that "interrupts may not be functioning") and stays there until I kill off the process or press the reset button. Any ideas what might've changed to make this problem resurface? I'm also wondering if I might not be better off actually replacing the card with something better, or at least something better suited to FreeBSD: with the discs' and controller's write-caching turned off, the 2410SA is s-l-o-w, about 6MB/s for contiguous writes to an array (either RAID-5 or RAID-10) (benchmarked using the admittedly somewhat crude "dd various block sizes to/from a /dev entry" technique), although reads are acceptable at ~50-60MB/s, if not especially earth-shattering. Any suggestions (for something inexpensive! If money were no object I'd've gone for a SCSI-only system), or might I just as well stick with the 2410SA? Cheers, Chris. From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 16:33:48 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A83C716A41A for ; Fri, 9 Jun 2006 16:33:48 +0000 (UTC) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60C2643D70 for ; Fri, 9 Jun 2006 16:33:48 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 1B957F1AF3; Fri, 9 Jun 2006 09:33:48 -0700 (PDT) X-Virus-Scanned: by amavisd-new at mcneil.com Received: from mail.mcneil.com ([127.0.0.1]) by localhost (triton.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qeb17VFFCSv; Fri, 9 Jun 2006 09:33:44 -0700 (PDT) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 56F9AF18C8; Fri, 9 Jun 2006 09:33:44 -0700 (PDT) From: Sean McNeil To: Joseph Koshy In-Reply-To: <84dead720606090703l13f11e15t1ac87b52d6014bf6@mail.gmail.com> References: <1149810690.2642.11.camel@triton.mcneil.com> <84dead720606082015i3631f179v4da9ea76b7e0712@mail.gmail.com> <1149826124.3548.1.camel@triton.mcneil.com> <84dead720606090703l13f11e15t1ac87b52d6014bf6@mail.gmail.com> Content-Type: text/plain Date: Fri, 09 Jun 2006 09:33:43 -0700 Message-Id: <1149870823.1329.0.camel@triton.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 09 Jun 2006 16:52:12 +0000 Cc: current@freebsd.org Subject: Re: bugus rc.conf.d locations recently committed to -STABLE? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 16:33:48 -0000 On Fri, 2006-06-09 at 19:33 +0530, Joseph Koshy wrote: > sm> I get what looks like bogus warnings: > > sm> root: /etc/rc: WARNING: Warning: /etc/rc.conf.d/ntpdate is deprecated, > sm> please use /etc/rc/etc/rc.conf.d/ntpdate instead. > > jk> Which -STABLE? Which architecture? > > sm> FreeBSD triton.mcneil.com 6.1-STABLE FreeBSD 6.1-STABLE \ > sm> #17: Thu Jun 8 13:18:19 PDT 2006 \ > sm> root@triton.mcneil.com:/usr/obj/usr/src/sys/TRITON amd64 > > I updated a system to today's (i.e., Jun 9th) RELENG_6 > without problems. > > FreeBSD slbf 6.1-STABLE FreeBSD 6.1-STABLE #9: \ > Fri Jun 9 13:17:51 IST 2006 \ > root@slbf:/home/obj/home/src-6x/sys/SLBF amd64 > > You might want to run `mergemaster` and check whether > your /etc is upto-date. 1.34.2.13 2006.06.09.10.14.39 flz The recent commit that reverts this changed behavior has fixed the problem for me. Thanks, Sean From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 18:52:08 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50C3A16A41A for ; Fri, 9 Jun 2006 18:52:08 +0000 (UTC) (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 1A02343D70 for ; Fri, 9 Jun 2006 18:52:07 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 87A0B72DA1; Fri, 9 Jun 2006 11:50:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 80DE872D9F; Fri, 9 Jun 2006 11:50:41 -0700 (PDT) Date: Fri, 9 Jun 2006 11:50:41 -0700 (PDT) From: Doug White To: Danny Braniss In-Reply-To: Message-ID: <20060609115016.S60598@carver.gumbysoft.com> References: <447AB34C.4030509@sippysoft.com> <447B5A43.4000707@samsco.org> <447B69EA.20502@sippysoft.com> <20060603174637.M40001@carver.gumbysoft.com> <44823080.9030709@samsco.org> <20060603175920.G40001@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "current@freebsd.org" , Maxim Sobolev Subject: Re: Importing iSCSI target from NetBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 18:52:08 -0000 On Tue, 6 Jun 2006, Danny Braniss wrote: >> I believe Wasabi is shipping that target driver in some of their >> storage-appliance software, so they feel confident about it apparently. > > are you sure it's the same one? I haven't poked around their images, but they do ship software that acts as an iSCSI target. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 19:09:41 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C259F16A418 for ; Fri, 9 Jun 2006 19:09:41 +0000 (UTC) (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 93C2143D70 for ; Fri, 9 Jun 2006 19:09:41 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 3E27E72DA2; Fri, 9 Jun 2006 12:08:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 3BD8A72D9F; Fri, 9 Jun 2006 12:08:15 -0700 (PDT) Date: Fri, 9 Jun 2006 12:08:15 -0700 (PDT) From: Doug White To: Chris Hedley In-Reply-To: <20060609163735.D829@aga.cbhnet> Message-ID: <20060609120159.I60598@carver.gumbysoft.com> References: <20060609163735.D829@aga.cbhnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: aac0: COMMAND 0xffffffffxxxxxxxx TIMEOUT AFTER xx SECONDS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 19:09:41 -0000 On Fri, 9 Jun 2006, Chris Hedley wrote: > I've been receiving this message quite a lot lately if I put my Adaptec > 2410SA aac controller under really heavy load. A quick look at the archives > suggests that it used to be a problem a couple of years ago, but was > apparently fixed. Personally I've had no bother with it until a few months > ago when I upgraded my version of -CURRENT, at which point it started > misbehaving. I assume you've checked cabling and termination? Frequently, driver updates can improve performance which means less tolerance for marginal configurations. > I'm also wondering if I might not be better off actually replacing the card > with something better, or at least something better suited to FreeBSD: with > the discs' and controller's write-caching turned off, the 2410SA is s-l-o-w, > about 6MB/s for contiguous writes to an array (either RAID-5 or RAID-10) > (benchmarked using the admittedly somewhat crude "dd various block sizes > to/from a /dev entry" technique), although reads are acceptable at > ~50-60MB/s, if not especially earth-shattering. Any suggestions (for > something inexpensive! If money were no object I'd've gone for a SCSI-only > system), or might I just as well stick with the 2410SA? 6MB/s sounds like you aren't getting any help from the card's write cache; its having to do stripe reads to recalculate parity instead of doing full stripe writes. Many cards disable write-back cache if the battery module isn't present -- make sure you have one and its working. /dev accesses also use physio so you don't get any benefit from write combining in the filesystem layer. Also, in general, hardware RAID beats PCI RAID, hands down. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 19:33:20 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 826B716A41A for ; Fri, 9 Jun 2006 19:33:20 +0000 (UTC) (envelope-from cbh-freebsd-current@groups.chrishedley.com) Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6427D43D98 for ; Fri, 9 Jun 2006 19:33:11 +0000 (GMT) (envelope-from cbh-freebsd-current@groups.chrishedley.com) Received: from 53-233.adsl.zetnet.co.uk ([194.247.53.233] helo=mail.chrishedley.com country=GB ident=postmaster*pop3^chrishedley&com) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.219) id 4489ccf5.67c0.1df for current@freebsd.org; Fri, 9 Jun 2006 20:33:09 +0100 (envelope-sender ) Received: from localhost (localhost [127.0.0.1]) by mail.chrishedley.com (Postfix) with ESMTP id C5AC2CCAF; Fri, 9 Jun 2006 20:33:07 +0100 (BST) X-Virus-Scanned: amavisd-new at chrishedley.com Received: from mail.chrishedley.com ([127.0.0.1]) by localhost (mail.chrishedley.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06JTeXRj72dK; Fri, 9 Jun 2006 20:33:05 +0100 (BST) Received: from aga.cbhnet (aga.cbhnet [192.168.1.16]) by mail.chrishedley.com (Postfix) with ESMTP id C962ECCAE; Fri, 9 Jun 2006 20:33:05 +0100 (BST) Date: Fri, 9 Jun 2006 20:33:07 +0100 (BST) From: Chris Hedley X-X-Sender: cbh@aga.cbhnet To: Doug White In-Reply-To: <20060609120159.I60598@carver.gumbysoft.com> Message-ID: <20060609202536.Y829@aga.cbhnet> References: <20060609163735.D829@aga.cbhnet> <20060609120159.I60598@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: aac0: COMMAND 0xffffffffxxxxxxxx TIMEOUT AFTER xx SECONDS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 19:33:20 -0000 On Fri, 9 Jun 2006, Doug White wrote: > On Fri, 9 Jun 2006, Chris Hedley wrote: >> I've been receiving this message quite a lot lately if I put my Adaptec >> 2410SA aac controller under really heavy load. A quick look at the >> archives suggests that it used to be a problem a couple of years ago, but >> was apparently fixed. Personally I've had no bother with it until a few >> months ago when I upgraded my version of -CURRENT, at which point it >> started misbehaving. > > I assume you've checked cabling and termination? Frequently, driver updates > can improve performance which means less tolerance for marginal > configurations. The 2410SA uses SATA discs (I was trying to get SCSI performance on the cheap, ever the optimist!) so I'm assuming that the cables are okay. At least there's no user-breakable termination settings for me to worry about... >> I'm also wondering if I might not be better off actually replacing the card >> with something better, or at least something better suited to FreeBSD: with >> the discs' and controller's write-caching turned off, the 2410SA is >> s-l-o-w, about 6MB/s for contiguous writes to an array (either RAID-5 or >> RAID-10) (benchmarked using the admittedly somewhat crude "dd various block >> sizes to/from a /dev entry" technique), although reads are acceptable at >> ~50-60MB/s, if not especially earth-shattering. Any suggestions (for >> something inexpensive! If money were no object I'd've gone for a SCSI-only >> system), or might I just as well stick with the 2410SA? > > 6MB/s sounds like you aren't getting any help from the card's write cache; > its having to do stripe reads to recalculate parity instead of doing full > stripe writes. Many cards disable write-back cache if the battery module > isn't present -- make sure you have one and its working. /dev accesses also > use physio so you don't get any benefit from write combining in the > filesystem layer. I've deliberately turned off write-caching because the 2410SA doesn't support battery-backed memory. I'm not sure if it's really necessary to disable it, but having experienced the odd disc crash in the past I've become a little paranoid about my data... > Also, in general, hardware RAID beats PCI RAID, hands down. In my case, software raid beats it too! I have my "fast discs" attached to an old 3960 controller and mirror them with gmirror, and the write performance is an order of magnitude better than the 2410SA, which tells me that something somewhere must be wrong. I know I shouldn't really expect SCSI performance from SATA discs, but this seems a bit much to me (I also have write-caching turned off on my SCSI discs, but I have enabled tagged queueing). I'm still slightly uncomfortable with the idea of software RAID, but it hasn't lost anything yet, in spite of a few "unplanned outages". Chris. From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 20:50:44 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7594916A554 for ; Fri, 9 Jun 2006 20:50:44 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C332F444B8 for ; Fri, 9 Jun 2006 20:18:50 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([69.15.205.254]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k59KIbTG040331; Fri, 9 Jun 2006 14:18:45 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4489D796.4010202@samsco.org> Date: Fri, 09 Jun 2006 14:18:30 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Hedley References: <20060609163735.D829@aga.cbhnet> <20060609120159.I60598@carver.gumbysoft.com> <20060609202536.Y829@aga.cbhnet> In-Reply-To: <20060609202536.Y829@aga.cbhnet> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.1 required=3.8 tests=SUBJECT_NOVOWEL autolearn=no version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: current@freebsd.org Subject: Re: aac0: COMMAND 0xffffffffxxxxxxxx TIMEOUT AFTER xx SECONDS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 20:50:44 -0000 Chris Hedley wrote: > On Fri, 9 Jun 2006, Doug White wrote: > >> On Fri, 9 Jun 2006, Chris Hedley wrote: >> >>> I've been receiving this message quite a lot lately if I put my >>> Adaptec 2410SA aac controller under really heavy load. A quick look >>> at the archives suggests that it used to be a problem a couple of >>> years ago, but was apparently fixed. Personally I've had no bother >>> with it until a few months ago when I upgraded my version of >>> -CURRENT, at which point it started misbehaving. >> >> >> I assume you've checked cabling and termination? Frequently, driver >> updates can improve performance which means less tolerance for >> marginal configurations. > > > The 2410SA uses SATA discs (I was trying to get SCSI performance on the > cheap, ever the optimist!) so I'm assuming that the cables are okay. At > least there's no user-breakable termination settings for me to worry > about... > >>> I'm also wondering if I might not be better off actually replacing >>> the card with something better, or at least something better suited >>> to FreeBSD: with the discs' and controller's write-caching turned >>> off, the 2410SA is s-l-o-w, about 6MB/s for contiguous writes to an >>> array (either RAID-5 or RAID-10) (benchmarked using the admittedly >>> somewhat crude "dd various block sizes to/from a /dev entry" >>> technique), although reads are acceptable at ~50-60MB/s, if not >>> especially earth-shattering. Any suggestions (for something >>> inexpensive! If money were no object I'd've gone for a SCSI-only >>> system), or might I just as well stick with the 2410SA? >> >> >> 6MB/s sounds like you aren't getting any help from the card's write >> cache; its having to do stripe reads to recalculate parity instead of >> doing full stripe writes. Many cards disable write-back cache if the >> battery module isn't present -- make sure you have one and its >> working. /dev accesses also use physio so you don't get any benefit >> from write combining in the filesystem layer. > > > I've deliberately turned off write-caching because the 2410SA doesn't > support battery-backed memory. I'm not sure if it's really necessary to > disable it, but having experienced the odd disc crash in the past I've > become a little paranoid about my data... > What the battery gives you is consistency of the parity data in the case of power loss. You can have a situation where a block is being modified, and thus the parity also needs to be modified. If the block gets written but not the parity, or the parity gets written but not the block, the stripe will be inconsistent. You won't see this until you have a drive failure and are trying to do a rebuild from teh parity. By that point, it's too late, you'll have silent data corruption due to the inconsistency. For RAID-0, the battery is pointless, and for RAID-1, the battery is nearly pointless; the mirror members will either agree or not, and if they disagree the worst that will happen is that you'll get old data. This is no different than if the OS crashes without flushing out all buffers. Old data is much easier to recover from than corrupt data, which is what you get if the parity is inconsistent. >> Also, in general, hardware RAID beats PCI RAID, hands down. > > > In my case, software raid beats it too! I have my "fast discs" attached > to an old 3960 controller and mirror them with gmirror, and the write > performance is an order of magnitude better than the 2410SA, which tells > me that something somewhere must be wrong. I know I shouldn't really > expect SCSI performance from SATA discs, but this seems a bit much to me > (I also have write-caching turned off on my SCSI discs, but I have > enabled tagged queueing). I'm still slightly uncomfortable with the > idea of software RAID, but it hasn't lost anything yet, in spite of a > few "unplanned outages". Software RAID will almost always be faster for trivial tasks than PCI RAID. What PCI RAID gives you is task offloading from the CPU, and protection while the OS is not running. If your CPU is sitting idle most of the time, then software RAID often is a win. That said, the design of a PCI RAID controller plays a huge role in how it performs. Let's just say that the 2410 design is, um, "low end". There are other cards out there from several vendors, especially the newer generation ones that use PCI-Express and PCI-X, that perform a whole heck of a lot better. I have several cards that beat software RAID by a wide margin, but they are also expensive. Scott From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 20:40:12 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1A3416A477; Fri, 9 Jun 2006 20:40:12 +0000 (UTC) (envelope-from rip@overflow.no) Received: from mail.mailwhiz.net (mail.mailwhiz.net [24.244.141.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id D93F743D7C; Fri, 9 Jun 2006 20:40:09 +0000 (GMT) (envelope-from rip@overflow.no) Message-ID: <4489DCAE.3070005@overflow.no> Date: Fri, 09 Jun 2006 16:40:14 -0400 From: Chris User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Jeremie Le Hen References: <20060526153422.GB25953@obiwan.tataz.chchile.org> <20060609095751.GI1273@obiwan.tataz.chchile.org> In-Reply-To: <20060609095751.GI1273@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 09 Jun 2006 23:21:35 +0000 Cc: freebsd-security@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [fbsd] Integrating ProPolice/SSP into FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 20:40:12 -0000 Jeremie Le Hen wrote: > Hi list, > > I haven't got much feedback so far. I would be glad if any people > who have been using this patch told be if they have been faced with > some problems. > > Thank you > Regards, > Jeremie > > On Fri, May 26, 2006 at 05:34:22PM +0200, Jeremie Le Hen wrote: > >> Hi, >> >> first sorry for cross-posting but I thought this patch might interest >> -CURRENT users as well as people concerned by security. >> >> I wrote a patch that integrates ProPolice/SSP into FreeBSD, one step >> further than it has been realized so far. >> >> It is available here : >> http://tataz.chchile.org/~tataz/FreeBSD/SSP/ >> >> Everything is explained on the web page, but I will repeat some >> informations here. The patchset is splitted in two parts to ease the >> review of the patch. The -propolice patch is only the original >> ProPolice patch for GCC 3.4.4 applied on FreeBSD source tree. The >> -freebsd patch contains the glue I have written to make things neat. >> >> The patch exists in both for CURRENT and RELENG_6. Both introduce a >> new make.conf(5) (and src.conf(5)) knob to enable stack protection >> on a per Makefile basis. It if of course possible to compile your >> world with it. Please refer to the web page for more informations. >> >> The patch has been tested and works pretty well. My laptop and my >> workstation at work are compiled with SSP : world, kernel and ports, >> including X.org. >> >> I hope you will enjoy it. >> Regards, >> I'm using it successfuly with the stackp-gap and the random mmap on 6.1-RELEASE. No problems at all really :) Except that i want a nob for gcc to use the protection by default. We discussed this in another email. I'm also using nomad's 5.4 one of my 5.4-p14 with stack gap and random mmap (slight modication was needed to get it working), which for me has the desired default behaviour. I hope to see this on 6.x too, keep up the good work. - Chris From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 23:30:09 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 070E016A46F; Fri, 9 Jun 2006 23:30:08 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2216843D7E; Fri, 9 Jun 2006 23:30:05 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.pc (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.6/8.13.6/Debian-1) with ESMTP id k59NTbWN002621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Jun 2006 02:29:43 +0300 Received: from gothmog.pc (gothmog [127.0.0.1]) by gothmog.pc (8.13.6/8.13.6) with ESMTP id k59NVmVd088400; Sat, 10 Jun 2006 02:31:49 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.pc (8.13.6/8.13.6/Submit) id k59NVmOw088399; Sat, 10 Jun 2006 02:31:48 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sat, 10 Jun 2006 02:31:48 +0300 From: Giorgos Keramidas To: Chris Message-ID: <20060609233148.GA88285@gothmog.pc> References: <20060526153422.GB25953@obiwan.tataz.chchile.org> <20060609095751.GI1273@obiwan.tataz.chchile.org> <4489DCAE.3070005@overflow.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4489DCAE.3070005@overflow.no> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.096, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 1.30, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-security@freebsd.org, freebsd-current@freebsd.org, Jeremie Le Hen Subject: Re: [fbsd] Integrating ProPolice/SSP into FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 23:30:09 -0000 On 2006-06-09 16:40, Chris wrote: >Jeremie Le Hen wrote: >> On Fri, May 26, 2006 at 05:34:22PM +0200, Jeremie Le Hen wrote: >>> Hi, >>> first sorry for cross-posting but I thought this patch might interest >>> -CURRENT users as well as people concerned by security. >>> >>> I wrote a patch that integrates ProPolice/SSP into FreeBSD, one step >>> further than it has been realized so far. >>> >>> It is available here : >>> http://tataz.chchile.org/~tataz/FreeBSD/SSP/ >> >> Hi list, >> I haven't got much feedback so far. I would be glad if any people >> who have been using this patch told be if they have been faced with >> some problems. >[...] > I'm using it successfuly with the stackp-gap and the random mmap > on 6.1-RELEASE. No problems at all really :) Except that i want a nob > for gcc to use the protection by default. We discussed this in another > email. You can always use `/etc/make.conf' to set it globally, right? From owner-freebsd-current@FreeBSD.ORG Fri Jun 9 23:51:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9059016A418 for ; Fri, 9 Jun 2006 23:51:07 +0000 (UTC) (envelope-from tarc@tarc.po.cs.msu.su) Received: from tarc.po.cs.msu.su (tarc.po.cs.msu.su [158.250.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id D559043D70 for ; Fri, 9 Jun 2006 23:51:06 +0000 (GMT) (envelope-from tarc@tarc.po.cs.msu.su) Received: from tarc.po.cs.msu.su (localhost [127.0.0.1]) by tarc.po.cs.msu.su (8.13.4/8.13.4) with ESMTP id k59Nqnm9039806 for ; Sat, 10 Jun 2006 03:52:49 +0400 (MSD) (envelope-from tarc@tarc.po.cs.msu.su) Received: (from tarc@localhost) by tarc.po.cs.msu.su (8.13.4/8.13.4/Submit) id k59Nqldk039805 for freebsd-current@freebsd.org; Sat, 10 Jun 2006 03:52:47 +0400 (MSD) (envelope-from tarc) Date: Sat, 10 Jun 2006 03:52:47 +0400 From: Tarc To: freebsd-current Message-ID: <20060609235246.GA48940@tarc.po.cs.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: mutt-ng/devel-r581 (FreeBSD) Subject: compat6x port X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 23:51:07 -0000 When will this port be released?! -- Best regards, Arseny Nasokin From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 00:04:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8704016A479 for ; Sat, 10 Jun 2006 00:04:24 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BD9843D80 for ; Sat, 10 Jun 2006 00:04:21 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k5A04G4G023733; Fri, 9 Jun 2006 20:04:17 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060609233148.GA88285@gothmog.pc> References: <20060526153422.GB25953@obiwan.tataz.chchile.org> <20060609095751.GI1273@obiwan.tataz.chchile.org> <4489DCAE.3070005@overflow.no> <20060609233148.GA88285@gothmog.pc> Date: Fri, 9 Jun 2006 20:04:15 -0400 To: Giorgos Keramidas , Chris From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.3 Cc: freebsd-current@freebsd.org Subject: Re: [fbsd] Integrating ProPolice/SSP into FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 00:04:24 -0000 At 2:31 AM +0300 6/10/06, Giorgos Keramidas wrote: >On 2006-06-09 16:40, Chris wrote: > > > I'm using it successfuly with the stackp-gap and the random > > mmap on 6.1-RELEASE. No problems at all really :) Except > > that I want a nob for gcc to use the protection by default. > > We discussed this in another email. > >You can always use `/etc/make.conf' to set it globally, right? Not quite globally. That will only set it for programs whose makefiles .include /usr/share/mk/sys.mk . That's all of buildworld, but it wouldn't include programs that people are building on their own. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 00:16:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 518DE16A473 for ; Sat, 10 Jun 2006 00:16:57 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 716A843D70 for ; Sat, 10 Jun 2006 00:16:56 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.pc (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.6/8.13.6/Debian-1) with ESMTP id k5A0Gdxa004315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Jun 2006 03:16:43 +0300 Received: from gothmog.pc (gothmog [127.0.0.1]) by gothmog.pc (8.13.6/8.13.6) with ESMTP id k5A0IoZC089562; Sat, 10 Jun 2006 03:18:51 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.pc (8.13.6/8.13.6/Submit) id k5A0Ioim089561; Sat, 10 Jun 2006 03:18:50 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sat, 10 Jun 2006 03:18:50 +0300 From: Giorgos Keramidas To: Garance A Drosihn Message-ID: <20060610001850.GA89531@gothmog.pc> References: <20060526153422.GB25953@obiwan.tataz.chchile.org> <20060609095751.GI1273@obiwan.tataz.chchile.org> <4489DCAE.3070005@overflow.no> <20060609233148.GA88285@gothmog.pc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.116, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 1.28, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: Chris , freebsd-current@freebsd.org Subject: Re: [fbsd] Integrating ProPolice/SSP into FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 00:16:57 -0000 On 2006-06-09 20:04, Garance A Drosihn wrote: >At 2:31 AM +0300 6/10/06, Giorgos Keramidas wrote: >>On 2006-06-09 16:40, Chris wrote: >>> I'm using it successfuly with the stackp-gap and the random mmap >>> on 6.1-RELEASE. No problems at all really :) Except that I want a >>> nob for gcc to use the protection by default. We discussed this >>> in another email. >> >> You can always use `/etc/make.conf' to set it globally, right? > > Not quite globally. That will only set it for programs whose > makefiles .include /usr/share/mk/sys.mk . That's all of buildworld, > but it wouldn't include programs that people are building on their > own. Precisely. I used 'globally' as an implicit reference to buildworld, so thanks for the clarification :) From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 00:30:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C7AB16A418 for ; Sat, 10 Jun 2006 00:30:46 +0000 (UTC) (envelope-from rip@overflow.no) Received: from mail.mailwhiz.net (mail.mailwhiz.net [24.244.141.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16E8A43D70 for ; Sat, 10 Jun 2006 00:30:45 +0000 (GMT) (envelope-from rip@overflow.no) Message-ID: <448A12BB.3040401@overflow.no> Date: Fri, 09 Jun 2006 20:30:51 -0400 From: Chris User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Garance A Drosihn References: <20060526153422.GB25953@obiwan.tataz.chchile.org> <20060609095751.GI1273@obiwan.tataz.chchile.org> <4489DCAE.3070005@overflow.no> <20060609233148.GA88285@gothmog.pc> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 10 Jun 2006 02:29:46 +0000 Cc: Giorgos Keramidas , freebsd-current@freebsd.org Subject: Re: [fbsd] Integrating ProPolice/SSP into FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 00:30:46 -0000 Garance A Drosihn wrote: > At 2:31 AM +0300 6/10/06, Giorgos Keramidas wrote: >> On 2006-06-09 16:40, Chris wrote: >> >> > I'm using it successfuly with the stackp-gap and the random >> > mmap on 6.1-RELEASE. No problems at all really :) Except >> > that I want a nob for gcc to use the protection by default. >> > We discussed this in another email. >> >> You can always use `/etc/make.conf' to set it globally, right? > For the system itself, yes, but as the below text also says: not for customs built programs. > Not quite globally. That will only set it for programs > whose makefiles .include /usr/share/mk/sys.mk . That's > all of buildworld, but it wouldn't include programs that > people are building on their own. > Exactly :) This is however the default on the 4.x and 5.x patches as opposed to the 6.x and 7.x which has slight modified behaviour. I think Jeremie did this to make it as little intrusive as possible, which was a good thought, although I would like the option to make it very intrusive :) -Chris From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 02:06:46 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BFB216A41B for ; Sat, 10 Jun 2006 02:06:46 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A66143D73 for ; Sat, 10 Jun 2006 02:06:44 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so653982nfe for ; Fri, 09 Jun 2006 19:06:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=BJclid+J+YejtMbk9TOi78tQjBtuBuYUSO2Dy+MFVwWIwTtXCyomwN7ZciraK7A0WYyjiXm+YVofF0IdWqQUUOVwsu5E2ot4TEEcrpHrT6GzJd2AoFOurK1r2o8hS2QiMoaB0ZJoccViZHBSFQKwdxK4QyZYLz1NjA8E1x6rYVw= Received: by 10.49.78.6 with SMTP id f6mr2894865nfl; Fri, 09 Jun 2006 19:06:42 -0700 (PDT) Received: by 10.48.30.10 with HTTP; Fri, 9 Jun 2006 19:06:42 -0700 (PDT) Message-ID: <6eb82e0606091906j7d9f69aarcf1f9738c7565677@mail.gmail.com> Date: Fri, 9 Jun 2006 22:06:42 -0400 From: "Rong-en Fan" To: stable@freebsd.org, current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Sat, 10 Jun 2006 02:30:07 +0000 Cc: peter@freebsd.org Subject: Updating ncurses in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 02:06:46 -0000 Hi, [I'm also CC'ed peter@ since he is the maintainer of ncurses in base] As you may know, the current ncurses in the base system is rather old (it is 4 years old). I have been working on updating ncurses to the latest version 5.5 and enable wide character as default. I have put the description, goal, issues, current status, and tarball for test at the following URL: http://www.rafan.org/FreeBSD/ncurses/ I use the updated ncurses on my 7-CURRENT for sometime, everything works well. As I note in that page, there are some issues related to building framework of libncurses and related libraries. I hope there are some experienced people here can show me which way is most likely to be included in the base system. In addition to those issues, I hope some of you can test it and feedback. I really would like to see ncurses in base is updated in the near future. Regards, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 02:38:54 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11E9F16A41A; Sat, 10 Jun 2006 02:38:54 +0000 (UTC) (envelope-from rivers@dignus.com) Received: from dignus.com (client196-2.dsl.intrex.net [209.42.196.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79F1243D72; Sat, 10 Jun 2006 02:38:53 +0000 (GMT) (envelope-from rivers@dignus.com) Received: from lakes.dignus.com (lakes.dignus.com [10.1.0.3]) by dignus.com (8.13.1/8.12.9) with ESMTP id k5A2Wl52097110; Fri, 9 Jun 2006 22:32:47 -0400 (EDT) (envelope-from rivers@dignus.com) Received: (from rivers@localhost) by lakes.dignus.com (8.11.6/8.11.3) id k5A2f7556191; Fri, 9 Jun 2006 22:41:07 -0400 (EDT) (envelope-from rivers) Date: Fri, 9 Jun 2006 22:41:07 -0400 (EDT) From: Thomas David Rivers Message-Id: <200606100241.k5A2f7556191@lakes.dignus.com> To: current@freebsd.org, grafan@gmail.com, stable@freebsd.org In-Reply-To: <6eb82e0606091906j7d9f69aarcf1f9738c7565677@mail.gmail.com> X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on office.dignus.com X-Mailman-Approved-At: Sat, 10 Jun 2006 02:51:31 +0000 Cc: peter@freebsd.org Subject: Re: Updating ncurses in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 02:38:54 -0000 Unfortunately, I won't be able to test the newer curses anytime soon... But - I did report some years ago that c3270 doesn't build with the current ncurses because of a name clash. If someone gets a chance, it might be a good idea to test that port with the newer ncurses. - Thanks - - Dave Rivers - > Hi, > > [I'm also CC'ed peter@ since he is the maintainer of ncurses in base] > > As you may know, the current ncurses in the base system is rather old > (it is 4 years old). I have been working on updating ncurses to the latest > version 5.5 and enable wide character as default. I have put the description, > goal, issues, current status, and tarball for test at the following URL: From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 05:55:09 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 827AF16A418 for ; Sat, 10 Jun 2006 05:55:09 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37D7A43D70 for ; Sat, 10 Jun 2006 05:55:09 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 198F51A3C20; Fri, 9 Jun 2006 22:55:09 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C0B50516B8; Sat, 10 Jun 2006 01:55:07 -0400 (EDT) Date: Sat, 10 Jun 2006 01:55:07 -0400 From: Kris Kennaway To: Tarc Message-ID: <20060610055507.GA17226@xor.obsecurity.org> References: <20060609235246.GA48940@tarc.po.cs.msu.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <20060609235246.GA48940@tarc.po.cs.msu.su> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current Subject: Re: compat6x port X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 05:55:09 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jun 10, 2006 at 03:52:47AM +0400, Tarc wrote: > When will this port be released?! Some time after someone writes it. Perhaps you could do the work?! Kris --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEil66Wry0BWjoQKURAgwkAJ9bIFdYIO87PxPsHUgcD9/u2TXoOACg1vin xmbTYfHOLaCtQ9FiZSXkyBQ= =Pran -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 06:20:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89F6A16A46F for ; Sat, 10 Jun 2006 06:20:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2100043D73 for ; Sat, 10 Jun 2006 06:20:12 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k5A6HVcG062739; Sat, 10 Jun 2006 00:17:31 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 10 Jun 2006 00:17:41 -0600 (MDT) Message-Id: <20060610.001741.1021577364.imp@bsdimp.com> To: drosih@rpi.edu From: "M. Warner Losh" In-Reply-To: References: <4489DCAE.3070005@overflow.no> <20060609233148.GA88285@gothmog.pc> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: keramida@ceid.upatras.gr, rip@overflow.no, freebsd-current@freebsd.org Subject: Re: [fbsd] Integrating ProPolice/SSP into FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 06:20:12 -0000 In message: Garance A Drosihn writes: : At 2:31 AM +0300 6/10/06, Giorgos Keramidas wrote: : >On 2006-06-09 16:40, Chris wrote: : > : > > I'm using it successfuly with the stackp-gap and the random : > > mmap on 6.1-RELEASE. No problems at all really :) Except : > > that I want a nob for gcc to use the protection by default. : > > We discussed this in another email. : > : >You can always use `/etc/make.conf' to set it globally, right? : : Not quite globally. That will only set it for programs : whose makefiles .include /usr/share/mk/sys.mk . That's : all of buildworld, but it wouldn't include programs that : people are building on their own. Actually, all invocationso of make use /usr/share/mk/sys.mk. It is global. And therefore /etc/make.conf is included for all Makefiles in the system (except when one uses gmake :-). Warner From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 06:25:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 800A916A41B for ; Sat, 10 Jun 2006 06:25:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 232A043D70 for ; Sat, 10 Jun 2006 06:25:52 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k5A6PIa3062808; Sat, 10 Jun 2006 00:25:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 10 Jun 2006 00:25:28 -0600 (MDT) Message-Id: <20060610.002528.-457443946.imp@bsdimp.com> To: rip@overflow.no From: "M. Warner Losh" In-Reply-To: <448A12BB.3040401@overflow.no> References: <20060609233148.GA88285@gothmog.pc> <448A12BB.3040401@overflow.no> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: keramida@ceid.upatras.gr, freebsd-current@freebsd.org, drosih@rpi.edu Subject: Re: [fbsd] Integrating ProPolice/SSP into FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 06:25:52 -0000 In message: <448A12BB.3040401@overflow.no> Chris writes: : Garance A Drosihn wrote: : > At 2:31 AM +0300 6/10/06, Giorgos Keramidas wrote: : >> On 2006-06-09 16:40, Chris wrote: : >> : >> > I'm using it successfuly with the stackp-gap and the random : >> > mmap on 6.1-RELEASE. No problems at all really :) Except : >> > that I want a nob for gcc to use the protection by default. : >> > We discussed this in another email. : >> : >> You can always use `/etc/make.conf' to set it globally, right? : > : For the system itself, yes, but as the below text also says: not for : customs built programs. : > Not quite globally. That will only set it for programs : > whose makefiles .include /usr/share/mk/sys.mk . That's : > all of buildworld, but it wouldn't include programs that : > people are building on their own. : > : : Exactly :) This is however the default on the 4.x and 5.x patches as : opposed to the 6.x and 7.x which has slight modified behaviour. : I think Jeremie did this to make it as little intrusive as possible, : which was a good thought, although I would like the option to make it : very intrusive :) -current includes /usr/share/mk/sys.mk, which brings in /etc/make.conf. The src.conf is only used for buildworld, and only in -current. This has been the behavior back to sometime in the 2.x timeframe... All the WITH/WITHOUT stuff hasn't been MFC'd. Warner From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 06:52:11 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 103B216A418 for ; Sat, 10 Jun 2006 06:52:11 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D6AF43D78 for ; Sat, 10 Jun 2006 06:52:09 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 17A9433C93; Sat, 10 Jun 2006 08:52:06 +0200 (SAST) Date: Sat, 10 Jun 2006 08:52:06 +0200 From: John Hay To: Kris Kennaway Message-ID: <20060610065206.GA14916@zibbi.meraka.csir.co.za> References: <20060609235246.GA48940@tarc.po.cs.msu.su> <20060610055507.GA17226@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060610055507.GA17226@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Cc: Tarc , freebsd-current Subject: Re: compat6x port X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 06:52:11 -0000 On Sat, Jun 10, 2006 at 01:55:07AM -0400, Kris Kennaway wrote: > On Sat, Jun 10, 2006 at 03:52:47AM +0400, Tarc wrote: > > When will this port be released?! > > Some time after someone writes it. Perhaps you could do the work?! But can a useable compat6 be built without first bumping the libpthread version in -current? I don't think so. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 16:34:39 2006 Return-Path: X-Original-To: freebsd-current@mx1.freebsd.org Delivered-To: freebsd-current@mx1.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D75A616A5E5 for ; Sat, 10 Jun 2006 16:34:39 +0000 (UTC) (envelope-from ggajic@tesla.rcub.bg.ac.yu) Received: from tesla.rcub.bg.ac.yu (tesla.rcub.bg.ac.yu [147.91.1.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C67849ABA for ; Sat, 10 Jun 2006 15:35:01 +0000 (GMT) (envelope-from ggajic@tesla.rcub.bg.ac.yu) Received: by tesla.rcub.bg.ac.yu (Postfix, from userid 2055) id D6F812409B; Sat, 10 Jun 2006 12:08:48 +0200 (CEST), Found to be clean Received: from localhost (localhost [127.0.0.1]) by tesla.rcub.bg.ac.yu (Postfix) with ESMTP id D3F6B24093; Sat, 10 Jun 2006 12:08:48 +0200 (CEST) Date: Sat, 10 Jun 2006 12:08:48 +0200 (CEST) From: Goran Gajic To: Yar Tikhiy In-Reply-To: <20060608110046.GD69869@comp.chem.msu.su> Message-ID: References: <20060608110046.GD69869@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sat, 10 Jun 2006 16:43:41 +0000 Cc: freebsd-current@mx1.freebsd.org Subject: Re: 7.0-CURRENT panics if scroll lock is pressed during boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 16:34:39 -0000 On Thu, 8 Jun 2006, Yar Tikhiy wrote: > It might be another issue in kbdmux, as keyboard not working in the > debugger apparently is. You can try hitting Scroll Lock with kbdmux > disabled in device.hints or not compiled into the kernel in order > to see if it's the case. Should the system still panic, you'll at > least have the keyboard working in the debugger. You were right: when I have disabled kbdmux in /boot/device.hints scroll lock hitting is no longer causing panics and I have noticed that scroll lock, caps lock and pause/break LEDs are working again. For some reason after cvsup at the end of May LEDs stopped working.. Regrads, gg. From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 17:48:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5559A16A41A for ; Sat, 10 Jun 2006 17:48:07 +0000 (UTC) (envelope-from yoichi@FreeBSD.org) Received: from alcoholic.geiin.org (59x87x89x234.ap59.ftth.ucom.ne.jp [59.87.89.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE2CA4828C for ; Sat, 10 Jun 2006 17:44:37 +0000 (GMT) (envelope-from yoichi@FreeBSD.org) Received: from localhost.geiin.org (localhost [127.0.0.1]) by alcoholic.geiin.org (Postfix) with ESMTP id 1D2A221CC3E for ; Sun, 11 Jun 2006 02:44:38 +0900 (JST) Date: Sun, 11 Jun 2006 02:44:36 +0900 Message-ID: <87mzckaosb.wl%yoichi@FreeBSD.org> From: Yoichi Nakayama To: freebsd-current@freebsd.org User-Agent: Wanderlust/2.15.3 (Almost Unreal) EMIKO/1.14.1 (Choanoflagellata) FLIM/1.14.8 (=?ISO-2022-JP?B?GyRCO00+chsoQg==?=) APEL/10.6 Emacs/22.0.50 (i686-pc-linux-gnu) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) Organization: Geiin.org X-Face: wLZki+KbGjgKe0,<&3g*rA|R**vj[a8L%[v]ecJh1L(Uqm|LBx; v7Nq7n%?0d.aS]F#[~C\!{m?m,C&#U5}$_pZvBR>5VmX1Ol0`P\M-U8`sUF<5Quj'z&zzW8r|Zl9#W7Wut3duYzpKrP{n+AbarKtJ!i"Al7]P; -?[=iBZa*]r=>C':0~JECx]IH+RXq=/hUX}MB9e]oQKBxsDd/ X-SKK: Daredevil SKK/13.0.90 (Hattori) MIME-Version: 1.0 (generated by EMIKO 1.14.1 - "Choanoflagellata") Content-Type: text/plain; charset=US-ASCII Subject: shared libarary not placed in /lib X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 17:48:07 -0000 Hi, I've updated FreeBSD from 6.1R to current and noticed that libutil.so.6 needed by getty, etc is not placed in /lib but in /usr/lib, and startup failed. # Then I booted the machine in single user mode and copied # libutil.so.6 from /usr/lib. I found "make -n install" in src/lib/libutil shows install -s -o root -g wheel -m 444 libutil.so.6 /usr/lib on current. The line "SHLIBDIR?= /lib" in Makefile have no effect? Best regards, -- Yoichi NAKAYAMA From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 17:48:08 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25FE616A479; Sat, 10 Jun 2006 17:48:08 +0000 (UTC) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7CDB48376; Sat, 10 Jun 2006 17:45:27 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (ppp-71-139-110-14.dsl.snfc21.pacbell.net [71.139.110.14]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id k5AHjQqL014504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Jun 2006 10:45:26 -0700 Message-ID: <448B04D0.1040302@root.org> Date: Sat, 10 Jun 2006 10:43:44 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org Subject: resume changes, please test X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 17:48:08 -0000 I've committed some overall minor changes to the resume assembly code as a result of a code review. Please test to be sure nothing was broken, and perhaps something got improved along the way. Now there is also a tunable/sysctl "debug.acpi.resume_beep". Setting it to 1 will beep the pc speaker very early in resume so we can figure out if hangs on resume are a driver or acpi problem. -- Nate From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 18:08:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF8C716A6B8; Sat, 10 Jun 2006 18:08:20 +0000 (UTC) (envelope-from yoichi@FreeBSD.org) Received: from alcoholic.geiin.org (59x87x89x234.ap59.ftth.ucom.ne.jp [59.87.89.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2243343D99; Sat, 10 Jun 2006 18:08:20 +0000 (GMT) (envelope-from yoichi@FreeBSD.org) Received: from localhost.geiin.org (localhost [127.0.0.1]) by alcoholic.geiin.org (Postfix) with ESMTP id D0A64154341; Sun, 11 Jun 2006 03:08:20 +0900 (JST) Date: Sun, 11 Jun 2006 03:08:19 +0900 Message-ID: <87lks4anos.wl%yoichi@FreeBSD.org> From: Yoichi Nakayama To: freebsd-current@freebsd.org,delphij@FreeBSD.org In-Reply-To: <87mzckaosb.wl%yoichi@FreeBSD.org> References: <87mzckaosb.wl%yoichi@FreeBSD.org> User-Agent: Wanderlust/2.15.3 (Almost Unreal) EMIKO/1.14.1 (Choanoflagellata) FLIM/1.14.8 (=?ISO-2022-JP?B?GyRCO00+chsoQg==?=) APEL/10.6 Emacs/22.0.50 (i686-pc-linux-gnu) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) Organization: Geiin.org X-Face: wLZki+KbGjgKe0,<&3g*rA|R**vj[a8L%[v]ecJh1L(Uqm|LBx; v7Nq7n%?0d.aS]F#[~C\!{m?m,C&#U5}$_pZvBR>5VmX1Ol0`P\M-U8`sUF<5Quj'z&zzW8r|Zl9#W7Wut3duYzpKrP{n+AbarKtJ!i"Al7]P; -?[=iBZa*]r=>C':0~JECx]IH+RXq=/hUX}MB9e]oQKBxsDd/ X-SKK: Daredevil SKK/13.0.90 (Hattori) MIME-Version: 1.0 (generated by EMIKO 1.14.1 - "Choanoflagellata") Content-Type: text/plain; charset=US-ASCII Cc: Subject: Re: shared libarary not placed in /lib X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 18:08:20 -0000 At Sun, 11 Jun 2006 02:44:36 +0900, Yoichi Nakayama wrote: > I've updated FreeBSD from 6.1R to current and noticed that > libutil.so.6 needed by getty, etc is not placed in /lib > but in /usr/lib, and startup failed. > # Then I booted the machine in single user mode and copied > # libutil.so.6 from /usr/lib. > > I found "make -n install" in src/lib/libutil shows > install -s -o root -g wheel -m 444 libutil.so.6 /usr/lib > on current. The line "SHLIBDIR?= /lib" in Makefile have no effect? I found src/lib/libutil/Makefile rev 1.61 changes the behavior. Including bsd.own.mk did define SHLIBDIR before "SHLIBDIR?= /lib". Regards, -- Yoichi NAKAYAMA From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 18:37:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 155AB16A53E for ; Sat, 10 Jun 2006 18:37:10 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd5mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4216477D6 for ; Sat, 10 Jun 2006 12:54:25 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd2mr1so.prod.shaw.ca (pd2mr1so-qfe3.prod.shaw.ca [10.0.141.110]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0N006F1AIPK280@l-daemon> for freebsd-current@freebsd.org; Sat, 10 Jun 2006 06:54:25 -0600 (MDT) Received: from pn2ml6so.prod.shaw.ca ([10.0.121.150]) by pd2mr1so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0J0N00EFAAIP62A0@pd2mr1so.prod.shaw.ca> for freebsd-current@freebsd.org; Sat, 10 Jun 2006 06:54:25 -0600 (MDT) Received: from hexahedron.daemonology.net ([24.82.18.31]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with SMTP id <0J0N00ATBAIOPCD0@l-daemon> for freebsd-current@freebsd.org; Sat, 10 Jun 2006 06:54:25 -0600 (MDT) Received: (qmail 52843 invoked from network); Sat, 10 Jun 2006 12:54:24 +0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; Sat, 10 Jun 2006 12:54:24 +0000 Date: Sat, 10 Jun 2006 05:54:23 -0700 From: Colin Percival To: FreeBSD Current Message-id: <448AC0FF.5060804@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Enigmail-Version: 0.94.0.0 User-Agent: Thunderbird 1.5 (X11/20060416) Subject: /usr/obj and releases X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 18:37:10 -0000 In src/etc/mtree/BSD.usr.dist, it says that /usr/obj should exist: 41 obj nochange However, in src/release/Makefile, the doTARBALL specifically avoids putting /usr/obj into a tarball, with the result that it will not be extracted during release installation: 1114 tar --exclude CVS --exclude obj --exclude BOOTMFS -cf - ${ARG} | \ ^^^^^^^^^^^^^ This discrepancy has existed since March 1995, so I'm guessing that it isn't a mistake -- but can someone explain the reason for this? Colin Percival From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 19:28:49 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C63D16B1A3 for ; Sat, 10 Jun 2006 19:28:49 +0000 (UTC) (envelope-from tarc@tarc.po.cs.msu.su) Received: from tarc.po.cs.msu.su (tarc.po.cs.msu.su [158.250.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D3C048AF0 for ; Sat, 10 Jun 2006 14:21:34 +0000 (GMT) (envelope-from tarc@tarc.po.cs.msu.su) Received: from tarc.po.cs.msu.su (localhost [127.0.0.1]) by tarc.po.cs.msu.su (8.13.4/8.13.4) with ESMTP id k5AENMlR082986 for ; Sat, 10 Jun 2006 18:23:22 +0400 (MSD) (envelope-from tarc@tarc.po.cs.msu.su) Received: (from tarc@localhost) by tarc.po.cs.msu.su (8.13.4/8.13.4/Submit) id k5ADgfOe082851 for freebsd-current@freebsd.org; Sat, 10 Jun 2006 17:42:41 +0400 (MSD) (envelope-from tarc) Resent-From: Tarc Resent-Date: Sat, 10 Jun 2006 17:42:41 +0400 Resent-Message-ID: <20060610134241.GA79921@tarc.po.cs.msu.su> Resent-To: freebsd-current Date: Sat, 10 Jun 2006 17:14:19 +0400 From: Tarc To: freebsd-current Message-ID: <20060610131419.GB48940@tarc.po.cs.msu.su> References: <20060609235246.GA48940@tarc.po.cs.msu.su> <20060610055507.GA17226@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20060610055507.GA17226@xor.obsecurity.org> User-Agent: mutt-ng/devel-r581 (FreeBSD) Subject: Re: compat6x port X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 19:28:49 -0000 > > When will this port be released?! > > Some time after someone writes it. Perhaps you could do the work?! > > Kris Ok, It's seems simple. Which libraries needed? -- Best regards, Arseny Nasokin From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 20:34:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB48F16A64C for ; Sat, 10 Jun 2006 20:34:12 +0000 (UTC) (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 D91FB47AB8 for ; Sat, 10 Jun 2006 13:20:58 +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.6/8.13.6/NETPLEX) with ESMTP id k5ADKuUE028366; Sat, 10 Jun 2006 09:20:57 -0400 (EDT) Date: Sat, 10 Jun 2006 09:20:56 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Hay In-Reply-To: <20060610065206.GA14916@zibbi.meraka.csir.co.za> Message-ID: References: <20060609235246.GA48940@tarc.po.cs.msu.su> <20060610055507.GA17226@xor.obsecurity.org> <20060610065206.GA14916@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Tarc , freebsd-current , Kris Kennaway Subject: Re: compat6x port X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 20:34:13 -0000 On Sat, 10 Jun 2006, John Hay wrote: > On Sat, Jun 10, 2006 at 01:55:07AM -0400, Kris Kennaway wrote: >> On Sat, Jun 10, 2006 at 03:52:47AM +0400, Tarc wrote: >>> When will this port be released?! >> >> Some time after someone writes it. Perhaps you could do the work?! > > But can a useable compat6 be built without first bumping the libpthread > version in -current? I don't think so. It isn't as easy as that. All libraries need to have their version bumped. -- DE From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 20:36:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 808A616B38E; Sat, 10 Jun 2006 20:36:32 +0000 (UTC) (envelope-from tarc@tarc.po.cs.msu.su) Received: from tarc.po.cs.msu.su (tarc.po.cs.msu.su [158.250.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id E58A549C42; Sat, 10 Jun 2006 15:48:01 +0000 (GMT) (envelope-from tarc@tarc.po.cs.msu.su) Received: from tarc.po.cs.msu.su (localhost [127.0.0.1]) by tarc.po.cs.msu.su (8.13.4/8.13.4) with ESMTP id k5AFnqHe078722; Sat, 10 Jun 2006 19:49:52 +0400 (MSD) (envelope-from tarc@tarc.po.cs.msu.su) Received: (from tarc@localhost) by tarc.po.cs.msu.su (8.13.4/8.13.4/Submit) id k5AFnqDC078721; Sat, 10 Jun 2006 19:49:52 +0400 (MSD) (envelope-from tarc) Date: Sat, 10 Jun 2006 19:49:51 +0400 From: Tarc To: Daniel Eischen Message-ID: <20060610154951.GC48940@tarc.po.cs.msu.su> References: <20060609235246.GA48940@tarc.po.cs.msu.su> <20060610055507.GA17226@xor.obsecurity.org> <20060610065206.GA14916@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: mutt-ng/devel-r581 (FreeBSD) Cc: John Hay , freebsd-current , Kris Kennaway Subject: Re: compat6x port X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 20:36:32 -0000 On Sat, Jun 10, 2006 at 09:20:56AM -0400, Daniel Eischen wrote: > On Sat, 10 Jun 2006, John Hay wrote: > > >On Sat, Jun 10, 2006 at 01:55:07AM -0400, Kris Kennaway wrote: > >>On Sat, Jun 10, 2006 at 03:52:47AM +0400, Tarc wrote: > >>>When will this port be released?! > >> > >>Some time after someone writes it. Perhaps you could do the work?! > > > >But can a useable compat6 be built without first bumping the libpthread > >version in -current? I don't think so. > > It isn't as easy as that. All libraries need to have their > version bumped. > > -- > DE I can mantain this port. Can anyone tell me, what libraries are needed? -- Best regards, Arseny Nasokin From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 20:37:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BA3616A53F for ; Sat, 10 Jun 2006 20:37:24 +0000 (UTC) (envelope-from granted14@yahoo.com) Received: from web55609.mail.re4.yahoo.com (web55609.mail.re4.yahoo.com [206.190.58.233]) by mx1.FreeBSD.org (Postfix) with SMTP id CAD76444F8 for ; Sat, 10 Jun 2006 20:22:42 +0000 (GMT) (envelope-from granted14@yahoo.com) Received: (qmail 33264 invoked by uid 60001); 10 Jun 2006 20:22:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rAy3YOhAz7yyM0if/6epCSf2gwqLLJBp7FWMZKifbTl6NSoUpKiKdautZcMum2+ofcVwUQC6C3G7VMSMzAUY4BCUkgzoBf8JESckN7MjaLyGJ8YVLses8WE5lfyarC99NxDcmgnwtj4FbCko8zD6DY8xaRnSTWREwTOU3GSoNgs= ; Message-ID: <20060610202242.33262.qmail@web55609.mail.re4.yahoo.com> Received: from [70.83.250.146] by web55609.mail.re4.yahoo.com via HTTP; Sat, 10 Jun 2006 16:22:42 EDT Date: Sat, 10 Jun 2006 16:22:42 -0400 (EDT) From: Etienne Robillard To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: sam@freebsd.org, brooks@freebsd.org Subject: dhclient on 7-CURRENT refuse to cooperate (no DHCPOFFER) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 20:37:24 -0000 I upgraded to a one-week old 7-CURRENT (HEAD) on a i386 type system and it seems like the OpenBSD dhclient app wont work for me... It worked a while, but for some reasons, its impossible to get a lease. The symptoms are: - DHCPDISCOVER... - DHCPDISCOVER... and thats pretty much it. It doesnt pass that point, and thus is can't proceed with DHCPOFFER nor with DHCPPACK... Also, I tried running /sbin/dhclient from the OpenBSD cd, and it works! So, it looks to me that somehow there's something wrong here, but its really hard to make any further diagnosis. The value of ``kern.osreldate`` is: 700017. Whether there's a patch or a work-around it would be really great to know how to apply--please let me know :-) Thanks, Etienne -- Etienne Robillard JID: incidah AT njs.netlab.cz YMS/MSN: granted14 AT yahoo.com TEL: +1 514.962.7703 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 21:05:50 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B15316A597 for ; Sat, 10 Jun 2006 21:05:50 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from mx6.mail.ru (mx6.mail.ru [194.67.23.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57B56445F9 for ; Sat, 10 Jun 2006 20:51:00 +0000 (GMT) (envelope-from vadim_nuclight@mail.ru) Received: from [82.211.136.13] (port=24231 helo=nuclight.avtf.net) by mx6.mail.ru with esmtp id 1FpAPw-000AbI-00 for freebsd-current@freebsd.org; Sun, 11 Jun 2006 00:50:53 +0400 Organization: AVTF TPU Hostel To: "freebsd-current@freebsd.org" Message-ID: Date: Sun, 11 Jun 2006 03:50:28 +0700 From: "Vadim Goncharov" Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit User-Agent: Opera M2/7.54 (Win32, build 3865) Subject: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 21:05:50 -0000 Hello All! I wrote new netgraph(4) node, called ng_tag, able to match packets by their mbuf_tags(9) and assign new tags to mbufs. This can be used for many things in the kernel network subsystem, but particularly useful with recently added ipfw(8) tag/tagged functionality (will be MFCed to RELENG_6 after Jun 24). With this node, in conjunction with ng_bpf(4), I was able to match and block (perhaps shaping is also possible, but this relies solely on ipfw) DirectConnect P2P data connections traffic - you know, they're using random ports, so you can't match them with usual firewall rules and must check data payload contents of the packets. See man page for example of how to do this. Download files from here: http://antigreen.org/vadim/freebsd/ng_tag/ Then do: make kldload ./ng_tag.ko Man page can be viewed as: cat ng_tag.4 | /usr/bin/tbl | /usr/bin/groff -S -Wall -mtty-char -man \ -Tascii | /usr/bin/col | more -s Please especially test tags with non-zero tag_len, if you can (though it's not needed for ipfw). P.S. BTW, what is correct subject prefix for new contributions? I think [PATCH] is not correct as these are new files, not patch :) -- WBR, Vadim Goncharov From owner-freebsd-current@FreeBSD.ORG Sat Jun 10 23:24:36 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78E1316A41A for ; Sat, 10 Jun 2006 23:24:36 +0000 (UTC) (envelope-from mbsd@pacbell.net) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C73D43D46 for ; Sat, 10 Jun 2006 23:24:35 +0000 (GMT) (envelope-from mbsd@pacbell.net) Received: from pimout7-ext.prodigy.net (pimout7-int.prodigy.net [207.115.4.147]) by ylpvm15.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id k5ANOjEq030590 for ; Sat, 10 Jun 2006 19:24:45 -0400 X-ORBL: [71.139.19.160] DomainKey-Signature: a=rsa-sha1; s=sbc01; d=pacbell.net; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=ROGtoLr8COMA1oThxPGuVWleWASxNUF8/G/nHKvvJ0kpkcALPb8rE3SithYuTcTyZ 8g9BvtnEec2XNjl74zOog== Received: from spirou.home (ppp-71-139-19-160.dsl.snfc21.pacbell.net [71.139.19.160]) by pimout7-ext.prodigy.net (8.13.6 out.dk/8.13.6) with ESMTP id k5ANOXpv152142; Sat, 10 Jun 2006 19:24:34 -0400 Date: Sat, 10 Jun 2006 16:24:24 -0700 (PDT) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= X-X-Sender: mikko@spirou.home To: Ulrich Spoerlein In-Reply-To: <20060607195303.GA3225@roadrunner.q.local> Message-ID: <20060610161947.I1026@spirou.home> References: <20060607195303.GA3225@roadrunner.q.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: [PATCH] Call for bfe(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 23:24:36 -0000 On Wed, 7 Jun 2006, Ulrich Spoerlein wrote: > Hi, > > I investigated a bug/missing feature in the bfe(4) driver, which makes > it not see any LINK DOWN events unless you happen to invoke ifconfig. > > If you are running bfe hardware, *please* test the following (NO > PATCHING OR REBOOTING REQUIRED) > > 1. Plug in ethernet cable > 2. Watch dmesg/syslogd for the LINK UP message > 3. Remove the cable > 4. Do you see a LINK DOWN message? Does it appear after you issue > 'ifconfig'? > > Please run these simple steps and report back to me, if you get the LINK > DOWN message or not and which hardware you are running. For reference, > mine is a BCM4401, card=0x81271028 chip=0x440114e4 rev=0x01. No link notifications until I run "ifconfig". bfe0@pci2:5:0: class=0x020000 card=0x018d1028 chip=0x170c14e4 rev=0x02 hdr=0x00 > If you want to give the patch a try, you are of course encouraged to do > so. With the patch, I get LINK UP/DOWN messages. Thanks, /Mikko